Debian hésiterait entre Systemd et Upstart

Pause Café
#41

[quote=“tuxshake”]Oui et derrière il y a aussi d’autres soucis, avec upstart notamment …
Ça ne me plairai pas trop de voir débarquer des morceaux de licence ubuntu-canonical dans ma debian pour la booter.[/quote]
J’ai pas regardé la vidéo, mais j’en ai pas besoin pour savoir que ce que tu dis est est faux ftp-master.metadata.debian.org/c … _copyright.
upstart c’est du code libre sous licence GPLv2, c’est pour ça qu’il est dans la section main des dépôts officiels.

Ce dont tu parle c’est d’un contrat que les contributeurs doivent passer à fin de donner leur copyright à Canonical. C’est une pratique pas nouvelle (Sun le pratiquait notamment pour ZFS) et ça permet à l’entreprise de garder le copyright sur l’ensemble de la base de code pour en changer la licence facilement. Bien sur ça permet de faire passer du code en propriétaire, mais ça permet aussi de passer de la GPLv2 à la GPLv3 (la facilité de changer de licence est un vrai problème et la FSF conseil de mettre son code sous licence GPLv3 ou supérieur, car les licences sont sujettes à faille). Je n’imagine pas Canonical passer upstart en propriétaire (il leur est arrivé d’avoir un mode de développement « fermé », c’est à dire non publique, mais jamais, à ma connaissance, de code propriétaire).

Du FUD, du FUD, du FUD. Faut pas être surpris que des boites comme Apple ou MS en font si nous en faisons entre les projets libres.

#42

Je ne vois pas ce qui est faux dans les 2 lignes que j’ai écrites.
Debian se retrouverai bien avec du code ( vraiment important ) dépendant du bon vouloir et de la politique du moment de canonical.

Pour le reste, je n’ai rien dit d’autre.

Sur l’aspect technique, j’avoue être plus convaincu par systemd en plus sa licence ne pose pas de problème, en tout les cas c’est un beau chamboulement qui se profile.

A mon sens le seul vrai problème avec systemd, c’est que ce n’est développé que pour linux et pas pour FreeBSD et Hurd.

#43

Si tu parle d’une licence qui n’existe pas.

Les 2 sont sous licence GPLv2.
ohloh.net/p/systemd
ohloh.net/p/upstart
Ils ont la même licence à la virgule prêt. Ils sont tous les 2 libres.

Sincèrement montre moi la différence de licence qu’ils ont.
Regarde je viens de télécharger la dernier version des 2 et :

% sha256sum upstart-1.11/COPYING systemd-208/LICENSE.GPL2 ab15fd526bd8dd18a9e77ebc139656bf4d33e97fc7238cd11bf60e2b9b8666c6 upstart-1.11/COPYING ab15fd526bd8dd18a9e77ebc139656bf4d33e97fc7238cd11bf60e2b9b8666c6 systemd-208/LICENSE.GPL2

En fait c’est subtile j’ai découvert en le téléchargeant que systemd est sous triple licence GPLv2, LGPLv2.1 et MIT, mais ça ne change pas grand chose les deux sont libres et ont la même licence que sysvinit.

Pour ce qui est de la dépendance vers une entreprise, systemd c’est RedHat et upstart c’est Canonical. Chacune de ses 2 entreprises ont une main mise totale sur le développement de leur solution. Ne crois pas que l’un est plus ouvert que l’autre c’est faux, Lennart est autoritaire et propose de forker systemd à tout ceux qui voudraient ajouter des trucs qui ne conviennent pas RedHat. Mais les deux sont libres et restent donc forkables. Ce n’est pas un problème de licence.

Il a un couplage assez fort avec d’autres composant comme logind. C’est pas mal reproché. Il a aussi des problèmes techniques sur la gestion des volumes notament quand tu veux faire de l’autofs ou chiffrer tes partitions.

#44

[quote=“MisterFreez”]
Si tu parle d’une licence qui n’existe pas.[/quote]
Moi je trouve que cela pose un sérieux problème pour la pérennité.
Tu le dis toi même…

Et plus haut, on se rend compte que c’est encore pire :

En fait c’est encore pire que ce que j’avais noté, les 2 posent problème.

#45

[quote=“tuxshake”][quote=“MisterFreez”]
Si tu parle d’une licence qui n’existe pas.[/quote]
Moi je trouve que cela pose un sérieux problème pour la pérennité.
Tu le dis toi même…[/quote]
C’est fou de voir autant de manichéisme. Je dis juste que ce n’est pas un problème de licence. Le code actuel est sous licence GPL et ça personne ne peux le changer.
Ce n’est pas parce que j’ai dis que ton argument était faux que ça signifie qu’upstart est bon, juste que ton argument est faux : upstart est un logiciel libre. Avoir des opinions c’est une bonne chose, mais il faut qu’elles soit basée au maximum sur des choses exactes sinon elles ne tiennent pas debout. Tu comprends ?

D’un point de vu technique upstart est à la ramasse, il a subi un développement au ralentis et commence à peine à reprendre du poils de la bête, mais il est (était ?) basé sur des gros hacks pas très fiables. Par exemple pour vérifier qu’aucun processus ne s’échape il scrutait les appels systèmes de tous les processus pour trouver les appels à [mono]fork()[/mono], là où systemd utilise cgroup (cgroup c’est bien mais c’est l’un des principaux trucs qui le rend incompatible avec autre chose que linux). Le sujet n’est pas trivial.

Pour ce qui est de la licence, Canonical ne peut pas fermer le code actuel et ne fermera pas la suite ça n’aurait vraiment pas de sens, mais le développement est dicté par Mark Shuttleworth alors que systemd c’est par Lennart Poettering (employé RedHat). D’ailleurs le couplage systemd/gnome n’a rien de surprenant quand on voit d’où viennent les contributeurs de ces 2 projets. Personnellement, j’aurais envie d’utiliser upstart (ou openRC ou SMF ou autre) rien que pour faire chier et pour souligner ce couplage fort entre les composants, mais c’est augmenter sa propre charge de travail pour pas grand chose et je ne contribue pas assez pour pouvoir en parler.

Sinon comme déjà dis, metainit me semble la solution la plus pertinente.

#46

Si on met de coté l’aspect licence, personnalité des personnes, entités impliquées.

J’ai regardé certains débats sur upstart et systemd.
Pour linux, je trouve systemd vraiment alléchant et plus prometteur que upstart :slightly_smiling:
Qui dit changement, dit aussi problème, mais ça apporte un fameux lot de fonctions alléchantes.

Entre autre pour “cgroup”, il y avait un post intéressant sur le forum d’archlinux
( d’ailleurs, ils ont opté pour cette solution ).

bbs.archlinux.org/viewtopic.php … 0#p1149530

#47

Le problème c’est que ceux qui débatent sont de parti pris. Par exemple :

C’est faux ou disons que c’est une manière de montrer les choses. Il y a une modularité interne dans le sens où chaque sous programme ne fait qu’un chose et le fait bien, mais :
[ul]
[li]l’interface entre ces modules n’est pas bien défini, donc tu peut difficilement remplacer un module par autre chose[/li]
[li]la modularité externe n’existe pas vraiment, tu ne peux plus utiliser systemd sans logind et il y a toute une interface pour manipuler systemd en dbus qui est vraiment spécifique systemd [/li][/ul]

Ça moi ça me fait peur. C’est la même personne qui a développé consolekit et systemd. Qu’est ce qui nous dis que dans 5 ans il va pas nous expliquer que finallement il faut tout reprendre et jeter l’existant ?

Mais systemd est probablement le plus sérieux prétendant. upstart est le seul qui tente de se hausser au même niveau de fonctionnalité mais il est encore bancale (même si je préfère son approche qui me semble by design plus simple et plus portable¹), les autres sont des simplifications de sysvinit.

1 : systemd lance en parallèle le maximum de service et utilise des fonctionnalités très pointues de linux pour gérer les dépendances (inetd pour une dépendance réseau, un même genre pour le fs, etc), upstart cherche (du moins c’est ce que j’avais lu à la base) a tout unifier via des évènements tout est évènements et chaque processus est lancé sur un évènements (disponibilité du réseau, montage du système de fichier, il est 2h du mat (oui oui comme cron), etc, etc). Ça me paraît plus simple au sens KISS et ça n’empêche aucune de fonctionnalités que propose systemd.

#48

Bon, c’est systemd qui est choisi.
lists.debian.org/debian-ctte/20 … 00294.html

(cela dit ça latte un peu quand même, lire les fils suivants)

#49

Je n’ai jamais compris cette façon d’organiser les fils de discussions (c’est très peu lisible).

#50

Lennart a dû sabrer le champagne :mrgreen:

#51

Pfff…
Je n’ai que survolé l’engueulade, mais ça suffit à me donner envie de pleurer…
Il y a pourtant une différence claire entre « option par défaut » et « option imposée » !

ALSA est le serveur audio par défaut, et ça n’empêche personne d’utiliser OSS ou jack.
GNOME est l’environnement de bureau par défaut, et pourtant même moi humble utilisateur suis capable d’utiliser Debian avec XFCE ou KDE.
systemd sera le système d’init par défaut pour Jessie, mais libre à tout un chacun d’utiliser/développer/maintenir upstart, openRC ou sysV.

Comme je ne pense pas que ces gens soient des idiots, je suppose que ce sont des trolls…

(et encore, je pense que les réactions auraient été encore plus violentes si upstart avait été choisi)

Décidément cette guerre des inits est déprimante…
Vivement qu’ils ferment tous leur gueule et se remettent à coder !

#52

Les débats ont commencés sur les listes en juin et le ctte a commencé à débattre il y a 5 mois, les discussions ont étaient très… dynamiques. C’est logique que ça gueule fort à la fin, on arrête pas un débat aussi passionné du jour au lendemain. Le temps ferra son affaire les mainteneurs savent un peu mieux ce qu’ils ont à faire.

#53

Tout a fait d’accord, mais le truc c’est que [mono]systemd[/mono] est fortement lié au noyau linux et que GDM/Gnome3 ne fonctionne pas/mal sans lui.
Perso je n’aime pas ce bloc qui s’impose peu à peu. Le système de démarrage est certes ancien avec divers défaut de conception, mais est éprouvé et ne froisse aucune sensibilité.
Debian supporte une version avec le noyau kFreeBSD, que va-t-elle devenir ? Mourir a petit feu ?
Un certain nombre de développeurs Debian sont des employé de Cannonical, il est normal qu’il pousse pour Upstart, mais j’ai peur qu’avec cette décision dans le meilleur des cas il se redirige vers d’autres parties de la distrib ou au pire se désengage partiellement ou complètement.
Arch a fait le choix de ne pas prendre [mono]systemd[/mono] par défaut, je pense sincèrement que les rejoindre aurait permis de garder une véritable alternative à Fédora/red Hat/CentOS et autres dérivées.

Ensuite il ne s’agit que d’un vote, peut être que la mise en place sera plus problématique que prévu, même si cela me semble peu probable du fait que certain l’ai déjà expérimenté avec succès.

Sinon je n’ai pas vu la possibilité de changer de système d’init lors de l’install de Debian … mais comme je n’en fait pas tous les 4 matins :mrgreen:

#54

Tout a fait d’accord, mais le truc c’est que [mono]systemd[/mono] est fortement lié au noyau linux et que GDM/Gnome3 ne fonctionne pas/mal sans lui.
Perso je n’aime pas ce bloc qui s’impose peu à peu. Le système de démarrage est certes ancien avec divers défaut de conception, mais est éprouvé et ne froisse aucune sensibilité.
Debian supporte une version avec le noyau kFreeBSD, que va-t-elle devenir ? Mourir a petit feu ?[/quote]
On ne change pas le boot tous les 4 matins. Ça peut être l’occasion pour Debian/kFreeBSD de passer à rc.d, ce qui la rapprocherait et lui donnerait un intérêt aux yeux des bsdistes.
Pour ce qui est de GDM/Gnome3 (ou autre) la question de la dépendance forte au système d’init n’a pas encore était tranché.

Canonical n’est pas tout blanc. La CLA sur upstart a joué un rôle non négligeable dans le choix (il faut abandonner son copyright à Canonical pour participer à upstart). J’aime beaucoup l’idée initiale d’upstart, mais l’implémentation n’est pas aussi bonne que prévue. S’ils avaient voulu le remonter dans Debian, il aurait fallu s’y prendre plutôt, virer c’te CLA et ne pas laisser le projet stagner pendant le développement de systemd.

Tu es en retard d’une guerre Arch utilise systemd par défaut depuis pas mal de temps maintenant (et ils en sont content). Pour ne pas passer à systemd, il faut passer à gento (openrc), slackware (rc.d) ou bien sûr ubuntu (upstart) (il y en a probablement d’autres comme mint).

C’est du fantasme. Le soft (contrairement à ce que tu dis plus haut) est éprouvé par pas mal de monde. Si c’est un objectif de jessie ça arrivera ne t’inquiète pas pour ça.

Il n’y a pas cette possibilité, elle n’existait pas alors qu’on pouvait changer de système d’init (upstart, systemd, openrc, initng,…) en quoi ça devrait changer ? Si tu veut faire comme tu le sens soit tu fait le changement après installe soit tu fais une installation via debootstrap (c’est déjà ce que je fais par préférence).

#55

sysV, systemd et openRC sont tous trois présents dans les dépôts officiels Debian (branche experimental pour ce dernier).
Je ne sais pas comment passer de l’un à l’autre, mais c’est sûrement déjà possible et je ne vois pas de raison que ça change suite au remplacement de sysV par systemd comme init par défaut pour Jessie.

C’est pour ça que je ne comprends pas tout le tollé accompagnant cette décision…

#56

Tu es en retard d’une guerre Arch utilise systemd par défaut depuis pas mal de temps maintenant (et ils en sont content). Pour ne pas passer à systemd, il faut passer à gento (openrc), slackware (rc.d) ou bien sûr ubuntu (upstart) (il y en a probablement d’autres comme mint).
[/quote]
J’ai confondu Arch et Gentoo …

L’espoire fait vivre non ? :mrgreen:

[quote=“MisterFreez”]

Il n’y a pas cette possibilité, elle n’existait pas alors qu’on pouvait changer de système d’init (upstart, systemd, openrc, initng,…) en quoi ça devrait changer ? Si tu veut faire comme tu le sens soit tu fait le changement après installe soit tu fais une installation via debootstrap (c’est déjà ce que je fais par préférence).[/quote]
Si avant on avait pas le choix c’était un héritage de version précédente, et que personne (ou très peu) de personnes se plaignaient, maintenant que ce choix est plus polémique il ne m’étonnerait pas que le choix soit proposé.

#57

Tout a fait d’accord, mais le truc c’est que [mono]systemd[/mono] est fortement lié au noyau linux et que GDM/Gnome3 ne fonctionne pas/mal sans lui.
Perso je n’aime pas ce bloc qui s’impose peu à peu. Le système de démarrage est certes ancien avec divers défaut de conception, mais est éprouvé et ne froisse aucune sensibilité.
Debian supporte une version avec le noyau kFreeBSD, que va-t-elle devenir ? Mourir a petit feu ?
Un certain nombre de développeurs Debian sont des employé de Cannonical, il est normal qu’il pousse pour Upstart, mais j’ai peur qu’avec cette décision dans le meilleur des cas il se redirige vers d’autres parties de la distrib ou au pire se désengage partiellement ou complètement.
Arch a fait le choix de ne pas prendre [mono]systemd[/mono] par défaut, je pense sincèrement que les rejoindre aurait permis de garder une véritable alternative à Fédora/red Hat/CentOS et autres dérivées.

Ensuite il ne s’agit que d’un vote, peut être que la mise en place sera plus problématique que prévu, même si cela me semble peu probable du fait que certain l’ai déjà expérimenté avec succès.

Sinon je n’ai pas vu la possibilité de changer de système d’init lors de l’install de Debian … mais comme je n’en fait pas tous les 4 matins :mrgreen:[/quote]

Le soucis, si j’ai bien compris, est qu’il faut que les mainteneurs des paquets qui se lancent au démarrage fournissent les fichiers pour le système d’iniatialisation. Le système d’initialisation « par défaut » sera complètement supporté, les autres systèmes d’init n’auront pas nécessairement le nécessaire dans les paquets. Or si un seul script d’init manque, l’utilisation du système d’initialisation alternatif va devenir compliqué.

Dans ce cas « par défaut » signifie fiable. Le système d’initialisation est beaucoup moins indépendant que, disons, un environnement de bureau alternatif.

Là où cela devient compliqué, c’est qu’une distribution dérivée comme Ubuntu se repose sur la base Debian. Du coup, il y aura plus de taf s’ils doivent fournir les scripts d’init pour chacun de paquets qui ne l’intègrent pas. C’est ça ou utiliser systemd à leur tour comme système d’initialisation (pourquoi pas ?). En définitive, le choix de licence ([strike]CLA[/strike]) et une politique plus volontaire quant à la collaboration avec l’upstream, auraient sans doute aider à faire basculer la décision… :whistle:

#58

Vont pas nous faire pleurer non plus, chez Ubuntu. Il ont déjà à leur actif (ou doit-on dire “passif”? :stuck_out_tongue: ) Unity, Mir…
Des trucs développés chez eux et que pour leur distro.

#59

En fait le truc ça serais d’avoir un système de script d’init unifié, comme ça la mécanique derrière pourrait être remplacer avec un impact minimal :mrgreen: hein quoi :033 on a le droit de rêver non :033

#60

[quote=“Mimoza”]En fait le truc ça serais d’avoir un système de script d’init unifié, comme ça la mécanique derrière pourrait être remplacer avec un impact minimal :mrgreen: hein quoi :033 on a le droit de rêver non :033[/quote]MisterFreeze avait parlé d’un truc comme ça : metainit (debian-fr.org/debian-hesite … ml#p458772). Ce serait le plus élégant.

[quote=“agentsteel”]Vont pas nous faire pleurer non plus, chez Ubuntu. Il ont déjà à leur actif (ou doit-on dire “passif”? :stuck_out_tongue: ) Unity, Mir…
Des trucs développés chez eux et que pour leur distro.[/quote]Ça je suis bien d’accord, c’est pour éviter de troller que je me suis arrêté là où je l’ai fait. Le « par défaut » affilié au système d’init, n’a pas les mêmes conséquences que celui pour l’environnement de bureau. Canonical aurait été plus malin de la jouer plus fine pour faire faire le taf en amont — ce coup-là c’est rapé…

Sinon l’utilisateur final s’en carre tant que ça fonctionne, et s’y fera s’il faut bidouiller.