C'est quand même pas mal, Linux, Í  cÍ´té de Windows, c'est même plutÍ´t mieux.

Le 08/07/2022 Í  21:47, Stéphane CARPENTIER a écrit :

Le 07-07-2022, Matthieu <matthieu@x.localhost> a écrit :

Le 07.07.2022 Í  11:49 François a écrit:

Le 06/07/2022 Í  09:11, Matthieu a écrit :

J'en arrive parfois Í  regretter
l'ancien temps - sous DOS, tout était bien plus simple!

Les triturations du config.sys et de l'autoexec.bat, avec le système
qui ne redémarre pas en cas d'erreur

F5/F8 permettait assez simplement d'identifier le problème.

Ce n'est pas vraiment différent de ce qu'on a aujourd'hui - si on se
loupe lors d'une mise Í  jour kernel ou bêtement dans une configuration
grub, on se retrouve aussi avec un PC qui ne démarre plus et qu'il faut
réanimer avec quelques incantations ésotériques.

LÍ , c'était pas une mise Í  jour Windows qui posait problème, c'était
l'achat d'un nouveau jeu qui imposait les mises Í  jour du boot du dos
pour que les drivers soient lancés dans le bon ordre. Ça n'avait rien de
simple.

Bonjour Í  toutes et tous,

A vrai dire je suis abasourdi par ce que je li.
Un système d'exploitation t'offre une interface d'accès Í  des services
suffisamment sophistiqués pour te permettre de faire tourner une
application même complexe.

Et lÍ  je li qu'il faut changer le boot du système pour faire tourner une
application ?

C'est le grand retour vers les premières versions de Windows qui
n'étaient pas un système, mais un ensemble de bibliothèques partageant
entre autre le même espace mémoire. Bill Gates c'est fait prendre Í  son
propre jeu en présentant une de ces versions qu'il a publiquement
montrer se planter et être face Í  un écran bleu...

La notion de système avec un espace de mémoire différentié entre les
services systèmes et les applications est apparue avec Windows 95.
Mais le gestion mémoire était-elle vraiment virtuelle ???
Sur ce point j'ai des doutes.
Il a fallu qu'un ingénieur Français, Louis Pouzin, très engagé, même
précurseur avec Cyclades, dans les réseaux et le systèmes Multics,
spécialisé dans les systèmes d'exploitation, lance le projet SOL (1980)
Í  l'INRIA avec Í  sa direction Michel Gien un Ingénieur du CNET comme
Louis Pouzin. C'est ce projet Pilote qui a formé les premiers
spécialistes du système Unix en France.

Alors, vous pouvez vous poser la question, "mais qu'est qu'il nous veux
ce vieux con ?"

Bonne question.
C'est quand même pas mal, Linux, Í  cÍ´té de Windows, c'est même plutÍ´t
mieux."

Ce thread a dérivé comme d'habitude vers des discussions exemptes de
sens. Il y aura toujours des aficionados de windows et d'autre d'un
système compatible Í  Posix comme le noyau Linux. L'environnement de base
provenant de la FSF (Free Software Fondation).

Car de base c'est en effet cet ensemble qui fait un système complet
pouvant gérer un matériel informatique.
Ensuite pour les utilisateurs qui ont besoin d'une métaphore de
"bureau", il reste un chois entre KDE-plasma et gnome.
Les autres logiciels comme xfce, MATE, Puis vers les plus légés : LXDE,
très beau mais pas pratique : Enlightenment,
LXQT, Cinnamon.


Personnellement j'utilise KDE/plasma. Il est bien intégré avec la
gestion du fenêtrage du serveur X et donne aisément accès aux
fonctionnalités de la présentation Í  l'utilisateur du système de base.



Ce thread ayant comme sujet : "C'est quand même pas mal, Linux, Í  cÍ´té
de Windows, c'est même plutÍ´t mieux."

--
Pierre Léonard https://www.le-refuge.org/

www.leonard.nom.fr https://www.sidaction.org/

Le 08/07/2022 Í  18:54, Christophe PEREZ a écrit :

Le Thu, 7 Jul 2022 11:49:14 +0200,
François <nafnaf.29@laposte.net.invalid> a écrit :

Les triturations du config.sys et de l'autoexec.bat, avec le système
qui ne redémarre pas en cas d'erreur, les lanceurs et les menus Í 
faire Í  la main, un pilote d'imprimante pour chaque programme, du
moins quand l'éditeur dudit programme avait prévu un pilote pour ton
imprimante.

Tu oublies le fait de taper dans la base de registres pour "corriger"
bugs et autres défauts.
Et tellement d'autres choses inconsistantes...

Je parlais de MS-DOS. La BdR et les autres joyeusetés sont venues plus
tard, avec le progrès.

--
Faͱch

Le Sat, 9 Jul 2022 21:10:05 +0200,
François <nafnaf.29@laposte.net.invalid> a écrit :

Le 08/07/2022 Í  18:54, Christophe PEREZ a écrit :
> Le Thu, 7 Jul 2022 11:49:14 +0200,
> François <nafnaf.29@laposte.net.invalid> a écrit :
>
>> les lanceurs et les menus Í  faire Í  la main
>
> Tu oublies le fait de taper dans la base de registres pour
> "corriger" bugs et autres défauts.
> Et tellement d'autres choses inconsistantes...
>
Je parlais de MS-DOS. La BdR et les autres joyeusetés sont venues
plus tard, avec le progrès.

"Les lanceurs et menu", dans MsDOS ?
Alors j'ai vraiment oublié ce que c'était. Pourtant, j'ai baigné dedans.

Le 09-07-2022, Matthieu <matthieu@x.localhost> a écrit :

Le 09.07.2022 Í  08:26 Stéphane CARPENTIER a écrit:

Quand tu as un programme qui fait 1000 lignes de code basé uniquement
sur le langage de base tu n'as pas les mêmes contraintes que pour un
programme qui fait 1000000 de lignes de codes et qui s'appuie sur des
librairies développées par d'autres équipes.

Tu simplifies beaucoup le passé.

Oui, c'est pour montrer que j'illustre et que ça ne doit pas être pris
de façon littérale.

Les programmes DOS ne faisaient pas tous 1000 lignes de codes,

Sans blague ? On ne fait pas grand-chose avec 1000 lignes de code (sauf
avec beaucoup de librairies qui font tout). De même que tous les
programmes actuels ne font pas 1000000 de lignes de code.

il existait également des produits très complexes et aboutis.

Alors deux choses. D'abord, je ne méprise absolument pas les programmes
d'il y a trente ans. Ensuite, je ne méprise absolument pas les
programmeurs d'il y a trente ans.

Mais regarde ce qu'il se fait aujourd'hui, ce n'est pas la même chose
que ce qui se faisait il y a trente ans. Je ne dis pas que c'était plus
facile Í  l'époque, mais que la complexité générale (ie: le programme et
tout son écosystème) a considérablement augmenté. Et les contraintes ont
considérablement changées aussi.

Les programmes actuels sont beaucoup plus complexes que ceux que tu
installais au siècle dernier. Les développeurs ont dÍ» prendre en
compte ces contraintes et tu ne sembles pas le comprendre.

Tu simplifies de nouveau.

LÍ , non. Par programme, je n'entends pas juste le bout de code pondu par
le développeur mais tout l'écosystème qui vient avec. Par complexité, je
ne dis pas que c'est plus dur. Les contraintes de RAM/CPU/Espace disque
ne sont plus aussi fortes que ce qu'elles étaient il y a trente ans.

L'utilisation de librairies dynamiques n'est pas fonction de la
complexité du programme, ni un symptÍ´me de contrainte particulières.
C'est uniquement un choix d'architecture que l'on retrouve
principalement sous Linux et BSD aujourd'hui (avec les quelques
exceptions notables type guix, FlatPak, AppImage, etc), mais pas sous
Windows ou Android par exemple (au-delÍ  des interfaces nativement
fournies avec ces système).

C'est un choix, mais qui est imposé aussi par des contraintes qui ne
sont pas les mêmes qu'il y a trente ans. Quand tu parles du DOS, Í 
l'époque, lorsque tu lançais un programme, il n'y avait que ce programme
qui tournait et rien d'autre. Le programme devait définir toute son
interface graphique. Aujourd'hui, l'utilisateur s'attend Í  une bonne
intégration des programmes dans l'environnement et Í  une certaine
homogénéité. Ça change les contraintes.

Quand tu parles du DOS, le programmeurs devait prendre en compte
chaque carte son. Il n'avait pas de raison de partager ses librairies
ou une partie de son code.

C'est un exemple complètement raté, puisque la vaste majorité des
éditeurs de jeux ne développait pas leurs propres drivers de cartes son.
Ils exploitaient des librairies (généralement commerciales) comme Miles
Sound System, AIL, DigPak, Allegro, etc.

J'ai pas dit qu'ils devaient développer les drivers mais prendre en
compte les cartes son. C'est pas exactement pareil. Une carte son qui
sortait après le jeu pouvait ne pas bien être reconnue par le jeu.

--
Si vous avez du temps Í  perdre :
https://scarpet42.gitlab.io

Le 09-07-2022, Pierre Leonard <pierre@leonard.nom.fr> a écrit :

Et lÍ  je li qu'il faut changer le boot du système pour faire tourner une
application ?

Non. Il dit que c'était plus simple avant avec le DOS, je dis que je ne
suis pas d'accord puisqu'Í  l'époque du DOS, les deux fichiers de conf
étaient écrit en fonction de ce qui était utilisé. À aucun moment je ne
dis que aujourd'hui c'est nécessaire ni même utile.

--
Si vous avez du temps Í  perdre :
https://scarpet42.gitlab.io

Le 10/07/2022 Í  01:47, Christophe PEREZ a écrit :

"Les lanceurs et menu", dans MsDOS ?
Alors j'ai vraiment oublié ce que c'était. Pourtant, j'ai baigné dedans.

Ce n'était pas obligatoire, mais ça simplifiait le lancement des programmes.

Les lanceurs : des fichiers .bat contenant le nom et le chemin du
programme. 1.bat, 2.bat, etc. et retour au menu en sortie du programme.

Le menu : un fichier texte contenant la liste des lanceurs et appelé Í 
partir d'autoexec.bat ou d"un fichier menu.bat

Il suffisait alors de taper le numéro du programme au lieu de son nom

--
Faͱch

Le 10.07.2022 Í  09:11 Stéphane CARPENTIER a écrit:

Le 09-07-2022, Pierre Leonard <pierre@leonard.nom.fr> a écrit :
>
> Et lÍ  je li qu'il faut changer le boot du système pour faire
> tourner une application ?

Non. Il dit que c'était plus simple avant avec le DOS, je dis que je
ne suis pas d'accord puisqu'Í  l'époque du DOS, les deux fichiers de
conf étaient écrit en fonction de ce qui était utilisé.

Il y a malentendu. Il dit que c'était plus simple d'un point de vue
strictement technique, pas nécessairement pour l'utilisateur final en
terme d'ergonomie au quotidien. Et non, il ne voudrait pas revenir Í 
cette époque lointaine, il est juste parfois un petit peu nostalgique
du temps ou un PC avec son système étaient des choses relativement
simple Í  comprendre.

Matthieu

Le 10.07.2022 Í  09:06 Stéphane CARPENTIER a écrit:

C'est un choix, mais qui est imposé aussi par des contraintes qui ne
sont pas les mêmes qu'il y a trente ans.

C'est l͠ o͹ l'argumentation devient discutable, puisque si
l'utilisation de librairies partagées était, comme tu le dis, lié
uniquement au type de technologie, alors aujourd'hui tout le monde
ferait pareil.

Quand tu parles du DOS, Í  l'époque, lorsque tu lançais un programme,
il n'y avait que ce programme qui tournait et rien d'autre.

Cela ne change pas grand chose pour l'aspect "librairie". Certes, ont
peut imaginer que plusieurs programmes en cours utilisent le même
shared object en mémoire, mais Í  l'ère des PC portables avec 64G de RAM
ce n'est pas le partage d'un libz partagé de 100K qui va changer grand
chose...

Sinon pour la parenthèse je dois dire que "il n'y avait que ce
programme qui tournait et rien d'autres" n'est pas complètement vrai,
puisqu'il y avait tout de même les drivers (carte son, réseau...) et
autres TSRs qui restaient tout de même chargés, et qui
s'activaient soit sur appel de leur API, soit continuellement via
l'attachement Í  une interruption périodique (timer RTC sur int 0x08
typiquement, mais pas que). Oui je sais, je radote.

Le programme devait définir toute son interface graphique.
Aujourd'hui, l'utilisateur s'attend Í  une bonne intégration des
programmes dans l'environnement et Í  une certaine homogénéité. Ça
change les contraintes.

Certes, mais on parle ici alors plutÍ´t d'API natives au système (WinAPI
sous Windows, X/GTK/QT/autres sous Linux), pas de librairies externes.

J'ai pas dit qu'ils devaient développer les drivers mais prendre en
compte les cartes son. C'est pas exactement pareil. Une carte son qui
sortait après le jeu pouvait ne pas bien être reconnue par le jeu.

C'est vrai, même si des exceptions existaient (il était par
exemple possible de mettre Í  jour le composant Miles Sound System
utilisé par certains applicatifs), mais en tous les cas ce n'était pas
vraiment un problème de librairie, plutÍ´t un problème de manque d'API
universelle pour le son. D'ailleurs sous Linux ce n'est pas toujours
évident non plus: certains applicatifs utilisent OSS, d'autres ALSA,
PulseAudio, Jack ou autre chose encore... Pas toujours simple de faire
cohabiter tout ce petit monde. Le problème est similaire Í  celui d'il y
a 30 ans sous DOS: si je décide d'implémenter le support de PulseAudio
et Jack dans mon applicatif et que chez l'utilisateur il n'y a que
ALSA... ben c'est pas de chance. Je ne dis évidemment pas que c'est
identique au problème d'antan, mais on peut tout de même tracer
quelques lignes parallèles et l'utilisation ou non de librairies
dynamiques n'y fait pas grand chose. D'ailleurs le problème ne se pose
pas sous Windows, alors que le concept de librairies dynamiques y est
très limité. C'est juste une question de stabilité d'API.

Matthieu

Le 10-07-2022, Matthieu <matthieu@x.localhost> a écrit :

Le 10.07.2022 Í  09:06 Stéphane CARPENTIER a écrit:

C'est un choix, mais qui est imposé aussi par des contraintes qui ne
sont pas les mêmes qu'il y a trente ans.

C'est l͠ o͹ l'argumentation devient discutable, puisque si
l'utilisation de librairies partagées était, comme tu le dis, lié
uniquement au type de technologie, alors aujourd'hui tout le monde
ferait pareil.

Je parle de contraintes qui évoluent. Et tout le monde n'évolue pas au
même rythme. Et tout le monde n'a pas forcément trouvé toutes les
réponses. Et tout le monde ne veut pas faire pareil.

Regarde systemd qui était lÍ  pour remplacer un système de démarrage. Il
y a quelques arguments sérieux contre lui. Mais il y a aussi beaucoup
d'arguments de principe.

Quand tu parles du DOS, Í  l'époque, lorsque tu lançais un programme,
il n'y avait que ce programme qui tournait et rien d'autre.

Cela ne change pas grand chose pour l'aspect "librairie".

Un peu quand même. Parce que les ressources étaient beaucoup plus
limitées qu'aujourd'hui. Alors tu n'installais et ne lançais que ce que
tu étais sÍ»r d'utiliser parce que tu ne pouvais pas tout installer ni
tout lancer.

Certes, ont
peut imaginer que plusieurs programmes en cours utilisent le même
shared object en mémoire, mais Í  l'ère des PC portables avec 64G de RAM
ce n'est pas le partage d'un libz partagé de 100K qui va changer grand
chose...

VoilÍ , il y a des ressources alors on installe tous les drivers de tout
ce qui est disponible pour qu'il n'y ait qu'Í  brancher sans avoir Í  se
poser de questions.

Sinon pour la parenthèse je dois dire que "il n'y avait que ce
programme qui tournait et rien d'autres" n'est pas complètement vrai,
puisqu'il y avait tout de même les drivers (carte son, réseau...) et
autres TSRs qui restaient tout de même chargés, et qui
s'activaient soit sur appel de leur API, soit continuellement via
l'attachement Í  une interruption périodique (timer RTC sur int 0x08
typiquement, mais pas que).

Oui, mais c'est négligeable par rapport Í  ce que fait un système
d'exploitation actuel. De plus, ce n'était lancé que si nécessaire. Tu
ne lançais pas les drivers de ta carte son pour lancer un traitement de
texte ou un tableur, ce n'était que pour les jeux. Et les cartes réseau,
c'était pas vendu sur tous les ordinateurs par défaut, ce n'était
disponible que si nécessaire.

--
Si vous avez du temps Í  perdre :
https://scarpet42.gitlab.io

Le Sun, 10 Jul 2022 12:20:15 +0200,
François <nafnaf.29@laposte.net.invalid> a écrit :

Les lanceurs : des fichiers .bat contenant le nom et le chemin du
programme. 1.bat, 2.bat, etc. et retour au menu en sortie du
programme.

Ah, oui, si tu appelles ça un lanceur...

Le menu : un fichier texte contenant la liste des lanceurs et appelé
Í  partir d'autoexec.bat ou d"un fichier menu.bat

Ah oui, d'accord, j'avoue, c'est un menu...

Vraiment Í  la première lecture, ce n'était pas du tout ce que j'avais
en tête.
Mais j'en conviens, ma mémoire n'est pas remontée assez loin.