Sytoka Modon a écrit 4544 commentaires

le 8086 c'était cool

Une daube tu veux dire ! J'ai fait un peu d'assembleur 6502 puis du 8086, celui du 6502 était une merveille en comparaison. Le moindre truc dans le 8086 relevait déjà de la bidouille (de mémoire parce que tout cela est quand même vieux, on partageait par exemple le bus de données et le bus d'adressage via une patte spéciale).

C'est exactement ce que j'allais proposer. Tous les courriels sont signés, cela ne coûte rien. Une fois en possession de la signature de la personne dans tes contacts, il est très facile de lui répondre avec un courriel signé et chiffré.

Il est important de rajouter dans le protocole la gestion du changement de signature car les clefs ne sont pas éternelles. Chose qui avait été oublié par exemple dans ssh.

Donc au final, un premier échange en clair mais signé pas confidentiel puis tout devient confidentiel automatiquement…

Ah la vache, c'est caca boudin ! Deux try/except en aussi peu de ligne, aucune variable déclarée… C'est quoi ce langage de daube ;-)

Impossible de parler CPU sans penser à Chuck Moore et au boulot incroyable de ce gars autour du langage Forth. Si mes souvenirs sont bons, le NC4016 est le premier microprocesseur Forth. Je n'en ai jamais eu mais ce truc faisait rêver par sa puissance et sa simplicité.

http://users.ece.cmu.edu/~koopman/stack_computers/sec4_4.html

C'est pas possible. Une merde pareille. Avec le 6502, tout est vachement plus clair qu'avec ce machin infâme !

L'ARM est le digne successeur du 6502 ;-)

https://en.wikipedia.org/wiki/ARM_architecture

Enfin, bash + grep étendus + tr + sed…

Au CNRS, on a une daube (agate) et malgré que les chercheurs puissent être en délégation 6 mois ou 1 an à l'étranger, il n'est pas prévu de pouvoir avoir des jours fériés différents selon les utilisateurs… Allez travailler un 4 juillet aux USA par exemple. Bref, à l'heure européenne, il est important de pouvoir adapter les jours fériées en fonction du lieu de travail (je ne sais pas ce que dis la lois sur le sujet).

Attention, c'est du one-liner, l'objectif est principalement ici d'écrire du code jetable et celui-ci est particulièrement lisible malgré ce que tu dis. Ceci dis, si tu n'y comprends rien, je pense qu'une petite plongée dans Perl ne peut alors que faire du bien histoire d'ouvrir de nouveau paradigme ;-) Bref, c'est une bête machine à état basée sur deux expressions rationnelles assez simples. Il y a pleins de one-liner incompréhensibles (c'est aussi un jeu) mais honnêtement, pas celle-là ;-)

Tu veux juste dire que Python est un langage déclaratif qui a un certain de module bien fait ;-)

use Config::Tiny;
my $Config = Config::Tiny->read('/etc/myinifile.cfg');


C'est franchement difficile d'être plus clair pourtant ! On a juste deux commandes, une qui pose le contexte, une qui fait la sortie. C'est juste une petite merveille.

Il faut savoir être ouvert sur les autres tribus et reconnaître à chacun ses mérites ;-)

Si tu restes en pure bash, tu ne mets pas de $( ) … La première qu'on voit dans ton script sont les sous commandes sed ! Bref, la monoligne Perl est vraiment plus esthétique et rapide. Si tu veux des variables à la fin, à peine modifié, tu fait un eval de son résultat.

On peut ajouter qu'il était facile d'installer PHP au début sous Windows… Click click click, finit.

Sinon, on pouvait faire du eperl au début du PHP, cela ressemblait comme deux gouttes d'eau au PHP mais avec un vrai langage ! Donc le PHP a vraiment fonctionné principalement grâce à Windows + effet de mode.

Comme quoi il y a un boulot avant linuxfr ;-)

Depuis quand les nazis se sont posés des questions de vocabulaire… Merci de ne pas raconter n'importe quoi histoire de juste faire une blague à deux balles ;-)

On est dans un monde pressé ;-)

Il y en a qui parlent de "nazis de l'interface" et ça ne remet pas en cause l'atrocité de l'époque.

C'est toi qui le dis ! Je suis 100% contre cette expression parce qu'elle banalise l'usage du terme 'nazis' pour des comportements certes reprochables mais très, très loin du nazisme… Il y a pour moi une différence entre l'utiliser une fois de temps en temps pour faire de l'humour noir et la banaliser.

Une très bonne solution est dans le langage Sather https://fr.wikipedia.org/wiki/Sather

Sather sépare la notion d'héritage et d'inclusion de code. Dans l'arbre des classes, on ne peux hériter que de classes virtuelles. Toutes les classes ayant du code sont forcément des feuilles d'extrémités. Pour ne pas tout ré-écrire, tu peux inclure du code qui est aussi une forme d'héritage… C'est très propre, clean et sans aucun risque.

Bonus, le langage est contravariant et permet le surtypage et là, c'est très rare. En gros, tu te rends compte que A et B implémente tous les deux C, tu peux rajouter la liaison que A hérite de C et idem pour B, et cela marche ! C'est absolument génial car quelque soit l'arbre des classes, le ou les concepteurs ont toujours oublié un cas, surtout si tu mélanges plusieurs bibliothèques…

Je rajouterais qu'en plus d'Apple, il y avait Amiga (Commodore), Atari… Sur les PC, il y avait OS/2.

Bref, comme pour la photographie ou le cinéma, c'était dans l'air du temps et à quelques mois / années près, le résultat final n'aurait pas forcément été bien différent. Cf sur les téléphones ou Androïd domine et n'est pas spécialement plus sympa que Windows/DOS à l'époque. L'histoire se répète un peu ;-)

Pour le moment je continue faire "confiance" à Mozilla mais ça me turlupine.

Pourquoi pas un rapprochement de Mozilla et de Xorg via une intégration dans SPI ! Xorg était sur le point d'intégrer le SPI mais ça a foiré de peu et je ne sais plus pourquoi mais c'était pas vraiment la volonté des participants. Au final, on le voit avec FirefoxOS, Firefox joue petit à petit le même rôle que X…

c'est le premier langage que je vois de ma vie à évoluer aussi vite..

Tiens, en voila un qui sors une version tous les mois ;-)

http://rakudo.org/how-to-get-rakudo/

Si tu veux, en plus les détails d'implémentation varient selon les OS ;-) En pratique, on ne trouve pas de malloc dans du code C en mode noyau. J'ai pris exprès l'exemple de malloc car c'est vraiment l'instruction que tu vois très rapidement lorsque tu débutes en C ET qui n'est pas une vraie primitive du langage (comme printf…).

Comment ton programme peux avoir de la mémoire sans demander au noyau ? Voir par exemple https://fr.wikipedia.org/wiki/Appel_syst%C3%A8me

Il me semble que ce que tu décris est du passé, non sur la partie non libre ou il est clair que la FSF ne pousse pas au non libre (et ils n'ont pas tord) mais l'architecture de GCC a été fortement ouverte ces derniers temps et j'ai vu des greffons arriver sur cette plate-forme qu'on ne voyait que sur LLVM.

On voit que GCC évolue lui aussi et que la dernière version, 5.1, permet par exemple le JIT. Bref, il est désormais possible d'envisager une machine virtuelle dans GCC comme cela se fait sous LVVM.

L'équipe de Rust envisage t-elle un portable sur GCC ?