On peut concevoir un système de démarrage séquentiel ou basé sur des événements prévisible, propre et prenant en compte l'environnement autour. Pacemaker est un système proche de celui que nous décrivons.
Dans mon esprit, cet init utiliserait des scripts, mais j'avoue ne pas être un grand fan des scripts sh (comme le fait Pacemaker), je verrais bien du lua dans ce rôle (peut-être parce que NetBSD a choisi ce langage pour scripter le noyau). Ensuite, oui, il faudrait un système qui permet de lier des morceaux de lua à des événements. Cet init ne deviendrait plus qu'un cadre de travail fournissant les fonctionnalités de base à travers une jolie API en lua qui permettrait d'exprimer des trucs genre : Quand X est vrai, fait Y, où X est, en fait, une fonction qui attend sur le réseau et, quand l'attente est finie, fait une requête HTTPS pour récupérer un résultat, le parser et, selon le résultat, paramétrer le service correctement puis retourner vrai. Y est simplement l'exécution d'un binaire avec vérification de signature.
Tout ça n'est pas facile à obtenir aujourd'hui
Je penses que c'est plus facile qu'il n'y paraît si on part du principe que l'init ne doit fournir qu'un cadre de travail et n'essaie pas de tout faire. Après à chaque solution, donc distribution, administrateur, utilisateur, d'utiliser ce système comme il le souhaite.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Ce n'est pas parce qu'une fonctionnalité a été limitée qu'elle est inutile. Le problème du secureboot c'est de ne pas pouvoir ajouter soi-même ses propres clés. Ensuite j'ai lancé une série d'idée sans avoir vraiment réfléchi plus que 20 secondes à ce qui serait potentiellement faisable. D'autres solutions existent et trouver la meilleure serait un des objectifs de cet hypothétique projet.
Mais je reste convaincu qu'un système de démarrage qui te permette de te garantir que le ssh qui démarre est celui que tu as installé est utile. Si l'UEFI n'est pas utilisable, d'autres solutions le seront, ce n'est qu'une solution jetée au hasard parmi tant d'autre, pas de quoi fouetter un chat.
Et l'utilisateur lambda, rien à branler … je veux pas un système qui devienne numéro 1, je veux un système qui fonctionne bien … mais c'est de moins en moins le cas parce que l'objectif c'est d'être numéro 1 à tous les étages … tous les projets partent en sucette parce qu'il faut être numéro 1 alors qu'il y a quoi, 2% d'utilisateurs qui sont en fait dessus parce qu'ils ont justement envie à s'emmerder à bricoler leur système.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Pour le complexe, Zenitram a déjà répondu. Spécialisé ? La sécurité d'un système est un truc spécialisé en ces temps ? Je suis pas convaincu, ça jamais été autant essentiel et tout publique (des problèmes de sécurité qui font la une de journaux locaux c'est assez nouveau). Overkill ? Tout est là, il reste juste à assembler les éléments disponibles, pas tant overkill que ça.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Diverses solutions sont certainement possibles, je n'ai pas réfléchi spécifiquement mais, sans réfléchir, je dirais utilisation de TPM quand disponible, utilisation de média en lecture seul, utilisation de matériel spécialisé , … Il suffirait d'effectuer une signature des binaires, empêcher que la clé publique soit modifiée et fournir la clé privée uniquement durant les mises à jour pour signer les nouveaux binaires. Peut-être des solutions peuvent être trouvée du côté de UEFI, simplement chiffrée et l'utilisateur entre son mot de passe au démarrage (pour les ordinateurs de bureau par exemple), … bref la question reste ouverte car les possibilités sont multiples, mais ça reste réalisable.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Je ne connais pas les arguments de Upstart et d'ailleurs il n'en fait pas mention dans l'article, il fait mention de Upstart comment étant la seule alternative à sysv init qui "a pris" (dans l'intro), mais sinon il parle de vitesse, vitesse et vitesse, puis il parle de chose que fait Upstart (dans la partie "On Upstart") parce que justement c'est le seul qui "a pris" et donc ça vaut la peine d'analyser ce projet.
Mais tout le document parle d'aller plus vite en utilisant diverse technique ("start less" = démarrage à la demande, parallélisation parce que "CPU and disk IO bandwidth maxed out, and hence the overall start-up time minimized", socket activation parce que "their start-up is delayed" par l'attente, abandon des script parce que "Shell is fast and shell is slow. It is fast to hack, but slow in execution", …)
Non, ce document parle bien de comment faire le système de démarrage le plus rapide possible : systemd. Le but est déclaré dès le début puis répété à sous chaque titre, par contre il ne fait pas mention de la vitesse de Upstart.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Et ensuite une description de toute les techniques utilisées pour démarrer plus vite. De plus, le contexte de sortie de systemd correspond à la période où Intel annonçait vouloir un démarrage en 2 secondes maximum sur les netbooks, où Microsoft parlait de gagner une seconde en enlevant le logo au démarrage, … bref 2009-2010 c'était la période du démarrage ultra-rapide. systemd sortait dans se contexte annonçant qu'un bon système de démarrage démarrait vite.
Donc 1) Ils ne l'ont pas toujours dis et 2) l'accélération du boot était un objectif.
Ensuite je n'ai rien contre systemd mais je n'ai rien pour non plus. Il ne fais que synthétiser les us et coutumes des scripts de démarrage en un tout plus cohérent, ce qui est bien, mais ça reste trop faible car le constat de départ est erroné. Pour moi le constat qui aurait pu amener une évolution significatives, voir une révolution, c'est :
"Un bon système de démarrage a pour but d'amener un espace utilisateur propre de manière prévisible dans son déroulement en prenant en compte l'environnement autour du système".
Ce qui aurait donner un système de démarrage avec les fonctionnalités suivantes :
vérification du binaire exécuté avant exécution
possibilité d'attendre sur un service local ou distant
démarrage dans un ordre prévu par l'administrateur
possibilité de validé qu'un service démarrer est fonctionnel
Parce que ton ssh démarre que quand tu en as besoin c'est cool, mais que ton ssh est bien ton ssh et pas un ssh vérolé, je trouve ça mieux.
Parce que la réplication de ton ldap démarre que quand le ldap qu'il réplique est démarrer ça serait bien et, pour le bureau, que ton service dépendant de dropbox, goole drive, … démarre que quand ces services sont disponible, c'est un vrai plus.
Parce que quand ton serveur http démarre c'est cool, mais s'il se plante et ne répond pas, ben c'est un peu dommage.
Bref, systemd est là et le système de démarrage n'a finalement pas vraiment changé, par contre il a le mérite d'avoir lancé le débat sur les systèmes de démarrage (je me serais jamais posé la question qu'est-ce qu'un bon système de démarrage sans l'arrivée de systemd).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Le rapport est où ? Le chômage en Suisse n'est pas vraiment une préoccupation avec un taux oscillant entre 2 et 4% depuis 20 ans (et peut-être plus, je sais pas, pas regarder). D'ailleurs les arguments des initiants ne parlaient pas de réduction de chômage, uniquement de confort de vie. Bon c'est dommage, j'étais pour, je suis à 4 semaines par année …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Les gens du projet HyperCrypt, par exemple, critiquent la qualité du code de ClearCrypt. La description de ClearCrypt indique :
ClearCrypt : Considéré par la communauté de la sécurité comme une grosse bouse puante plein de caca avec une API romanesque et une implémentation fantaisiste.
L'avis des gens de HyperCrypt :
ClearCrypt est de la putain de sorcellerie et réaliser une nouvelle implémentation ClearCrypt interopérable peut seulement être faite par des sorciers.
Le projet HyperCrypt
HyperCrypt va être réaliser en Ada parce que c'est hyper plus sécurisé et le C c'est un langage tout pourri pour faire de la sécurité y'a qu'à regarder OpenSSH qui enchaîne faille sur faille et qui met en péril quotidiennement le monde Libre que ça fait même pleurer Blake et Mortimer.
Les certificats tout pourri X.509 seront dans un nouveau format grammar free, context free, word free afin que les chiens, les humains et la plantes carnivores d'appartement du premier étage puissent les lire quand ils s'emmerdent vraiment devant leur ordi.
Le protocole sera basé sur StraightXZ qui démontre un perte totale des paquets en cas de congestion réseau mais ça a été écrit par un grand nom de la sécurité alors c'est trop génial.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
C'est un peu ce que je dis, c'est utile à moitié. Donc inutile. Soit tu es sur un système de bureau et, finalement, tu n'as que très peu, voir pas du tout, de service en écoute sur le réseau, soit tu es sur un serveur et là tu vas mettre en place les tests complets de tes services et donc systemd ne fait qu'un truc inutile, un test sans intérêt vu qu'il y a des tests plus complets mis en place. En fait le seul cas utile de cette surveillance c'est pour les ordinateurs de bureau des "power user", mi-serveur, mi-"ordi de bureau". Et cette situation est normal, vu que systemd a été développé pour la vitesse de démarrage. D'ailleurs à l'annonce de systemd, l'explication de l'activation des sockets donne (emphase de moi):
[ … ] on MacOS the listening of the sockets is pulled out of all daemons and done by launchd. The services themselves hence can all start up in parallel and dependencies need not to be configured for them. And that is actually a really ingenious design, and the primary reason why MacOS manages to provide the fantastic boot-up times it provides
Ah oui, ben en fait ils ont fait ça pour avoir le « fantastic boot-up times » de MacOS … Et en plus ça permet de ne plus gérer les dépendances … Oh ! Mince ! En fait systemd ne fait pas de gestion des dépendances !
Enfin on en revient à mon premier message, systemd a été conçu uniquement pour la vitesse ; dans le cadre historique et dans l'annonce de sa sortie, tout concorde.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
C'est exactement ce que fait inetd. Et comme stunnel est à TLS ce que inetd est à IP, pourquoi systemd ne prend pas en charge l'initialisation des sockets TLS, dans leur logique ça devrait être le cas ?
Et "démarrer le réseau" dépend du service qui va tourner dessus. systemd supporte-t-il l'activation pour les services utilisant les "raw socket" (vrai question) ?
L'activation permet aussi le démarrage dans un ordre non garanti, et permet de relancer en cas de crash.
Il me semblait qu'une gestion des dépendances permettaient de lancer les services dans un ordre correct et non pas dans n'importe quel ordre.
Quand à la gestion des crash, c'est indépendant de l'activation des socket de systemd et, pour faire juste, il faudrait communiquer avec le service afin de contrôler son fonctionnement. Le service peut sembler fonctionnel alors qu'en fait il est planter, donc on est obliger de prévoir une solution supplémentaire capable de parler le protocole du service afin de s'assurer qu'il fonctionne correctement.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Une année avant la sortie (avril 2009) de systemd, Intel annonçait l'objectif du démarrage en 2 secondes pour son système Moblin (basé sur Linux). À ce moment là, la première version d'Android venait de sortir sur smartphone (octobre 2008) et Moblin était bien perçu pour entrer sur le marché mobile. Une année après l'annonce du démarrage en 2 secondes d'Intel, sortait le code de systemd avec un message expliquant qu'il était rapide. De mon point de vu, une année pour décider, designer, coder et sortir un système de démarrage tel que systemd me semble assez juste.
Donc du fait que systemd soit apparu durant une période où Linux faisait la course au démarrage et que le message de sortie de systemd ne parlait que d'un système de démarrage rapide, je suis convaincu que l'idée principale des devs de systemd était fast.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Sauf que la gestion n'est pas propre, "socket activation" en est la preuve. Si la gestion était propre, un service réseau ne démarrerait qu'après le réseau. Là, on fait croire au service que le réseau est là alors qu'on a juste systemd et son socket en carton … Ce truc existe juste pour la vitesse (on lance tout d'un coups et on gérera ensuite), une gestion propre des dépendances c'est : "si un service à besoin du réseau, il démarre quand le réseau est disponible". Comme pour le système autofs, si un service à besoin du système de fichier, il doit partir après que le système de fichier soit monté.
Faut arrêter ! systemd est conçu pour aller vite et c'est tout. Il suffit de relire l'annonce de systemd, tout tourne autour de fast !
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast.
For a fast and efficient boot-up two things are crucial:
D'ailleurs si on enlève le côté rapide de systemd, il ne reste plus rien de bénéfique. D'ailleurs ça faisait des années que je n'avais plus eu un ordinateur qui se vautrait au démarrage, systemd m'a ramené à cette bonne vieille période parce que mon fstab contenait une entrée plus valide mais sans grande importance.
Et maintenant quant à chaque fois que je lance "top" je vois systemd dans le top 3 sur un core i7, je me dis qu'on va se la prendre sévère dans la gueule.
Enfin, centralisation et monoculture, c'est la base d'un fiasco et c'est les fondamentaux de systemd …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Non, DH il y a un échange non-chiffré de valeurs pouvant être connues de tous et permettant d'obtenir une clé privée qui sera ensuite utilisée par un algorithme symétrique pour générer le message chiffré.
Le chiffrement c'est le fait de rendre un message incompréhensible par quiconque ne possédant pas la clé permettant de le rendre compréhensible. Dans un échange Diffie-Hellman, toutes les valeurs échangées sont compréhensibles par n'importe qui écoutant l'échange. Il n'y a pas le moindre chiffrement.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Il existe heureusement une parade si on utilise un cipher de type Diffie Hellman
Cipher veut dire algorithme de chiffrement/déchiffrement, Diffie-Hellman c'est une méthode (protocole) d'échange de clé (secret). Donc non, avec DH on ne fait pas de chiffrement, on s'échange un secret qui va permettre à un algorithme de chiffrement symétrique de chiffrer le message.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Non mais pacemaker fait ça. Tu démarres avec l'init classique les services de bases et ensuite pacemaker (corosync avant lui) et tu laisses pacemaker démarrer tes services l'un après l'autre en fonction des diverses contraintes que tu lui as indiqué. Sur les serveurs, l'init risque de devenir de plus en plus négligeable, il sera là juste pour lancer les deux, trois services de bases et les vrais services seront délégués à un système comme pacemaker. Et même dans les petites entreprises, le coût de deux machines est négligeable et l'installation d'un Pacemaker/DRBD/OCFS2/CTDB/Samba devrait tendre à se démocratiser.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Bah, d'ici la prochaine Debian, il y aura un nouveau système d'init encore plus révolutionnaire que systemd. Non parce que ce qui manque dans l'init actuel c'est de pouvoir, par exemple, lancer le service X quand le service Y a été lancé sur une autre machine puisqu'X est une réplication de Y ….
Qui pour commencer un projet d'init qui va mélanger les fonctionnalités de systemd et celles de pacemaker ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Je ne dis pas ça non plus car je suis particulièrement critique à l'égard de ce pays parce que j'y vis. Maintenant qu'est-ce que ça venait faire dans le débat cette remarque ? À part une attaque gratuite et sans intérêt.
Sinon tu ne peux pas comprendre aussi longtemps que tu compareras la législation suisse à celle de l'Europe ou de la France. C'est pas parce qu'en France il y a une histoire d'avocat en garde à vue avec l'Europe qui aussi mais non, qu'en Suisse c'est la même chose. Le pays ne fait ni parti de l'Europe, ni de la France. Donc s'il se passe des histoires trop cool avec des avocats en garde à vue en France, je ne peux être que content pour toi, mais ça change en rien la structure politique de la Suisse.
Alors pour mettre un terme, au lieu de citer une page de Wikipedia, allons-y pour citer la constitution suisse :
Art. 1 Confédération suisse
Le peuple suisse et les cantons de Zurich, de Berne, de Lucerne, d'Uri, de Schwyz, d'Obwald et de Nidwald, de Glaris, de Zoug, de Fribourg, de Soleure, de Bâle-Ville et de Bâle-Campagne, de Schaffhouse, d'Appenzell Rhodes-Extérieures et d'Appenzell Rhodes-Intérieures, de Saint-Gall, des Grisons, d'Argovie, de Thurgovie, du Tessin, de Vaud, du Valais, de Neuchâtel, de Genève et du Jura forment la Confédération suisse.
[…]
Art. 3 Cantons
Les cantons sont souverains en tant que leur souveraineté n'est pas limitée par la Constitution fédérale et exercent tous les droits qui ne sont pas délégués à la Confédération.
[…]
Art. 39 Exercice des droits politiques
1 La Confédération règle l'exercice des droits politiques au niveau fédéral; les cantons règlent ces droits aux niveaux cantonal et communal.
Donc on apprend que la Suisse est formée par des cantons souverains que la Suisse règle le droit de vote de la Suisse et que les cantons règlent le droit de vote des cantons souverains. C'est donc, honteusement, en 1971 que la Suisse a attribué le droit de vote aux femmes. Et, honteusement, c'est le seul pays sur cette foutu planète qui l'a fait par décision du peuple.
Finalement cette constitution a été votée, honteusement, par le peuple en 1999. On aurait aimé se voir imposé, fièrement, des traités de Maastricht, des V Républiques et autres traités et/ou consitutions par quelques puisssants, mais on a honteusement décidé de décider nous-même. Et c'est vraiment la honte de prendre son destin en main et décider au lieu de suivre bêtement des "leaders".
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
Sinon, on parle d'une différence de 20 ans, ça ne change pas que c'est la honte quand même ce 1971…
Tu oublies de dire qu'on a interdit les minarets, qu'on est un paradis fiscal et que c'est très flou la position de la Suisse durant la période nazi (et en mettant flou, je suis modéré).
Sinon le reste de ton explication est fumeuse et fausse, mais je crois que tu ne veux pas comprendre alors j'arrête de t'expliquer.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Justement
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 0.
Ouais on tombe quelque part entre sysv et systemd.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Justement
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 1.
Nos avis ne s'opposent aucunement.
On peut concevoir un système de démarrage séquentiel ou basé sur des événements prévisible, propre et prenant en compte l'environnement autour. Pacemaker est un système proche de celui que nous décrivons.
Dans mon esprit, cet init utiliserait des scripts, mais j'avoue ne pas être un grand fan des scripts sh (comme le fait Pacemaker), je verrais bien du lua dans ce rôle (peut-être parce que NetBSD a choisi ce langage pour scripter le noyau). Ensuite, oui, il faudrait un système qui permet de lier des morceaux de lua à des événements. Cet init ne deviendrait plus qu'un cadre de travail fournissant les fonctionnalités de base à travers une jolie API en lua qui permettrait d'exprimer des trucs genre : Quand X est vrai, fait Y, où X est, en fait, une fonction qui attend sur le réseau et, quand l'attente est finie, fait une requête HTTPS pour récupérer un résultat, le parser et, selon le résultat, paramétrer le service correctement puis retourner vrai. Y est simplement l'exécution d'un binaire avec vérification de signature.
Je penses que c'est plus facile qu'il n'y paraît si on part du principe que l'init ne doit fournir qu'un cadre de travail et n'essaie pas de tout faire. Après à chaque solution, donc distribution, administrateur, utilisateur, d'utiliser ce système comme il le souhaite.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Justement
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 10.
Ce n'est pas parce qu'une fonctionnalité a été limitée qu'elle est inutile. Le problème du secureboot c'est de ne pas pouvoir ajouter soi-même ses propres clés. Ensuite j'ai lancé une série d'idée sans avoir vraiment réfléchi plus que 20 secondes à ce qui serait potentiellement faisable. D'autres solutions existent et trouver la meilleure serait un des objectifs de cet hypothétique projet.
Mais je reste convaincu qu'un système de démarrage qui te permette de te garantir que le ssh qui démarre est celui que tu as installé est utile. Si l'UEFI n'est pas utilisable, d'autres solutions le seront, ce n'est qu'une solution jetée au hasard parmi tant d'autre, pas de quoi fouetter un chat.
Et l'utilisateur lambda, rien à branler … je veux pas un système qui devienne numéro 1, je veux un système qui fonctionne bien … mais c'est de moins en moins le cas parce que l'objectif c'est d'être numéro 1 à tous les étages … tous les projets partent en sucette parce qu'il faut être numéro 1 alors qu'il y a quoi, 2% d'utilisateurs qui sont en fait dessus parce qu'ils ont justement envie à s'emmerder à bricoler leur système.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Justement
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 3.
Pour le complexe, Zenitram a déjà répondu. Spécialisé ? La sécurité d'un système est un truc spécialisé en ces temps ? Je suis pas convaincu, ça jamais été autant essentiel et tout publique (des problèmes de sécurité qui font la une de journaux locaux c'est assez nouveau). Overkill ? Tout est là, il reste juste à assembler les éléments disponibles, pas tant overkill que ça.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Justement
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 2.
Diverses solutions sont certainement possibles, je n'ai pas réfléchi spécifiquement mais, sans réfléchir, je dirais utilisation de TPM quand disponible, utilisation de média en lecture seul, utilisation de matériel spécialisé , … Il suffirait d'effectuer une signature des binaires, empêcher que la clé publique soit modifiée et fournir la clé privée uniquement durant les mises à jour pour signer les nouveaux binaires. Peut-être des solutions peuvent être trouvée du côté de UEFI, simplement chiffrée et l'utilisateur entre son mot de passe au démarrage (pour les ordinateurs de bureau par exemple), … bref la question reste ouverte car les possibilités sont multiples, mais ça reste réalisable.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Justement
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 5.
Je ne connais pas les arguments de Upstart et d'ailleurs il n'en fait pas mention dans l'article, il fait mention de Upstart comment étant la seule alternative à sysv init qui "a pris" (dans l'intro), mais sinon il parle de vitesse, vitesse et vitesse, puis il parle de chose que fait Upstart (dans la partie "On Upstart") parce que justement c'est le seul qui "a pris" et donc ça vaut la peine d'analyser ce projet.
Mais tout le document parle d'aller plus vite en utilisant diverse technique ("start less" = démarrage à la demande, parallélisation parce que "CPU and disk IO bandwidth maxed out, and hence the overall start-up time minimized", socket activation parce que "their start-up is delayed" par l'attente, abandon des script parce que "Shell is fast and shell is slow. It is fast to hack, but slow in execution", …)
Non, ce document parle bien de comment faire le système de démarrage le plus rapide possible : systemd. Le but est déclaré dès le début puis répété à sous chaque titre, par contre il ne fait pas mention de la vitesse de Upstart.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Justement
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Centos / Redhat 7 : coup de gueule sur systemd. Évalué à 6.
Non, non et non. La première annonce introduit systemd avec le constat de départ suivant :
http://0pointer.de/blog/projects/systemd.html
Et ensuite une description de toute les techniques utilisées pour démarrer plus vite. De plus, le contexte de sortie de systemd correspond à la période où Intel annonçait vouloir un démarrage en 2 secondes maximum sur les netbooks, où Microsoft parlait de gagner une seconde en enlevant le logo au démarrage, … bref 2009-2010 c'était la période du démarrage ultra-rapide. systemd sortait dans se contexte annonçant qu'un bon système de démarrage démarrait vite.
Donc 1) Ils ne l'ont pas toujours dis et 2) l'accélération du boot était un objectif.
Ensuite je n'ai rien contre systemd mais je n'ai rien pour non plus. Il ne fais que synthétiser les us et coutumes des scripts de démarrage en un tout plus cohérent, ce qui est bien, mais ça reste trop faible car le constat de départ est erroné. Pour moi le constat qui aurait pu amener une évolution significatives, voir une révolution, c'est :
"Un bon système de démarrage a pour but d'amener un espace utilisateur propre de manière prévisible dans son déroulement en prenant en compte l'environnement autour du système".
Ce qui aurait donner un système de démarrage avec les fonctionnalités suivantes :
Parce que ton ssh démarre que quand tu en as besoin c'est cool, mais que ton ssh est bien ton ssh et pas un ssh vérolé, je trouve ça mieux.
Parce que la réplication de ton ldap démarre que quand le ldap qu'il réplique est démarrer ça serait bien et, pour le bureau, que ton service dépendant de dropbox, goole drive, … démarre que quand ces services sont disponible, c'est un vrai plus.
Parce que quand ton serveur http démarre c'est cool, mais s'il se plante et ne répond pas, ben c'est un peu dommage.
Bref, systemd est là et le système de démarrage n'a finalement pas vraiment changé, par contre il a le mérite d'avoir lancé le débat sur les systèmes de démarrage (je me serais jamais posé la question qu'est-ce qu'un bon système de démarrage sans l'arrivée de systemd).
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Encore des pleurnichards ....
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Que pensez-vous de cette citation de Axelle LEMAIRE ?. Évalué à 2.
Le rapport est où ? Le chômage en Suisse n'est pas vraiment une préoccupation avec un taux oscillant entre 2 et 4% depuis 20 ans (et peut-être plus, je sais pas, pas regarder). D'ailleurs les arguments des initiants ne parlaient pas de réduction de chômage, uniquement de confort de vie. Bon c'est dommage, j'étais pour, je suis à 4 semaines par année …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Encore des pleurnichards ....
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Que pensez-vous de cette citation de Axelle LEMAIRE ?. Évalué à 2.
?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# HyperCrypt
Posté par Etienne Bagnoud (site web personnel) . En réponse à la dépêche « Triple poignée de main », faille dans le protocole TLS. Évalué à 10.
Les gens du projet HyperCrypt, par exemple, critiquent la qualité du code de ClearCrypt. La description de ClearCrypt indique :
L'avis des gens de HyperCrypt :
Le projet HyperCrypt
HyperCrypt va être réaliser en Ada parce que c'est hyper plus sécurisé et le C c'est un langage tout pourri pour faire de la sécurité y'a qu'à regarder OpenSSH qui enchaîne faille sur faille et qui met en péril quotidiennement le monde Libre que ça fait même pleurer Blake et Mortimer.
Les certificats tout pourri X.509 seront dans un nouveau format grammar free, context free, word free afin que les chiens, les humains et la plantes carnivores d'appartement du premier étage puissent les lire quand ils s'emmerdent vraiment devant leur ordi.
Le protocole sera basé sur StraightXZ qui démontre un perte totale des paquets en cas de congestion réseau mais ça a été écrit par un grand nom de la sécurité alors c'est trop génial.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: If it works, don't fix it.
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à -6.
C'est un peu ce que je dis, c'est utile à moitié. Donc inutile. Soit tu es sur un système de bureau et, finalement, tu n'as que très peu, voir pas du tout, de service en écoute sur le réseau, soit tu es sur un serveur et là tu vas mettre en place les tests complets de tes services et donc systemd ne fait qu'un truc inutile, un test sans intérêt vu qu'il y a des tests plus complets mis en place. En fait le seul cas utile de cette surveillance c'est pour les ordinateurs de bureau des "power user", mi-serveur, mi-"ordi de bureau". Et cette situation est normal, vu que systemd a été développé pour la vitesse de démarrage. D'ailleurs à l'annonce de systemd, l'explication de l'activation des sockets donne (emphase de moi):
Ah oui, ben en fait ils ont fait ça pour avoir le « fantastic boot-up times » de MacOS … Et en plus ça permet de ne plus gérer les dépendances … Oh ! Mince ! En fait systemd ne fait pas de gestion des dépendances !
Enfin on en revient à mon premier message, systemd a été conçu uniquement pour la vitesse ; dans le cadre historique et dans l'annonce de sa sortie, tout concorde.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: If it works, don't fix it.
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 3.
C'est exactement ce que fait inetd. Et comme stunnel est à TLS ce que inetd est à IP, pourquoi systemd ne prend pas en charge l'initialisation des sockets TLS, dans leur logique ça devrait être le cas ?
Et "démarrer le réseau" dépend du service qui va tourner dessus. systemd supporte-t-il l'activation pour les services utilisant les "raw socket" (vrai question) ?
Il me semblait qu'une gestion des dépendances permettaient de lancer les services dans un ordre correct et non pas dans n'importe quel ordre.
Quand à la gestion des crash, c'est indépendant de l'activation des socket de systemd et, pour faire juste, il faudrait communiquer avec le service afin de contrôler son fonctionnement. Le service peut sembler fonctionnel alors qu'en fait il est planter, donc on est obliger de prévoir une solution supplémentaire capable de parler le protocole du service afin de s'assurer qu'il fonctionne correctement.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: If it works, don't fix it.
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 6.
Une année avant la sortie (avril 2009) de systemd, Intel annonçait l'objectif du démarrage en 2 secondes pour son système Moblin (basé sur Linux). À ce moment là, la première version d'Android venait de sortir sur smartphone (octobre 2008) et Moblin était bien perçu pour entrer sur le marché mobile. Une année après l'annonce du démarrage en 2 secondes d'Intel, sortait le code de systemd avec un message expliquant qu'il était rapide. De mon point de vu, une année pour décider, designer, coder et sortir un système de démarrage tel que systemd me semble assez juste.
Donc du fait que systemd soit apparu durant une période où Linux faisait la course au démarrage et que le message de sortie de systemd ne parlait que d'un système de démarrage rapide, je suis convaincu que l'idée principale des devs de systemd était fast.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: If it works, don't fix it.
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 8.
Sauf que la gestion n'est pas propre, "socket activation" en est la preuve. Si la gestion était propre, un service réseau ne démarrerait qu'après le réseau. Là, on fait croire au service que le réseau est là alors qu'on a juste systemd et son socket en carton … Ce truc existe juste pour la vitesse (on lance tout d'un coups et on gérera ensuite), une gestion propre des dépendances c'est : "si un service à besoin du réseau, il démarre quand le réseau est disponible". Comme pour le système autofs, si un service à besoin du système de fichier, il doit partir après que le système de fichier soit monté.
Faut arrêter ! systemd est conçu pour aller vite et c'est tout. Il suffit de relire l'annonce de systemd, tout tourne autour de fast !
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: If it works, don't fix it.
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 10.
Bon faut arrêter ces conneries, le but originel de systemd c'est, en premier lieu, un démarrage rapide. Le message d'annonce de systemd commence comme suit (emphase de moi) :
D'ailleurs si on enlève le côté rapide de systemd, il ne reste plus rien de bénéfique. D'ailleurs ça faisait des années que je n'avais plus eu un ordinateur qui se vautrait au démarrage, systemd m'a ramené à cette bonne vieille période parce que mon fstab contenait une entrée plus valide mais sans grande importance.
Et maintenant quant à chaque fois que je lance "top" je vois systemd dans le top 3 sur un core i7, je me dis qu'on va se la prendre sévère dans la gueule.
Enfin, centralisation et monoculture, c'est la base d'un fiasco et c'est les fondamentaux de systemd …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: DH ne chiffre pas
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Chiffrement SSL et confidentialité. Évalué à 5.
Non, DH il y a un échange non-chiffré de valeurs pouvant être connues de tous et permettant d'obtenir une clé privée qui sera ensuite utilisée par un algorithme symétrique pour générer le message chiffré.
Le chiffrement c'est le fait de rendre un message incompréhensible par quiconque ne possédant pas la clé permettant de le rendre compréhensible. Dans un échange Diffie-Hellman, toutes les valeurs échangées sont compréhensibles par n'importe qui écoutant l'échange. Il n'y a pas le moindre chiffrement.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# DH ne chiffre pas
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Chiffrement SSL et confidentialité. Évalué à 10. Dernière modification le 06 septembre 2013 à 09:23.
Cipher veut dire algorithme de chiffrement/déchiffrement, Diffie-Hellman c'est une méthode (protocole) d'échange de clé (secret). Donc non, avec DH on ne fait pas de chiffrement, on s'échange un secret qui va permettre à un algorithme de chiffrement symétrique de chiffrer le message.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Bah...
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 2.
Non mais pacemaker fait ça. Tu démarres avec l'init classique les services de bases et ensuite pacemaker (corosync avant lui) et tu laisses pacemaker démarrer tes services l'un après l'autre en fonction des diverses contraintes que tu lui as indiqué. Sur les serveurs, l'init risque de devenir de plus en plus négligeable, il sera là juste pour lancer les deux, trois services de bases et les vrais services seront délégués à un système comme pacemaker. Et même dans les petites entreprises, le coût de deux machines est négligeable et l'installation d'un Pacemaker/DRBD/OCFS2/CTDB/Samba devrait tendre à se démocratiser.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Bah...
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Les BSD isolés. Évalué à 3. Dernière modification le 05 septembre 2013 à 19:03.
Bah, d'ici la prochaine Debian, il y aura un nouveau système d'init encore plus révolutionnaire que systemd. Non parce que ce qui manque dans l'init actuel c'est de pouvoir, par exemple, lancer le service X quand le service Y a été lancé sur une autre machine puisqu'X est une réplication de Y ….
Qui pour commencer un projet d'init qui va mélanger les fonctionnalités de systemd et celles de pacemaker ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pas étonnant
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Howto LUKS, LVM et Debian ont fucké my head.. Évalué à 1.
L'installeur Debian ne le fait pas ?
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Et les couteaux ?
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Armée Suisse, modèle ou pas ?. Évalué à 9.
Pour les officiers, si, il y a un tire-bouchon …
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Ne pas oublier
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Armée Suisse, modèle ou pas ?. Évalué à 3.
Non bon bref, en effet, la Suisse est comme tu l'as défini.
Et sinon, oui, la liberté a un prix. Mais je préfère la payer moi-même que la faire payer à d'autres.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Ne pas oublier
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Armée Suisse, modèle ou pas ?. Évalué à 7.
Je ne dis pas ça non plus car je suis particulièrement critique à l'égard de ce pays parce que j'y vis. Maintenant qu'est-ce que ça venait faire dans le débat cette remarque ? À part une attaque gratuite et sans intérêt.
Sinon tu ne peux pas comprendre aussi longtemps que tu compareras la législation suisse à celle de l'Europe ou de la France. C'est pas parce qu'en France il y a une histoire d'avocat en garde à vue avec l'Europe qui aussi mais non, qu'en Suisse c'est la même chose. Le pays ne fait ni parti de l'Europe, ni de la France. Donc s'il se passe des histoires trop cool avec des avocats en garde à vue en France, je ne peux être que content pour toi, mais ça change en rien la structure politique de la Suisse.
Alors pour mettre un terme, au lieu de citer une page de Wikipedia, allons-y pour citer la constitution suisse :
[…]
[…]
Donc on apprend que la Suisse est formée par des cantons souverains que la Suisse règle le droit de vote de la Suisse et que les cantons règlent le droit de vote des cantons souverains. C'est donc, honteusement, en 1971 que la Suisse a attribué le droit de vote aux femmes. Et, honteusement, c'est le seul pays sur cette foutu planète qui l'a fait par décision du peuple.
Finalement cette constitution a été votée, honteusement, par le peuple en 1999. On aurait aimé se voir imposé, fièrement, des traités de Maastricht, des V Républiques et autres traités et/ou consitutions par quelques puisssants, mais on a honteusement décidé de décider nous-même. Et c'est vraiment la honte de prendre son destin en main et décider au lieu de suivre bêtement des "leaders".
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Ne pas oublier
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Armée Suisse, modèle ou pas ?. Évalué à 4.
Tu oublies de dire qu'on a interdit les minarets, qu'on est un paradis fiscal et que c'est très flou la position de la Suisse durant la période nazi (et en mettant flou, je suis modéré).
Sinon le reste de ton explication est fumeuse et fausse, mais je crois que tu ne veux pas comprendre alors j'arrête de t'expliquer.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Ne pas oublier
Posté par Etienne Bagnoud (site web personnel) . En réponse au journal Armée Suisse, modèle ou pas ?. Évalué à 2.
Si c'est sur wikipedia, c'est que c'est vrai.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell