C'est quand même pas mal, Linux, Í cÍ´té de Windows, c'est même plutÍ´t mieux.
115 réponses
Ghost-Raider
Mises-Í -jour du jour d'aujourd'hui :
https://www.cjoint.com/doc/22_06/LFCnHsVtgk4_2022-06-28-Mises-%C3%A0-jour.png
MS pourrait en prendre de la graine, avec ses mises-Í -jour désordonnées,
ambiguës, mal commentées, mal traduites et pleines de bugs qui seront
corrigés la prochaine fois et en attendant, on rétrograde Í la
mise-Í -jour précédente, si elle est encore lÍ ....
Pour les copies d'écran aussi d'ailleurs. Celles de mon Mint Cinnamon
sont d'une logique parfaite et d'une simplicité enfantine, alors que
celles de Windows 10 sont mal fichues au possible et s'écrasent les unes
les autres si on ne les renomme pas.
Je sais que je prêche des convaincus mais de simples exemples comme
ceux-ci sont particulièrement édifiants.
--
Courrier envoyé par mon top super extra PC Hardware.fr sous Linux Mint
Cinnamon
Le 07 Jul 2022 09:13:35 GMT, Nicolas George <nicolas$ a écrit :
Les binaires statiques et les packages lourds, c'est aussi la grande joie des développeurs médiocres qui ne savent pas programmer de manière portable,
Tout le problème est lÍ . Il ne fait que défendre ses intérêts partisans en dépit de toute honnêteté intellectuelle.
lire la doc d'une bibliothèque pour utiliser ses fonctionnalités comme documenté plutÍ´t que d'exploiter des coͯncidences, et qui vont se précipiter vers des bibliothèques médiocres et mal ficelées parce qu'ils ne sont pas capables d'implémenter eux-mêmes des fonctionnalités élémentaires.
Pour arriver Í des logiciels qui pèsent des tonnes parce que c'est plus simple et donc plus rentable que de les optimiser. Pourvu que ces développeurs restent Í développer pour windows, et ne s'aventurent jamais Í développer pour Linux (je sais, I have a dream).
Le 07 Jul 2022 09:13:35 GMT,
Nicolas George <nicolas$george@salle-s.org> a écrit :
Les binaires statiques et les packages lourds, c'est aussi la grande
joie des développeurs médiocres qui ne savent pas programmer de
manière portable,
Tout le problème est lÍ . Il ne fait que défendre ses intérêts partisans
en dépit de toute honnêteté intellectuelle.
lire la doc d'une bibliothèque pour utiliser ses
fonctionnalités comme documenté plutÍ´t que d'exploiter des
coͯncidences, et qui vont se précipiter vers des bibliothèques
médiocres et mal ficelées parce qu'ils ne sont pas capables
d'implémenter eux-mêmes des fonctionnalités élémentaires.
Pour arriver Í des logiciels qui pèsent des tonnes parce que c'est plus
simple et donc plus rentable que de les optimiser.
Pourvu que ces développeurs restent Í développer pour windows, et ne
s'aventurent jamais Í développer pour Linux (je sais, I have a dream).
Le 07 Jul 2022 09:13:35 GMT, Nicolas George <nicolas$ a écrit :
Les binaires statiques et les packages lourds, c'est aussi la grande joie des développeurs médiocres qui ne savent pas programmer de manière portable,
Tout le problème est lÍ . Il ne fait que défendre ses intérêts partisans en dépit de toute honnêteté intellectuelle.
lire la doc d'une bibliothèque pour utiliser ses fonctionnalités comme documenté plutÍ´t que d'exploiter des coͯncidences, et qui vont se précipiter vers des bibliothèques médiocres et mal ficelées parce qu'ils ne sont pas capables d'implémenter eux-mêmes des fonctionnalités élémentaires.
Pour arriver Í des logiciels qui pèsent des tonnes parce que c'est plus simple et donc plus rentable que de les optimiser. Pourvu que ces développeurs restent Í développer pour windows, et ne s'aventurent jamais Í développer pour Linux (je sais, I have a dream).
Christophe PEREZ
Le Thu, 7 Jul 2022 11:49:14 +0200, François 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...
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...
Le Thu, 7 Jul 2022 11:49:14 +0200, François 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...
Stéphane CARPENTIER
Le 05-07-2022, william a écrit :
On 2022-07-03, Jo Engo wrote:
Le 02 Jul 2022 21:28:57 GMT, william a écrit :
parapluie / velo et linux / internet ?
Juste que l'on peut très bien utiliser linux sans internet (même y faire des mise Í jour, pourvu qu'on est un support (comme une clé usb et un support internet distant (accessible Í vélo)), mais lÍ ça peut aller trop loin)
Pour avoir utilisé des versions obsolètes de slackware (une époque avec internet trop cher), j'utilisais l'internet de l'école. Et j'ai installé les sources programmes pour "voir" des versions de desktop environment récent. C'etait pas facile de télécharger les dépendances. Alors que pour windows, un simple binaire et il y avait tout dedans.
Moi, quand j'ai installé slackware Í l'époque o͹ je n'avais pas Internet, il y avait tout dans le CD-ROM fournis avec le livre. Il y avait beaucoup plus de trucs que sur un Windows de base (3.11 Í l'époque) -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Le 05-07-2022, william <blop@no.spam> a écrit :
On 2022-07-03, Jo Engo <yl@icite.fr> wrote:
Le 02 Jul 2022 21:28:57 GMT, william a écrit :
parapluie / velo et linux / internet ?
Juste que l'on peut très bien utiliser linux sans internet (même y faire
des mise Í jour, pourvu qu'on est un support (comme une clé usb et un
support internet distant (accessible Í vélo)), mais lÍ ça peut aller trop
loin)
Pour avoir utilisé des versions obsolètes de slackware (une époque avec
internet trop cher), j'utilisais l'internet de l'école. Et j'ai installé
les sources programmes pour "voir" des versions de desktop environment
récent. C'etait pas facile de télécharger les dépendances.
Alors que pour windows, un simple binaire et il y avait tout dedans.
Moi, quand j'ai installé slackware Í l'époque o͹ je n'avais pas
Internet, il y avait tout dans le CD-ROM fournis avec le livre. Il y
avait beaucoup plus de trucs que sur un Windows de base (3.11 Í
l'époque)
--
Si vous avez du temps Í perdre :
https://scarpet42.gitlab.io
Juste que l'on peut très bien utiliser linux sans internet (même y faire des mise Í jour, pourvu qu'on est un support (comme une clé usb et un support internet distant (accessible Í vélo)), mais lÍ ça peut aller trop loin)
Pour avoir utilisé des versions obsolètes de slackware (une époque avec internet trop cher), j'utilisais l'internet de l'école. Et j'ai installé les sources programmes pour "voir" des versions de desktop environment récent. C'etait pas facile de télécharger les dépendances. Alors que pour windows, un simple binaire et il y avait tout dedans.
Moi, quand j'ai installé slackware Í l'époque o͹ je n'avais pas Internet, il y avait tout dans le CD-ROM fournis avec le livre. Il y avait beaucoup plus de trucs que sur un Windows de base (3.11 Í l'époque) -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Stéphane CARPENTIER
Le 06-07-2022, Matthieu a écrit :
C'est possible sous Linux aussi, via des binaires statiques, mais ce n'est pas la règle. Au contraire, les Linuxiens préfèrent gérer des milliers de bibliothèques, y lier dynamiquement les programmes utilisés et gérer les tonnes de dépendances qui en découlent avec les problèmes que cela génèrent parfois (exemple: programme fonctionne bien avec libsdl 2.0.1, mais cesse de fonctionner après upgrade vers libsdl 2.0.2... ou inversement).
Tu devrais regarder du cÍ´té de nixos et guix, il n'y a, par construction, pas de problème de dépendance, de mise Í jour ou autre. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Le 06-07-2022, Matthieu <matthieu@x.localhost> a écrit :
C'est possible sous Linux aussi, via des binaires statiques, mais ce
n'est pas la règle. Au contraire, les Linuxiens préfèrent gérer des
milliers de bibliothèques, y lier dynamiquement les programmes utilisés
et gérer les tonnes de dépendances qui en découlent avec les problèmes
que cela génèrent parfois (exemple: programme fonctionne bien avec
libsdl 2.0.1, mais cesse de fonctionner après upgrade vers libsdl
2.0.2... ou inversement).
Tu devrais regarder du cÍ´té de nixos et guix, il n'y a, par
construction, pas de problème de dépendance, de mise Í jour ou autre.
--
Si vous avez du temps Í perdre :
https://scarpet42.gitlab.io
C'est possible sous Linux aussi, via des binaires statiques, mais ce n'est pas la règle. Au contraire, les Linuxiens préfèrent gérer des milliers de bibliothèques, y lier dynamiquement les programmes utilisés et gérer les tonnes de dépendances qui en découlent avec les problèmes que cela génèrent parfois (exemple: programme fonctionne bien avec libsdl 2.0.1, mais cesse de fonctionner après upgrade vers libsdl 2.0.2... ou inversement).
Tu devrais regarder du cÍ´té de nixos et guix, il n'y a, par construction, pas de problème de dépendance, de mise Í jour ou autre. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Stéphane CARPENTIER
Le 07-07-2022, Matthieu 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. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
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.
--
Si vous avez du temps Í perdre :
https://scarpet42.gitlab.io
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. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Christophe PEREZ
Le 08 Jul 2022 19:32:29 GMT, Stéphane CARPENTIER a écrit :
Moi, quand j'ai installé slackware Í l'époque o͹ je n'avais pas Internet, il y avait tout dans le CD-ROM fournis avec le livre. Il y avait beaucoup plus de trucs que sur un Windows de base (3.11 Í l'époque)
Quand j'ai commencé avec Mandrake (qui est devenue mandriva ensuite), j'avais commandé mes CD sur ikarios. Je crois qu'il y en avait 4 (plusieurs c'est sÍ»r) et sans aucune mesure avec ce que j'ai toujours vu Windows proposer.
Le 08 Jul 2022 19:32:29 GMT,
Stéphane CARPENTIER <sc@fiat-linux.fr> a écrit :
Moi, quand j'ai installé slackware Í l'époque o͹ je n'avais pas
Internet, il y avait tout dans le CD-ROM fournis avec le livre. Il y
avait beaucoup plus de trucs que sur un Windows de base (3.11 Í
l'époque)
Quand j'ai commencé avec Mandrake (qui est devenue mandriva ensuite),
j'avais commandé mes CD sur ikarios. Je crois qu'il y en avait 4
(plusieurs c'est sͻr) et sans aucune mesure avec ce que j'ai toujours
vu Windows proposer.
Le 08 Jul 2022 19:32:29 GMT, Stéphane CARPENTIER a écrit :
Moi, quand j'ai installé slackware Í l'époque o͹ je n'avais pas Internet, il y avait tout dans le CD-ROM fournis avec le livre. Il y avait beaucoup plus de trucs que sur un Windows de base (3.11 Í l'époque)
Quand j'ai commencé avec Mandrake (qui est devenue mandriva ensuite), j'avais commandé mes CD sur ikarios. Je crois qu'il y en avait 4 (plusieurs c'est sÍ»r) et sans aucune mesure avec ce que j'ai toujours vu Windows proposer.
Matthieu
Le 08.07.2022 Í 19:37 Stéphane CARPENTIER a écrit:
Tu devrais regarder du cÍ´té de nixos et guix, il n'y a, par construction, pas de problème de dépendance, de mise Í jour ou autre.
Je connaissais déjÍ guix, mais pas nixos. Le concept semble être le même. À une époque pas si lointaine, "l'installation" d'un programme passait par un mkdir c:program suivi d'un copy a:*.* c:program. L'humanité revient petit Í petit Í la raison, c'est cool. Matthieu
Le 08.07.2022 Í 19:37 Stéphane CARPENTIER a écrit:
Tu devrais regarder du cÍ´té de nixos et guix, il n'y a, par
construction, pas de problème de dépendance, de mise Í jour ou autre.
Je connaissais déjÍ guix, mais pas nixos. Le concept semble être le
même.
À une époque pas si lointaine, "l'installation" d'un programme passait
par un mkdir c:program suivi d'un copy a:*.* c:program.
L'humanité revient petit Í petit Í la raison, c'est cool.
Le 08.07.2022 Í 19:37 Stéphane CARPENTIER a écrit:
Tu devrais regarder du cÍ´té de nixos et guix, il n'y a, par construction, pas de problème de dépendance, de mise Í jour ou autre.
Je connaissais déjÍ guix, mais pas nixos. Le concept semble être le même. À une époque pas si lointaine, "l'installation" d'un programme passait par un mkdir c:program suivi d'un copy a:*.* c:program. L'humanité revient petit Í petit Í la raison, c'est cool. Matthieu
Matthieu
Le 08.07.2022 Í 19:47 Stéphane CARPENTIER a écrit:
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.
Si si, c'était simple. Enfin, simple sur le principe technique - après, le jeu du chat et de la souris pour arriver aux 597K de RAM conventionnelle nécessaires pour satisfaire le programme x ou y tout en gardant le lecteur de CD fonctionnel, c'était une autre paire de manches. MEMMAKER aidait pas mal. C'était une époque différente. Aujourd'hui c'est complètement l'inverse - tout se veut "simple" pour l'utilisateur, mais avec des usines Í gaz sous le capot. On y a gagné Í de nombreux points de vue, mais au prix d'un utilisateur qui est devenu une amibe informatique. Matthieu
Le 08.07.2022 Í 19:47 Stéphane CARPENTIER a écrit:
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.
Si si, c'était simple. Enfin, simple sur le principe technique - après,
le jeu du chat et de la souris pour arriver aux 597K de RAM
conventionnelle nécessaires pour satisfaire le programme x ou y tout en
gardant le lecteur de CD fonctionnel, c'était une autre paire de
manches. MEMMAKER aidait pas mal. C'était une époque différente.
Aujourd'hui c'est complètement l'inverse - tout se veut "simple" pour
l'utilisateur, mais avec des usines Í gaz sous le capot. On y a gagné Í
de nombreux points de vue, mais au prix d'un utilisateur qui est devenu
une amibe informatique.
Le 08.07.2022 Í 19:47 Stéphane CARPENTIER a écrit:
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.
Si si, c'était simple. Enfin, simple sur le principe technique - après, le jeu du chat et de la souris pour arriver aux 597K de RAM conventionnelle nécessaires pour satisfaire le programme x ou y tout en gardant le lecteur de CD fonctionnel, c'était une autre paire de manches. MEMMAKER aidait pas mal. C'était une époque différente. Aujourd'hui c'est complètement l'inverse - tout se veut "simple" pour l'utilisateur, mais avec des usines Í gaz sous le capot. On y a gagné Í de nombreux points de vue, mais au prix d'un utilisateur qui est devenu une amibe informatique. Matthieu
Stéphane CARPENTIER
Le 09-07-2022, Matthieu a écrit :
Le 08.07.2022 Í 19:37 Stéphane CARPENTIER a écrit:
Tu devrais regarder du cÍ´té de nixos et guix, il n'y a, par construction, pas de problème de dépendance, de mise Í jour ou autre.
Je connaissais déjÍ guix, mais pas nixos. Le concept semble être le même.
Oui, le principe est le même puisque guix reconnais s'être inspiré de nixos. Le gros problème de nixos, c'est sa doc.
À une époque pas si lointaine, "l'installation" d'un programme passait par un mkdir c:program suivi d'un copy a:*.* c:program. L'humanité revient petit Í petit Í la raison, c'est cool.
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. 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. 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. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Le 09-07-2022, Matthieu <matthieu@x.localhost> a écrit :
Le 08.07.2022 Í 19:37 Stéphane CARPENTIER a écrit:
Tu devrais regarder du cÍ´té de nixos et guix, il n'y a, par
construction, pas de problème de dépendance, de mise Í jour ou autre.
Je connaissais déjÍ guix, mais pas nixos. Le concept semble être le
même.
Oui, le principe est le même puisque guix reconnais s'être inspiré de
nixos. Le gros problème de nixos, c'est sa doc.
À une époque pas si lointaine, "l'installation" d'un programme passait
par un mkdir c:program suivi d'un copy a:*.* c:program.
L'humanité revient petit Í petit Í la raison, c'est cool.
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.
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.
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.
--
Si vous avez du temps Í perdre :
https://scarpet42.gitlab.io
Le 08.07.2022 Í 19:37 Stéphane CARPENTIER a écrit:
Tu devrais regarder du cÍ´té de nixos et guix, il n'y a, par construction, pas de problème de dépendance, de mise Í jour ou autre.
Je connaissais déjÍ guix, mais pas nixos. Le concept semble être le même.
Oui, le principe est le même puisque guix reconnais s'être inspiré de nixos. Le gros problème de nixos, c'est sa doc.
À une époque pas si lointaine, "l'installation" d'un programme passait par un mkdir c:program suivi d'un copy a:*.* c:program. L'humanité revient petit Í petit Í la raison, c'est cool.
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. 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. 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. -- Si vous avez du temps Í perdre : https://scarpet42.gitlab.io
Matthieu
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é. Les programmes DOS ne faisaient pas tous 1000 lignes de codes, il existait également des produits très complexes et aboutis. Et le concept de librairie existait bien, mais il ne s'agissait pas de librairies dynamiques.
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'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).
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. Matthieu
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é. Les programmes DOS ne faisaient pas
tous 1000 lignes de codes, il existait également des produits très
complexes et aboutis.
Et le concept de librairie existait bien, mais il ne s'agissait pas de
librairies dynamiques.
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'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).
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.
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é. Les programmes DOS ne faisaient pas tous 1000 lignes de codes, il existait également des produits très complexes et aboutis. Et le concept de librairie existait bien, mais il ne s'agissait pas de librairies dynamiques.
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'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).
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. Matthieu
