Ouai je comprends. Ça me paraît être un mauvais usage de l'initsysv.
Je viens de regarder dans ma distrib' (debian stable) ssh ne souffre pas de ce problème mais exim si.
Bah, voila, une troisième méthode que je connaissait pas, et non, je parle en effet d'une autre façon de faire.
Mon coloc s'était plaint de devoir mettre "UsePAM yes" dans sa config, et j'avais fini par trouver un truc en lançant ssh à la demande via les sockets, ce qui fait 1 cgroup par connexion.
Par exemple, sur ma machine ( ou je fait ça pour économiser 3mo de ram afin de pouvoir continuer à lancer des gros trucs java pour remplir les 8G qui reste ), en lançant 2 connexion ssh, j'ai 2 entrées dans la sortie de systemctl :
~ $ sudo systemctl | grep ssh
sshd@2-:...:1:51441.service loaded active running SSH Per-Connection Server
sshd@3-:...:1:51442.service loaded active running SSH Per-Connection Server
sshd.socket loaded active listening SSH Socket for Per-Connection Servers
~ $ systemctl status sshd@3-::1:22-::1:51442.service
sshd@3-::1:22-::1:51442.service - SSH Per-Connection Server
Loaded: loaded (/etc/systemd/system/sshd@.service; static)
Active: active (running) since lun. 2013-01-28 16:16:56 CET; 39s ago
Main PID: 4148 (sshd)
CGroup: name=systemd:/system/sshd@.service/3
Et chacune est dans son propre cgroup, ce qui fait qu'un restart du service ne tue rien.
Mais c'est pour moi un effet de bord du fonctionnement par socket plus qu'autre chose, donc je trouve ma méthode tiré par les cheveux.
Je n'ai pas bien compris ça. Tu peux en dire plus, s'il te plaît ?
en gros, tu prends un job upstart au pif, genre ssh sur mon n9 :
$ head /etc/init/ssh.conf
description "SSH"
# started by group-mce.conf
stop on stopped dbus
console output
respawn
respawn limit 3 300
normal exit 0
oom -17
script
test -x /usr/sbin/sshd || exit 0
if test -f /etc/default/ssh; then
. /etc/default/ssh
fi
root_permitted="-o PermitRootLogin=no"
if test -x /usr/sbin/rdc_cert_verify && \
$(/usr/sbin/rdc_cert_verify &> /dev/null)
then
root_permitted="-o PermitRootLogin=yes"
fi
# Create the PrivSep empty dir if necessary
if [ ! -d /var/run/sshd ]; then
mkdir -p /var/run/sshd
chmod 0755 /var/run/sshd
fi
exec /usr/sbin/sshd $root_permitted $SSHD_OPTS
end script
Il y a 2 parties :
* la partie script ( entre script / end script )
* la partie pas script, à savoir le reste
La, si je veux par exemple que ssh ne s’arrête pas quand dbus se coupe ( c'est mon tel, je fais ce que je veux ). Ou imaginons que je veuille changer la directive oom, changer la valeur de nice, etc. Faut que je modifie le fichier.
Sauf que si je modifie le fichier, il se passe quoi à la prochaine mise à jour qui va faire pareil ( exemple, une modif qui change le chmod 0755 en 0700 pour cause d'un souci de sécurité ( exemple inventé )) ?
3 choix :
- le système de paquets écrase ma modification. Donc je doit repasser pour la remettre, si je m'en souvient.
- le système de paquets n'écrase pas la modification. Mais je doit passer pour rajouter sa modif dans mon fichier modifié.
- le système de paquets me demande, donc je doit passer pour fusionner les changements.
Dans tout les cas, ça requiert d'être la pour s'occuper de l'upgrade et tout ça parce qu'il y a des informations du domaine de la distribution (à savoir la partie 'script' ) mélangés avec des choses du domaine de l'admin ( à savoir les dépendances, le choix de l'oom ou pas, du nice, etc ). Et ça, c'est un job simple, il y a pas mal d'option en plus dans upstart.
Systemd gére ça de façon élégante en prenant les informations de 3 fichiers, et en appliquant la config dans un ordre précis. Si j'ai toto.service dans /lib et dans /etc:, les informations en plus de /etc ( genre une valeur de nice ) se rajoute à celle de /lib. Donc quand la distro modifie le fichier dans /lib, j'ai rien à faire de spécial. Il y a même un outil spécifique ( http://www.freedesktop.org/software/systemd/man/systemd-delta.html ) pour trouver ce qui a été modifié dans /etc par rapport à /lib
Je trouve ça bizarre pourquoi ne pas faire
Les daemons font en général un double fork. Donc ton wait va attendre sur le premier, pas sur le second. Et tu ne peux faire de wait que sur un process fils, sauf erreur de ma part. Donc à partir du moment ou ton script d'init t'a rendu la main, tu peux plus faire de wait sur le pid de bind, donc inapplicable dans le cas exposé, à savoir d'un reboot. D'ou l'usage de ptrace par upstart pour choper le pid ( http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ ).
Oui c'est proposé par Lennard, mais rien de très spécifique à systemd là dedans.
oui, et sauf erreur de ma part, Ubuntu ( entre autre ) l'a fait avant que Lennart ne pousse ça dans systemd, vu que je me souvient distinctement avoir entendu raler le dev debian qui servait de sysadmin dans mon ancien job contre les devs Ubuntu d'avoir mis /var/run en tmpfs. Il avait du rajouter 2/3 lignes pour le script d'init pour refaire /var/run/nufw/ ou ce genre de choses avant de lancer le démon de notre produit.
D’après ce que je lit ici et la, grub-ieee127 ne serait pas ce que tu veux ? ( la dernière sparc que j'ai vu, c'était à la poubelle y a 1 an, donc je suis plus très au courant de ce qu'il faut faire en dehors de "magouiller avec l'open firmware" ).
Mais si tu arrives à le faire marcher, je suis sur qu'un peu de doc pourrait aider.
Mais Pat est le fondateur de Slackware donc je ne prends pas à la légère ce qu'il dit.
Alors d'une part, il y a d'autre fondateurs de distros qui postent parfois ici et la, et tu sembles prendre ça plus à la légère ce qu'ils disent ( enfin pareil, c'est un avis personnel, pas une parole divine ).
Et d'autre part, Patrick a un vision orienté vers son but, à savoir la maintenabilité par lui même de la distribution, et la simplicité extréme que ça requiert, quitte à ce que ça ne réponde pas au besoin de tout le monde.
Son refus de pam est un exemple, et pas grand monde ne va le suivre sur ce point, car même si pam a eu des débuts difficiles, ça reste relativement pratique dés que tu veux avoir un serveur ( comptes en ldap, kerberos ) ou si tu veux essayer de rivaliser avec du windows sur le poste client ( pareil, ldap, etc ). Ou de la sécurité ( authentification à 2 facteurs, lecteur d'empreinte digital ).
D'ailleurs, la gestion des processus par cgroups de systemd ( pour en revenir au sujet ) implique de dire à sshd de se "détacher" des processus utilisateurs pour éviter de les tuer lors d'un restart, et d'avoir son propre cgroups par utilisateur ( ce qui permet d'appliquer des quotas cpu/ram/etc par utilisateur via les cgroups, justement ). Et pour ça, le moyen le plus propre est de passer par pam, qui va voir au login qu'il y a un utilisateur et qui va le changer de cgroups.
Sans ça, tout les utilisateurs sont dans le cgroup de sshd, et se font donc tuer sans pitié en cas de restart du demon. ( il y a une méthode pour faire autrement, mais c'était tirer par les cheveux et j'ai oublié ).
Donc un passage à systemd serait sans doute aller à l'encontre de son objectif de garder pam hors de slackware ( sauf si ce n'est plus d'actualité, bien sur ).
Pour Ubuntu, qui était à l'origine de upstart (non?), je pourrais tout aussi bien les accuser de refuser systemd pour
cause de syndrôme NIH. (c'est tellement facile de dire que "les autres n'en veulent pas parce que c'est pas bien").
Et moi, j'avais le sentiment que upstart a commencé comme projet à part ( au vue du vieux nom de domaine en .at ) avant de passer sous l'aile de Canonical. Mais vu que dans mon souvenir, il y a le fameux CLA, je doit sans doute avoir tout faux.
Tel que je vois la ou Canonical veux aller, c'est l'embarqué ( smartphone, tv ), et le cloud avec des bécanes jetables ( ie, les guests ). Et je pense que le concept de gestion d'événement s’intègre bien aussi avec le premier ( besoin de mobilité et d'une gestion dynamique ) qu'avec le second ( rajouter un file system en réseau via ceph, etc ).
Upstart a été utilisé pour chromeos ( donc un pc portable mobile ), pour le nokia n9 ( donc aussi un appareil mobile ), et sans doute dans Ubuntu Tv et le reste.
Ensuite, pour la partie cloud, ils sont partie sur juju plutôt que de l'intégrer ça directement dans l'OS via upstart, c'est un peu dommage ( et qu'on me dise pas "ça rends juju portable" car ça continue à utiliser des ppa à tout va ). La transparence réseau de upstart, ça aurait pu faire une sacré killer feature pour le système.
Si, le projet est à l'abandon. Mais j’étais pas au courant du port pour netbsd, ni du fait que ça dépend fortement de mach ( ceci dit, j'aurais du m'en douter, mais j'aurais penser qu'un soft non portable aurait fait raler tout le monde ). Je suppose que le fait de dépendre des plists ( un format basé sur xml d'os x, qui peut aussi être compilé en binaire ) risque de faire grincer des dents.
Il explique par exemple que le fait de lancer plusieurs choses en même temps permet de tirer parti des machines multi cores, il montre pas mal d'idées qui se sont retrouvés dans systemd ( le lancement activé par un chemin, par socket et dans le désordre ), et il montre aussi le genre de choses qu'on peut faire avec l'activation par socket dans la session user. Son exemple, lancer X ( qui plante quand il teste ) ou ssh-agent à la demande, ce qui permet de décharger la session des trucs qu'on utilise pas vraiment ( avec comme avantage de consommer un peu moins de ressources, d'avoir un session qui démarre un peu plus vite et surtout d'être plus robuste ).
Quelle est la valeur d'une paire de soucis? Peanuts
Ce que l'auteur pense importe peu. Vous avez peur de dire ce que vous en pensez ?
Vous êtes proFedora donc vous manquez d'objectivité car vous défendrez forcément systemd
upstart c'est de l'ubuntu donc forcément vous ne l'aimerez pas…
Donc récapitulons. J'ai une opinion donc je manque d'objectivité ( c'est grosso modo la définition, mais bon, passons ). Je donne donc pour éviter de tomber dans ce travers un lien de quelqu'un que je connais pas, mais d'un coup j'aurais peur de dire ce que j'ai déjà dit 15 fois sur linuxfr.
Certes. Et au final, quoi que je dise, je suis pro fedora, donc forcement, je vomis ce que fait Ubuntu. Parce que c'est bien connu, quand on utilise une distribution, ça retire tout sens critique, donc pas besoin de donner d'argument.
Au lieu de m'éterniser sur des arguments stériles et des attaques ad hominem, regardons de plus prêt ce que l'auteur de l'article dit :
il donne également l'exemple de la modification de la config d'un systéme, ou pareil, le fait de modifier le fichier fait qu'il risque de passer à coté d'une modification, car c'est plus proche d'un script. Pareil, il mets la correction de ce souci comme avantage de systemd. Lien : http://utcc.utoronto.ca/~cks/space/blog/linux/UpstartDependencyProblem
Donc voila 4 problèmes liés à l'architecture d'upstart ( ie, le fait d'avoir un fichier de config qui est en fait un script, et le fait d'utiliser ptrace pour suivre les processus ), corrigé par le design de systemd, à savoir avoir des fichiers au format .ini, ce qui permet de mettre des priorités sur les directives qui découlent d'un ordre de lecture prétabli, et l'usage des cgroups, pour gérer les groupes de processus. Cgroups déjà à la base de lxc, donc relativement étanche.
Exemple typique de manque d'objectivité:
Le soucis est subtile , donc pas vraiment identifié…
Une affirmation pertinente serait de préciser LE soucis
Quand je dit subtile, je veux dire par la difficilement identifiable. Par exemple, se connecter en ssh, et relancer un serveur web et voir plus tard que tout d'un coup, ton cgi qui appelle la commande 'sort' merdouille parce que la variable LANG n'a pas été nettoyé ( ie, LANG=FR_fr est passé au script, puis à apache, puis à ton cgi, puis à 'sort' qui va trier les caractères diacritiques d'une façon différente en fonction de la locale ). Ou voir qu'en fonction de comment est lancé ton soft, tu as un autre format de date dans les logs, car il reprends LC_ALL et LC_TIME. Bien sur, si on était sur d'avoir toujours le même environnement clean, ça n'arriverais pas ( khofhttp://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRestartEnvironmentkhof )
Gentoo est connu comme très solide et très sérieux.
ah ah ah
Pardon.
J'ai rien contre Gentoo, j'ai un serveur sous Gentoo chez OVh, et je dirais même que je connais des gentooistes ( bien la preuve que je suis pas raciste ). Mais sérieux et solide n'est pas forcément ce qui me vient à l'esprit. J'aurais plutôt dit flexible et adaptatif.
Sérieux, pour moi, ça implique par exemple un suivi des soucis de sécurité et pendant un bon bout de temps, il n'y plus eu d'alertes de sécurité (cf http://www.gentoo.org/security/en/glsa/index.xml entre janvier 2010 et mai 2010 ).
Solide, je dirais que c'est plus la personne qui décide de pas abuser de l'adaptabilité. Il faut bien voir qu'en pratique et en fonction des choix de l'admin, chacun a un système différent. L'utilisateur est le premier, dernier et seul personne à faire la QA de son système. ( bon, pas exactement, mais j'ai toujours voulu caser la formule ). Les paquets passent de masked a unmasked sur la base des retours des gens, ce qui garantit des tests minimums, mais les retours sont se font dans des environnements différents. Et c'est une approche différente d'une debian ou d'une autre distro binaire, ou tout le monde a les mêmes binaires ce qui fait que si ça marche chez X personnes, alors il y a moins de raison que ça foire ailleurs. Alors que gentoo, avec les use flags, etc…
Et comme il y a pas de mises à jours de sécu au sens "mise à jour minimal" avec la QA qui va avec, la solidité n'est pas une chose que j'estime acquise, bien que je n'ai pas eu à me plaindre personnellement si souvent et que c'est suffisant pour ce que j'en fait.
Openrc, qui a quand même eu 10 ans pour se faire adopter, semble faire un revival. Bien sur, personne ne va dire que openrc, il supporte le boot en parallèle avec des bugs compliqué à reproduire ( https://bugs.gentoo.org/show_bug.cgi?id=391945 ).
it apparently does per-user fair share scheduling by default (but I haven't had a chance to run systemd in a
situation where I could really see this in action)
En gros donc, vous nous vantez les mérites de systemd comme étant une révolution, mais même ce monsieur n'arrive
pas à réaliser une telle opération qui est théoriquement facile puisque systemd est une révolution.
Je n'ai pas dit "révolution", j'ai laissé mon pull noir à col roulé au placard. Et j'ai du mal à saisir. L'auteur de l'article n'a pas eu de situation ou le "fair share scheduling", traduisons par "partage équitable de l'ordonnanceur" a pu s'appliquer, donc ça rends systemd compliqué ? Si ses serveurs ne sont pas chargé ras la gueule au point d'en avoir besoin, ou est le souci ?
Pour info, ce dont il parle est détaillé la : http://lwn.net/Articles/415740/ , avec la réponse de lennart la : http://lwn.net/Articles/415756/. Si les gens passent pas leur temps à mettre leur bécane sur les genoux à grand coup de compile kernel pour constater si systemd fait un truc, c'est la faute de systemd ?
is mostly written in C […] XML [15% du code]
Pour info, ce que l'auteur a voulu dire, c'est que contrairement à smf, l'init de solaris, systemd n'utilise pas de xml pour sa config donc l'admin n'a pas à interagir avec. Ensuite, la doc est en docbook ( un format de publication en xml ), et en effet, 15% du contenu du tarball, c'est de la doc en xml.
Mais c'était bien tenté.
Tout le monde est d'avis que le système [init] fonctionne correctement depuis 40 ans.
Pas moi. Ni les gens de chez Sun, vu qu'ils ont refait le système avec SMF. Ni les gens d'Ubuntu ou de Chrome OS, vu qu'ils ont upstart ( ou RHEL 6, ou Maemo ). D'ailleurs pas les gens de Gentoo, vu qu'ils ont fait openrc. En fait, Apple aussi a refait son système d'init il y a 3/4 versions. Donc oui, si on retire tout ça, tout le monde pense que ça marche.
Enfin pas ceux qui ont fait runit ou initng non plus. Ni les gens de FreeBSD qui ont proposé un portage de launchd dans un Google Summer of Code.
Enfin donc, à part tout les gens qui sont tellement d'avis que ça fonctionne correctement qu'ils se sont dit qu'il faut le remplacer, ouais, tout les autres pensent que ça marche.
Enfin si on retire tout ceux qui ont choisi systemd, comme arch, opensuse, mandriva, fedora mageia, ou des boites comme intel ou rackspace ( vu que intel bosse dessus, rackspace bosse sur journald ), oui, tout les autres pensent sans doute que ça marche comme il faut.
Mais bon, je suppose que juste donner des noms, ça ne va convaincre personne, donc je vais détailler. Déjà, quand tu dit "le systeme d'init marche depuis 40 ans", tu veux sans doute parler de sysvinit, et donc depuis 30 ans. Bon, pas grave, 10 ans, c'est presque rien. Le système des premiers unix était sans doute un chouia plus frustre, et je me demande si à l'époque, les gens ont ralés devant la complexité d'avoir gasp, une couche d'indirection de plus.
Alors déjà, si ça marche bien, pourquoi toutes les distros ont rajouté le support des tags LSB pour l'ordre des scripts si le format de base est si bien ? Non, pas la peine de répondre, c'est parce que c'est moisi de devoir choisir à la main l'ordre. Et parce qu'il y a pas vraiment de format, juste des conventions, comme le fait de faire un printf, le fait d'avoir X ordres. Je vais pas parler des codes de retour des initscripts, je risquerais de devenir grossier.
Ensuite, non ça me marche pas bien. Par exemple, bind est le premier exemple que je donne à chaque fois. Bind utilise la commande rdnc pour signaler au processus principal qu'il doit s’arrêter. Sauf que comme c'est une communication unidirectionnel, en fonction de la charge de la machine, tu ne sais pas si bind est coupé ou pas au moment ou la commande rends la main. On pourrait croire naïvement que ça n'a pas d'importance, sauf que si tu fais un stop et un start ( ce qui est quand même la façon la plus universelle de faire restart ), et ben parfois, bind ne se relance pas, car l'autre n'est pas mort. Bien sur, ça dépend de la machine et de sa charge. Et se dire qu'on est passé d'un coup en fonctionnement asynchrone sans le savoir, ça montre bien qu'il y a des soucis.
Les distros gèrent ça de différentes façon. Debian fait une boucle avec un kill -0 ( donc n'envoie pas de signal fatal ) et attends que le process meurt, donc que le kill échoue. Ce qui est moche pour le cas rare ou le PID est recyclé assez vite ( ie, il y a une race condition ), car le script attendrait à l'infini ou presque.
Mandriva fait ça avec un sleep 5, ce qui tout aussi un hack.
Systemd, il gère ça en suivant tout les process du groupe. Ie, quand ils sont morts, il le sait.
Le deuxième exemple, c'est mon ami Sympa. Sympa, c'est vachement bien, plus souple de mailman sauf qu'il y a un léger souci. Quand tu le connectes à postgresql ( ce que l'équipe de sysadmin de Mageia a fait ), si la base de données n'est pas disponible, il attends. Il attends pas en tache de fond. Il attends et le script d'init ( une horreur qui lance 5 services d'un coup ) se bloque. Donc si ta base se lance après par la magie des scripts, ton serveur se bloque au boot. En fait, c'est aussi amusant si postgresql mets du temps à mettre son socket à disposition pour une raison X ou Y, car même en étant lancé avant, sympa bloque le boot. Alors bien sur, une fois que tu as pigé le souci, ç'est facile à corriger. D'ailleurs, ça a été corrigé upstream d’après le packageur debian avec qui j'ai eu le temps d'échanger sur le sujet.
Systemd, il gère ça en lançant tout en même temps, et en s'en foutant d'un process qui bloque.
Alors le 3eme exemple, c'est Apache. Apache, c'est un soft cool, ça gère les processus pour toi. Sauf que voila, parfois, y a des processus qui partent en vrille ( ce qui arrive quand on embarque des saletés dedans comme php, ou des cgis ), et parfois, pareil que bind, ça mets du temps à mourir. Comme le process principal tot ou tard meurt, il reste parfois des orphelins. Et c'est coriace ce genre de bestiole, car faut que l'admin vienne à la main faire le ménage. Bien sur, pareil que bind, ça arrive pas toujours, même rarement. Il faut bien tomber sur des circonstances aggravantes pour que ça se produise.
Mais bon, c'est pareil, c'est entièrement du à sysV. Parce qu'avec les cgroups, tu peux faire du kill(9) à tout va après un temps.
Ensuite, des gens vont te dire que la pauvreté de sysV implique de dupliquer le code pour passer un soft en daemon dans chaque soft, que statistiquement tout le monde ne le fait pas tout ce qu'il faut comme il faut ( à savoir se rattacher à un groupe de process, faire un chdir('/'), fermer tout les descripteurs de fichiers, faire un double fork, et sans doute des trucs que j'oublie ) et que du coup, ça cause des soucis
Avec sans doute une petite biére, ils vont continuer pour expliquer qu'il y a des problématiques à la con entre setuid, setgid ( l'ordre par exemple, ou le fait de fait un initgroup avec setgid ), et que même les meilleurs oublient, ou te parler de cas ou un init script s'est vautré sur un fichier de pid non effacé du à un reboot intempestif de la machine.
D'autres gens vont te répondre que systemd mutualise tout ça et que le code écrit une fois utilisé pour 50 softs est plus sur que le code écrit 50 fois par 50 personnes. Ces autres gens vont aussi te dire que systemd va gérer /var/run sur un tmpfs ( http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html ), ce qui est "reboot intempestif friendly".
Mais bon, je suppose que tout ces gens, tu va sans doute dire que leur objectivité est impossible, qu'ils ont tort parce que toi, tu as eu aucun problème donc ça prouve bien que ça n'existe pas ?
L'auteur détaille une paire de souci avec upstart tout au long de l'article, et explique aussi tout au long des liens le genre de souci subtile qu'il y a avec l'usage de scripts de démarrage ( genre l'environnement pas clean )
Le souci du raid logiciel, c'est qu'il est logiciel. IE, avant d'avoir grub2, je pense qu'il fallait magouiller pour booter directement sur un raid logiciel sans avoir un /boot séparé. Il y a aussi l’intégration avec la carte de management distante souvent vendu avec les serveurs, ce qui permet d'agir même quand le serveur est dans le pâté complet
L'avantage aussi du raid hardware, c'est que c'est grosso modo "techos pas cher"-friendly. Tu as ton alerte, tu as le disque qui clignote, tu dit au mec de remettre le disque en réserve, et voila. ( et je sais pas si le disque qui clignote est une feature standard des serveurs avec du raid soft ).
Enfin perso, moi, j'étais dans le camp des gens en faveur du raid soft quand on a eu la discussion à mon taf, mais j'irais pas qualifier les gens qui font du raid hard de mauvais admins. Si les cartes raids se vendent, c'est bien parce qu'il y a des gens qui achètent et qu'ils y trouvent leur compte
Perso, un mec qui a une kalach en état de marche et qui s'en sert, je suis pas sur que j'aurais vraiment de le contrarier en remettant en cause ses capacités. Je dit ça, je dit rien.
Ouf, enfin un peu de bon sens. Le kernel n'est pas fait pour faire du nat, pour ça, il y a des démons en userspace qui existe ( comme natd sur os x ), et je vois vraiment pas pourquoi le code qui gère l’accès au disque est aussi stocké dans le même git que celui qui gère les cartes sons, y a quand même aucune synergie ou raison valable.
Faut arrêter de déconner, on a réussi à faire de la vidéo hors du kernel, on doit bien réussir à faire pareil pour le reste.
À ce rythme la, on va se retrouver à avoir directement des machines virtuelles dedans et trouver ça ultra cool.
( attention, ce post contient des sarcasmes préemptifs en vue de moquer des futures discussions qui vont arriver )
Je pense que tu devrais déjà voir à qui tu réponds, ça t'aiderais sans doute à ne pas dire de connerie.
Alors 1) y a rien à redire, si tu juges les softs par rapport à un développeur plus que par rapport au soft, je ne vois même pas quoi répondre tellement ça frôle les pâquerettes.
2) Le critère qu'une bonne distro s'installe partout et à un livecd, c'est une vision bien personnel de la qualité. Moi, je considère que les livecds, y a que les utilisateurs de base qui s'en préoccupe. Un livecd, c'est joli pour faire une démo, voir un test, mais les démos et les tests, c'est pour les gens qui ont jamais installé une distro. Pour moi, un livecd, ça a avant tout un cout en terme de travail pour les distributions vu qu'il faut les tester, voir si ça démarre bien, s'assurer que ça rentre dans l'espace limité, etc. Vu qu'à moins de vouloir se tirer une balle dans le pied ( ce que Mandriva a fait après le départ de la communauté pour Mageia ), tu ne va pas retirer ton installeur classique, tu te retrouves donc à toujours avoir plus de tests à faire pour proposer des livecds. Et au passage, Debian n'a un livecd officiel que depuis 2008 avec Lenny, alors que d'autres ont eu beaucoup plus tôt ( par exemple, en 2003, mandrake move : http://lwn.net/Articles/63784/ livecd + clé usb ). Bien sur, tu peux dire que Knoppix, c'était le livecd de debian sauf que si Debian ne le reconnait pas comme tel pour divers raisons ( non libre, fait à l'arrache, mélange de paquets ), je vois pas qui tu es pour le faire à la place du projet.
Et pour ton cd et xorg, peut être que ton cd était… mal gravé ? Il y a tout une procédure documenté et publique de test des isos dispo sur le wiki : https://fedoraproject.org/wiki/QA:Fedora_18_Install_Results_Template#Test_Matrix
Tu noteras que "démarrer le lived" en fait parti, et qu'aucun souci n'a été rapporté. Donc soit le problème vient de toi, soit il y a un complot visant à sortir un produit gratuit juste dans le but d'avoir mauvaise réputation sur son propre projet. Au vue du reste des arguments que tu as donné, je pense que l'option 2 est un chouia plus probable.
3) les versions à jour. Comparons au hasard le noyau. Pour avoir le kernel à jour dans debian faut passer par expérimental et unstable. Ou un backport. Pour avoir le kernel à jour dans Fedora, suffit en général d'avoir la version stable de la distro. On regarde Gnome ? Pareil, faut passer par expérimental, le temps de faire les transitions dans unstable. On peut parler du multiarch, ou pendant longtemps, Debian a eu comme solution un truc à base de chroot. ( même si maintenant, je reconnais que le système de Debian est bien plus souple, mais il a fallu du temps pour l'avoir )
On peut parler de tout les trucs que Ubuntu a eu avant Debian aussi ( genre les histoires avec le mainteneur de python, employé Canonical qui a poussé des trucs plus à jour sur Ubuntu que Debian, montrant quand même que Debian était à la traine ).
Même sur les systèmes de build. Debian a un système des plus simples, ou les gens font leur paquets dans leur coin, puis upload tout ça sur le réseau de buildd. Pendant ce temps, Fedora est en train de déployer une architecture avec un bus ou tout le monde peut se brancher http://fedoraproject.org/wiki/Messaging_SIG . Y a pas que Fedora, le système de Build de Suse ( l'Open Build Service ) intègre la revue de paquet avant migration, la maintenance par groupe de paquets, son propre VCS, la recompilation automatique en cas de changement des libs, une interface web de construction de livecd, etc. Même ubuntu, avec le système de ppa, est en avance.
Le truc de debian, il fait le boulot, mais pas plus. Même des distros relativement petites comme Mageia arrivent à innover sur des points par rapport à Debian, comme le fait de publier intégralement la configuration des machines via puppet ( http://svnweb.mageia.org/adm/puppet/ ) pour pousser la transparence et la collaboration à un niveau plus loin.
La communauté Debian fait plein de choses, remplit un rôle essentiel, contribue au libre comme toutes les distros, voir plus via le portage sur des plateformes exotiques, fournit une version totalement communautaire et libre. Mais de la à dire qu'ils sont "toujours devant", c'est se fourrer le doigt dans l’œil. Comme souvent, la réalité est plus nuancé. Debian a pour objectif la stabilité, la qualité, la liberté. En général, ça va à l'encontre de l'innovation rapide. D'ailleurs, c'est aussi le constat fait en 2010 par une des membres du projet : http://penta.debconf.org/dc10_schedule/events/627.en.html
Quand à ta remarque sur le fait de pas savoir faire de paquets xorg, il y a une différence entre "faire un paquet", et "s'assurer que ça crashe nulle part". En fait, quand tu vois le nombre de dev Xorg chez RH qui sont affecté sur Fedora, je pense que tu commencerais aussi par investiguer plus sérieusement l'hypothèse d'un souci sur le cd.
Et si vraiment tu as trouvé un bug dans xorg au point de crasher avec ta carte, bravo, n'hésite pas à le remonter, sauf à croire que des lutins magiques vont le corriger tout seul. Le code de X.org, c'est globalement le même partout, et Fedora essaye de se tenir au plus proche de l'upstream pour justement pouvoir remonter les soucis.
Sur le fait de faire des paquets à jour, c'est tellement simple qu'un script perl peut le faire. Exemple http://www.linuxcertif.com/man/1/rpmbuildupdate/
Tu noteras la présence de mon nom en bas dans la liste des auteurs, donc globalement, ce que tu fais "presque automatiquement", d'autre l'ont fait avant toi, de façon plus générique ( car c'est pas "juste le kernel" à coup de make-kpkg, c'est un paquet arbitraire rpm d'une distro complète ), et depuis un chouia plus longtemps ( genre 5 à 7 ans ). En fait, je connais même une personne qui gère automatiquement la mise à jours de tout les paquets perl d'une distro linux. Genre 500 paquets, via un script. Le vrai souci, c'est pas la mise à jour, c'est la correction des soucis suite aux mises à jour, ou les adaptations, répondre aux bugs, ou ce genre de choses. Pas remplacer la version, télécharger un tar.gz et lancer une commande. C'est déjà bien de faire ça, tout le monde n'arrive pas et je ne peux que t'encourager à contacter mentors.debian.net, mais moi, ça m'impressionne pas le moins du monde.
4) Pour la fiabilité,je te renvoie sur la réponse sur la durée de vie ( en point 6 ). Sinon, comme tu n'as pas eu le temps de chercher plus en détail les choses, un des buts de Fedora est l'innovation, ce qui passe par un cycle d'itération rapide ( en gros, par des changements ). C'est marqué sur le site web : https://fedoraproject.org/wiki/Objectives .
C'est pas ce que tu cherches, pas de souci.
5) alors les admins en question, c'est des amis à moi, et je pense qu'au vue des articles sur openldap publié par l'un d'eux dans linuxmag, tu assumes un manque de compétence totalement mal placé. Moi, j'ai été payé pour être admin debian pendant des années, donc je pense que je suis assez compétent et bien placé pour dire ce qui ne va pas. Et pareil pour les autres ( genre, y en a un qui est maintenant sysadmin chez Google, boite qui n'est pas connu pour embaucher des rigolos ). Et la plupart continuent à faire de l'admin d'autre chose que de la Debian sur leur temps libre ou pro. ( genre, gasp, certains font même des paquets pour des distributions ou font du code libre ). Toi, je sais toujours pas ce que tu fais, à part étaler un élitisme mal placé, à plus forte raison quand tu explique que tu n'es pas admin. Donc si tu tiens à avoir un avis sur des gens que tu connais pas, je pense que tu devrais te restreindre à ceux dont tu connais le métier ( genre, ton métier ), les contraintes et les besoins, et pas généraliser ton avis de mec extérieur sur la base d'un panel non représentatif car sélectif et renfermé sur lui même.
6) la durée de vie ( ie le support de sécurité ) d'une Debian, c'est ~ 3 ans. La durée de vie d'une Ubuntu, c'est 5 ans sur la dernière LTS. La durée de vie d'une RHEL, c'est 10 ans ( voir 13 pour la maintenance étendu sur RHEL 5 ). Windows 2000 c'est 10 ans aussi, 13 pour XP. Solaris, ça tape aussi dans les 10/12 ans. Source :http://benjamin-schweizer.de/operating-systems-lifecycle-chart.html + tout les sites des distros. Tu m'excuseras donc de trouver un peu courte et limité ta vision du long terme.
Certes, 3 ans c'est bien pour une distribution communautaire, même un exploit quand on regarde à quel point ça fait chier de faire de la maintenance pour le bénévole moyen. Mais bon, voila, 3 ans, ça fait 2 ans de moins que du FreeBSD ( qui est aussi un projet communautaire ).
Quand à prendre une Knoppix, c'est juste surréaliste. La knoppix est in-upgradable, n'a pas de mise à jours de sécurité, et est un mélange de testing, unstable et d'experimental. Je compte plus le nombre de gens ayant eu des soucis sur les listes des lugs que j'ai fréquenté. C'est pas pour rien que Debian a un projet à part pour les lives. Non seulement Knoppix réponds pas aux exigences qualités de Debian ( ou même dés le début, ne réponds pas aux critères en matière de licence, comme le rappelle une polémique que tu as sans doute pas connu il y a 10 ans http://lwn.net/Articles/14651/ ), mais en plus, en 12 ans, ils ont pas cherché à y répondre et à intégrer Debian, alors qu'il y a un projet pour depuis des années.
7) j'ai pas dit qu'il y a que Fedora, mais force est de constater que Debian est arrivé bien tard. C'est pas moi qui le dit, c'est le DPL lors qu'il a annoncé l'équipe Debian Cloud ( http://wiki.debian.org/Cloud ) lors de la mini Debconf à Paris en Novembre 2012, tu peux voir les lightings talks du dimanche, sauf erreur de ma part. Il suffit de voir que l'intégration d'Openstack est faite pour le moment à part ( alors que Ubuntu l'a fait très vite, que Fedora a depuis une paire de release une version à jour des dits logiciels, que Suse et RH investisse dessus et ont donc les paquets et l'expertise, voir se prépare à proposer du support ). On peut parler des plateformes de PaaS, ou il y a rien pour le moment sur Debian ( genre, pas openshift, pas cloudfoundry, pas de cloudbees, pour ne citer que les plateformes libres et connus ).
Et non, dire "j'ai vu de la virtualisation", c'est pas du SaaS. Le SaaS, ou Software As A servie, c'est par exemple des choses comme Gmail, ou Salesforce.Y en a un des 2 qui tourne sur une version custom de Debian avec des softs maisons ( cf Debconf 2011 en croatie, présentation sur Ganeti, Ganeti qui est libre juste parce qu'une équipe de dev Debian l'ont poussé ), et l'autre sur une RHEL non modifié ( https://www.redhat.com/resourcelibrary/case-studies/salesforce-com-relies-on-red-hat-2 ). Certes, le SaaS, c'est super vieux, et c'est très largement indépendant de la plateforme sous jacente, et bien sur, on peut faire du SaaS sur Debian, si on fait le taf à la mano, voir si on rajoute sa propre pile ( ie, si on est Google ). Je ne doute pas que Debian rattrape les choses via le travail des gens d'Enovance, et je ne doute pas que Debian soit une bonne base pour ça, je ne doute pas qu'en rajoutant des paquets externes, on arrive à avoir une plateforme de qualité. Mais c'est au final comme tout système linux, justement parce qu'il y a rien de magique. Kvm est dispo partout, libvirt aussi.
Donc, "j'ai vu en 2005/2007 des gens faire de la virtualisation en prod sur de la debian", c'est bien joli. Moi, j'ai vu des projets de déploiement de VMWare sur du Windows 2003 à mon taf en 2005/2006 par des prestas externes, je vais pas clamer "Microsoft a fait du cloud en 2005". Y a une définition communément admise faite par le NIST, et je pense que "faire de la virtualisation en prod" n'est pas vraiment la traduction française de :
"Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."
Et encore une fois, le but n'est pas de savoir si on peut le faire ou pas. Le but est de savoir si c'est simple ou pas d'avoir les dernières technos à jour sans ajout externe. Le concept "d'intégration dans une distro", c'est pas d'aller prendre des choses hors de la distro par définition.
8) Enfin, si je te suis, parce que les gens de Backtrack ont pris Ubuntu, alors ça fout en l'air tout l'argumentaire ? Donc je vais répondre par 3 questions :
I) si Debian est bien pourquoi Backtrack n'a pas pris Debian directement. Car oui, l'argument avec Ubuntu est à double tranchant. En fait, si Debian est si bien, pourquoi Backtrack, Mint ou autres ne se basent pas vraiment dessus directement ?
II) si Debian est si bien, pourquoi est ce qu'il faudrait une dérivé ( backtrack ) de dérivé ( ubuntu ) pour faire des choses ?
III) Si Debian est si bien, pourquoi les "gars de Backtrack" ne sont pas directement "les gars de Debian" ?
Donc sur la base de ça, en quoi Backtrack serait un exemple de raison de dire que Debian est mieux que tout alors que tout montre que c'est tellement mieux qu'ils sont obligés de faire leur propre fork pour mettre des outils que d'autres distros filent de base.
Par exemple, sur ma Fedora, j'ai pas eu de souci à casser le wep de 3 de mes voisins vu qu'il y a tout ce qu'il faut à portée de main. Et non seulement il y a tout ce qu'il faut, mais en plus, pour les gens qui préfèrent les versions spécialisés et les livecds, il y a en un qui existe ( http://spins.fedoraproject.org/security/ ).
Et si le but est de fournir juste une série d'outils pré-installés, c'est à mon sens ridicule de faire un projet et un livecd séparé. Tout les systèmes de paquets que je connais ( et j'en ai fait un paquet ) sont capable de faire un paquet vide qui tire X autres paquets pour obtenir le même effet.
Donc pour terminer, oui, je pense que je peux difficilement te prendre au sérieusement, malgré une passion et une bonne volonté à cause de ta façon d'exposer des certitudes sans nuancer ou justifier. J'ai donné assez de sources vérifiables, et que j'estime non partial à l'encontre de Debian, j'ai donné des exemples concrets et divers, j'ai pris le temps d'expliquer en détail les points, donc si à partir de la, tu persistes, soit, c'est ton droit.
Peut être le coté "j'ai raison, c'est indéniable". Moi, je connais au moins une équipe d'admin qui a quitté des mandriva pour prendre des debian, puis pour revenir vers de la mandriva ( car debian était trop en retard ). Donc tes données totalement subjectives sont contredites par mes données subjectives. On peut pas en tirer grand chose, à part que tes certitudes mal placés valent bien un -10.
Sinon dire "ça vaut pas debian", c'est chercher les coups de bâtons. Par exemple, quand tu veux l'intégration de softs nouveaux, genre tout ce qui tourne sur le cloud ( l'équipe cloud de debian étant un chouia en retard par rapport à de la fedora ou de l'ubuntu, vu que ça date d'il y a moins de 4 mois ), quand tu veux avoir des versions de softs comme systemd ( qu'on aime ou non, y a des gens dont moi qui aiment l'idée et visiblement, au moins un debianneux vu qu'il y a un paquet ) ou du selinux ( pareil que systemd, on peut aimer ou pas, mais debian est pas la plateforme de choix pour ça ). Y a largement des tas de raisons dans l'annonce ( par exemple, les outils pour utiliser secureboot avec tes propres clés, eucalyptus ou openstack, etc ).
Donc encore une fois, ta certitude fait que oui, tu passes pour un rigolo. Tu a le droit de pas aimer Fedora, d'aimer Debian, tu as sans doute des raisons valables comme le fit qu'autour de toi, tout le monde te dit que c'est mieux, ou de pas retrouver tes habitudes, je le discute pas, et je te demande même pas de remettre ça en cause. Par contre, tout le monde n'a pas tes raisons, tout le monde ne fait pas tes choix, et des gens content avec de la fedora ou du red hat, ça existe. Ça existe assez pour avoir des contributions externes. Les gens font pas ça car ils sont tous idiots et n'ont pas vu la lumière d'aller faire du debian.
yumex ? C'est packagekit l'outil par défaut. Il y a eu des discussions pour le portage du software control ( ou plutot un fork qui ne requiert pas d'assignation de copyright ) il y a un temps, mais je sais pas ou sont les efforts.
Et ouais, Fedora est pas très soft proprio friendly. Je me souviens d'une mise à jours de X ou le choix était entre "faire des correctifs pour les pilotes intels libres" ou "garder l'ancienne version de X pour que les pilotes nvidia tournent encore". Et le choix en faveur de la mise à jour a été faite. La distribution bouge trop vite pour qu'un éditeur proprio veuille suivre. Donc oui, si tu as une dépendance vers des softs fermés, je te conseille pas de prendre une Fedora, ç'est clairement pas le but de la distribution, une Ubuntu sera plus en accord avec ce genre de philosophie.
En fait, j'ai regardé un collègue faire des trucs avec l'outil de partitionnement, et il a réussi une fois qu'on a vu qu'il faut pas mettre l'unité dans le popup pour la taille, contrairement à ce que l'infobulle dit. Je sais pas si c'est la traduction ou la formulation qui n'est pas clair. Ensuite, c'est un mec un peu technique, je comprends que ça bloque d'autres personnes.
J'ai des doutes sur btrfs par défaut en F19, il y a justement un thread sur le sujet en ce moment sur fedora-devel.
Et les gens remontent divers soucis sur le sujet, avec bug reports parfois, c'est rien de dramatique, mais pas pour du défaut.
Le libre n'a pas vraiment pour vocation première d'être un produit fini, plus de faire avancer l'innovation, la collaboration, le partage des connaissances. Bien que tout le monde bosse pour arriver à un produit fini, ça n'arrive pas tout seul, et il faut à un moment mettre à dispo des versions moins fini pour faire avancer les choses.
C'est le souci du hardware, tu peux pas vraiment le faire produire gratuitement, au contraire du logiciel ou le cout de la copie est proche de 0.
C'est pas fini, ouais. C'est cher, ouais aussi. Mais je pense que c'est pas à destination des gens moyens, c'est pour les gens qui veulent faire avancer le logiciel libre en codant dessus. C'est une boite qui a tenté de produire à ses frais un produit de niche et qui n'attends pas d'avoir attends la masse critique pour le vendre à tous car ça ne va pas arriver sans un premier lots ( ni même plein d'autres lots ).
Si maintenant, c'est trop cher pour toi, c'est pas grave. Je pense que tu n'aurais pas codé dessus, donc te le vendre ou pas, à ce stade, ça va rien changer. Tu va pouvoir te morfondre à te dire "pourquoi y pas plus de libre dans le matos" sans comprendre que ça se fait pas en un jour, ni les mécanismes économiques derrières.
Parce que la collaboration, c'est difficile, alors que forker, c'est plus simple, tu as juste à faire un git clone, et voila. Et puis tu remplaces 2/3 chaines et c'est bon.
Le mec derrière solusos, c'est celui qui a fait LMDE. LMDE, c'est basé sur mint, un fork de ubuntu, qui est un fork de debian. Formidable de voir combien de distro y a besoin pour adresser les besoins des gens ( ie, autant ubuntu et debian, c'est différent, autant mint aurait pu aider ubuntu ou debian ).
Encore une fois, je pense que je suis bien placé pour dire que faire un os ou un bureau, c'est plus dur qu'on crois, et que forker doit être le dernier recours, et pas le premier. C'est comme dans une relation, partir et se séparer n'est pas la première chose à faire, c'est la dernière. Vu que déjà, Mint gère pas les updates de sécurité sur son code ( CVE-2012-1566 ), Mate se contente la plupart du temps de reprendre les patchs que gnome fait sur son code ( exemple, les commits du 21 décembre pour https://github.com/mate-desktop/mate-file-manager/commits/master ) ou des patchs mineurs sur configure etc, je vois pas comment avec encore moins de ressources, ça va donner un truc.
Le souci est surtout que le modem 3g du gta4 utilise des commandes standards AT, alors que de ce que j'ai vu, les modems divers et variés sur la plupart des tels utilisent des protocoles tout à fait proprio et fait maison ( et parfois binaire ).
Ma foi, c'est pas comparable plus plusieurs raisons :
- il y a des vies en jeu dans le fait de conduire. C'est pas le cas dans le mariage.
il y a pas une règle qui dit "faut pas laisser les handicapés conduire", mais "il faut garder le contrôle du véhicule". Dans le cas du mariage, la règle, c'est de jurer de s'aimer, de se protéger mutuellement, de s'être fidèle. Rien qui ne soit impossible pour 2 personnes, indépendamment du sexe et des orientations.
Si le handicap ne te permet pas de suivre les règles, alors c'est pas parce que tu es handicapé mais parce que tu peux pas suivre les règles.
Ensuite, si pour toi, les règles du mariage, ça implique que le mâle féconde la femelle pour fonder une famille, ouais, je comprends que ça te gène. Grande nouvelle, la reproduction sexuée n'est pas la seule façon de fonder une famille. L'adoption existe depuis toujours. La fécondation in-vitro, qu'on accepte pour un couple stérile. Ou juste ne pas avoir d'enfant, ça reste pas moins une famille ( que je sache, on ne mets pas de limite supérieur ou inférieur, si tu vis avec tes parents, ça reste une famille, si tu vis sans également ).
Donc il existe déjà des familles à tout les sens du terme non lié à la fécondation. Et dans le cas de l'adoption, c'est même pire, je crois pas qu'on soit en manque de gamin à adopter, plutôt le contraire.
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
Alors en lisant la discussion sur lwn, quelqu'un a pointé
et notamment http://upstart.ubuntu.com/cookbook/#override-files
Donc ça peut se faire proprement depuis upstart 1.3 ( soit depuis bientôt 2 ans ).
[^] # Re: rapidité, changement
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Bah, voila, une troisième méthode que je connaissait pas, et non, je parle en effet d'une autre façon de faire.
Mon coloc s'était plaint de devoir mettre "UsePAM yes" dans sa config, et j'avais fini par trouver un truc en lançant ssh à la demande via les sockets, ce qui fait 1 cgroup par connexion.
Par exemple, sur ma machine ( ou je fait ça pour économiser 3mo de ram afin de pouvoir continuer à lancer des gros trucs java pour remplir les 8G qui reste ), en lançant 2 connexion ssh, j'ai 2 entrées dans la sortie de systemctl :
Et chacune est dans son propre cgroup, ce qui fait qu'un restart du service ne tue rien.
Mais c'est pour moi un effet de bord du fonctionnement par socket plus qu'autre chose, donc je trouve ma méthode tiré par les cheveux.
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 5.
en gros, tu prends un job upstart au pif, genre ssh sur mon n9 :
Il y a 2 parties :
* la partie script ( entre script / end script )
* la partie pas script, à savoir le reste
La, si je veux par exemple que ssh ne s’arrête pas quand dbus se coupe ( c'est mon tel, je fais ce que je veux ). Ou imaginons que je veuille changer la directive oom, changer la valeur de nice, etc. Faut que je modifie le fichier.
Sauf que si je modifie le fichier, il se passe quoi à la prochaine mise à jour qui va faire pareil ( exemple, une modif qui change le chmod 0755 en 0700 pour cause d'un souci de sécurité ( exemple inventé )) ?
3 choix :
- le système de paquets écrase ma modification. Donc je doit repasser pour la remettre, si je m'en souvient.
- le système de paquets n'écrase pas la modification. Mais je doit passer pour rajouter sa modif dans mon fichier modifié.
- le système de paquets me demande, donc je doit passer pour fusionner les changements.
Dans tout les cas, ça requiert d'être la pour s'occuper de l'upgrade et tout ça parce qu'il y a des informations du domaine de la distribution (à savoir la partie 'script' ) mélangés avec des choses du domaine de l'admin ( à savoir les dépendances, le choix de l'oom ou pas, du nice, etc ). Et ça, c'est un job simple, il y a pas mal d'option en plus dans upstart.
Systemd gére ça de façon élégante en prenant les informations de 3 fichiers, et en appliquant la config dans un ordre précis. Si j'ai toto.service dans /lib et dans /etc:, les informations en plus de /etc ( genre une valeur de nice ) se rajoute à celle de /lib. Donc quand la distro modifie le fichier dans /lib, j'ai rien à faire de spécial. Il y a même un outil spécifique ( http://www.freedesktop.org/software/systemd/man/systemd-delta.html ) pour trouver ce qui a été modifié dans /etc par rapport à /lib
Les daemons font en général un double fork. Donc ton wait va attendre sur le premier, pas sur le second. Et tu ne peux faire de wait que sur un process fils, sauf erreur de ma part. Donc à partir du moment ou ton script d'init t'a rendu la main, tu peux plus faire de wait sur le pid de bind, donc inapplicable dans le cas exposé, à savoir d'un reboot. D'ou l'usage de ptrace par upstart pour choper le pid ( http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ ).
oui, et sauf erreur de ma part, Ubuntu ( entre autre ) l'a fait avant que Lennart ne pousse ça dans systemd, vu que je me souvient distinctement avoir entendu raler le dev debian qui servait de sysadmin dans mon ancien job contre les devs Ubuntu d'avoir mis /var/run en tmpfs. Il avait du rajouter 2/3 lignes pour le script d'init pour refaire /var/run/nufw/ ou ce genre de choses avant de lancer le démon de notre produit.
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 1.
D’après ce que je lit ici et la, grub-ieee127 ne serait pas ce que tu veux ? ( la dernière sparc que j'ai vu, c'était à la poubelle y a 1 an, donc je suis plus très au courant de ce qu'il faut faire en dehors de "magouiller avec l'open firmware" ).
Mais si tu arrives à le faire marcher, je suis sur qu'un peu de doc pourrait aider.
[^] # Re: rapidité, changement
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Alors d'une part, il y a d'autre fondateurs de distros qui postent parfois ici et la, et tu sembles prendre ça plus à la légère ce qu'ils disent ( enfin pareil, c'est un avis personnel, pas une parole divine ).
Et d'autre part, Patrick a un vision orienté vers son but, à savoir la maintenabilité par lui même de la distribution, et la simplicité extréme que ça requiert, quitte à ce que ça ne réponde pas au besoin de tout le monde.
Son refus de pam est un exemple, et pas grand monde ne va le suivre sur ce point, car même si pam a eu des débuts difficiles, ça reste relativement pratique dés que tu veux avoir un serveur ( comptes en ldap, kerberos ) ou si tu veux essayer de rivaliser avec du windows sur le poste client ( pareil, ldap, etc ). Ou de la sécurité ( authentification à 2 facteurs, lecteur d'empreinte digital ).
D'ailleurs, la gestion des processus par cgroups de systemd ( pour en revenir au sujet ) implique de dire à sshd de se "détacher" des processus utilisateurs pour éviter de les tuer lors d'un restart, et d'avoir son propre cgroups par utilisateur ( ce qui permet d'appliquer des quotas cpu/ram/etc par utilisateur via les cgroups, justement ). Et pour ça, le moyen le plus propre est de passer par pam, qui va voir au login qu'il y a un utilisateur et qui va le changer de cgroups.
Sans ça, tout les utilisateurs sont dans le cgroup de sshd, et se font donc tuer sans pitié en cas de restart du demon. ( il y a une méthode pour faire autrement, mais c'était tirer par les cheveux et j'ai oublié ).
Donc un passage à systemd serait sans doute aller à l'encontre de son objectif de garder pam hors de slackware ( sauf si ce n'est plus d'actualité, bien sur ).
[^] # Re: rapidité, changement
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Scott explique pourquoi il a pas pris initng, launchd etc dans ce post :
http://netsplit.com/2006/08/26/upstart-in-universe/
Et moi, j'avais le sentiment que upstart a commencé comme projet à part ( au vue du vieux nom de domaine en .at ) avant de passer sous l'aile de Canonical. Mais vu que dans mon souvenir, il y a le fameux CLA, je doit sans doute avoir tout faux.
Il y a aussi eu des discussions pour l'intégration de systemd, voir une page de wiki ( https://wiki.ubuntu.com/systemd ), mais Canonical a choisi de garder Upstart ( http://www.iloveubuntu.net/ubuntu-1210-quantal-quetzal-continue-upstart-systemds-rumors-cleared ). La raison évoqué est les tests ( upstart possède une batterie de 12000 lignes de tests en C ), et le fait que upstart réponde plus à leurs besoins.
Tel que je vois la ou Canonical veux aller, c'est l'embarqué ( smartphone, tv ), et le cloud avec des bécanes jetables ( ie, les guests ). Et je pense que le concept de gestion d'événement s’intègre bien aussi avec le premier ( besoin de mobilité et d'une gestion dynamique ) qu'avec le second ( rajouter un file system en réseau via ceph, etc ).
Upstart a été utilisé pour chromeos ( donc un pc portable mobile ), pour le nokia n9 ( donc aussi un appareil mobile ), et sans doute dans Ubuntu Tv et le reste.
Ensuite, pour la partie cloud, ils sont partie sur juju plutôt que de l'intégrer ça directement dans l'OS via upstart, c'est un peu dommage ( et qu'on me dise pas "ça rends juju portable" car ça continue à utiliser des ppa à tout va ). La transparence réseau de upstart, ça aurait pu faire une sacré killer feature pour le système.
( sinon, upstart dépend de libNIH /o\ )
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 1.
Si, le projet est à l'abandon. Mais j’étais pas au courant du port pour netbsd, ni du fait que ça dépend fortement de mach ( ceci dit, j'aurais du m'en douter, mais j'aurais penser qu'un soft non portable aurait fait raler tout le monde ). Je suppose que le fait de dépendre des plists ( un format basé sur xml d'os x, qui peut aussi être compilé en binaire ) risque de faire grincer des dents.
D'ailleurs, si des gens ont du temps à perdre, y a la présentation du dev de launchd chez Google en 2007 :
http://www.youtube.com/watch?v=SjrtySM9Dns
Il explique par exemple que le fait de lancer plusieurs choses en même temps permet de tirer parti des machines multi cores, il montre pas mal d'idées qui se sont retrouvés dans systemd ( le lancement activé par un chemin, par socket et dans le désordre ), et il montre aussi le genre de choses qu'on peut faire avec l'activation par socket dans la session user. Son exemple, lancer X ( qui plante quand il teste ) ou ssh-agent à la demande, ce qui permet de décharger la session des trucs qu'on utilise pas vraiment ( avec comme avantage de consommer un peu moins de ressources, d'avoir un session qui démarre un peu plus vite et surtout d'être plus robuste ).
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Visiblement, c'est dispo :
http://robertmh.wordpress.com/2009/07/18/grub-on-sparc/
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
Ou Ceph, ou glusterfs.
Je suis pas sur que zfs fasse la transparence réseau. ( mais comme tout les ex produits Sun, ça fait sans doute tout y compris le café )
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Il dit qu'il a plus de genoux
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 10.
Donc récapitulons. J'ai une opinion donc je manque d'objectivité ( c'est grosso modo la définition, mais bon, passons ). Je donne donc pour éviter de tomber dans ce travers un lien de quelqu'un que je connais pas, mais d'un coup j'aurais peur de dire ce que j'ai déjà dit 15 fois sur linuxfr.
Certes. Et au final, quoi que je dise, je suis pro fedora, donc forcement, je vomis ce que fait Ubuntu. Parce que c'est bien connu, quand on utilise une distribution, ça retire tout sens critique, donc pas besoin de donner d'argument.
Au lieu de m'éterniser sur des arguments stériles et des attaques ad hominem, regardons de plus prêt ce que l'auteur de l'article dit :
Rajoutons donc ce que je sais à savoir que upstart utilise la commande ptrace pour suivre les process, et que curieusement, ça passe pas tout le temps. Comme je ne veux pas donner dans le FUD, il y a 2 liens :
https://bugs.launchpad.net/upstart/+bug/406397
https://bugs.launchpad.net/upstart/+bug/703800
Donc voila 4 problèmes liés à l'architecture d'upstart ( ie, le fait d'avoir un fichier de config qui est en fait un script, et le fait d'utiliser ptrace pour suivre les processus ), corrigé par le design de systemd, à savoir avoir des fichiers au format .ini, ce qui permet de mettre des priorités sur les directives qui découlent d'un ordre de lecture prétabli, et l'usage des cgroups, pour gérer les groupes de processus. Cgroups déjà à la base de lxc, donc relativement étanche.
Quand je dit subtile, je veux dire par la difficilement identifiable. Par exemple, se connecter en ssh, et relancer un serveur web et voir plus tard que tout d'un coup, ton cgi qui appelle la commande 'sort' merdouille parce que la variable LANG n'a pas été nettoyé ( ie, LANG=FR_fr est passé au script, puis à apache, puis à ton cgi, puis à 'sort' qui va trier les caractères diacritiques d'une façon différente en fonction de la locale ). Ou voir qu'en fonction de comment est lancé ton soft, tu as un autre format de date dans les logs, car il reprends LC_ALL et LC_TIME. Bien sur, si on était sur d'avoir toujours le même environnement clean, ça n'arriverais pas ( khof http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRestartEnvironment khof )
J'ai rien contre Gentoo, j'ai un serveur sous Gentoo chez OVh, et je dirais même que je connais des gentooistes ( bien la preuve que je suis pas raciste ). Mais sérieux et solide n'est pas forcément ce qui me vient à l'esprit. J'aurais plutôt dit flexible et adaptatif.
Sérieux, pour moi, ça implique par exemple un suivi des soucis de sécurité et pendant un bon bout de temps, il n'y plus eu d'alertes de sécurité (cf http://www.gentoo.org/security/en/glsa/index.xml entre janvier 2010 et mai 2010 ).
Solide, je dirais que c'est plus la personne qui décide de pas abuser de l'adaptabilité. Il faut bien voir qu'en pratique et en fonction des choix de l'admin, chacun a un système différent. L'utilisateur est le premier, dernier et seul personne à faire la QA de son système. ( bon, pas exactement, mais j'ai toujours voulu caser la formule ). Les paquets passent de masked a unmasked sur la base des retours des gens, ce qui garantit des tests minimums, mais les retours sont se font dans des environnements différents. Et c'est une approche différente d'une debian ou d'une autre distro binaire, ou tout le monde a les mêmes binaires ce qui fait que si ça marche chez X personnes, alors il y a moins de raison que ça foire ailleurs. Alors que gentoo, avec les use flags, etc…
Et comme il y a pas de mises à jours de sécu au sens "mise à jour minimal" avec la QA qui va avec, la solidité n'est pas une chose que j'estime acquise, bien que je n'ai pas eu à me plaindre personnellement si souvent et que c'est suffisant pour ce que j'en fait.
Openrc, qui a quand même eu 10 ans pour se faire adopter, semble faire un revival. Bien sur, personne ne va dire que openrc, il supporte le boot en parallèle avec des bugs compliqué à reproduire ( https://bugs.gentoo.org/show_bug.cgi?id=391945 ).
Je n'ai pas dit "révolution", j'ai laissé mon pull noir à col roulé au placard. Et j'ai du mal à saisir. L'auteur de l'article n'a pas eu de situation ou le "fair share scheduling", traduisons par "partage équitable de l'ordonnanceur" a pu s'appliquer, donc ça rends systemd compliqué ? Si ses serveurs ne sont pas chargé ras la gueule au point d'en avoir besoin, ou est le souci ?
Pour info, ce dont il parle est détaillé la : http://lwn.net/Articles/415740/ , avec la réponse de lennart la : http://lwn.net/Articles/415756/. Si les gens passent pas leur temps à mettre leur bécane sur les genoux à grand coup de compile kernel pour constater si systemd fait un truc, c'est la faute de systemd ?
Pour info, ce que l'auteur a voulu dire, c'est que contrairement à smf, l'init de solaris, systemd n'utilise pas de xml pour sa config donc l'admin n'a pas à interagir avec. Ensuite, la doc est en docbook ( un format de publication en xml ), et en effet, 15% du contenu du tarball, c'est de la doc en xml.
Mais c'était bien tenté.
Pas moi. Ni les gens de chez Sun, vu qu'ils ont refait le système avec SMF. Ni les gens d'Ubuntu ou de Chrome OS, vu qu'ils ont upstart ( ou RHEL 6, ou Maemo ). D'ailleurs pas les gens de Gentoo, vu qu'ils ont fait openrc. En fait, Apple aussi a refait son système d'init il y a 3/4 versions. Donc oui, si on retire tout ça, tout le monde pense que ça marche.
Enfin pas ceux qui ont fait runit ou initng non plus. Ni les gens de FreeBSD qui ont proposé un portage de launchd dans un Google Summer of Code.
Enfin donc, à part tout les gens qui sont tellement d'avis que ça fonctionne correctement qu'ils se sont dit qu'il faut le remplacer, ouais, tout les autres pensent que ça marche.
Enfin si on retire tout ceux qui ont choisi systemd, comme arch, opensuse, mandriva, fedora mageia, ou des boites comme intel ou rackspace ( vu que intel bosse dessus, rackspace bosse sur journald ), oui, tout les autres pensent sans doute que ça marche comme il faut.
Mais bon, je suppose que juste donner des noms, ça ne va convaincre personne, donc je vais détailler. Déjà, quand tu dit "le systeme d'init marche depuis 40 ans", tu veux sans doute parler de sysvinit, et donc depuis 30 ans. Bon, pas grave, 10 ans, c'est presque rien. Le système des premiers unix était sans doute un chouia plus frustre, et je me demande si à l'époque, les gens ont ralés devant la complexité d'avoir gasp, une couche d'indirection de plus.
Alors déjà, si ça marche bien, pourquoi toutes les distros ont rajouté le support des tags LSB pour l'ordre des scripts si le format de base est si bien ? Non, pas la peine de répondre, c'est parce que c'est moisi de devoir choisir à la main l'ordre. Et parce qu'il y a pas vraiment de format, juste des conventions, comme le fait de faire un printf, le fait d'avoir X ordres. Je vais pas parler des codes de retour des initscripts, je risquerais de devenir grossier.
Ensuite, non ça me marche pas bien. Par exemple, bind est le premier exemple que je donne à chaque fois. Bind utilise la commande rdnc pour signaler au processus principal qu'il doit s’arrêter. Sauf que comme c'est une communication unidirectionnel, en fonction de la charge de la machine, tu ne sais pas si bind est coupé ou pas au moment ou la commande rends la main. On pourrait croire naïvement que ça n'a pas d'importance, sauf que si tu fais un stop et un start ( ce qui est quand même la façon la plus universelle de faire restart ), et ben parfois, bind ne se relance pas, car l'autre n'est pas mort. Bien sur, ça dépend de la machine et de sa charge. Et se dire qu'on est passé d'un coup en fonctionnement asynchrone sans le savoir, ça montre bien qu'il y a des soucis.
Les distros gèrent ça de différentes façon. Debian fait une boucle avec un kill -0 ( donc n'envoie pas de signal fatal ) et attends que le process meurt, donc que le kill échoue. Ce qui est moche pour le cas rare ou le PID est recyclé assez vite ( ie, il y a une race condition ), car le script attendrait à l'infini ou presque.
Mandriva fait ça avec un sleep 5, ce qui tout aussi un hack.
Systemd, il gère ça en suivant tout les process du groupe. Ie, quand ils sont morts, il le sait.
Le deuxième exemple, c'est mon ami Sympa. Sympa, c'est vachement bien, plus souple de mailman sauf qu'il y a un léger souci. Quand tu le connectes à postgresql ( ce que l'équipe de sysadmin de Mageia a fait ), si la base de données n'est pas disponible, il attends. Il attends pas en tache de fond. Il attends et le script d'init ( une horreur qui lance 5 services d'un coup ) se bloque. Donc si ta base se lance après par la magie des scripts, ton serveur se bloque au boot. En fait, c'est aussi amusant si postgresql mets du temps à mettre son socket à disposition pour une raison X ou Y, car même en étant lancé avant, sympa bloque le boot. Alors bien sur, une fois que tu as pigé le souci, ç'est facile à corriger. D'ailleurs, ça a été corrigé upstream d’après le packageur debian avec qui j'ai eu le temps d'échanger sur le sujet.
Systemd, il gère ça en lançant tout en même temps, et en s'en foutant d'un process qui bloque.
Alors le 3eme exemple, c'est Apache. Apache, c'est un soft cool, ça gère les processus pour toi. Sauf que voila, parfois, y a des processus qui partent en vrille ( ce qui arrive quand on embarque des saletés dedans comme php, ou des cgis ), et parfois, pareil que bind, ça mets du temps à mourir. Comme le process principal tot ou tard meurt, il reste parfois des orphelins. Et c'est coriace ce genre de bestiole, car faut que l'admin vienne à la main faire le ménage. Bien sur, pareil que bind, ça arrive pas toujours, même rarement. Il faut bien tomber sur des circonstances aggravantes pour que ça se produise.
Mais bon, c'est pareil, c'est entièrement du à sysV. Parce qu'avec les cgroups, tu peux faire du kill(9) à tout va après un temps.
Ensuite, des gens vont te dire que la pauvreté de sysV implique de dupliquer le code pour passer un soft en daemon dans chaque soft, que statistiquement tout le monde ne le fait pas tout ce qu'il faut comme il faut ( à savoir se rattacher à un groupe de process, faire un chdir('/'), fermer tout les descripteurs de fichiers, faire un double fork, et sans doute des trucs que j'oublie ) et que du coup, ça cause des soucis
Avec sans doute une petite biére, ils vont continuer pour expliquer qu'il y a des problématiques à la con entre setuid, setgid ( l'ordre par exemple, ou le fait de fait un initgroup avec setgid ), et que même les meilleurs oublient, ou te parler de cas ou un init script s'est vautré sur un fichier de pid non effacé du à un reboot intempestif de la machine.
D'autres gens vont te répondre que systemd mutualise tout ça et que le code écrit une fois utilisé pour 50 softs est plus sur que le code écrit 50 fois par 50 personnes. Ces autres gens vont aussi te dire que systemd va gérer /var/run sur un tmpfs ( http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html ), ce qui est "reboot intempestif friendly".
Mais bon, je suppose que tout ces gens, tu va sans doute dire que leur objectivité est impossible, qu'ils ont tort parce que toi, tu as eu aucun problème donc ça prouve bien que ça n'existe pas ?
# Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 4.
On m'a filé ça :
http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight
L'auteur détaille une paire de souci avec upstart tout au long de l'article, et explique aussi tout au long des liens le genre de souci subtile qu'il y a avec l'usage de scripts de démarrage ( genre l'environnement pas clean )
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 6.
Le souci du raid logiciel, c'est qu'il est logiciel. IE, avant d'avoir grub2, je pense qu'il fallait magouiller pour booter directement sur un raid logiciel sans avoir un /boot séparé. Il y a aussi l’intégration avec la carte de management distante souvent vendu avec les serveurs, ce qui permet d'agir même quand le serveur est dans le pâté complet
L'avantage aussi du raid hardware, c'est que c'est grosso modo "techos pas cher"-friendly. Tu as ton alerte, tu as le disque qui clignote, tu dit au mec de remettre le disque en réserve, et voila. ( et je sais pas si le disque qui clignote est une feature standard des serveurs avec du raid soft ).
Enfin perso, moi, j'étais dans le camp des gens en faveur du raid soft quand on a eu la discussion à mon taf, mais j'irais pas qualifier les gens qui font du raid hard de mauvais admins. Si les cartes raids se vendent, c'est bien parce qu'il y a des gens qui achètent et qu'ils y trouvent leur compte
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 10.
Perso, un mec qui a une kalach en état de marche et qui s'en sert, je suis pas sur que j'aurais vraiment de le contrarier en remettant en cause ses capacités. Je dit ça, je dit rien.
[^] # Re: Non, systemd ne doit pas tout faire
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 10.
Ouf, enfin un peu de bon sens. Le kernel n'est pas fait pour faire du nat, pour ça, il y a des démons en userspace qui existe ( comme natd sur os x ), et je vois vraiment pas pourquoi le code qui gère l’accès au disque est aussi stocké dans le même git que celui qui gère les cartes sons, y a quand même aucune synergie ou raison valable.
Faut arrêter de déconner, on a réussi à faire de la vidéo hors du kernel, on doit bien réussir à faire pareil pour le reste.
À ce rythme la, on va se retrouver à avoir directement des machines virtuelles dedans et trouver ça ultra cool.
( attention, ce post contient des sarcasmes préemptifs en vue de moquer des futures discussions qui vont arriver )
[^] # Re: Quel est l'intérêt d'utiliser Fedora ?
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 1.
Je pense que tu devrais déjà voir à qui tu réponds, ça t'aiderais sans doute à ne pas dire de connerie.
Alors 1) y a rien à redire, si tu juges les softs par rapport à un développeur plus que par rapport au soft, je ne vois même pas quoi répondre tellement ça frôle les pâquerettes.
2) Le critère qu'une bonne distro s'installe partout et à un livecd, c'est une vision bien personnel de la qualité. Moi, je considère que les livecds, y a que les utilisateurs de base qui s'en préoccupe. Un livecd, c'est joli pour faire une démo, voir un test, mais les démos et les tests, c'est pour les gens qui ont jamais installé une distro. Pour moi, un livecd, ça a avant tout un cout en terme de travail pour les distributions vu qu'il faut les tester, voir si ça démarre bien, s'assurer que ça rentre dans l'espace limité, etc. Vu qu'à moins de vouloir se tirer une balle dans le pied ( ce que Mandriva a fait après le départ de la communauté pour Mageia ), tu ne va pas retirer ton installeur classique, tu te retrouves donc à toujours avoir plus de tests à faire pour proposer des livecds. Et au passage, Debian n'a un livecd officiel que depuis 2008 avec Lenny, alors que d'autres ont eu beaucoup plus tôt ( par exemple, en 2003, mandrake move : http://lwn.net/Articles/63784/ livecd + clé usb ). Bien sur, tu peux dire que Knoppix, c'était le livecd de debian sauf que si Debian ne le reconnait pas comme tel pour divers raisons ( non libre, fait à l'arrache, mélange de paquets ), je vois pas qui tu es pour le faire à la place du projet.
Et pour ton cd et xorg, peut être que ton cd était… mal gravé ? Il y a tout une procédure documenté et publique de test des isos dispo sur le wiki : https://fedoraproject.org/wiki/QA:Fedora_18_Install_Results_Template#Test_Matrix
Tu noteras que "démarrer le lived" en fait parti, et qu'aucun souci n'a été rapporté. Donc soit le problème vient de toi, soit il y a un complot visant à sortir un produit gratuit juste dans le but d'avoir mauvaise réputation sur son propre projet. Au vue du reste des arguments que tu as donné, je pense que l'option 2 est un chouia plus probable.
3) les versions à jour. Comparons au hasard le noyau. Pour avoir le kernel à jour dans debian faut passer par expérimental et unstable. Ou un backport. Pour avoir le kernel à jour dans Fedora, suffit en général d'avoir la version stable de la distro. On regarde Gnome ? Pareil, faut passer par expérimental, le temps de faire les transitions dans unstable. On peut parler du multiarch, ou pendant longtemps, Debian a eu comme solution un truc à base de chroot. ( même si maintenant, je reconnais que le système de Debian est bien plus souple, mais il a fallu du temps pour l'avoir )
On peut parler de tout les trucs que Ubuntu a eu avant Debian aussi ( genre les histoires avec le mainteneur de python, employé Canonical qui a poussé des trucs plus à jour sur Ubuntu que Debian, montrant quand même que Debian était à la traine ).
Un autre exemple ? Mariadb. Intégré dans Mageia depuis la version 2. En cours d'intégration dans Fedora pour la 19
( https://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB et en fait, le paquet est déjà la ). Toujours en cours de discussion depuis 2/3 ans chez Debian ( http://penta.debconf.org/dc10_schedule/events/688.en.html ).
Même sur les systèmes de build. Debian a un système des plus simples, ou les gens font leur paquets dans leur coin, puis upload tout ça sur le réseau de buildd. Pendant ce temps, Fedora est en train de déployer une architecture avec un bus ou tout le monde peut se brancher http://fedoraproject.org/wiki/Messaging_SIG . Y a pas que Fedora, le système de Build de Suse ( l'Open Build Service ) intègre la revue de paquet avant migration, la maintenance par groupe de paquets, son propre VCS, la recompilation automatique en cas de changement des libs, une interface web de construction de livecd, etc. Même ubuntu, avec le système de ppa, est en avance.
Le truc de debian, il fait le boulot, mais pas plus. Même des distros relativement petites comme Mageia arrivent à innover sur des points par rapport à Debian, comme le fait de publier intégralement la configuration des machines via puppet ( http://svnweb.mageia.org/adm/puppet/ ) pour pousser la transparence et la collaboration à un niveau plus loin.
La communauté Debian fait plein de choses, remplit un rôle essentiel, contribue au libre comme toutes les distros, voir plus via le portage sur des plateformes exotiques, fournit une version totalement communautaire et libre. Mais de la à dire qu'ils sont "toujours devant", c'est se fourrer le doigt dans l’œil. Comme souvent, la réalité est plus nuancé. Debian a pour objectif la stabilité, la qualité, la liberté. En général, ça va à l'encontre de l'innovation rapide. D'ailleurs, c'est aussi le constat fait en 2010 par une des membres du projet :
http://penta.debconf.org/dc10_schedule/events/627.en.html
Quand à ta remarque sur le fait de pas savoir faire de paquets xorg, il y a une différence entre "faire un paquet", et "s'assurer que ça crashe nulle part". En fait, quand tu vois le nombre de dev Xorg chez RH qui sont affecté sur Fedora, je pense que tu commencerais aussi par investiguer plus sérieusement l'hypothèse d'un souci sur le cd.
Et si vraiment tu as trouvé un bug dans xorg au point de crasher avec ta carte, bravo, n'hésite pas à le remonter, sauf à croire que des lutins magiques vont le corriger tout seul. Le code de X.org, c'est globalement le même partout, et Fedora essaye de se tenir au plus proche de l'upstream pour justement pouvoir remonter les soucis.
Sur le fait de faire des paquets à jour, c'est tellement simple qu'un script perl peut le faire. Exemple http://www.linuxcertif.com/man/1/rpmbuildupdate/
Tu noteras la présence de mon nom en bas dans la liste des auteurs, donc globalement, ce que tu fais "presque automatiquement", d'autre l'ont fait avant toi, de façon plus générique ( car c'est pas "juste le kernel" à coup de make-kpkg, c'est un paquet arbitraire rpm d'une distro complète ), et depuis un chouia plus longtemps ( genre 5 à 7 ans ). En fait, je connais même une personne qui gère automatiquement la mise à jours de tout les paquets perl d'une distro linux. Genre 500 paquets, via un script. Le vrai souci, c'est pas la mise à jour, c'est la correction des soucis suite aux mises à jour, ou les adaptations, répondre aux bugs, ou ce genre de choses. Pas remplacer la version, télécharger un tar.gz et lancer une commande. C'est déjà bien de faire ça, tout le monde n'arrive pas et je ne peux que t'encourager à contacter mentors.debian.net, mais moi, ça m'impressionne pas le moins du monde.
4) Pour la fiabilité,je te renvoie sur la réponse sur la durée de vie ( en point 6 ). Sinon, comme tu n'as pas eu le temps de chercher plus en détail les choses, un des buts de Fedora est l'innovation, ce qui passe par un cycle d'itération rapide ( en gros, par des changements ). C'est marqué sur le site web :
https://fedoraproject.org/wiki/Objectives .
C'est pas ce que tu cherches, pas de souci.
5) alors les admins en question, c'est des amis à moi, et je pense qu'au vue des articles sur openldap publié par l'un d'eux dans linuxmag, tu assumes un manque de compétence totalement mal placé. Moi, j'ai été payé pour être admin debian pendant des années, donc je pense que je suis assez compétent et bien placé pour dire ce qui ne va pas. Et pareil pour les autres ( genre, y en a un qui est maintenant sysadmin chez Google, boite qui n'est pas connu pour embaucher des rigolos ). Et la plupart continuent à faire de l'admin d'autre chose que de la Debian sur leur temps libre ou pro. ( genre, gasp, certains font même des paquets pour des distributions ou font du code libre ). Toi, je sais toujours pas ce que tu fais, à part étaler un élitisme mal placé, à plus forte raison quand tu explique que tu n'es pas admin. Donc si tu tiens à avoir un avis sur des gens que tu connais pas, je pense que tu devrais te restreindre à ceux dont tu connais le métier ( genre, ton métier ), les contraintes et les besoins, et pas généraliser ton avis de mec extérieur sur la base d'un panel non représentatif car sélectif et renfermé sur lui même.
6) la durée de vie ( ie le support de sécurité ) d'une Debian, c'est ~ 3 ans. La durée de vie d'une Ubuntu, c'est 5 ans sur la dernière LTS. La durée de vie d'une RHEL, c'est 10 ans ( voir 13 pour la maintenance étendu sur RHEL 5 ). Windows 2000 c'est 10 ans aussi, 13 pour XP. Solaris, ça tape aussi dans les 10/12 ans. Source :http://benjamin-schweizer.de/operating-systems-lifecycle-chart.html + tout les sites des distros. Tu m'excuseras donc de trouver un peu courte et limité ta vision du long terme.
Certes, 3 ans c'est bien pour une distribution communautaire, même un exploit quand on regarde à quel point ça fait chier de faire de la maintenance pour le bénévole moyen. Mais bon, voila, 3 ans, ça fait 2 ans de moins que du FreeBSD ( qui est aussi un projet communautaire ).
Quand à prendre une Knoppix, c'est juste surréaliste. La knoppix est in-upgradable, n'a pas de mise à jours de sécurité, et est un mélange de testing, unstable et d'experimental. Je compte plus le nombre de gens ayant eu des soucis sur les listes des lugs que j'ai fréquenté. C'est pas pour rien que Debian a un projet à part pour les lives. Non seulement Knoppix réponds pas aux exigences qualités de Debian ( ou même dés le début, ne réponds pas aux critères en matière de licence, comme le rappelle une polémique que tu as sans doute pas connu il y a 10 ans http://lwn.net/Articles/14651/ ), mais en plus, en 12 ans, ils ont pas cherché à y répondre et à intégrer Debian, alors qu'il y a un projet pour depuis des années.
7) j'ai pas dit qu'il y a que Fedora, mais force est de constater que Debian est arrivé bien tard. C'est pas moi qui le dit, c'est le DPL lors qu'il a annoncé l'équipe Debian Cloud ( http://wiki.debian.org/Cloud ) lors de la mini Debconf à Paris en Novembre 2012, tu peux voir les lightings talks du dimanche, sauf erreur de ma part. Il suffit de voir que l'intégration d'Openstack est faite pour le moment à part ( alors que Ubuntu l'a fait très vite, que Fedora a depuis une paire de release une version à jour des dits logiciels, que Suse et RH investisse dessus et ont donc les paquets et l'expertise, voir se prépare à proposer du support ). On peut parler des plateformes de PaaS, ou il y a rien pour le moment sur Debian ( genre, pas openshift, pas cloudfoundry, pas de cloudbees, pour ne citer que les plateformes libres et connus ).
Et non, dire "j'ai vu de la virtualisation", c'est pas du SaaS. Le SaaS, ou Software As A servie, c'est par exemple des choses comme Gmail, ou Salesforce.Y en a un des 2 qui tourne sur une version custom de Debian avec des softs maisons ( cf Debconf 2011 en croatie, présentation sur Ganeti, Ganeti qui est libre juste parce qu'une équipe de dev Debian l'ont poussé ), et l'autre sur une RHEL non modifié ( https://www.redhat.com/resourcelibrary/case-studies/salesforce-com-relies-on-red-hat-2 ). Certes, le SaaS, c'est super vieux, et c'est très largement indépendant de la plateforme sous jacente, et bien sur, on peut faire du SaaS sur Debian, si on fait le taf à la mano, voir si on rajoute sa propre pile ( ie, si on est Google ). Je ne doute pas que Debian rattrape les choses via le travail des gens d'Enovance, et je ne doute pas que Debian soit une bonne base pour ça, je ne doute pas qu'en rajoutant des paquets externes, on arrive à avoir une plateforme de qualité. Mais c'est au final comme tout système linux, justement parce qu'il y a rien de magique. Kvm est dispo partout, libvirt aussi.
Donc, "j'ai vu en 2005/2007 des gens faire de la virtualisation en prod sur de la debian", c'est bien joli. Moi, j'ai vu des projets de déploiement de VMWare sur du Windows 2003 à mon taf en 2005/2006 par des prestas externes, je vais pas clamer "Microsoft a fait du cloud en 2005". Y a une définition communément admise faite par le NIST, et je pense que "faire de la virtualisation en prod" n'est pas vraiment la traduction française de :
"Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."
Et encore une fois, le but n'est pas de savoir si on peut le faire ou pas. Le but est de savoir si c'est simple ou pas d'avoir les dernières technos à jour sans ajout externe. Le concept "d'intégration dans une distro", c'est pas d'aller prendre des choses hors de la distro par définition.
8) Enfin, si je te suis, parce que les gens de Backtrack ont pris Ubuntu, alors ça fout en l'air tout l'argumentaire ? Donc je vais répondre par 3 questions :
I) si Debian est bien pourquoi Backtrack n'a pas pris Debian directement. Car oui, l'argument avec Ubuntu est à double tranchant. En fait, si Debian est si bien, pourquoi Backtrack, Mint ou autres ne se basent pas vraiment dessus directement ?
II) si Debian est si bien, pourquoi est ce qu'il faudrait une dérivé ( backtrack ) de dérivé ( ubuntu ) pour faire des choses ?
III) Si Debian est si bien, pourquoi les "gars de Backtrack" ne sont pas directement "les gars de Debian" ?
Donc sur la base de ça, en quoi Backtrack serait un exemple de raison de dire que Debian est mieux que tout alors que tout montre que c'est tellement mieux qu'ils sont obligés de faire leur propre fork pour mettre des outils que d'autres distros filent de base.
Par exemple, sur ma Fedora, j'ai pas eu de souci à casser le wep de 3 de mes voisins vu qu'il y a tout ce qu'il faut à portée de main. Et non seulement il y a tout ce qu'il faut, mais en plus, pour les gens qui préfèrent les versions spécialisés et les livecds, il y a en un qui existe ( http://spins.fedoraproject.org/security/ ).
Et si le but est de fournir juste une série d'outils pré-installés, c'est à mon sens ridicule de faire un projet et un livecd séparé. Tout les systèmes de paquets que je connais ( et j'en ai fait un paquet ) sont capable de faire un paquet vide qui tire X autres paquets pour obtenir le même effet.
Donc pour terminer, oui, je pense que je peux difficilement te prendre au sérieusement, malgré une passion et une bonne volonté à cause de ta façon d'exposer des certitudes sans nuancer ou justifier. J'ai donné assez de sources vérifiables, et que j'estime non partial à l'encontre de Debian, j'ai donné des exemples concrets et divers, j'ai pris le temps d'expliquer en détail les points, donc si à partir de la, tu persistes, soit, c'est ton droit.
[^] # Re: Quel est l'intérêt d'utiliser Fedora ?
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 2.
Peut être le coté "j'ai raison, c'est indéniable". Moi, je connais au moins une équipe d'admin qui a quitté des mandriva pour prendre des debian, puis pour revenir vers de la mandriva ( car debian était trop en retard ). Donc tes données totalement subjectives sont contredites par mes données subjectives. On peut pas en tirer grand chose, à part que tes certitudes mal placés valent bien un -10.
Sinon dire "ça vaut pas debian", c'est chercher les coups de bâtons. Par exemple, quand tu veux l'intégration de softs nouveaux, genre tout ce qui tourne sur le cloud ( l'équipe cloud de debian étant un chouia en retard par rapport à de la fedora ou de l'ubuntu, vu que ça date d'il y a moins de 4 mois ), quand tu veux avoir des versions de softs comme systemd ( qu'on aime ou non, y a des gens dont moi qui aiment l'idée et visiblement, au moins un debianneux vu qu'il y a un paquet ) ou du selinux ( pareil que systemd, on peut aimer ou pas, mais debian est pas la plateforme de choix pour ça ). Y a largement des tas de raisons dans l'annonce ( par exemple, les outils pour utiliser secureboot avec tes propres clés, eucalyptus ou openstack, etc ).
Donc encore une fois, ta certitude fait que oui, tu passes pour un rigolo. Tu a le droit de pas aimer Fedora, d'aimer Debian, tu as sans doute des raisons valables comme le fit qu'autour de toi, tout le monde te dit que c'est mieux, ou de pas retrouver tes habitudes, je le discute pas, et je te demande même pas de remettre ça en cause. Par contre, tout le monde n'a pas tes raisons, tout le monde ne fait pas tes choix, et des gens content avec de la fedora ou du red hat, ça existe. Ça existe assez pour avoir des contributions externes. Les gens font pas ça car ils sont tous idiots et n'ont pas vu la lumière d'aller faire du debian.
[^] # Re: Quel est l'intérêt d'utiliser Fedora ?
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 2.
yumex ? C'est packagekit l'outil par défaut. Il y a eu des discussions pour le portage du software control ( ou plutot un fork qui ne requiert pas d'assignation de copyright ) il y a un temps, mais je sais pas ou sont les efforts.
Et ouais, Fedora est pas très soft proprio friendly. Je me souviens d'une mise à jours de X ou le choix était entre "faire des correctifs pour les pilotes intels libres" ou "garder l'ancienne version de X pour que les pilotes nvidia tournent encore". Et le choix en faveur de la mise à jour a été faite. La distribution bouge trop vite pour qu'un éditeur proprio veuille suivre. Donc oui, si tu as une dépendance vers des softs fermés, je te conseille pas de prendre une Fedora, ç'est clairement pas le but de la distribution, une Ubuntu sera plus en accord avec ce genre de philosophie.
[^] # Re: Le partitionnement!!
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 2.
En fait, j'ai regardé un collègue faire des trucs avec l'outil de partitionnement, et il a réussi une fois qu'on a vu qu'il faut pas mettre l'unité dans le popup pour la taille, contrairement à ce que l'infobulle dit. Je sais pas si c'est la traduction ou la formulation qui n'est pas clair. Ensuite, c'est un mec un peu technique, je comprends que ça bloque d'autres personnes.
[^] # Re: Le partitionnement!!
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 2.
J'ai des doutes sur btrfs par défaut en F19, il y a justement un thread sur le sujet en ce moment sur fedora-devel.
Et les gens remontent divers soucis sur le sujet, avec bug reports parfois, c'est rien de dramatique, mais pas pour du défaut.
[^] # Re: justification
Posté par Misc (site web personnel) . En réponse au journal Encore un journal bookmark!. Évalué à 7.
Ici sans doute :
https://lwn.net/Articles/526082/
[^] # Re: À quand les smartphones et tablettes libres ?
Posté par Misc (site web personnel) . En réponse à la dépêche GTA04 : Une nouvelle production en voie !. Évalué à 8.
Le libre n'a pas vraiment pour vocation première d'être un produit fini, plus de faire avancer l'innovation, la collaboration, le partage des connaissances. Bien que tout le monde bosse pour arriver à un produit fini, ça n'arrive pas tout seul, et il faut à un moment mettre à dispo des versions moins fini pour faire avancer les choses.
C'est le souci du hardware, tu peux pas vraiment le faire produire gratuitement, au contraire du logiciel ou le cout de la copie est proche de 0.
C'est pas fini, ouais. C'est cher, ouais aussi. Mais je pense que c'est pas à destination des gens moyens, c'est pour les gens qui veulent faire avancer le logiciel libre en codant dessus. C'est une boite qui a tenté de produire à ses frais un produit de niche et qui n'attends pas d'avoir attends la masse critique pour le vendre à tous car ça ne va pas arriver sans un premier lots ( ni même plein d'autres lots ).
Si maintenant, c'est trop cher pour toi, c'est pas grave. Je pense que tu n'aurais pas codé dessus, donc te le vendre ou pas, à ce stade, ça va rien changer. Tu va pouvoir te morfondre à te dire "pourquoi y pas plus de libre dans le matos" sans comprendre que ça se fait pas en un jour, ni les mécanismes économiques derrières.
[^] # Re: justification
Posté par Misc (site web personnel) . En réponse au journal Encore un journal bookmark!. Évalué à 10.
Parce que la collaboration, c'est difficile, alors que forker, c'est plus simple, tu as juste à faire un git clone, et voila. Et puis tu remplaces 2/3 chaines et c'est bon.
Le mec derrière solusos, c'est celui qui a fait LMDE. LMDE, c'est basé sur mint, un fork de ubuntu, qui est un fork de debian. Formidable de voir combien de distro y a besoin pour adresser les besoins des gens ( ie, autant ubuntu et debian, c'est différent, autant mint aurait pu aider ubuntu ou debian ).
Encore une fois, je pense que je suis bien placé pour dire que faire un os ou un bureau, c'est plus dur qu'on crois, et que forker doit être le dernier recours, et pas le premier. C'est comme dans une relation, partir et se séparer n'est pas la première chose à faire, c'est la dernière. Vu que déjà, Mint gère pas les updates de sécurité sur son code ( CVE-2012-1566 ), Mate se contente la plupart du temps de reprendre les patchs que gnome fait sur son code ( exemple, les commits du 21 décembre pour https://github.com/mate-desktop/mate-file-manager/commits/master ) ou des patchs mineurs sur configure etc, je vois pas comment avec encore moins de ressources, ça va donner un truc.
Et si on regarde les commentaires sur le blog ( http://solusos.com/blog/2013/01/the-consort-desktop-environment/ ), on voit que le dev dit :
"The decision to fork was also made months ago, before the
decision was finally made to drop fallback.".
En gros, ils sont déjà parti avec l'idée de forker depuis longtemps.
[^] # Re: cher, ou pas ?
Posté par Misc (site web personnel) . En réponse au journal [GTA04] Une nouvelle production en voie !. Évalué à 2.
Le souci est surtout que le modem 3g du gta4 utilise des commandes standards AT, alors que de ce que j'ai vu, les modems divers et variés sur la plupart des tels utilisent des protocoles tout à fait proprio et fait maison ( et parfois binaire ).
[^] # Re: Et lire aussi
Posté par Misc (site web personnel) . En réponse au journal Que faire cet après-midi ?. Évalué à 4.
Ma foi, c'est pas comparable plus plusieurs raisons :
- il y a des vies en jeu dans le fait de conduire. C'est pas le cas dans le mariage.
Si le handicap ne te permet pas de suivre les règles, alors c'est pas parce que tu es handicapé mais parce que tu peux pas suivre les règles.
Ensuite, si pour toi, les règles du mariage, ça implique que le mâle féconde la femelle pour fonder une famille, ouais, je comprends que ça te gène. Grande nouvelle, la reproduction sexuée n'est pas la seule façon de fonder une famille. L'adoption existe depuis toujours. La fécondation in-vitro, qu'on accepte pour un couple stérile. Ou juste ne pas avoir d'enfant, ça reste pas moins une famille ( que je sache, on ne mets pas de limite supérieur ou inférieur, si tu vis avec tes parents, ça reste une famille, si tu vis sans également ).
Donc il existe déjà des familles à tout les sens du terme non lié à la fécondation. Et dans le cas de l'adoption, c'est même pire, je crois pas qu'on soit en manque de gamin à adopter, plutôt le contraire.
Donc oui, ton argument est moisi et puant.