car "Red Hat Enterprise Linux Roadmap: Part 1", ça ne se traduit pas vraiment pas "truc qu'on envisage". Si c'était "stuff that we are looking at", ou une expression similaire,
Et si par exemple c'était dans la partie "Development Topics" slides 31 à 37 qui liste les limitations, les améliorations et les éléments qui sont en cours d'études et de développement, il se passerait quoi ?
Je pourrais sans doute continuer pendant des heures, mais je vais pas m'acharner sur le sujet
Surtout que tout ton argumentaire repose sur le fait qu'il fasse leurs études et tests sur Fedora, chose que j'ai signalé dans mon post au fait. Et que donc il va leur être difficile de na pas mettre systemd dans RH 7 (ce que j'ai dit aussi).
je suis sur que tu as des tas d'arguments et de témoignage de gens qui sont super proche du pdg de RH
Ben justement non j'en ai aucun. Que ce soit chez Suse ou chez Red Hat ca joue à ni oui ni non. Même le support (payant) RH est pas foutu de répondre à la question "dans RH7 ca sera systemd ou sysinit ou les deux".
Or le truc c'est que dans le milieu professionnel les "c'est évident" et les "ca se voit" on a tendance à s'en méfier pas mal. (Surtout avec RH à qui ca ne fait pas peur de faire passer à la trappe une techno du jour au lendemain).
_ et que même si Arch et Mageia ont fait la migration avec 3 bouts de ficelle sans soucis majeurs, c'est impossible que des boites avec plus de moyens fassent de même_
OK. Donc tu n'as juste pas compris le problème en fait.
En dehors des utilisateurs qui utilisent Linux pour s'amuser et s'instruire, il y a des sociétés (parfois même des grosses sociétés) qui utilisent Linux pour traiter des données sensibles, des fois vitales à la boite, dans leur activité de tous les jours. Ces sociétés ne représentent pas une portion très importante des utilisateurs de Linux, par contre elles représentent 100% des clients payant de boites comme RH ou Suse.
Or ces sociétés ont souvent des scripts, des outils, des programmes même codés maison et qui utilisent la puissance de l'init traditionnel pour fonctionner (processing turing complet, prise en charge des variables d'environnement, init prévisible, logs dans des fichiers plats etc.)
Je n'ai pas vraiment de vision sur ces sociétés, je n'en connais que trois. Mais les trois que je connais (en l’occurrence leurs sysadmin) ne veulent pas de systemd. Et ils n'en veulent pas parce que :
a) Il y a beaucoup de boulot et de tests à faire pour s'assurer que tout fonctionne.
b) Certaines choses (certains fs chiffrés, demande de mot de passe à l'init par service, templates etc.) ne sont pas possible avec systemd.
c) Systemd n'est pas fini/normalisé et du coup même si ils trouvent des parades aujourd'hui rien ne prouve qu'elles seront encore valables dans dix jours (spéciale dédicace udev)
Le fait que ArchLinux et Mageia ait fait le pas en tant que distrib ne prouve rien au niveau de l'utilisabitlité du bigniou par des sysadmins.
Ah, on me dit dans l'oreille que c'est pas parce qu'il y a marqué systemd dans un rapport de bug que c'est un bug sur systemd et que ta liste est utilisé juste pour du FUD. Dommage, presque crédible.
Ah oui, je donne la liste mais j'ai oublié de dire qu'il fallait lire :
Bug 774126 : si on se logue trop tôt sur une interface série le getty crashe définitivement. Il existe une solution mais elle est trop complexe pour être backportée
Bug 779434 : pas de splash dans le boot kernel, pas de /var. Systemd refuse de monter le /var si plymouthd a un fichier de lock qui traine dessus. COOOL
Bug 780006 : Un boot pas à pas dans systemd ? Vous plaisantez bien sur. De..bug ? Jamais entendu parlé.
Bug 780441 : L'automount NFS ne marche pas (pas chez Fedora non plus) - mais on a presque fini d'avoir une bonne idée sur comment contourner le problème. (N.B : ce bug a une priorité P5 - none. Autmount NFS ? Ca interresse quelqu'un ? )
Bug 767394 : Un disque plein ? C'est un scandale ! Je me casse… (signé systemd).
Après tu fais comme tu veux, mais moi ce genre de bugs sur des trucs que j'utilise couramment (pas comme le timer du device machin sur une architecture ARM spécifique que l'on ne retrouve que sur des téléphones portables hackés) ca me fait peur.
L'init doit être le process le plus robuste qui soit. C'est lui le centre névralgique du système. Si il bugue on ne peut plus rien faire. L'init est presque plus importante que le kernel au niveau debug (une bonne init peut permettre de comprendre ce qui a chié dans le kernel, la réciproque n'est pas vraie).
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 10.
car "Red Hat Enterprise Linux Roadmap: Part 1", ça ne se traduit pas vraiment pas "truc qu'on envisage". Si c'était "stuff that we are looking at", ou une expression similaire,
Et si par exemple c'était dans la partie "Development Topics" slides 31 à 37 qui liste les limitations, les améliorations et les éléments qui sont en cours d'études et de développement, il se passerait quoi ?
Je pourrais sans doute continuer pendant des heures, mais je vais pas m'acharner sur le sujet
Surtout que tout ton argumentaire repose sur le fait qu'il fasse leurs études et tests sur Fedora, chose que j'ai signalé dans mon post au fait. Et que donc il va leur être difficile de na pas mettre systemd dans RH 7 (ce que j'ai dit aussi).
je suis sur que tu as des tas d'arguments et de témoignage de gens qui sont super proche du pdg de RH
Ben justement non j'en ai aucun. Que ce soit chez Suse ou chez Red Hat ca joue à ni oui ni non. Même le support (payant) RH est pas foutu de répondre à la question "dans RH7 ca sera systemd ou sysinit ou les deux".
Or le truc c'est que dans le milieu professionnel les "c'est évident" et les "ca se voit" on a tendance à s'en méfier pas mal. (Surtout avec RH à qui ca ne fait pas peur de faire passer à la trappe une techno du jour au lendemain).
_ et que même si Arch et Mageia ont fait la migration avec 3 bouts de ficelle sans soucis majeurs, c'est impossible que des boites avec plus de moyens fassent de même_
OK. Donc tu n'as juste pas compris le problème en fait.
En dehors des utilisateurs qui utilisent Linux pour s'amuser et s'instruire, il y a des sociétés (parfois même des grosses sociétés) qui utilisent Linux pour traiter des données sensibles, des fois vitales à la boite, dans leur activité de tous les jours. Ces sociétés ne représentent pas une portion très importante des utilisateurs de Linux, par contre elles représentent 100% des clients payant de boites comme RH ou Suse.
Or ces sociétés ont souvent des scripts, des outils, des programmes même codés maison et qui utilisent la puissance de l'init traditionnel pour fonctionner (processing turing complet, prise en charge des variables d'environnement, init prévisible, logs dans des fichiers plats etc.)
Je n'ai pas vraiment de vision sur ces sociétés, je n'en connais que trois. Mais les trois que je connais (en l’occurrence leurs sysadmin) ne veulent pas de systemd. Et ils n'en veulent pas parce que :
a) Il y a beaucoup de boulot et de tests à faire pour s'assurer que tout fonctionne.
b) Certaines choses (certains fs chiffrés, demande de mot de passe à l'init par service, templates etc.) ne sont pas possible avec systemd.
c) Systemd n'est pas fini/normalisé et du coup même si ils trouvent des parades aujourd'hui rien ne prouve qu'elles seront encore valables dans dix jours (spéciale dédicace udev)
Le fait que ArchLinux et Mageia ait fait le pas en tant que distrib ne prouve rien au niveau de l'utilisabitlité du bigniou par des sysadmins.
Ah, on me dit dans l'oreille que c'est pas parce qu'il y a marqué systemd dans un rapport de bug que c'est un bug sur systemd et que ta liste est utilisé juste pour du FUD. Dommage, presque crédible.
Ah oui, je donne la liste mais j'ai oublié de dire qu'il fallait lire :
Bug 774126 : si on se logue trop tôt sur une interface série le getty crashe définitivement. Il existe une solution mais elle est trop complexe pour être backportée
Bug 779434 : pas de splash dans le boot kernel, pas de /var. Systemd refuse de monter le /var si plymouthd a un fichier de lock qui traine dessus. COOOL
Bug 780006 : Un boot pas à pas dans systemd ? Vous plaisantez bien sur. De..bug ? Jamais entendu parlé.
Bug 780441 : L'automount NFS ne marche pas (pas chez Fedora non plus) - mais on a presque fini d'avoir une bonne idée sur comment contourner le problème. (N.B : ce bug a une priorité P5 - none. Autmount NFS ? Ca interresse quelqu'un ? )
Bug 767394 : Un disque plein ? C'est un scandale ! Je me casse… (signé systemd).
Après tu fais comme tu veux, mais moi ce genre de bugs sur des trucs que j'utilise couramment (pas comme le timer du device machin sur une architecture ARM spécifique que l'on ne retrouve que sur des téléphones portables hackés) ca me fait peur.
L'init doit être le process le plus robuste qui soit. C'est lui le centre névralgique du système. Si il bugue on ne peut plus rien faire. L'init est presque plus importante que le kernel au niveau debug (une bonne init peut permettre de comprendre ce qui a chié dans le kernel, la réciproque n'est pas vraie).