Obsidian a écrit 5288 commentaires

Salut et merci pour tes remarques.

Il fallait bien sûr lire « d'ores et déjà être utilisé par toute autre feuille ». J'ai eu un problème d'édition cette nuit avec le corps du journal dupliqué en plein milieu de mon texte…

Pour les flèches, ce sont des caractères UTF-8 et effectivement, c'est toujours un problème si les fontes installées ne les prennent pas en charge. C'est le cas aussi de la flèche pour « remonter au commentaire parent » à gauche du bouton « # » dans le titre des commentaires. Si ça passe mal, il faudra effectivement passer au SVG.

Parce que quand je vais les styles, je vois… une longue liste de capture d'écrans, sans nom.

En fait, ça, c'est une fonctionnalité du site lui-même, qui présente les feuilles de style sous forme de capture d'écran, en « randomisant » l'ordre d'affichage des captures pour éviter d'en favoriser certaines. Celle qui est présentée ici affiche un gros « Steelblue » vertical sur la gauche de la capture.

Génial ! Merci de l'avoir traité si vite !

Merci aussi pour les commentaires sur Github. Il y a bien sûr moyen de faire beaucoup mieux mais je suis un noob complet en Ror. :) Évidemment, j'ai fait de mon mieux pour valider totalement, documentation à l'appui, tout ce que j'ai écrit mais ça m'a coûté environ 24 heures par ligne :)

Une dépêche, c'est peut-être un peu beaucoup. Je vais au moins faire un journal pour l'annoncer. S'il est propre, on pourra éventuellement l'upgrader. Mais le mieux serait effectivement d'écrire quelque chose de concerté pour inciter ensuite les gens à faire pareil.

Encore merci !

A quand un nouveau langage spécialisé pour ces usages ? Où une expression litérale genre "123.50" serait interprété comme un type décimal, et pas un float ? Même l'autoboxing de Java, implémenté longtemps après que ce langage soit sorti de la niche de l'embarqué pour lequel il avait été conçu, ne supporte pas le BigDecimal qui reste cloîtré dans son package.

Parce que dans la majorité des cas, cela n'a en fait aucun intérêt.

Les problèmes d'arrondi sont les mêmes en binaire qu'en décimal : 1÷3, ça fait 0,33333333333… et il y aura donc une perte dans toutes les bases de calcul où ce nombre ne tombe pas rond (ça fait pile poil 1,3 en base 9, en revanche).

Même en utilisant un type « financier » avec un nombre de décimales fixes après la virgule (en général 2, parfois 3), ça ne te permettra pas de faire toutes les divisions possibles. Si tu veux répartir équitablement 1,43 € entre deux personnes, tu vas forcément perdre 1 centime dans l'opération. Ce ne sera pas mieux avec un type de longueur arbitraire comme un BigDecimal Java ni avec une bibliothèque telle que GMP parce que tu serais toujours confronté aux mêmes problèmes de division si leur développement décimal est infini.

Si, enfin, tu te restreins à des langages où le nombre de décimales est fixe et dans lesquels on ne peut faire que des additions, des soustractions ou des multiplications, alors il suffit de travailler en virgule fixe avec les formats habituels : au lieu de compter en euros, tu comptes en centimes et toutes tes valeurs sont alors des nombres entiers. Il devient alors trivial de les manipuler, même en binaire.

Salut,

C'est tout simplement parce que tu vois tous les problèmes comme des clous à planter.

Je ne suis pas sûr d'avoir complètement compris ce que tu entendais par là, mais si tu voulais dire « une manière de parvenir à ses fins, indépendamment de la curiosité mathématique », alors non. C'est même plutôt le contraire, si tu relis bien mon commentaire. C'est intéressant dans les langages tels que le Javascript qui sont non seulement interprétés, mais où les objets sont définis et remplis à l'exécution.

Par contre, il est important de ne pas faire tout et n'importe quoi juste pour résoudre le problème, même de façon théorique (ce qui nous ramènerait aux clous à planter). En développement logiciel, je suis assez adepte du « changement de paradigme », c'est-à-dire se laisser la possibilité d'utiliser un jeu de concepts totalement exotiques s'il le faut mais À CONDITION de poser le cadre dès le départ et de ne pas en sortir a posteriori au cours d'un projet, surtout si c'est pour se sortir d'une impasse.

En particulier, il y a beaucoup de gens qui font l'amalgame « classe = objet », alors que le mot « classe » doit en fait s'entendre dans le même sens que « classification du règne animal », par exemple. En ce sens, si tu ajoutes ou retires quelque chose à une classe, alors par définition, ce n'est plus la même classe ! Et ça pose problème avec les objets déjà instanciés.

Plus précisément, si l'on modifie une classe, c'est en fait l'ontologie elle-même que l'on modifie, même si cette ontologie est maintenue grâce à des données définies à l'exécution (et qui sont en fait des méta-données). Ça reste très séduisant en soi, mais c'est pour moi du même niveau que le code auto-généré. Ça n'est à utiliser qu'à partir du moment où tous les concepts initiaux sont parfaitement clairs et que, de là, on sait parfaitement ce que l'on fait.

Et là, il me semblait justement que le message du primo-postant n'avait pas vocation à débattre de ce sujet, mais était bien confronté à un cas de figure fondamental en programmation orientée objet, d'où la réponse qui me semblait être la plus appropriée.

Ça ne fait que 37 ans. Je ne suis pas pressé de vieillir. ;)

Cette fois-ci, j'ai fait ifconfig eth0 192.168.0.2 up, avec l'adresse IP qui va bien
(elle est paramétrée en adresse statique dans les paramètres DHCP de ma box, histoire de pas casser les redirections de ports à chaque reboot)

Tu as spécifié une adresse fixe dans la config du serveur DHCP (ce que je fais aussi) en fonction de sa mac address mais attention à ne pas déclarer « STATIC » l'adresse de ta carte sur ta machine, car cela signifie que le serveur DHCP ne sera pas interrogé…

Y'a du progrès.
Maintenant, je peux pinger ma box.
Par contre, j'arrive pas à pinger un nom de domaine, ni à faire les mises à jour par apt-get.
Je suppute un problème de DNS.

C'est normal. Pour que la résolution DNS fonctionne (et par conséquent tous les programmes dont les connexions se font vers un nom de domaine plutôt qu'une adresse IP, soit 99 % des applications Internet), il faut remplir /etc/resolv.conf pour lui indiquer quels sont les DNS à contacter pour faire la résolution. Et les adresses de ces serveurs sont indiqués sur les documents papier qui t'ont été envoyés par ton fournisseur d'accès.

Mais là encore, ces informations sont censées être communiquées automatiquement avec la requête DHCP. Tout semble venir de là.

C'est soit NetworkManager, soit les clients DHCP en ligne comme pump ou dhclient qui font la requête et qui remplissent le fichier le cas échéant. Vérifie la config de ta carte réseau dans ton gestionnaire. Si ça se trouve, tu as juste coché une mauvaise case et fait passer ta carte soit à l'état inactif, soit en configuration statique et avec des paramètres non renseignés.

Sinon, tu peux remplir /etc/resolv.conf. Attention, c'est peut-être un lien symbolique vers un autre fichier. Si tu as une box un peu sophistiquée comme une Freebox V6, il se peut qu'elle soit elle-même serveur DHCP et tu peux te contenter d'y écrire nameserver adresse.de.ta.box, sinon tu retrouves les bons serveurs, soit en cherchant sur le Net puisque tu as visiblement une connexion de secours, soit dans tes documents papier.

Pense à ajouter les serveurs IPv6 également si tu es concerné.

Salut,

Même en ayant l'habitude des langages (pré-)compilés où ce genre de manip' est impossible, ajouter dynamiquement des méthodes à une classe est déjà douteux, mais les ajouter à une instance précise est encore plus tordu. Pourtant, l'exercice aurait pu être intéressant en soi…

Mais dans le cas qui te concerne aujourd'hui, c'est un simple problème de conception objet : il faut définir une classe Véhicule, puis deux classes Voitures et Moto qui dérivent toutes les deux de la classe véhicule.

class Vehicule:
    def tourner(self):
        print("Vehicule qui tourne")

class Moto(Vehicule):
    def tourner(self):
        print("Moto qui tourne")

class Voiture(Vehicule):
    def tourner(self):
        print("Voiture qui tourne")

class Autogyre(Vehicule):
    def voler(self):
        print("Autogyre qui vole");

h = Vehicule()
m = Moto()
v = Voiture()
a = Autogyre()

h.tourner()
m.tourner()
v.tourner()
a.tourner()

Ce qui donne :

Vehicule qui tourne
Moto qui tourne
Voiture qui tourne
Vehicule qui tourne

Dans cet exemple, les classes Voiture et Moto dérivent de Véhicule, mais redéfinissent la méthode « tourner », et c'est cette dernière version qui est donc appelée. En revanche, la classe Autogyre dérive également de Véhicule mais définit une autre méthode sans redéfinir « tourner ». C'est donc la version par défaut héritée de « Véhicule » qui est appelée, et c'est pourquoi on obtient « Véhicule qui tourne » et non « Autogyre qui tourne ».

Hello, juste pour info, il est normal de ne pas voir les connexions down avec ifconfig. Il faut écrire ifconfig -a pour lui demander de les afficher toutes.

Vois déjà si ta connexion reste montée lorsque tu la redéfinis comme tu l'as fait en lui réaffectant une adresse et en la montant, avec ifconfig eth0 192.168.0.2 up puis ifconfig tout seul pour voir si elle apparaît bien. Ensuite, il faut que tu vérifies sur quel sous-réseau tu es censé te trouver. dark_star t'as suggéré 192.168.2.2 plus haut, mais ça peut être autre chose que 2.

Enfin, une fois ta carte réseau remontée, il faudra peut-être redéfinir la passerelle par défaut avec un truc du style `route add default gw 192.168.2.254 eth0' en remplaçant éventuellement 254 par 1, et le 2 par 0, 1, 2, 3… etc.

Évidemment, cela ne nous dit pas pourquoi ta manip' a fait planter ton réseau, mais il est possible que le fait d'avoir passé ta machine à 800 Mhz et avoir rebooté pousse un des scripts de démarrage à ramer suffisamment pour atteindre un timeout, mais ce serait étonnant quand même. On ne pourrait être fixés qu'en examinant les logs.

Autre piste : il y a des chances que ta carte réseau obtienne en fait son adresse via le DHCP (et que la passerelle soit configurée à cette occasion), que tes manips aient provoqué l'expiration du bail et que l'équipement censé lui renouveler ne le fasse plus.

30 ans de Windows, pff ! On y est donc déjà ? Mon dieu…

En tous cas, sois le bienvenu sous Linux en général et sur ce site en particulier.

Pour utiliser assez souvent un débogueur sous Windows sans forcément être root, je te confirme que tu peux modifier l'espace mémoire d'un process qui t'appartient. Et c'est pareil sous linux : pas besoin d'être root pour lancer gdb sur un process à soi.

Oui, mais le débogueur fait quand même appel à ptrace() pour pouvoir le faire. Il ne peut pas le faire directement.

Pas besoin de mapper le 2nd processus, il suffit d’accéder à la mémoire via des fonctions dédiées : ReadProcessMemory et WriteProcessMemory notamment.

Oui, c'est bien ce que je dis : avec des appels système.

Je pense que c'est de là que vient le malentendu à l'origine de la question d'Albert_ (« pourquoi pBpG a-t-il reçu des [-] ? »). Comme le fil s'est développé dans la longueur, la réponse était éloignée du message original et hors contexte, on a l'impression en le lisant qu'un processus voit directement ses congénères alors qu'il ne précise en fait qu'il n'y a pas besoin d'être root pour pouvoir le faire.

« Ils l'ont trop bien rangé. » (© Gaston Lagaffe)

Je crois que c'est dans les détails que ça fait douter les gens. Je ne suis pas sûr qu'un processus puisse directement en modifier un autre, même s'il y a filiation et qu'il est lancé sous l'identité du même utilisateur. Techniquement, le cloisonnement doit s'appliquer quand même. En plus, il faudrait mapper les deux processus dans des plages distinctes du plan mémoire. Par contre, il peut demander au système l'autorisation de le faire et les différents threads d'un même processus, eux, doivent pouvoir se marcher dessus.

Maintenant, ça me paraissait tellement évident que je n'ai jamais essayé. 'faudrait que je me replonge dedans pour être sûr de savoir de quoi je parle. :)

• afficher un message erroné puisque les tampons encreurs ne sont pas hors service.

Il faut être prudent avec ce genre de conclusion hâtive également, même si l'obsolescence programmée me hérisse comme tout le monde. À commencer par les PUCES de comptage sur les cartouches de toner…

Mais dans le cas présent, la capacité ultime des tampons encreurs n'est pas une science exacte et à moins d'avoir un dispositif interne spécifique pour les mesurer in situ, c'est difficile de faire autrement qu'utiliser une estimation commune pour tous avec marge de sécurité.

Moi j'utilise la version « FR — variante » et j'obtiens “” (à la place de «»).

À noter que pour les privilégiés qui disposent d'une touche « < & > », on peut obtenir ≤ et ≥ avec Alt+Gr.

Probablement un produit de la gamme « Big Q » :)

et le téléphone depuis une cabine publique :-)

Même ça, ça devient difficile à trouver !

C'était en ROM, et c'est ce qui est intéressant. Il n'y avait donc pas de système d'exploitation à charger au préalable mais, à contrario, il n'y avait rien d'utilisable en soi intégré directement à l'ordinateur non plus, qui ne servait donc que de plateforme de lancement. Comme on ne pouvait faire de programmation — de fait — comme exposé ci-dessus et que c'était encore limite pour un usage professionnel, et comme par ailleurs l'Atari ST avec un bon processeur graphique (avec l'équivalent d'un Copper) et une puce sonore caractéristique, et bien il servait principalement de plateforme de jeu, avec des disquettes bootables la plupart du temps, sinon lancées depuis le bureau GEM qui donc, ne servait à rien la plupart du temps.

Et pourtant, il a été extrêmement populaire ! En ce sens, c'était un peu l'équivalent avec clavier de la Playstation qui sortira quelques années plus tard (même s'il se rêvait en concurrent du Mac).

Ce qui me fascinait, à l'époque, c'est que pour moi, en ce temps, chaque machine avait son architecture propre et donc sa propre interface utilisateur (quelle qu'elle soit, d'ailleurs, bureau ou interpréteur). Et là, non seulement GEM ressemblait beaucoup au Mac (on peut lire aujourd'hui que ce n'était pas fortuit) mais c'était quelque chose que j'avais vu en premier lieu… sur PC ! Avant Windows (à partir de 3.0) mais surtout sur une machine où l'on utilisait principalement DOS ! Il faut dire que, sans disque dur, il fallait lancer le DOS, puis changer de disquette et lancer GEM, puis changer de disquette et lancer le logiciel qui nous intéressait. Donc, ça limitait un peu l'intérêt… mais j'avais fini par le trouver sur une de nos disquettes (5'1/4, 360Ko) et ce justement parce notre compatible PC un peu miteux (de marque « PC Land » à l'époque) ne faisait pas bien tourner MS/DOS, mais fonctionnait parfaitement avec… DR/DOS, de Digital Research, donc.

Le plus drôle, c'est que je m'aperçois que la boîte de 5'1/4 est toujours sur mon étagère. Ça fait donc 20 ans qu'elle n'a pas bougé. ^ ^

C'est à ça que je pensais aussi, effectivement, mais comme je ne les ai jamais essayés, je ne me suis pas prononcé sur ce point non plus. En revanche, j'ai les mêmes craintes que toi, parce que si on constate que beaucoup de monde maîtrise encore la chose, je me suis aperçu que la totalité ou presque des personnes concernées sont justement les gens qui ont connu l'époque des huit bits ou, en tout cas, qui ont commencé sur autre chose qu'un PC ou Mac récent.

Il me semble d'après ce que j'en ai compris que l'atari ST avait le basic intégré en ROM. Mais comme j'en avais pas (j'avais une meilleure machine, la meilleure de tous les temps : l'Amiga), je ne peux pas le confirmer. Quelqu'un dans la salle pour expliquer comment démarrait un Atari ST ?

On utilisait le bureau GEM :) avec son magnifique fond vert.

Pour les bases de programmation de µcontrôleur, sûrement, oui. J'ai aussi codé en mode réel sur du 16bits, c'était clairement plus simple. Plus simple aussi de cramer la machine en se trompant d'adresse mémoire.

Pour les microcontrôleurs, c'est certain. C'est ce qui s'en rapproche le plus aujourd'hui (même si les microcontrôleurs existaient déjà à cette époque et étaient à peu près du même niveau de puissance).

Le mode réel sur 16 bits, c'était plus simple aussi, même si à l'époque on s'arrachait les cheveux pour comprendre à quoi ça correspondait quand on était habitués aux « banques » de mémoire paginée. Et surtout : c'était déjà du PC. C'était quand même intéressant de pouvoir constater qu'un ordinateur n'est pas nécessairement un ersatz de l'IBM PC et de son 8086. En plus, à ce stade, on parle déjà d'assembleur et pour le coup, le grand débat de l'époque, c'était l'opposition Intel vs. Motorola. On disait que les premiers avaient été pensés par des électroniciens, les seconds par des programmeurs.

Du coup, même si on a eu toute la vague des Atari ST/Falcon vs Amiga, les huit bits branchés sur le téléviseur familial (ou déjà sur leur propre avec les Amstrad CPC) étaient vraiment une époque particulière, ne serait-ce parce que chaque machine était en elle-même une architecture propre et distincte des autres, même (et surtout) si tous les ordinateurs fonctionnent suivant le même principe. C'était vraiment la même différence qu'il pouvait y avoir entre un avion de ligne et un avion de chasse.

Par contre, pour des trucs plus compliqués, pas vraiment non. D'ailleurs, c'était passionnant, le graphisme en 16 couleurs… ou pas. Bon, j'exagère, je sais: c'était 256 couleurs en 320x200, vive le mode 13h.

Oui, le mode X aussi, toussa. Mais là encore, c'est le contraire même de ce que l'on parle, puisqu'il s'agit déjà d'assembleur sur PC. Note que l'assembleur, c'est génial en soi, même sur PC, mais ce n'est pas l'objet de ce qui nous intéresse. Quand tu faisais LINE en BASIC, tu mettais le numéro de couleur à la fin. Du coup, que tu disposes de 16 couleurs ou de 4294967296, ça ne changeait pas la syntaxe du langage, et ça ne change pas non plus celle des langages actuels.

Vraiment? Pas de POST, pas de BIOS?

Oui, vraiment.

Quand tu allumais un MO5 ou un CPC 6128, tu tombais immédiatement sur le BASIC. Il y avait environ une demi-seconde d'initialisation. Quand tu allumais un MO6 ou un TO8, tu tombais sur une page d'accueil où tu tapais un chiffre qui t'orientait immédiatement vers le BASIC de ton choix parce qu'il en proposait deux, ou vers de menus utilitaires, le tout étant contenu en ROM. Et tout cela parce que pendant très longtemps, les ordinateurs personnels, y compris PC, n'étaient pas dotés de disques durs.

Rien que le POST de mes 1ères machines (16bits, encore une fois… quoique, si ça se trouve j'ai connu du 8bits et je m'en souviens pas.

Oui mais tes machines étaient-elles des compatibles PC ? On rappelle bien que PC veut dire « Personal Computer » et que c'est à la base une marque et un modèle déposé d'IBM. Ça n'a jamais été un nom commun. Comme ils ont (volontairement) laissé leurs concurrents les imiter, ceux-ci ont dès le départ produit des ordinateurs « compatibles PC » (ou « compatible IBM », comme on le disait à l'époque) mais c'était une hypocrisie avouée dès le départ : il ne s'agissait pas d'une architecture complètement indépendante mais capable d'exécuter les programmes prévus pour l'IBM, mais bien d'un clone, à chaque fois.

C'est quand même malheureux parce que c'est à une époque où l'informatique n'a jamais été aussi répandue qu'il y a le moins de diversité et, paradoxalement, parce qu'il n'existe justement plus d'ordinateur grand public non-PC, hormis le mac, les gens ne sont plus capables de s'apercevoir qu'il s'agit bien du même, même s'il a tellement évolué en 35 ans qu'il n'a presque plus rien à voir avec l'original.

C'est vraiment un destin à la John Spartan : « et alors maintenant, tous les restaurants sont des Pizza Hut ». On en rigole en voyant le film mais il est de fait que c'est ce qui est arrivé à l'informatique grand public et quand on sait l'importance que ça a aujourd'hui, ça n'est pas réjouissant.

Je veux dire, en tant que PC pour bosser, sinon c'est certain que j'ai connu) mettait plusieurs secondes… passer l'étape complète du BIOS mettait plusieurs dizaines de secondes.

BIOS et POST sont des terminologies propres à l'IBM PC, même si les autres ordinateurs étaient dotés en ROM de routines d'initialisation similaires puisqu'on ne peut pas s'en passer.

Le PC, c'est vraiment le Vigor de l'informatique : une machine industrielle reconditionnée à petite échelle pour l'adapter à l'utilisateur individuel. Sur les grosses machines, la procédure d'initialisation n'avait pas beaucoup d'importance parce qu'elles sont vouées à rester allumées en permanence et parce qu'elles font souvent, par ailleurs, l'objet d'un contrat de maintenance une fois vendues aux structures auxquelles elles sont destinées. Sur AS/400, le démarrage s'appelle même « IPL » (Initial Program Load).

Le PC, par contre, outre le fait qu'il a été dès le départ une grosse boîte lourde, imposante et majoritairement vide, était doté d'équipements qui, pendant très longtemps, ne servaient vraiment à rien. Par exemple, le ventilateur. Aujourd'hui, ce serait difficile de faire sans mais à l'époque, la technologie était guère différente de celle des huit bits et même l'Amiga 1200, qui était un 32 bits sorti en 1992 et contemporain du 486 (68020, pas x86) s'en passait fort bien.

Pendant longtemps, le PC m'est apparu comme étant à la fois la machine la plus chère et la plus mal conçue, jusqu'à ce que ces défauts soient compensés par un moteur de fusée.

Il me semble bien que c'est le cas également de tous les langages interprétés que je connais, anciens ou modernes.

Oui, il me semblait que certains étaient moins adaptés que d'autres à cet usage mais comme, à y réfléchir, je n'ai pas d'exemple probant en tête, je ne te contredirai pas sur ce point.

Hum. De nos jours, il est possible au néophyte de faire des choses très élaborées avec Excel, sans jamais taper la moindre ligne de code. Malheureusement pour les devs qui doivent rattraper les dégâts, d'ailleurs :)

Oui mais là encore, c'est l'opposé de ce qui nous intéresse ici. Excel propose d'ailleurs le VBA, dont on pense ce que l'on veut, mais qui permet effectivement de faire pas mal de choses dans une feuille de calcul (à commencer par des âneries). Mais il s'agit quand même d'un logiciel dédié à une utilisation précise, qu'il faut lancer dans un environnement déjà opérationnel, et par des utilisateurs déjà grands.

À contrario, le PC, le Minitel et le TO7 sont sortis à la même époque, qui correspondait pour moi à la classe de CP (où on était venu nous présenter le dernier) et mes premiers vrais programmes, c'était en CM2 sur les machines du plan Informatique pour tous. L'idée est de faire en sorte que l'interface par défaut, même à destination des plus jeunes, puisse permettre de faire ce genre de choses sans que ce soit obligatoire.

Les notices ont été supprimées parce que ça coûte cher à imprimer et que de toute façon les gens ne les lisent pas. Ironiquement, c'est moi qui lis le plus souvent les notices des appareils dans ma famille, alors que je suis celui qui a la plus grande maîtrise de cet outil. Et je râle pas mal quand je dois aller chercher la doc sur le net ou dans les tréfonds d'un CD…

Oui mais ça, ça s'appelle de l'expérience. :)

La notice a disparu aussi parce qu'il n'y a plus grand chose à y mettre. Mais c'est surtout parce qu'on peut l'installer directement dans l'interface si on a un ordinateur qui démarre normalement. Et là, on pourrait y mettre les mêmes indications.

Dans mes souvenirs de jeunesse, j’utilisais des langages tels que le Basic ou le Logo. Une capacité à pouvoir faire simplement de petites choses, avec parfois même un soupçon de graphisme.
Des langages pour les quels quelques minutes et à peine quelques commandes, faisait apparaitre un résultat à l’écran.

C'est exactement l'impression que j'en ai moi aussi et plus le temps passe, plus je trouve que l'ère des 8 bits a été une époque bénie pour apprendre l'informatique. Et il ne s'agit pas d'une vaine nostalgie mais bien d'un temps particulièrement propice que j'ai été heureux de vivre.

Et c'est vrai que les machines de l'époque étaient très faciles à aborder : quand on les allumait, elle étaient immédiatement utilisables (pas de temps de boot), elle ne faisaient aucun bruit (sauf si on leur demandait d'en faire, bien sûr) et on tombait directement dans le BASIC (qui était en fait une caractéristique du premier PC XT qui, lui, paradoxalement, a vite abandonné la chose).

Ce qui était intéressant, c'est que le BASIC était présenté d'emblée comme langage de programmation (ce qui est effectivement sa vocation), mais qu'il servait à la fois d'interface utilisateur et de système d'exploitation. Et surtout : il était doté d'un mode direct ! On pouvait exécuter directement une commande et avoir son résultat, mais on pouvait également commencer à écrire un programme en mémoire en utilisant les numéros de ligne.

Du coup, on écrivait PRINT "BONJOUR" et on avait directement le résultat, on tapait BOX et on avait un carré à l'écran. Non seulement le néophyte avait tout de suite une réaction de sa machine la première fois qu'il la sollicitait, mais on pouvait très rapidement enchaîner tout de suite sur des choses plus élaborées… avant même de connaître la commande pour sauver son programme ! Chose qui, d'ailleurs, était paradoxalement compliquée surtout quand on utilisait des cassettes. :)

De coup, même quelqu'un qui ne se servait de son ordinateur que pour lancer ses logiciels faisait de fait de la programmation puisqu'il fallait au moins faire « RUN"…" » pour les exécuter (ce qui était donc précisé sur l'étiquette, en général). Et ça, c'est très différent des machines actuelles où l'interface des OS est un « bureau », soit une chose effectivement conçue pour le travail en entreprise, à la base, puis à destination d'un « usager » plus qu'un opérateur.

Du coup, il serait intéressant de réintroduire un standard (oui, je sais, XKCD) qui permettrait de faire la même chose, à savoir une interface minimaliste (même une ligne de commande) mais disponible partout, qui contiendrait par défaut un nombre d'instructions limité fixe mais parfaitement défini, d'usage général (tracer des figures, jouer du son, lancer une application, écrire à l'écran) et qui serait immédiatement utilisable sans même avoir à faire le moindre « @import ». En précisant que cela pourrait quand même s'appuyer sur l'existant, qui continuerait à être utilisé normalement en dehors de ce contexte particulier. Il faudrait aussi minimiser tout le sucre syntaxique pour ces commandes élémentaires (genre pas de point-virgule, ni de tabulations obligatoires).

C'est déjà en substance ce que fais le shell dans une certaine mesure et c'était l'idéal imaginé au départ par pas mal de langages de scripts, et il y a bien des consoles Javascript dans un certain nombre d'environnement (par exemple Looking Glass dans GNOME 3 avec Alt+F2 puis « lg ») mais si c'était partout et immédiatement accessible, on pourrait mettre ça dans la notice d'un ordinateur neuf (ce qui se faisait en fait à l'époque) et ce serait la première chose que découvriraient les nouveaux utilisateurs.

Hmm. J'avais répondu à ce commentaire et il semblerait qu'il ait disparu. Bizarre…

Je crois bien que j'ai parlé trop vite : ton patch, comme ton journal, est daté du 12 novembre 2017. Je ne sais pas si cela correspond à ton propre commit en local où si c'est la date à laquelle tu l'as soumis, mais toujours est-il que c'est aussi exactement le jour de la sortie du noyau 4.14.

Donc, normalement, c'était aussi le début de la fenêtre d'intégration des patches qui dure typiquement 14 jours (deux semaines, du lundi au… lundi). Bon, il est entendu qu'en principe, un patch doit d'abord passer par linux-next et y être intensivement testé mais étant donné la chose, on aurait pu faire ça en accéléré et faire tenir toute la procédure dans les deux semaines critiques.

Normalement, la fenêtre a dû se refermer le 25 au soir et la commit date de ton patch est marquée du… 29 :-\ Je ne sais pas si c'est délibéré (dans le sens où le mainteneur doit se charger de faire intégrer les patches déjà en attente, puis s'occuper de préparer les nouveaux une fois la fenêtre refermée) ou si c'est parce que ça a traîné mais quoi qu'il en soit, le noyau 4.15 doit sortir soit lundi prochain, soit dans dix jours. Donc, ce sera pour l'intégration du 4.16 à venir incessamment, mais il faudra bien te faire rappeler à leur bon souvenir pour être sûr que ce soit fait…

Reste à savoir si ce correctif critique va pouvoir être immédiatement rétroporté comme indiqué dans les directives présentées ailleurs, ou s'il va falloir attendre deux mois que le 4.16 sorte officiellement avant d'envisager la chose… et d'attendre ensuite la publication d'une nouvelle branche stable.

Si ça pullule, il y a des chances que ce soit des Zerg mais globalement, c'est bien ça. ^{^}

D'ailleurs, on dirait bien que les derniers lamers ont disparu avec les disquettes. Ils ont été remplacés par les noobs…

Je ne vois pas où est le problème de recalculer toutes les sommes de contrôle. C'est ce que fait Git à chaque fois qu'on clone un dépôt afin justement de vérifier qu'aucune version n'a été altérée.

Oui mais justement : on est censé retrouver les MÊMES sommes, et c'est entre autres ce qui permet de travailler de façon décentralisée sans avoir besoin de coordonnateur.

Changer de fonction de hachage n'altère en rien le fonctionnement théorique du logiciel (ce qui, en soi, est la marque d'une conception très bien pensée) et serait relativement facile à implémenter. Par contre, ce serait un cauchemar pour les administrateurs systèmes car cela implique de migrer l'intégralité des objets d'un dépôt ET d'amender tous les commits puisque ceux-ci contiennent en clair la somme de leur ou de leurs parents. On ne pourrait pas se contenter de les renommer, donc.

Ensuite, la grosse difficulté viendrait du fait que tout dépôt basé sur l'ancienne somme serait incompatible avec la nouvelle. Il n'y aurait donc pas de transition douce : tous les acteurs d'un même projet seraient donc d'abord obligés de mettre leur version de Git à jour, puis de migrer tous leur dépôts avant de pouvoir continuer à travailler ensemble. Et cela ne concernerait pas seulement les développeurs actifs : toute personne ayant cloné le noyau sur kernel.org serait concernée.

Enfin, cela rendrait caduques toutes les sommes publiées sous forme texte, que soit par mail, sur Usenet, sur le Web et sur les différents outils collaboratifs, que ce soit la LKML ou les commentaires des tickets Github. En outre, et par définition, les dépôts clonés cesseraient d'être des clones, puisqu'il pourrait y avoir plusieurs versions différentes d'un même objet : non seulement les sommes d'un commit serait différentes selon la fonction choisie, mais leur propre contenu le serait aussi puisqu'ils se référeraient à des sommes différentes. Il n'y aurait pour ainsi dire plus rien d'officiel pour indiquer facilement qu'ils sont les homologues de ceux calculés avec l'ancienne somme.

Le pire, c'est qu'il n'y aurait pas moyen de faire une conversion de l'ancienne somme vers la nouvelle a posteriori. Il faudrait dresser « pour l'histoire » une table de correspondance au moment où la migration se fait et ne surtout pas la perdre après cela.