Moonz a écrit 3686 commentaires

C'est rigolo de transformer "une personne pas d'accord avec toi" en "un fanboy".

Je suis d’accord.

Tout autant que transformer "une personne pas d’accord avec toi" en "réactionnaire qui déteste le changement"

les coûts donnés sont archi-faux

Pour me dire que ma proposition est fausse, tu vas devoir me prouver qu’au moins une de ces deux propositions est fausse :

• la quantité de code dans init de sysvinit est plus faible que dans celui systemd
• le code de systemd (intrinsèquement plus complexe, et testé sur une échelle infiniment moindre) a au moins autant de bug / ligne de sysv

Bonne chance.

Juste une question : tu as déjà mis les yeux dans le code d’un de ces deux projets ?

J'ajouterais, quand on est administrateur système d'expérience, n'est-il pas nécessaire de faire de la veille technologique sur l'ensemble des technologies de ce type pour au moins savoir comment cela fonctionne et évaluer l'intérêt de ces solutions ?

Je me répète mais…

C’est ce que je fais. Sur certaines machines j’ai d’ailleurs adopté systemd bien avant qu’il devienne le système d’init officiel de la distrib, et j’étais sur d’autres systèmes d’init avant systemd (initng).

Mais bien entendu, dans le royaume des fanboys toute critique vient nécessairement des haters irrationnels, n’est-ce pas ?

(deux niveaux différents, pourquoi n'as-tu pas comparé SysV à systemd et bash aux unités? Mystère…).

Bon, je vais m’arrêter là, ça sert à rien d’essayer de discuter avec des fanboys pour qui leur chouchou est parfait.

Pourquoi je compare les deux ? Il te suffit de relire le fil deux secondes avec ton cerveau allumé (autrement qu’en mode automatique « il critique certains aspects de systemd donc c’est un con »)

• Moi : plus de fonctionnalités => plus de bugs (parce que si tu veux faire la comparaison, systemd a beaucoup plus de fonctionnalités que sysvinit dans le PID 1 : ne serait-ce que le système d’IPC avec DBUS. Et non je fais pas l’erreur de croire que toutes les fonctionnalités de systemd sont dans le PID 1, je sais encore lire la sortie de ps, merci pour moi) => questionnements sur la fiabilité
• Toi : Ya des bugs dans les scripts bash aussi, donc l’argument de la fiabilité c’est n’importe quoi
• Moi : C’est pas le même impact entre un bug dans le PID 1 (KP) et dans un script bash
• Toi : Pourquoi tu compares deux niveaux différents ?

Et pour ceux plus haut qui disent « si sysvinit plante c’est KP aussi », je le sais merci, le truc c’est que le PID 1 dans sysvinit a moins de fonctionnalités (pas d’IPC via dbus par exemple), moins d’interactions utilisateur (on compare systemctl et telinit ?). Ça a nécessairement un coût en terme de fiabilité. Moi, tout ce que je dis, c’est que pour certains (type totof) les coûts surpassent les avantages, pour d’autres les avantages surpassent les coûts. Si ça c’est de la mauvaise foi, tant pis pour vous, je vais pas aller mentir et prétendre que les fonctionnalités supplémentaires viennent « gratuitement » juste pour vous faire plaisir.

Un script bash qui plante ça finit rarement en kernel panic. Contrairement à un systemd qui plante.

C’est pour ça qu’on se tue à dire que c’est une mauvaise idée de déporter des fonctionnalités vers le PID 1. Un PID 1 qui démarre pas (à cause d’une lib pas trouvée) c’est tout simplement un OS qui démarre pas. Un script bash qui démarre pas son service à cause d’une lib manquante ? OSEF. Un PID 1 qui plante c’est un plantage de la machine complète. Un script bash plante ? OSEF.

Le problème n’est pas d’introduire des fonctionnalités et donc potentiellement des bugs, ça c’est une évolution normale à laquelle personne n’a rien à dire. Le problème est d’introduire des fonctionnalités et donc potentiellement des bugs dans le PID 1.

La "sélection sexuelle", c'est quoi exactement ?

Un truc de biologistes. Rien d’aussi sérieux et solide que l’anthropologie, quoi.

Si ton questionnement est sérieux, Wikipedia est assez complet.

LXC et les cgroup il y a l’équivalent avec les jails sous FreeBSD, ils ont pas eu besoin de jeter leur système d’init « complètement dépassé ».

Mais essaye de te poser juste une question de base, rapide à répondre : des mecs sont payés par des boites pour développer la chose, d'autres mecs intègrent ça dans leur distro, mais ça ne sert à rien?

Où ai-je dit que ça servait à rien ? Au contraire, sur un des serveurs que je gère on a été parmi les premiers à adopter systemd (vu les besoins tu peux même pas imaginer à quel point ça a été un soulagement pour le coup). Simplement, si tu m’avais dit à l’époque « bon maintenant les gars on fout du systemd partout » je t’aurai pris pour un fou.

Si ce besoin n'est pas un besoin bizarre à toi que en fait le problème vient plutôt de toi, je ne doute pas que tes besoins seront répondus (soit par systemd, soit par un initd maintenu).

Le besoin est parfaitement couvert par le vieux init complètement dépassé, ne t’inquiète pas pour ça.

Mais le problème ne vient peut-être pas de systemd…

Je croyais que « qui peut le plus peut le moins » ?

Si t'as une faille dans un soft accessible par reseau, tu risques la meme chose quel que soit le soft.

Ben non. Toute faille ne se résume pas à exécution de code arbitraire à distance.

Non, par exemple cette faille facilite un accès non-autorisé webcam/micro sans pour autant donner contrôle de tout le PC.

Peut-être parce qu’à l’époque la majorité des gens n’étaient pas aussi « connectés » ?

Le problème c'est que nombre de personnes sont persuadés que son besoin propre est supérieur à ceux des autres. Ici systemd répond à des besoins de nombreuses personnes et entreprises car l'init d'il y a 30 ans n'était pas adapté à la conception de l'informatique moderne.

Ceci n’est pas un argument. Je résume ce que tu as écrit : « c’est vieux donc c’est nul ».

On attend toujours les besoins « modernes » auxquels FreeBSD ne peut pas répondre (puisque ces abrutis de devs FreeBSD n’ont pas vu La Lumière et s’obstinent à utiliser un truc pas adapté à l’informatique moderne, les cons)

Si tu as une meilleure solution pour répondre au besoin tout en respectant cette phrase, n'hésite pas, propose!

Once again : quel besoin exactement ?

Parce que c’est super facile de dire « systemd répond mieux au besoin » sans définir précisément « besoin », moi aussi je peux le faire : MediaInfo c’est de la merde, ffmpeg répond mieux au besoin.

Parce que moi, sur une de mes machines, j’ai un besoin qui est « traitement complexe dans rc.local », et je peux te dire que systemd se vautre lamentablement là dessus.

Sauf que c'est tout refait avec des technos pourries et des VM super lourdes

Exactement comme Java Web Start quoi.

OSSv4 est à nouveau libre, dispo sous Linux, et a quelques fonctionnalités en plus que Alsa (dont un niveau de son par application, comme PulseAudio). Donc certains l’utilisent, oui.

Et c’est un problème, parce que… ?

Et en quoi est-ce spécifique à Linux ? Phonon, SDL, Xine, Gstreamer que tu retrouves dans le schéma fonctionnent aussi sous Windows. Windows qui lui-même a plusieurs API audio (DirectSound, Core Audio API, DirectMusic…)

(des flèches entre ALSA et OSS?!?)

Oui, Alsa peut utiliser OSS (Alsa -> OSS -> output device) tout comme une application OSS peut « utiliser » alsa (via la couche de compatibilité).

C’est pas une pile audio, c’est une liste de libs audio avec des flèches indiquant qui peut utiliser quoi comme backend juste pour faire croire que c’est compliqué.

Remplace Alsa par CoreAudio et le schéma est tout aussi valide sous MacOS X (à une ou deux exceptions).

C'est du comique de répétition ?

man gst-launch est un très bon début, surtout sa section Pipeline Examples.

mais sans PA, je ne crois pas que j'aurais pu mettre ça en place si rapidement.

Ça se fait en un pipeline simple sous gstreamer. Je crois pas que ça prenne des années non plus. Point bonus tu peux même réencoder ça en vorbis et le stocker.

Tu oublies le mathématicien : 1, 2, 3, beaucoup.

Dans la catégorie blague grasse :

Trois uniques survivant d’un naufrage se retrouvent sur une île déserte : un informaticien, une femme et un homosexuel. Rapidement, la tension monte entre la femme et l’homosexuel. Au bout d’un moment, la femme va voir l’informaticien et lui dit « cette tapette commence à me taper sur le système. Je te propose que cette nuit, pendant qu’il dort, on l’assomme et qu’on le rejette à la mer. On pourra ainsi reprendre une activité sexuelle normale ». Quelques heures plus tard, l’homosexuel vient voir l’informaticien et lui fait cette proposition : « j’en ai raz le cul de cette hystérique. Si ça te dit, ce soir on l’assomme, on la rejette à la mer et on pourra reprendre une activité sexuelle normale ».

La nuit suivante, l’informaticien assomma et rejeta à la mer la femme et l’homosexuel, et put ainsi reprendre une activité sexuelle normale.

Parce qu’Objective-C est un excellent langage, et que les API d’iOS sont très proches de celles de NextStep (par transitivité avec Cocoa ;)), qui est le meilleur framework qu’il m’ait été donné de voir (concepts extrèmement simple et très puissant, framework très cadré tout en restant très souple à l’usage).

La seule raison pour laquelle j’ai arrêté le dev iOS c’est que je hais l’« ergonomie » de tous les produits Apple (mention spéciale au getionnaire de fenêtre de MacOS X et aux claviers des MacBook qui me donnent envie de jeter le portable par la fenêtre dès que j’en ai un dans les mains).

(il a grandi, il utilise le terminal qu'en dernier recours).

Plus je grandis, plus j’utilise le terminal et plus les interfaces graphiques sont un dernier recours.

C’est grave docteur ?

J’ai des backups (dans le méchant cloud)

N’empêche que un SSD qui grille chez moi = interruption de service + intervention manuelle qui peut prendre des heures (le temps d’aller en racheter un, en priant pour que ce soit ni un dimanche, ni un jour férié, ni à 9h du soir), souvent au pire moment (puisque par définiton tu te rends compte qu’il grille que quand tu l’utilises, contrairement à Google qui monitore son matos H24 y compris quand je suis au lit). Un disque dur qui grille chez Google, ça fait partie de leur fonctionnement normal, avec 0 downtime pour l’utilisateur. Et un disque dur/SSD qui lâche, contrairement à ce qui est sous-entendu plus haut, ça arrive.

(tiens, avant-hier mon disque dur externe a littéralement grillé (fumée) quand je l’ai branché, je dois décidémment être dans une période de merde…)