Des disquettes pour mettre à jour un Boeing 747
Si d’aventure vous devez mettre à jour un Boeing 747, oubliez votre connexion Wi-Fi : contrairement aux appareils d’Apple revus chaque année, cet appareil-là a beaucoup plus de kilomètres au compteur et utilise des technologies autrement moins récentes : de bonnes vieilles disquettes 3,5 pouces. Selon The Register, la firme de sécurité Pen Test Partners a fait cette découverte insolite en inspectant les systèmes à bord d’un Boeing 747-400 qui partait bientôt à la casse1.
Ces disquettes ne mettent pas à jour tout l’avion, bien entendu, mais uniquement les bases de données de navigation. Cette opération doit tout de même être répétée tous les 28 jours, ce qui amuse sans doute beaucoup les ingénieurs des compagnies aériennes. Ces technologies antédiluviennes ont toutefois des avantages de taille dans le domaine de la sécurité : en plus d’être stables et éprouvées, elles diminuent les chances de piratage (c'est aussi le cas à la Nasa, d'ailleurs). Que les disquettes se rassurent, elles sont loin d'avoir pris leur retraite.
-
Faute de quoi la firme n’aurait jamais pu y avoir accès. ↩︎
Elles l’ont pourtant prise (la retraite) ...
@pagaupa :Elles l’ont pourtant prise (la retraite) ...
Il y en a qui ont de la chance de pouvoir la prendre !!!
Ils font comment pour en acheter des disquettes ?
@totoguile
"Ils font comment pour en acheter des disquettes ?"
Je ne crois pas qu’il y a encore des fabricants, mais on en trouve encore plein sur Amazon (cherche “floppy disk” sur amazon us). Il y a encore des stocks mondiaux depuis des annees, ca se compte sur les doigts de la main (ok, juste quelques millions,4-5?). Les industries qui utilisent encore les “floppy disk” en ont accumulé depuis un moment pour voir venir. Genre en banque, on les utilise encore (pour les ATM par example). J’ai encore lu recemment que certains militaires les utilisaient egalement ahah 🤓
@Paquito06
"J’ai encore lu recemment que certains militaires les utilisaient egalement ahah 🤓"
Yep j’ai posté plus loin une news de 2019 sur le retrait du service de disquette 8’’ (Oui 8, pas 5’’1/4, ni 3’’1/2) sur la force de frappe 🤯
@totoguile
"Ils font comment pour en acheter des disquettes ?"
En général quand la fin de vie d’une technologie s’annonce les entreprise font des gros stock.
Le militaire et l’aérospatiale qui contrairement à ce qu’on imagine adorent les technologies éprouvées font par exemple régulièrement des stock de composants électroniques avant leur retrait du marché (Entre autre sur les CPU)
Sur une anecdote plus personnelle en fin de vie des lecteurs 3’’1/2 j’en ai commandé deux en USB et quelques boites de disquettes (au cas où) 🤓
@YetOneOtherGit
"Le militaire et l’aérospatiale qui contrairement à ce qu’on imagine adorent les technologies éprouvées"
Ils détestent surtout les coûts astronomiques pour passer à une technologie éprouvée plus récente et souvent meilleure par ailleurs.
Insert disk 37/95....
Ça doit être passionnant en effet. Pour rappel une disquette c’était 1.44Mo. Donc le Go pour 700 disquettes.
Après il faut dire qu’à l’époque les programmes étaient optimisés. Un très bon jeu c’était 7 voir 10 disquettes 3.5’ ;-))
@julien74
8 disquettes de mémoire pour le jeu Colorado sur Atari STe
Et 1 seule pour BombJack !
@julien74
"Après il faut dire qu’à l’époque les programmes étaient optimisés. Un très bon jeu c’était 7 voir 10 disquettes 3.5’ ;-))"
bof, j'ai vécu cette époque.
Déjà à l'époque, les magazines répétaient le fantasme de "on optimise plus ma pov dame, on est que de la merde"
donc hein, 1.44mo ou +... disquette ou super nvme ssd... même combat dans le fantasme.
-
Wing Commande 2 était fourni sur 7 disquettes, il fallait le décompresser en l'installant, ce qui lui faisait prendre 21Mo sur un disque dur (plus de la moitié de mon disque dur de l'époque, heureusement, windows 3.1 tenait dans moins de 20Mo...)
le jeu était notoirement lent sur i386, le cpu du pc de base, alors que le 486 était nettement bien plus onéreux.
Alors l'optimisation hein...
Chaque époque a son fantasme de cette fameuse "optimisation". Vous devez admettre un compromis entre performance du logiciel, temps de développement et adaptabilité du logiciel pour diverses configurations.
Ainsi, on a eu des jeux atari 2600 bâclés et pas optimisés (si si) et des E.T., vous savez, le jeu que nombre de personnes déclarent comme jeu le plus pourri des temps. J'y ai joué, et comme tous les jeux Atari 2600 il était bien pourri, mais pas à ce point (au moins il a un fin, lui !).
Et bien ce jeu regorge de petites astuces de programmation qui, par le statut qu'à acquis ce jeu, sont bien documentées sur internet. Il est "optimisé", vraiment.
Mais on en avait rien à foutre, après être tombé 6 fois dans le même putain de trou, on éteint.
@ oomu
« le jeu était notoirement lent sur i386, le cpu du pc de base, alors que le 486 était nettement bien plus onéreux.
Alors l'optimisation hein... »
C'est vrai qu'un jeu grand public, c'est tout à fait comparable à un logiciel embarqué dans un Boeing. Bien sûr. 😳
@oomu
Le système 6 tenait sur une disquette, il suffisait de faire un copier/coller ....et roule ma poule.
@iPop
"Le système 6 tenait sur une disquette,"
Non. Il y avait une ROM dans la machine, plus grosse qu’une disquette. La disquette ne contenait que les modifs et ajouts.
@ fte : « Il y avait une ROM dans la machine, plus grosse qu’une disquette. »
Entre 128 et 512 ko de ROM pour les machines concernées par le Système 6, alors qu’elles lisaient des disquettes de 800 ko ou 1,4 Mo.
« La disquette ne contenait que les modifs et ajouts. »
Des compléments, on va dire. Il n’y avait évidemment pas tout en ROM (sauf dans le cas spécial du Classic et de son disque système en ROM, mais c’était juste une exception bizarre).
Cependant, il faut bien avouer que le Système 6 ne tenait pas entier sur une seule disquette. Il était distribué sur plusieurs. Mais on pouvait en faire une version minimale tenant sur une disquette.
@BeePotato
"Entre 128 et 512 ko de ROM pour les machines concernées pas le Système 6, alors qu’elles lisaient des disquettes de 800 ko ou 1,4 Mo."
Tiens, dans mon souvenir les II et les LC avaient déjà une ROM d’1 MB, 4 MB dès les 68030 et 40 des Performa et Quadra... probablement livrés avec la 7 d’ailleurs.
Mais c’est vieux tout ça. Tiens MacTracker !.. ne précise pas la ROM. Tant pis.
@ fte : « Tiens, dans mon souvenir les II et les LC avaient déjà une ROM d’1 MB »
256 ko seulement pour le Mac II (comme pour le SE, sauf que ce dernier n’avait pas besoin d’autant de place et c’est pourquoi l’espace inutilisé a pu être rempli avec les photos de l’équipe qu’on pouvait voir défiler en allant taper à la bonne adresse). Pour le LC, c’était 512 ko si je ne m’abuse.
Ce n’est qu’à partir des II vi et II vx que la ROM a atteint le Mo. Mais ces machines n’étaient déjà plus concernées par le Système 6 dont on parle ici, étant livrées avec le 7.
@julien74
"Après il faut dire qu’à l’époque les programmes étaient optimisés."
Ni plus ni moins qu’aujourd’hui.
@fte
250Mb pour Snapchat
10Mn pour Wing Commander 2 avec toutes ses cinématiques
Chercher l’erreur....
@julien74
"Chercher l’erreur...."
Ça ne prouve rien. En particulier pas que c’était optimisé plus que maintenant. Car ça ne l’était pas.
C’est une de ces légendes urbaines de l’informatique, dans le temps c’était optimisé, Apple est plus optimisé, les processeurs arm sont plus optimisés... faux.
@fte
D’un côté un jeu avec des dizaines d’heures de cinématiques donc des ressources multimédia (bon avec les résolutions de l’époque, ça faisait pas une grande résolution). Les monkey islands aussi.
De l’autre une application qui est 20x plus lourde.
Pourquoi? Du code ? Des ressources multimédia? Mais punaise qu’est ce qui peut prendre autant en graphique, son?
Si c’est du code c’est pas étonnant que le respect de la vie privée soit si légère si des Mo de code est dédié à cela via des librairies et API. Snapchat à la base c’est une appli de prise de photo, mise d’effet sur un média (photo ou vidéo), envoie, chat texte (wouah). Pas bien plus....
@julien74
"bon avec les résolutions de l’époque, ça faisait pas une grande résolution"
1991.
3D simulée, 640x480, 800x600 au mieux, palettes 8-bit.
2020.
Aujourd’hui le moindre téléphone est au moins 2400x1080 voire 3000x1440 voire plus, 24-bit voire HDR 30-bit, a un GPU capable de rendus complexes en 3D avec des millions de triangles et des textures haute résolution...
Tu compares un silex au LHC pour dire que le silex est plus optimisé.
@fte
Je compare justement un logiciel de l’époque des disquettes (sujet des commentaires) a une appli que je juge gifs traqué en taille pour l’intérêt que je lui porte (nul).
Ma question demeure: est ce les ressources graphiques contenues dans Snapchat qui lui donne son embonpoint?
Ou est ce du code qui lui donne cette taille?
@julien74
"Ma question demeure: est ce les ressources graphiques contenues dans Snapchat qui lui donne son embonpoint?
Ou est ce du code qui lui donne cette taille."
Okay. Prenons un exemple donc. L’icône d’une application iOS. Juste son icône.
Les iPhone et iPad viennent avec diverses densités de pixels, x1 des premiers iPhone, x2 des premiers retina, x3 des grands téléphones actuels. Les icônes, pour être pixel perfect et pas mise à l’échelle par l’OS (donc floutées au passage) doivent être fournies pour ces diverses densités et en diverses tailles pour les divers appareils : 120x120, 180x180, 152x152, 167x167, 1024x1024, le tout en 24-bit. C’est, pour simplement une icône, au moins 5 MB. Une icône.
Est-ce que ça te donne une idée de l’énorme gouffre qui sépare 1991 de 2020 ?
@fte
Je taquine: l’icône de Snapchat a t elle besoin d’être 24bits au vu de sa laideur? ;-))
Comme le reste de l’interface de Snapchat d’ailleurs...
Mais oui sur cet exemple ça permet d’expliquer.
@julien74
"Je taquine: l’icône de Snapchat a t elle besoin d’être 24bits au vu de sa laideur? ;-))"
Apple l’impose. Donc oui.
@fte
N’oublions pas aussi les approches du développement qui ont évoluées.
Des framework comme Electron ou React Native produisent des applications lourdisimes ou la part spécifique à l’application occupe une part très minime du poids de la solution.
Quand on voit ce que pèse Atom qui n’en fait pas beaucoup plus que Vi ou Emacs 😳😳
Et ce n’est qu’un exemple.
@julien74
Tiens, un lien pour documenter un peu plus en détail mon résumé ci-avant...
https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/app-icon/
@ julien74 : « Ma question demeure: est ce les ressources graphiques contenues dans Snapchat qui lui donne son embonpoint? »
Sans aucun doute. Comme l’a déjà fait remarquer fte, les hautes résolutions des écrans actuels imposent d’inclure des ressources graphiques d’une définition très élevée, qui pèsent lourd. Les tailles des applications s’envolent facilement à cause de ça.
@ julien74
« Ma question demeure: est ce les ressources graphiques contenues dans Snapchat qui lui donne son embonpoint?
Ou est ce du code qui lui donne cette taille? »
Tu peux avoir la réponse toi même, c'est hyper simple :
- Affiche l'application dans une fenêtre du Finder
- Fait un Ctrl-click dessus, et choisis "Afficher le contenu du paquet" dans le menu contextuel.
Tu peux alors voir la taille de tous les composants du logiciel, resources, code, etc.
@ fte : « C’est une de ces légendes urbaines de l’informatique, dans le temps c’était optimisé »
Pas d’accord.
Il y a réellement eu une époque où l’on était bien plus obligé que maintenant de travailler sur l’optimisation des logiciels, en particulier l’optimisation de l’espace occupé en RAM. Les développeurs de jeux sur machines 8 bits dotées de 32 ko de RAM devaient faire de gros efforts dans ce domaine dès qu’ils voulaient innover un peu, et ils ont vu avec bonheur arriver les 48 et 64 ko. De même, le développement initial du Mac a inclus beaucoup de boulot (comparativement à ce qu’est le développement d’OS de nos jours) pour s’accomoder des 128 ko de RAM de la machine.
Cette contrainte s’est ensuite peu à peu relâchée, pour en arriver à des machines donnant facilement à la plupart des développeurs l’impression d’être sans limite.
L’arrivée des smartphones a brièvement marqué le retour de telles considérations, mais ça n’a pas duré, les spécifications de ces plateformes ayant évolué à grande vitesse.
Concernant l’optimisation de la vitesse d’exécution, en revanche, je trouve que les choses n’ont pas tellement changé : les développeurs d’OS, de jeux et de certaines applications ont toujours été obligés de se pencher sur ce sujet et ça continue, tandis que les développeurs de la plupart des autres logiciels ne s’y intéressent qu’en cas de ralentissement notable.
@BeePotato
"Pas d’accord."
Ce que disent fte et oomu c’est qu’il ne faut pas confondre contrainte et optimisation, il me semble.
Oui les contraintes étaient très forte dans le passé et dans bien des cas la solution pour les affronter était principalement de limiter ses ambitions et de respecter quelques bonnes pratiques.
Le vrai travail d’optimisation aussi bien en temps qu’en espace a toujours été assez rare pour plusieurs raison :
- Il est très cronophage.
- Il demande une réelle expertise.
- Il conduit à des solutions plus difficiles à maintenir.
Ce qui c’est en grande partie perdue aujourd’hui où bien des contraintes ont disparu c’est la compréhension et le respect des bonnes pratiques.
Ce n’est pas un enjeu d’optimisation mais d’abus de ressources par manque de connaissances ou par paresse intellectuelle.
Ne pas faire des monstres dévorant les ressources en maîtrisant son sujet ce n’est pas faire de l’optimisation mais simplement travailler proprement.
La célèbre phrase de Hoare popularisée par Knuth : « premature optimization is the root of all evil. » a fait des ravages car elle a été détournée de son sens premier.
Produire des abominations par manque de connaissances , de reflexion et/ou de maitrise ce n’est pas ne pas optimiser c’est juste mal travailler 🤓
Beaucoup de mission de Refactoring ne font pas de l’optimisation mais simplement remette sur les bons rails des solutions qui ressemblent à du bricolage quick&dirty produits par des dev in name only.
La vraie optimisation c’est tout autre chose et en général elle s’appuie sur un profiling de l’exécution pour identifier les goulots d’étranglement qui ne sont pas toujours là où on les imagine.
@ YetOneOtherGit : « Ce que disent fte et oomu c’est qu’il ne faut pas confondre contrainte et optimisation, il me semble. »
Et ce que je dis (et répète), c’est qu’à une époque certaines contraintes étaient telles qu’il y a eu bien plus de travail d’optimisation que par la suite, car sans ça on ne pouvait pas faire grand chose.
« Oui les contraintes étaient très forte dans le passé et dans bien des cas la solution pour les affronter était principalement de limiter ses ambitions et de respecter quelques bonnes pratiques. »
Et dans bien d’autres cas la solution a été de chercher à optimiser l’utilisation des ressources.
@BeePotato
"bien plus de travail d’optimisation"
Nous ne restons pas d’accord sur la définition de l’optimisation, il me semble 😉
Travailler proprement en tenant compte des contraintes ce n’est pas optimiser 😎
@YetOneOtherGit
"Travailler proprement en tenant compte des contraintes ce n’est pas optimiser 😎"
Ça ne change rien. Il y avait des contraintes, il y a toujours des contraintes. Optimisations ou limites matérielles, ni plus ni moins hier qu’aujourd’hui.
@fte
"Ça ne change rien. Il y avait des contraintes"
Nous sommes d’accord sur ce point, je me suis sans doute mal exprimé ici en ne voulant pas faire une redite de mes autres contributions.
Jettes y un œil si tu as le temps 😉
@ fte
Ce que tu dis c'est vrai en théorie.
Mais j'ai comme l'impression que tout ça n'est que théorie pour toi et que tu n'as jamais vraiment travaillé dans des boîtes avec des n+x à qui on se doit d'obéir.
En pratique... les développeurs sont aussi des fainéants comme les autres, mais on leur demande souvent d'avoir fini avant d'avoir commencé. Alors dans ces conditions, si les contraintes matérielles n'imposent pas une optimisation maximale, et bien elle passe à la trape et "on fait au plus simple, au plus vite". Ou bien, on a des injonctions du type : "je veux cette fonction et qu'elle soit implémentée de telle manière, même si elle doit dégrader les performances". Et oui, il y a des "chefs" qui se targuent de choisir des solutions techniques contre ou sans consulter l'avis de leurs développeurs. Les pires, ce sont les "ex ingénieurs" aux connaissances obsolètes mais qui... bref.
On m'a même demandé un jour d'accepter la modification faite par un stagiaire qui avait pour conséquence qu'un process http (un seul) pouvait consommer jusqu'à plusieurs Go de mémoire, si bien que le serveur http aurait dû être consacré à une tâche et une seule !
@marc_os
"avec des n+x à qui on se doit d'obéir"
La responsabilité des donneur d’ordre est évidemment aussi très conséquente.
- « Qu’est-ce qu’on a à gagner avec des enjeux de qualités ? »
- « Qu’est-ce qu’on a à gagner avec des enjeux de sécurité ? »
- « Tester c’est douter, on perd pas de temps avec ça 3 »
- « Tu as fini cette pré-production ? On fait pas de la rocket-science quand même »
- « Oui c’est pas propre mais on verra plus tard, l’urgence là c’est de shipper »
- « On réglera ça au prochain sprint on fait du développement continu n’oublis pad »
...
La rencontre de cette politique et d’une masse de dev très mal formés produits des horreurs.
Dans cet esprit on a eut un très belle exemple récemment avec Zoom.
@marc_os
"Mais j'ai comme l'impression"
Oh les impressions tu sais, sur un forum...
@BeePotato
"Et dans bien d’autres cas la solution a été de chercher à optimiser l’utilisation des ressources."
La véritable optimisation au sens strict a toujours été rare.
Les compromis et/ou les bonnes pratiques ne sont pas de l’optimisation 😉
Ce n’est pas pour t’embêter en sodomisant les drosophiles mais l’abus de sens sur le concept d’optimisation est la mère de bien des horreurs.
« Mal nommer les choses, c'est ajouter au malheur de ce monde »
A. Camus 🤓😉
@ YetOneOtherGit : « Ce n’est pas pour t’embêter en sodomisant les drosophiles mais l’abus de sens sur le concept d’optimisation est la mère de bien des horreurs. »
C’est sans doute pour ça qu’il serait bien de ne pas imaginer que je tombe dans cet abus. ;-)
Je parlais bien d’optimisation, pas juste de « programmation propre ». Et je maintiens que ça se voyait plus souvent à l’époque où les contraintes matérielles étaient bien plus fortes et empêchaient d’obtenir un bon résultat sans optimisation.
« “Mal nommer les choses, c'est ajouter au malheur de ce monde” A. Camus 🤓😉 »
Désolé, je n’ai pas de bonne citation à proposer concernant le fait de partir du principe que son interlocuteur ne sait pas de quoi il parle. :-)
@BeePotato
"Désolé, je n’ai pas de bonne citation à proposer concernant le fait de partir du principe que son interlocuteur ne sait pas de quoi il parle. :-)"
Je ne part nullement de ce principe 😎
J’essaye évidemment d’évaluer ce niveau et dans ton cas je n’avais pas cette impression 😎
J’ai présumé que tu faisais une erreur très courante sur le sens de l’optimisation que l’on trouve j’ai beaucoup de dev.
@BeePotato
"Et je maintiens que ça se voyait plus souvent à l’époque où les contraintes matérielles étaient bien plus fortes et empêchaient d’obtenir un bon résultat sans optimisation."
Nous sommes simplement donc en désaccord, rien de plus.
fte, oomu et moi considérons qu’il y a pas mal de fantasmes sur le niveau d’optimisation du passé.
Pas toi,
C’est juste une divergence de vision et d’opinion sur quelque chose qui n’est pas objectivement décidable 😎
De mon point de vue :
- le niveau moyen du code produit était bien meilleur avant l’explosion du web
- la part du code réellement optimisé a toujours été minime et doit le rester.
@YetOneOtherGit
"De mon point de vue :
- le niveau moyen du code produit était bien meilleur avant l’explosion du web"
La complexité était très inférieure, la variété des profiles des programmeurs bien plus grande provenant de multiples horizons n’étant pas de développement et de multiples sexes et de multiples cultures, la quantité était très inférieure...
Tu compares la production d’artisans à de l’industrialisation de masse vite produite. Le lien entre les deux est très ténu. 😎
@ YetOneOtherGit : « fte, oomu et moi considérons qu’il y a pas mal de fantasmes sur le niveau d’optimisation du passé. Pas toi »
Ce n’est pas ça du tout.
Je peux tout à fait être d’accord qu’il y a pas mal de fantasmes sur ce sujet, tout en sachant qu’on voyait tout de même plus d’efforts d’optimisation à une époque. Les deux ne sont pas incompatibles, et ce n’est pas sur la simple existence de fantasmes que portait la discussion, mais bien sur la réalité qui se cache derrière ces fantasmes.
« - le niveau moyen du code produit était bien meilleur avant l’explosion du web »
C’est bien l’impression que ça donne, en effet (même si on oublie peut-être trop facilement la myriade de programmes mal écrits en BASIC qui circulaient avant ça).
« - la part du code réellement optimisé a toujours été minime et doit le rester. »
Oui.
C’est juste qu’elle était un peu moins minime par le passé. ;-)
@BeePotato
Ma position peut aussi s’exprimer ainsi : Nous sommes passés d’une époque où les pannes de cerveau, les méconnaissances, la non maitrise, l’ignorance des fondements et du sous-jacent, le non respect des bonnes pratiques identifiées, l’absence de réflexion avant l’action ... se payaient en général cash à une époque où cela fait la blague 😎
Ce n’est pas de la non optimisation mais du ni fait ni à faire 🤢
@BeePotato
"c’est qu’à une époque"
C’est toujours le cas.
Pour économiser 3 centimes sur un soc dans un appareil, on optimise l’usage mémoire pour tenir dans la puce moins dotée. Sur quelques millions d’appareils, ça chiffre ces centimes. Exemple réel : souris d’un fabricant suisse bien connu, littéralement au byte près.
Les contraintes se sont déplacées mais elles existent toujours.
@BeePotato
Un exemple typique et pourtant basique: le nombre de SELECT * en SQL que l’on peut trouver en production sur du front.
Les fondements du modèle relationnel n’étant pas compris on fait une requête ramenant beaucoup d’informations inutiles en plus de celle qui nous intéresse et on extrait en local la part qui nous intéresse avec des algorithmes souvent douteux.
Là typiquement ce n’est une non-optimisation mais une mauvaise pratique par manque de connaissances et de maitrise.
@BeePotato
"Pas d’accord."
Soit.
Mon propos, ce que tu cites est trompeur, n’est pas de dire que ce n’était pas optimisé. Je disais que ce n’était pas plus optimisé qu’aujourd’hui.
Je maintiens.
Il y avait évidemment des optimisations liées aux limites des matériels. Il y a aujourd’hui aussi évidemment des optimisations liées aux limites des matériels. Et quelques optimisations « pour la beauté de l’art ». Ou pour le confort. Bref.
Ni plus, ni moins. C’est ce que je disais.
Après, il y a optimisations et il y a limites matérielles incompressibles. On confond souvent les deux, on ne devrait pas confondre les deux, mais ça ne change rien à mon propos.
@fte
"Après, il y a optimisations et il y a limites matérielles incompressibles. On confond souvent les deux"
Yep et comme j’ai essayé de l’expliquer dans plusieurs contributions on confonds aussi : travailler simplement proprement et optimisation.
Transformer une roue carrée en roue ronde ce n’est pas de l’optimisation c’est suppléer à un design stupide. 😄
@ fte : « Mon propos, ce que tu cites est trompeur, n’est pas de dire que ce n’était pas optimisé. Je disais que ce n’était pas plus optimisé qu’aujourd’hui. »
C’est bien ce que j’avais compris, et c’est bien ce que disais le passage de ton commentaire que j’ai cité (et qui, du coup, n’est en rien trompeur).
« Je maintiens. »
Tout comme je maintiens qu’on croisait plus de cas d’optimisations qu’ajourd’hui dans les logiciels grand public. Tu as d’ailleurs dû te rabattre sur un exemple de logiciel très bas niveau pour trouver un cas similaire à ce qu’on devait faire alors pour des logiciels n’ayant rien à voir avec la simple gestion d’un périphérique.
« Il y avait évidemment des optimisations liées aux limites des matériels. Il y a aujourd’hui aussi évidemment des optimisations liées aux limites des matériels. »
En effet. Personne n’a dit le contraire.
C’est juste qu’il y en avait plus avant — ce qui est fort logique, vu qu’on atteignait alors bien plus rapidement les limites.
Pages