J'ai l'impression que Mozilla est devenu une religion : si on dit du bien, pas de problème (bizarrement on ne me critique jamais quand j'en dit du bien), mais si on critique, c'est innacceptable et la personne qui critique est forcément de mauvaise foi (et à ignorer?).
Tu veux dire, un peu comme tes réactions dès que ça discute de systemd ?
la coque du portable fait de vieux bruit de craquement voulant dire: "tu joues aux cons"
Les deux sont équivalents grosso-modo : je me nique le poignet = il est lourd, donc je dois fournir un certain effort pour le maintenir en équilibre. Je fournis un certain effort = j’impose un stress à la coque qui fait un vieux bruit de craquement.
Autrement dit, l’observation "la coque ne craque plus" ne signifie pas nécessairement "la coque est plus solide", c’est simplement que plus léger = transportable avec un stress moins important sur la coque, indépendamment de la solidité de la coque.
En fait, plus je te relis, plus je me dis que tu es très très mal parti.
De deux choses l’une :
Soit ton but est de produire un langage. Dans ce cas tu prends les choses d’un très mauvais angle en lisant le dragon rouge ; c’est un très bon bouquin pour qui veut comprendre les bases d’une toolchain de compilation, mais aujourd’hui on peut très bien écrire un langage sans écrire un compilateur. Et les chaînes de compilation d’aujourd’hui sont bien bien plus évoluées ; jamais tu n’arriveras à leur cheville avec cette approche. Ce serait quelqu’un qui dirait « bon, mon but est de concurrencer Intel. Étape numéro 1 : bouquiner un peu de logique booléenne ». Aujourd’hui, pour faire un langage pour de vrai, soit tu es un géant (et dans ce cas tu ne posterais pas ce genre de questions ici), soit tu t’appuies sur un géant (LLVM au plus bas niveau, Rust/F#/Nim au plus haut niveau, étant donné que plus haut niveau = chemin de moindre résistance)
Soit ton but est de te faire plaisir en apprenant, et dans ce cas oublie l’idée de « réutiliser un langage existant ». Ce serait comme essayer d’apprendre la mécanique newtonienne en faisant du reverse-engineering sur un airbus.
Bref : dans ton message, un truc n’a absolument rien à faire là, soit le Dragon Book, soit Python. Commence déjà par clarifier ça :)
Prend un langage qui n’a aucun (ou presque) mot de clé de base comme Lisp
Lua est connu pour être aisément modifiable
En Ruby, tu peux quasiment tout faire sans utiliser de mot clé, par exemple tu peux définir une méthode si sur la classe bool pour te permettre de transformer :
if toto then
tata
end
en
toto.si {
tata
}
J’ai ouïe dire que tu peux aussi faire ce genre de chose en F#, SmallTalk, Nim, Scala et Rust. Les versions récentes de JavaScript (Harmony) sont aussi un bon candidat.
Si tu veux faire une chaine complète, diriges toi vers LLVM au lieu de vouloir réinventer la roue.
Je laisserai à d’autres le soin de troller sur l’intérêt douteux de la chose :)
The encoding has traditionally been either ASCII, one of its many derivatives such as ISO/IEC 646 etc., or sometimes EBCDIC. Unicode-based encodings such as UTF-8 and UTF-16 are gradually replacing the older ASCII derivatives limited to 7 or 8 bit codes.
Je vois pas ou est marqué "du texte brut" dans ce qui est cité, c'est une interprétation de ta part sur ce que tu estime être clair. Techniquement, du xml serait aussi du texte brut, ça n'a rien de clair en pratique.
« Voici la philosophie Unix : écrire un bon programme qui ne réalise qu’une seule tâche. Écrire des programmes coopérant entre eux. Écrire des programmes qui gèrent des flots de données textuelles, car cette interface est universelle. » (McIlroy)
« La tradition Unix encourage les programmes qui manipulent des formats simples, en mode texte, orientés flot et indépendants des équipements. Unix appelle de tels programmes des filtres ; ils reçoivent un simple flot de texte en entrée, le traitent et génèrent un simple flot de texte en sortie. » (Eric Raymond)
On peut quand même voi comment une simple phrase sorti de son contexte et répété advitam eternam en guise d’épitome d'un ouvrage exposant l'état de l'art de la recherche d'il y a 40 ans dans un domaine bougant à toute vitesse est encore trop compliqué pour que les gens l'utilisent pour exprimer une idée clair.
Je commence à trouver ça curieux qu'un groupe fortement imprégné par l'esprit scientifique en revienne presque à des méthodes shamanique de vénération des textes "anciens" sans avoir le moindre recul vis à vis d'eux et de leur propre position.
Tu interprètes (très) mal la situation à mon avis.
Comme tu dis, Unix est là depuis plus de 40 ans, dans un domaine extrêmement mouvant. Ce n’est probablement pas un hasard ; il y a très certainement des invariants dessous susceptibles d’expliquer sa longévité. La « philosophie Unix » que beaucoup ici traitent avec mépris, c’est justement une tentative d’isoler et expliciter ces invariants, dans l’objectif d’en tirer des leçons pour l’architecture logicielle en général.
Bien sûr, l’analyse peut être fausse, les conclusions erronées voire contreproductives. Mais ce n’est pas en balançant nonchalamment « 40 ans ; trop vieux » (alors qu’au contraire, la longévité serait plutôt bon signe) ou « chamanisme irrationel » (alors que justement, quand on creuse un peu, on se rend compte que la philosophie Unix, elle sort pas d’un chapeau, elle sort d’un gros boulot d’analyse effectué par de nombreuses et éminentes personnes).
Si tu prends l’exemple justement de l’insistance des interfaces textuelles, il y a plusieurs raisons à ça. La plus importante selon moi est la suivante : cela te force à faire une distinction entre la représentation algorithmique de tes données, la représentation fonctionnelle de tes données, et la représentation sémantique de tes données. Représentation algorithmique : comment représenter les données en mémoire pour résoudre efficacement le problème. Représentation fonctionnelle des données : comment communiquer efficacement l’état du problème à la machine. Représentation sémantique des données : comment communiquer efficacement l’état du problème à l’humain. Quand tu forces tes entrées et tes sorties à être textuelles, tu es forcé de te poser ces questions, parce que tu es forcé d’écrire la conversion entre les différentes représentations et ce même si tu n’as pas idée de ces distinctions. Ça te donne quasiment-automatiquement un système aisément débuggable et aisément testable. À contrario, le binaire, en général, ça se passe comme ça : je code mon algorithme. À partir de mon algorithme, je décide comment sont représentées en mémoire les entrées et les sorties. Et de là, je définis mon protocole binaire : en entrée, read(struct ProblemSpecification), en sortie write(struct Solution).
Bien sûr, tu peux très bien faire cette analyse avec un format binaire (par exemple protobuf), et la foirer avec un format texte (pas mal de formats XML en sont un bon exemple effectivement, mais ce n’est pas étonnant si tu gardes en tête l’analyse précédente : beaucoup de formats XML sont juste une image de la structure interne du programme). Mais en pratique, si on accepte l’idée que faire l’analyse poussée des différentes représentations est une bonne idée, alors la spécification des entrées/sorties en format textuel est une bonne méthodologie, parce que les incitations naturelles derrière y tendent. Pour parler très abstraitement, il n’y a pas équivalence entre « protocole textuel » et « bien conçu », mais il y a certainement corrélation.
Ceci n’est qu’une raison parmi un certain nombre, mais mon message commence à être déjà assez long comme ça (et il faudrait que j’aille dormir ;)), et il y a des bouquins entiers qui analysent la « philosophie Unix » de cette manière. Pas en tant que révérence irrationnelle envers un passé idéalisé, mais en tant que leçons pragmatiques à tirer.
La philosophie Unix ce n’est pas un Dieu bienfaisant qui va te garantir le succès si tu répètes quelque mantras. La philosophie Unix ce n’est pas non plus un Dieu colérique qui va te punir si tu ne fais pas exactement comme écrit dans La Loi. Mais c’est la sagesse condensée de gens qui ont fait plus pour l’informatique que tout ce que tu pourras rêver de faire, et il est aussi bon d’avoir un peu d’humilité avant de mettre tout ça à la poubelle d’un revers de main.
Tu peux critiquer la philosophie Unix. Seulement, si tu veux la critiquer efficacement, il faut d’abord la comprendre. Quelqu’un qui dit « philosophie Unix : texte, par exemple json_encode($internalStruct) » est bien plus éloigné de la philosophie Unix que quelqu’un qui dit « OK, mon programme va communiquer en protobuf (binaire), mais que ça ne me dispense pas de réfléchir aux différentes représentations de mon problème ». Mais le plus éloigné de tous, c’est celui qui dit « haha, utiliser du texte en 2015 juste parce que quelqu’un en 1970 a dit que c’était cool ? ridicule ! ». En fait, j’en envie de dire que c’est bel et bien ceux qui l’ont comprise qui sont le mieux placé pour violer les règles. Si je devais faire du 100% « strict philosophie Unix » à mon boulot, ça ferait longtemps que je serais à la porte (parce que bon, un programme en ligne de commande pour le service compta, ça va pas le faire :)) ; par contre, je suis bien placé pour savoir que mon efficacité sur l’analyse du problème et la recherche de solutions provient directement d’un état d’esprit qui découle de la philosophie Unix — et ce d’autant plus que je n’ai pas toujous été « Unixien », et que je vois clairement la différence entre « avant » et « après », en terme d’efficacité.
(et pour continuer à faire du mal à ces pauvres insectes, « texte brut » est tout à fait clair et fait référence à une dichotomie bien réelle, c’est par opposition à « texte formaté » type .doc/.rtf/.odt)
C’est la séparation d’un problème en sous-problèmes distincts.
Par exemple, pour le problème « je veux compter le nombre de commentaires dans un code python », je peux séparer mon problème en « extraire les commentaires d’un fichier python » (grep '#' < script.py) et « compter le nombre de lignes extraites (| wc -l). Le premier outil se fiche de ce que je veux faire de mon extraction (je pourrai les supprimer, faire une traduction automatique avec Google translate, whatever), le second outil se fiche d’où viennent mes lignes : les deux sont orthogonaux.
L’avantage c’est que je peux tester les outils indépendamment l’un de l’autre, et réutiliser l’un ou l’autre dans d’autres contextes.
Ce que je retiens, c'est surtout que si ce point de la philosophie unix était important, on tournerais plus sous qnx ou le hurd. Voir même sur darwin, si je me souviens bien.
Si les éviter les bugs était important, on utiliserait aucun outil plus compliqué que ed.
Comme si RH avait le moindre pouvoir sur Canonical, Debian, et surtout son concurrent SUSE.
Bien sûr que oui il en a, non pas en tant que concurrent, mais en tant q’upstream (RH est un très gros contributeur aux projets upstreams, que ce soit du côté du kernel, de Gnome, ou de systemd).
à quel moment systemd va lui donner plus de boulot qu'avant ?
Exemple:
You need the userspace code to set up the bus and its policy and handle
activation. That's not a trivial task. For us, that's what sytemd does
in PID 1. You'd need to come up with an alternative for that.
Note aux altercomprenants qui sévissent dans le coin. Je ne dis pas (je précise : je ne sous-entend même pas) que les devs systemd sont obligés de faire ce qu’on dit parce qu’ils sont nos esclaves (oui, aussi bizarre que ça puisse paraître, il faut préciser ça si on veut pas se faire traiter d’esclavagiste). Tout ce que je dis, c’est que l’assertion « le mouvement dans l’écosystème Linux initié par systemd impose plus de boulot aux développeurs de solutions alternatives » est un fait admis par Lennart lui-même, ce n’est pas une lubie des anti-systemd. D’ailleurs, ceux qui ont un peu de mémoire se souviendront que ça a même été un argument utilisé par Lennart lors du débat systemd/upstart chez Debian : avec tous les changements à venir (chamboulement des cgroups, intégration kdbus/wayland, changements udev…), upstart va avoir beaucoup de difficultés à tenir le rythme :
Anyway, summary is: I wish them good luck, they are now going their own way, stuck in a legacy stack with little new engineering, becoming an island of their own. In the short time frame they might save money with this decision, in the long run this is going to be quite expensive for them, since as our stacks start to diverge more and more adopting systemd later on will get more and more expensive.
Autrement dit : dans le futur, les alternatives à systemd seront forcées de suivre le rythme d’évolution imposé par systemd, et ce sera quelque chose loin d’être trivial.
Voilà : le message est clair : si on arrête pas systemd, Linux va disparaître et Red Hat avec. Il faut stopper Red Hat dans son action suicidaire, etc…
Où arrives-tu à lire ça ?
Le mec il dit :
then you may as well just surrender Linux to them
Et non pas seulement (qui pour le coup irait dans le sens de ton interprétation) :
then you may as well just surrender Linux
Le type ne dit pas que Linux va disparaître, le mec dit que Linux va être approprié par RedHat.
Mais je les ai compris depuis le début, tu ne fais que confrimer ma compréhension.
Ou pas. Si tu m’avais compris, je ne serai pas obligé à chaque réponse de te hurler dans les oreilles « arrête de me faire dire ce que je n’ai pas dit » (en vain on dirait).
Moi par contre, je savais exactement ce que tu allais répondre (mais bon comme tu dis c’est pas difficile, c’est pas comme si tu savais faire autre chose que répéter ton discours haineux « vous êtes des esclavagistes, des cons et des ignares »)
une fois le dorure "on est méchant contre nous" enlevé.
Je n’ai jamais dit ou sous-entendu ça. Sauf si on = Zenitram bien sûr, parce qu’il faut n’avoir aucun respect pour son interlocuteur pour agir comme tu le fais avec moi (me mettre dans une case anti-systemd haineux, m’attribuer des propos que je n’ai pas en fonction de cette case, et persister alors que ton modèle est constamment à côté de la plaque).
Par contre si on = les mainteneurs des ditribs et de systemd, non.
pourquoi ne pas assumer simplement regretter que les autres ne veulent plus bosser gratos pour soit, et devoir râler parce que les gens utilisent leur liberté?
Perdu, encore une fois.
Ce que je regrette, c’est, par exemple, le choix du mainteneur de systemd-udev de rendre systemd nécessaire pour le bon fonctionnement de udev. Et histoire d’éviter un cycle de « Zenitram : en fait tu dis que … — Moi : non, pas du tout » : je ne fais que dire que je regrette et pourquoi je regrette (exactement ce qui s’est dit ici, plus précisément Zenitram: Et pour le moment, personne n'a pu avancer le moindre argument qui se tient sur pourquoi il regrette.). Je ne dit pas, je ne sous-entend pas que les devs de systemd-udev devraient faire comme j’ai décidé parce que ce sont mes esclaves.
Au final, l'écosystème essaye d'avancer malgré le conservatisme, c'est tout, rien de nouveau, ça a été toujorus comme ça dans la vie et ça le sera sans doute toujours dans le futur.
Encore perdu. Ce n’est pas du conservatisme, puisque les mêmes qui critiquent systemd parce que réduisant la bidouillabilité sont au contraire plutôt enthousiastes pour Wayland qui augmente la bidouillabilité (en simplifiant le bordel mosntre qu’est X.org).
Et personnellement, j’ai changé de système d’init avant même que tu aies la moindre idée qu’il y avait des alternatives. Autant pour le « conservatisme ». De fait, les bidouilleurs sont rarement des conservateurs.
Bon, un conseil entre nous : quand un modèle (type « les anti-systemd sont des esclavagistes en puissance ») te donne des prédictions systématiquement à côté de la plaque, c’est une bonne indication qu’il est temps d’en changer. Après tu fais ce que tu veux hein, je ne dis pas que tu es mon esclave et que tu dois faire ce que je dis (apparemment il faut préciser). Si tu refuses c’est juste par conservatisme, c’est tout.
en attendant que le bidouilleur propose autant de possibilités tout en étant bidouillable
J’attends toujours un exemple concret de ce que je peux pas faire avec uselessd.
Mais au final on parle de la même chose
Ben non, et tu le dit toi même : point de vue bidouilleur vs point de vue utilisateur.
C’est quand même impressionnant cette capacité à s’auto-contredire en deux phrases.
dont on se fout un peu
Dont tu te fous. Donc beaucoup de gens qui veulent le « l’année de Linux sur le Desktop » se foutent.
Dont les bidouilleurs comme moi ou totof2000 ou moi ne se foutent pas (bon, remarque moi je m’en fous un peu aujourd’hui en pratique. Mais la bidouillabilité de Linux, c’est ce qui m’a initié à l’informatique, et oui, ça me fait un pincement au cœur de le voir disparaître au nom de « le clipping au démarrage de l’ordinateur ça fait so 80's »)
Le jour où tu auras compris ça, tu auras compris les anti-systemd.
Mais je ne me fais pas d’illusion : je sais exactement ce que tu vas répondre, parce que tu ne veux pas comprendre, tu veux juste troller pour passer le temps.
De quoi tu parles ? En quoi les devs de nosh, par exemple, « creusent un trou pour le reboucher » ?
Et après c’est moi qui suis insultant envers ceux qui bossent ?
Tu dis que oui c'est une preuve que les gens sont motivés, on dit que non c'est juste ne rien faire.
Faire quelque chose c’est ne rien faire. L’ignorance c’est la force, la guerre c’est la paix, la liberté c’est l’esclavage.
Moonz, qui ne fait pas de maintenance de grosse distro, a raison sur les mainteneurs de distros!
Où ai-je dit, sous-entendu, que j’avais raison sur les mainteneurs de distributions ?
Il n’y a aucune, 0, contradiction entre « les mainteneurs de distrib n’ont pas intégré initng » et « initng était largement prêt pour la prod et feature-complete (pour les features de son époque) ». Scoop : pour un tel composant de base, il y a plein d’autres axes d’analyse pertinents qui peuvent changer la réponse.
Mais bon pour Zenitram les mainteneurs des distrib sont des types complètement irrationnels qui sautent sur le dernier truc à la mode pour peu que ça apporte la moindre fonctionnalité (t’as vu, moi aussi je sais mettre des débilités dans la bouche des autres)
Ce qui a l'air de déranger, c'est que tout le monde qui bosse a décidé de migrer vers systemd
C’est pour ça que tu dis plus loin « mais non systemd est pas obligatoire il y a des distribs qui l’ont pas mis par défaut » (comme Slackware et Gentoo).
Ou alors faut croire que pour toi bosser c’est intégrer systemd et ceux qui le font pas ne font que creuser des trous pour les reboucher.
Et leur mainteneur a admit que systemd était meilleur globalement (en plus de la dure réalité que personne d'autre n'était interessé par ce logiciel, qui n'a pas su démontrer ses valeurs il faut croire, mais toi pense qu'il avait plus de qualité que systemd?), il va migrer sur systemd
Et qui a dit le contraire ici, bordel de merde ?
Je n’ai pas dit « upstart (entre autre) est meilleur que systemd ». J’ai dit « upstart est la preuve que des gens prêt à bosser sur les système d’init, ça existe ».
Quant à initng ou runit, ils sont très loin de couvrir tous les cas d'utilisation que systemd couvre car qui les utilisent ? à peu près personne.
La vache d’argument.
Des tas de logiciels qui ont une couverture fonctionnelle correcte ne sont pas utilisés hein (Opera chez les browsers a longtemps été plus fonctionnel que tout les autres navigateurs du marché, en étant incapable de décoller)
Et aucune distrib ne l’utilise par défaut ≠ personne ne l’utilise (oui, je sais, un truc de fou !)
Initng (pour ce que je connais, runit j’ai jamais testé) effectivement n’a pas la même couverture fonctionnelle que systemd : il n’a pas de gestion des cgroups par exemple. Tout simplement parce qu’à l’époque de son développement, ça n’existait pas, pas parce que c’était un proof of concept pas sérieux.
Et sinon, ça change quoi à l’argument de base qui est « il existe des mainteneurs d’init alternatifs donc oui il y a des gens qui sont prêt à bosser » ?
Euh, je le trouve justement moins rigide que SysV ou Upstart, dans le sens où je peux remplacer les options d'une unité présente dans /etc en la copiant ailleurs en étant sûr que ça marchera, plutôt que d'être obligé de modifier des scripts bash en root dans /etc/init.d/
Vous parlez pas de la même chose.
Rigidité dans le sens de totof2000, c’est la capacité de remplacer/supprimer un composant individuel (par exemple /bin/init) sans avoir à chambouler les 3/4 du reste du système.
Donc si un projet Gtk devient un projet Gnome, ou si un projet Qt devient un projet KDE, on doit s'attendre à voir le même foin que pour udev dans systemd?
Figure toi que oui, ça a râlé quand Gtk a proposé de dépendre de certaines parties de Gnome.
[^] # Re: Et SourceSup
Posté par Moonz . En réponse au journal Fermeture progressive de Google Code. Évalué à 3.
Gitlab peut parfaitement tourner en interne.
Github aussi d’ailleurs, mais faut payer pour ça.
[^] # Re: Euh...
Posté par Moonz . En réponse au journal Tristan Nitot rejoint Cozy Cloud. Évalué à 1.
Tu veux dire, un peu comme tes réactions dès que ça discute de systemd ?
[^] # Re: ultra-fin
Posté par Moonz . En réponse au journal Tic-tac, tic-tac, tic-tac... plouf.. Évalué à 7.
Les deux sont équivalents grosso-modo : je me nique le poignet = il est lourd, donc je dois fournir un certain effort pour le maintenir en équilibre. Je fournis un certain effort = j’impose un stress à la coque qui fait un vieux bruit de craquement.
Autrement dit, l’observation "la coque ne craque plus" ne signifie pas nécessairement "la coque est plus solide", c’est simplement que plus léger = transportable avec un stress moins important sur la coque, indépendamment de la solidité de la coque.
[^] # Re: Au contraire
Posté par Moonz . En réponse au journal Tic-tac, tic-tac, tic-tac... plouf.. Évalué à 5.
La différence entre frein à main, pédale de frein et frein moteur, c’est pas de la mécanique ? (par exemple)
[^] # Re: Tres bon
Posté par Moonz . En réponse à la dépêche Sortie du noyau Linux 3.19. Évalué à 8.
Linux n’a pas les drivers dont ton écran n’a pas besoin ? J’ai du mal à voir où est le souci du coup.
[^] # Re: Facile
Posté par Moonz . En réponse au journal Et vous, à votre avis, pour où commencer une quête pour une chaîne de compilation espérantophone ?. Évalué à 10.
En fait, plus je te relis, plus je me dis que tu es très très mal parti.
De deux choses l’une :
Soit ton but est de produire un langage. Dans ce cas tu prends les choses d’un très mauvais angle en lisant le dragon rouge ; c’est un très bon bouquin pour qui veut comprendre les bases d’une toolchain de compilation, mais aujourd’hui on peut très bien écrire un langage sans écrire un compilateur. Et les chaînes de compilation d’aujourd’hui sont bien bien plus évoluées ; jamais tu n’arriveras à leur cheville avec cette approche. Ce serait quelqu’un qui dirait « bon, mon but est de concurrencer Intel. Étape numéro 1 : bouquiner un peu de logique booléenne ». Aujourd’hui, pour faire un langage pour de vrai, soit tu es un géant (et dans ce cas tu ne posterais pas ce genre de questions ici), soit tu t’appuies sur un géant (LLVM au plus bas niveau, Rust/F#/Nim au plus haut niveau, étant donné que plus haut niveau = chemin de moindre résistance)
Soit ton but est de te faire plaisir en apprenant, et dans ce cas oublie l’idée de « réutiliser un langage existant ». Ce serait comme essayer d’apprendre la mécanique newtonienne en faisant du reverse-engineering sur un airbus.
Bref : dans ton message, un truc n’a absolument rien à faire là, soit le Dragon Book, soit Python. Commence déjà par clarifier ça :)
# Facile
Posté par Moonz . En réponse au journal Et vous, à votre avis, pour où commencer une quête pour une chaîne de compilation espérantophone ?. Évalué à 7. Dernière modification le 05 mars 2015 à 20:27.
Dans le désordre :
Prend un langage qui n’a aucun (ou presque) mot de clé de base comme Lisp
Lua est connu pour être aisément modifiable
En Ruby, tu peux quasiment tout faire sans utiliser de mot clé, par exemple tu peux définir une méthode
sisur la classe bool pour te permettre de transformer :en
J’ai ouïe dire que tu peux aussi faire ce genre de chose en F#, SmallTalk, Nim, Scala et Rust. Les versions récentes de JavaScript (Harmony) sont aussi un bon candidat.
Je laisserai à d’autres le soin de troller sur l’intérêt douteux de la chose :)
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 1.
C’est écrit dans l’article lié plus haut.
[^] # Re: Tres bon
Posté par Moonz . En réponse à la dépêche Sortie du noyau Linux 3.19. Évalué à 3.
Généralement ça marchait mais en mode dégradé, limité à 640x480 avec 16 bits de profondeur.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10.
« Voici la philosophie Unix : écrire un bon programme qui ne réalise qu’une seule tâche. Écrire des programmes coopérant entre eux. Écrire des programmes qui gèrent des flots de données textuelles, car cette interface est universelle. » (McIlroy)
« La tradition Unix encourage les programmes qui manipulent des formats simples, en mode texte, orientés flot et indépendants des équipements. Unix appelle de tels programmes des filtres ; ils reçoivent un simple flot de texte en entrée, le traitent et génèrent un simple flot de texte en sortie. » (Eric Raymond)
Tu interprètes (très) mal la situation à mon avis.
Comme tu dis, Unix est là depuis plus de 40 ans, dans un domaine extrêmement mouvant. Ce n’est probablement pas un hasard ; il y a très certainement des invariants dessous susceptibles d’expliquer sa longévité. La « philosophie Unix » que beaucoup ici traitent avec mépris, c’est justement une tentative d’isoler et expliciter ces invariants, dans l’objectif d’en tirer des leçons pour l’architecture logicielle en général.
Bien sûr, l’analyse peut être fausse, les conclusions erronées voire contreproductives. Mais ce n’est pas en balançant nonchalamment « 40 ans ; trop vieux » (alors qu’au contraire, la longévité serait plutôt bon signe) ou « chamanisme irrationel » (alors que justement, quand on creuse un peu, on se rend compte que la philosophie Unix, elle sort pas d’un chapeau, elle sort d’un gros boulot d’analyse effectué par de nombreuses et éminentes personnes).
Si tu prends l’exemple justement de l’insistance des interfaces textuelles, il y a plusieurs raisons à ça. La plus importante selon moi est la suivante : cela te force à faire une distinction entre la représentation algorithmique de tes données, la représentation fonctionnelle de tes données, et la représentation sémantique de tes données. Représentation algorithmique : comment représenter les données en mémoire pour résoudre efficacement le problème. Représentation fonctionnelle des données : comment communiquer efficacement l’état du problème à la machine. Représentation sémantique des données : comment communiquer efficacement l’état du problème à l’humain. Quand tu forces tes entrées et tes sorties à être textuelles, tu es forcé de te poser ces questions, parce que tu es forcé d’écrire la conversion entre les différentes représentations et ce même si tu n’as pas idée de ces distinctions. Ça te donne quasiment-automatiquement un système aisément débuggable et aisément testable. À contrario, le binaire, en général, ça se passe comme ça : je code mon algorithme. À partir de mon algorithme, je décide comment sont représentées en mémoire les entrées et les sorties. Et de là, je définis mon protocole binaire : en entrée,
read(struct ProblemSpecification), en sortiewrite(struct Solution).Bien sûr, tu peux très bien faire cette analyse avec un format binaire (par exemple protobuf), et la foirer avec un format texte (pas mal de formats XML en sont un bon exemple effectivement, mais ce n’est pas étonnant si tu gardes en tête l’analyse précédente : beaucoup de formats XML sont juste une image de la structure interne du programme). Mais en pratique, si on accepte l’idée que faire l’analyse poussée des différentes représentations est une bonne idée, alors la spécification des entrées/sorties en format textuel est une bonne méthodologie, parce que les incitations naturelles derrière y tendent. Pour parler très abstraitement, il n’y a pas équivalence entre « protocole textuel » et « bien conçu », mais il y a certainement corrélation.
Ceci n’est qu’une raison parmi un certain nombre, mais mon message commence à être déjà assez long comme ça (et il faudrait que j’aille dormir ;)), et il y a des bouquins entiers qui analysent la « philosophie Unix » de cette manière. Pas en tant que révérence irrationnelle envers un passé idéalisé, mais en tant que leçons pragmatiques à tirer.
La philosophie Unix ce n’est pas un Dieu bienfaisant qui va te garantir le succès si tu répètes quelque mantras. La philosophie Unix ce n’est pas non plus un Dieu colérique qui va te punir si tu ne fais pas exactement comme écrit dans La Loi. Mais c’est la sagesse condensée de gens qui ont fait plus pour l’informatique que tout ce que tu pourras rêver de faire, et il est aussi bon d’avoir un peu d’humilité avant de mettre tout ça à la poubelle d’un revers de main.
Tu peux critiquer la philosophie Unix. Seulement, si tu veux la critiquer efficacement, il faut d’abord la comprendre. Quelqu’un qui dit « philosophie Unix : texte, par exemple
json_encode($internalStruct)» est bien plus éloigné de la philosophie Unix que quelqu’un qui dit « OK, mon programme va communiquer en protobuf (binaire), mais que ça ne me dispense pas de réfléchir aux différentes représentations de mon problème ». Mais le plus éloigné de tous, c’est celui qui dit « haha, utiliser du texte en 2015 juste parce que quelqu’un en 1970 a dit que c’était cool ? ridicule ! ». En fait, j’en envie de dire que c’est bel et bien ceux qui l’ont comprise qui sont le mieux placé pour violer les règles. Si je devais faire du 100% « strict philosophie Unix » à mon boulot, ça ferait longtemps que je serais à la porte (parce que bon, un programme en ligne de commande pour le service compta, ça va pas le faire :)) ; par contre, je suis bien placé pour savoir que mon efficacité sur l’analyse du problème et la recherche de solutions provient directement d’un état d’esprit qui découle de la philosophie Unix — et ce d’autant plus que je n’ai pas toujous été « Unixien », et que je vois clairement la différence entre « avant » et « après », en terme d’efficacité.[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3. Dernière modification le 26 février 2015 à 16:25.
Plain text
(qui est explicitement écrit dans l’article Text-based protocol)
Ho, et avant de me dire « oui mais texte brut en français c’est pas ça », regardez quelle est la version française de l’article anglais…
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3. Dernière modification le 26 février 2015 à 16:19.
(et pour continuer à faire du mal à ces pauvres insectes, « texte brut » est tout à fait clair et fait référence à une dichotomie bien réelle, c’est par opposition à « texte formaté » type .doc/.rtf/.odt)
[^] # Re: Orthogonalité ?
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10. Dernière modification le 26 février 2015 à 12:19.
C’est la séparation d’un problème en sous-problèmes distincts.
Par exemple, pour le problème « je veux compter le nombre de commentaires dans un code python », je peux séparer mon problème en « extraire les commentaires d’un fichier python » (
grep '#' < script.py) et « compter le nombre de lignes extraites (| wc -l). Le premier outil se fiche de ce que je veux faire de mon extraction (je pourrai les supprimer, faire une traduction automatique avec Google translate, whatever), le second outil se fiche d’où viennent mes lignes : les deux sont orthogonaux.L’avantage c’est que je peux tester les outils indépendamment l’un de l’autre, et réutiliser l’un ou l’autre dans d’autres contextes.
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 3.
Text-based protocol
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
Si les éviter les bugs était important, on utiliserait aucun outil plus compliqué que
ed.[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 6.
Bien sûr que oui il en a, non pas en tant que concurrent, mais en tant q’upstream (RH est un très gros contributeur aux projets upstreams, que ce soit du côté du kernel, de Gnome, ou de systemd).
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10.
Exemple:
Lennart Poettering
Note aux altercomprenants qui sévissent dans le coin. Je ne dis pas (je précise : je ne sous-entend même pas) que les devs systemd sont obligés de faire ce qu’on dit parce qu’ils sont nos esclaves (oui, aussi bizarre que ça puisse paraître, il faut préciser ça si on veut pas se faire traiter d’esclavagiste). Tout ce que je dis, c’est que l’assertion « le mouvement dans l’écosystème Linux initié par systemd impose plus de boulot aux développeurs de solutions alternatives » est un fait admis par Lennart lui-même, ce n’est pas une lubie des anti-systemd. D’ailleurs, ceux qui ont un peu de mémoire se souviendront que ça a même été un argument utilisé par Lennart lors du débat systemd/upstart chez Debian : avec tous les changements à venir (chamboulement des cgroups, intégration kdbus/wayland, changements udev…), upstart va avoir beaucoup de difficultés à tenir le rythme :
Autrement dit : dans le futur, les alternatives à systemd seront forcées de suivre le rythme d’évolution imposé par systemd, et ce sera quelque chose loin d’être trivial.
[^] # Re: Z spotted
Posté par Moonz . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 5.
Où arrives-tu à lire ça ?
Le mec il dit :
Et non pas seulement (qui pour le coup irait dans le sens de ton interprétation) :
Le type ne dit pas que Linux va disparaître, le mec dit que Linux va être approprié par RedHat.
[^] # Re: Du bon et du mauvais
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à -1.
Pourquoi est-il nécessaire de le répéter pour la 15e fois ?
La possibilité de changer un composant (par exemple
/bin/init) sans avoir à chambouler tout le reste (udev, dbus,…)[^] # Re: Du bon et du mauvais
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 5. Dernière modification le 19 février 2015 à 10:31.
Ou pas. Si tu m’avais compris, je ne serai pas obligé à chaque réponse de te hurler dans les oreilles « arrête de me faire dire ce que je n’ai pas dit » (en vain on dirait).
Moi par contre, je savais exactement ce que tu allais répondre (mais bon comme tu dis c’est pas difficile, c’est pas comme si tu savais faire autre chose que répéter ton discours haineux « vous êtes des esclavagistes, des cons et des ignares »)
Je n’ai jamais dit ou sous-entendu ça. Sauf si on = Zenitram bien sûr, parce qu’il faut n’avoir aucun respect pour son interlocuteur pour agir comme tu le fais avec moi (me mettre dans une case anti-systemd haineux, m’attribuer des propos que je n’ai pas en fonction de cette case, et persister alors que ton modèle est constamment à côté de la plaque).
Par contre si on = les mainteneurs des ditribs et de systemd, non.
Perdu, encore une fois.
Ce que je regrette, c’est, par exemple, le choix du mainteneur de systemd-udev de rendre systemd nécessaire pour le bon fonctionnement de udev. Et histoire d’éviter un cycle de « Zenitram : en fait tu dis que … — Moi : non, pas du tout » : je ne fais que dire que je regrette et pourquoi je regrette (exactement ce qui s’est dit ici, plus précisément Zenitram: Et pour le moment, personne n'a pu avancer le moindre argument qui se tient sur pourquoi il regrette.). Je ne dit pas, je ne sous-entend pas que les devs de systemd-udev devraient faire comme j’ai décidé parce que ce sont mes esclaves.
Encore perdu. Ce n’est pas du conservatisme, puisque les mêmes qui critiquent systemd parce que réduisant la bidouillabilité sont au contraire plutôt enthousiastes pour Wayland qui augmente la bidouillabilité (en simplifiant le bordel mosntre qu’est X.org).
Et personnellement, j’ai changé de système d’init avant même que tu aies la moindre idée qu’il y avait des alternatives. Autant pour le « conservatisme ». De fait, les bidouilleurs sont rarement des conservateurs.
Bon, un conseil entre nous : quand un modèle (type « les anti-systemd sont des esclavagistes en puissance ») te donne des prédictions systématiquement à côté de la plaque, c’est une bonne indication qu’il est temps d’en changer. Après tu fais ce que tu veux hein, je ne dis pas que tu es mon esclave et que tu dois faire ce que je dis (apparemment il faut préciser). Si tu refuses c’est juste par conservatisme, c’est tout.
[^] # Re: Du bon et du mauvais
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 2.
J’attends toujours un exemple concret de ce que je peux pas faire avec uselessd.
Ben non, et tu le dit toi même : point de vue bidouilleur vs point de vue utilisateur.
C’est quand même impressionnant cette capacité à s’auto-contredire en deux phrases.
Dont tu te fous. Donc beaucoup de gens qui veulent le « l’année de Linux sur le Desktop » se foutent.
Dont les bidouilleurs comme moi ou totof2000 ou moi ne se foutent pas (bon, remarque moi je m’en fous un peu aujourd’hui en pratique. Mais la bidouillabilité de Linux, c’est ce qui m’a initié à l’informatique, et oui, ça me fait un pincement au cœur de le voir disparaître au nom de « le clipping au démarrage de l’ordinateur ça fait so 80's »)
Le jour où tu auras compris ça, tu auras compris les anti-systemd.
Mais je ne me fais pas d’illusion : je sais exactement ce que tu vas répondre, parce que tu ne veux pas comprendre, tu veux juste troller pour passer le temps.
[^] # Re: Du bon et du mauvais
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 6.
De quoi tu parles ? En quoi les devs de nosh, par exemple, « creusent un trou pour le reboucher » ?
Et après c’est moi qui suis insultant envers ceux qui bossent ?
Faire quelque chose c’est ne rien faire. L’ignorance c’est la force, la guerre c’est la paix, la liberté c’est l’esclavage.
Où ai-je dit, sous-entendu, que j’avais raison sur les mainteneurs de distributions ?
Il n’y a aucune, 0, contradiction entre « les mainteneurs de distrib n’ont pas intégré initng » et « initng était largement prêt pour la prod et feature-complete (pour les features de son époque) ». Scoop : pour un tel composant de base, il y a plein d’autres axes d’analyse pertinents qui peuvent changer la réponse.
Mais bon pour Zenitram les mainteneurs des distrib sont des types complètement irrationnels qui sautent sur le dernier truc à la mode pour peu que ça apporte la moindre fonctionnalité (t’as vu, moi aussi je sais mettre des débilités dans la bouche des autres)
C’est pour ça que tu dis plus loin « mais non systemd est pas obligatoire il y a des distribs qui l’ont pas mis par défaut » (comme Slackware et Gentoo).
Ou alors faut croire que pour toi bosser c’est intégrer systemd et ceux qui le font pas ne font que creuser des trous pour les reboucher.
Et qui a dit le contraire ici, bordel de merde ?
Je n’ai pas dit « upstart (entre autre) est meilleur que systemd ». J’ai dit « upstart est la preuve que des gens prêt à bosser sur les système d’init, ça existe ».
[^] # Re: Du bon et du mauvais
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 3.
La vache d’argument.
Des tas de logiciels qui ont une couverture fonctionnelle correcte ne sont pas utilisés hein (Opera chez les browsers a longtemps été plus fonctionnel que tout les autres navigateurs du marché, en étant incapable de décoller)
Et aucune distrib ne l’utilise par défaut ≠ personne ne l’utilise (oui, je sais, un truc de fou !)
Initng (pour ce que je connais, runit j’ai jamais testé) effectivement n’a pas la même couverture fonctionnelle que systemd : il n’a pas de gestion des cgroups par exemple. Tout simplement parce qu’à l’époque de son développement, ça n’existait pas, pas parce que c’était un proof of concept pas sérieux.
Et sinon, ça change quoi à l’argument de base qui est « il existe des mainteneurs d’init alternatifs donc oui il y a des gens qui sont prêt à bosser » ?
[^] # Re: Du bon et du mauvais
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 3.
Vous parlez pas de la même chose.
Rigidité dans le sens de totof2000, c’est la capacité de remplacer/supprimer un composant individuel (par exemple /bin/init) sans avoir à chambouler les 3/4 du reste du système.
[^] # Re: Du bon et du mauvais
Posté par Moonz . En réponse au journal SD-Boot, l'EFI Boot Manager & Stub Loader de systemd, arrive. Évalué à 5.
RedHat, pourquoi ?
Figure toi que oui, ça a râlé quand Gtk a proposé de dépendre de certaines parties de Gnome.