Moonz a écrit 3542 commentaires

Le non-geek, pour chercher x sur wikipedia il tape "wiki x" sur google, donc OSEF un peu…

http://wikileaks.org/

Avec Optimus c’est effectivement un pilote différent, mais c’est aussi une carte différente. Ce n’est pas du tout la même chose que lancer deux pilotes différents qui accèderaient à la même carte.

Et puis je peux me tromper mais c’est pas déjà ce que l’on fait avec Optimus?

Non, ce n’est pas ce que tu fais Optimus. Très schématiquement Optimus lance un serveur X « virtuel » supplémentaire qui utilise le pilote pour la carte nvidia et qui demande à la carte nvidia de faire le rendu dans un buffer qui est ensuite transmis au serveur X principal, puis lance l’application demandée sur le serveur X virtuel. Mais sur ton serveur X principal, le pilote ne change pas, c’est toujours intel.

Sinon sur le reste de ton post rien à dire sauf qu'on retrouve ton habituel pessimisme.

Qui, il faut l’admettre, n’a jusqu’ici jamais été démenti par les faits…

c'est un système d'init identique qui est utilisé par plusieurs distributions

C’est aussi le cas du PID 1 de sysvinit (même s’il est vrai que tout ce qui est script bash genre rc.sysinit a tendance à changer d’une distrib à l’æutre).

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.