Linux? - Page 232

lol

reached stage foutage de gueule integral

Une blague de Kevin qui m'a fait marrer O_o

Nil (./6932) :
Une blague de Kevin qui m'a fait marrer O_o

mets une croix sur le calendrier et encadres le

"Work as design WONTFIX NOTABUG STUPIDUSER"


---

https://wiki.archlinux.org/index.php/systemd-boot

Dans 5s on va avoir

systemd-kernel

puis

systemd-computer

comme ca Redhat aura le control COMPLET

systemd-boot est optionnel et fait surtout pour l'embarqué, même Fedora ne l'utilise pas par défaut (Fedora utilise le shim pour "Secure Boot" et GRUB 2).

./6923 : j'ai creusé un peu, et bon sang... j'ai beau ne pas être utilisateur de Linux, plus je lis de trucs sur systemd, plus ça me confirme dans la mauvaise opinion que j'ai de ce machin (et du mec qui est derrière). Je ne comprends pas que Linus laisse son OS se faire saboter comme ça, franchement.

Kevin: de l'embarque?? UEFI?

lol

(c'est vraiment tout sauf un bootloader pour l'embarqué, ca ne marche que sur PC..)

De la même façon que certains parisiens pensent que le monde se limite à Paris, certains pensent que l'informatique se limite aux PCs ^^

Sinon en parlant de systemd, quelqu'un faisait remarquer que ce serait l'endroit idéal pour planquer une backdoor dans Linux : ça a un accès privilégié à tout plein de trucs, le code est assez opaque et ça n'est pas audité comme peut l'être le noyau. Je ne dis pas que c'est le cas, mais ça donne à réfléchir.

Pas besoin, il y a assez de failles pour ca

C'est l'autre possibilité

Godzil (./6938) :
Kevin: de l'embarque?? UEFI?

Godzil (./6940) :
(c'est vraiment tout sauf un bootloader pour l'embarqué, ca ne marche que sur PC..)

Pas vrai. Contrairement au vieux BIOS, UEFI a été conçu pour être portable, ça existe aussi au moins sous aarch64 (ARM 64-bits).

Et j'insiste, systemd-boot a été conçu pour un usage embarqué.

https://wiki.archlinux.org/index.php/systemd-boot
systemd-boot, previously called gummiboot, is a simple UEFI boot manager which executes configured EFI images

ni cette page ni https://en.wikipedia.org/wiki/Gummiboot_(software) ne parlent d'embarqué

google n'est pas bavard sur le sujet non plus
https://www.google.fr/search?q=systemd-boot+embedded

aarch64 n'est pas non plus spécialement fait pour l'embarqué.

donc source||gtfo

edit: yen a qui se font plaiz sur twitter

Ping @systemdsucks pic.twitter.com/2kdEYxzX4d

— Uppgiven liberal (@Qeruiem) July 12, 2017

Zerosquare (./6941) :
Sinon en parlant de systemd, quelqu'un faisait remarquer que ce serait l'endroit idéal pour planquer une backdoor dans Linux : ça a un accès privilégié à tout plein de trucs, le code est assez opaque et ça n'est pas audité comme peut l'être le noyau. Je ne dis pas que c'est le cas, mais ça donne à réfléchir.

Ce n'est pas évident.
1) comme dit Godzil, il y a déjà tout plein de failles partout
2) globalement, systemd « n'invente rien » : les besoins (et donc les élévations de privilèges) existaient avant systemd et étaient remplis par d'autres scripts (cron, at, init, …). Ce n'est pas évident que les différents binaires historiques soient mieux codés.
3) avec init, tu dois auditer le système d'init + tous les scripts shell plus ou moins pourris ET exécutés en root pour tous les services installés. avec systemd, tu ne dois auditer que le code de systemd.
4) systemd permet de limiter assez finement les ressources utilisables par chaque service. À ce niveau, c'est plutôt un gain

Zerosquare (./6937) :
./6923 : j'ai creusé un peu, et bon sang... j'ai beau ne pas être utilisateur de Linux, plus je lis de trucs sur systemd, plus ça me confirme dans la mauvaise opinion que j'ai de ce machin (et du mec qui est derrière). Je ne comprends pas que Linus laisse son OS se faire saboter comme ça, franchement.

Effectivement, on entend beaucoup parler des défauts, mais il y a aussi les gens qui refusent d'apprendre à utiliser les nouvelles commandes.

Bref, sans être fan de systemd (même si honnêtement ça me simplifie bien la vie), la réalité est loin d'être aussi binaire qu'on peut le lire.

flanker (./6948) :
1) comme dit Godzil, il y a déjà tout plein de failles partout

C'est pas une excuse
Et il y a déjà eu des tentatives par le passé d'introduire des backdoors dans Linux, donc c'est que certains doivent trouver que les failles ne suffisent pas.

flanker (./6948) :
Ce n'est pas évident que les différents binaires historiques soient mieux codés.

Certes, mais ils sont beaucoup plus petits et plus simples que systemd. Et leurs mainteneurs ne refusent pas de reconnaître et de corriger leurs bugs.

flanker (./6948) :
3) avec init, tu dois auditer le système d'init + tous les scripts shell plus ou moins pourris ET exécutés en root pour tous les services installés. avec systemd, tu ne dois auditer que le code de systemd.

Oui, mais le code de systemd est massif.

Zerosquare (./6937) :
Effectivement, on entend beaucoup parler des défauts, mais il y a aussi les gens qui refusent d'apprendre à utiliser les nouvelles commandes.

Je parlais des vrais défauts (les bugs, et surtout la philosophie et l'attitude des mainteneurs), pas du fait de changer des habitudes.

Zerosquare (./6949) :

flanker (./6948) :
Ce n'est pas évident que les différents binaires historiques soient mieux codés.

Certes, mais ils sont beaucoup plus petits et plus simples que systemd. Et leurs mainteneurs ne refusent pas de reconnaître et de corriger leurs bugs.

Pour le coup, je ne sais pas. Quels sont tous ces binaires historiques ? Quelle taille font-ils, au total ? Leur code est-il propre ?

flanker (./6948) :
3) avec init, tu dois auditer le système d'init + tous les scripts shell plus ou moins pourris ET exécutés en root pour tous les services installés. avec systemd, tu ne dois auditer que le code de systemd.

Oui, mais le code de systemd est massif.

Tant que ça ? (la partie critique s'entend : l'ensemble est découpé en pas mal de parties qui n'ont pas toutes beaucoup de privilèges)

Zerosquare (./6937) :
Effectivement, on entend beaucoup parler des défauts, mais il y a aussi les gens qui refusent d'apprendre à utiliser les nouvelles commandes.

Je parlais des vrais défauts (les bugs, et surtout la philosophie et l'attitude des mainteneurs), pas du fait de changer des habitudes.

ce n'est pas parfait, c'est certain. Mais de là à dire qu'il faut tout jeter et repartir 30 ans en arrière, il y a un pas que je ne franchirai pas…

L'approche de systemd est à l'origine celle de launchd (macOS) puis upstart (Ubuntu), freebsd bosse sur un truc équivalent de mémoire. Ça commence à faire du monde qui a les mêmes idées, elles ne sont peut-être pas si idiotes que ça ^^

flanker (./6950) :
Mais de là à dire qu'il faut tout jeter et repartir 30 ans en arrière, il y a un pas que je ne franchirai pas…

Ça tombe bien, je n'ai pas dit ça

L'idée de moderniser le système d'init n'est pas mauvaise en soi, et comme tu le fais remarquer, systemd n'est pas le premier à le faire (et les autres tentatives n'ont pas généré autant de remous et de rejet). Le souci est de confier quelque chose d'aussi critique a des gens comme Lennart Poettering, dont la qualité du code et surtout le comportement posent problème. Un projet peut être excellent sur le papier, mais s'il est mal implémenté et mal géré, c'est tout-à-fait légitime de lui préférer quelque chose d''archaïque" mais de mieux maîtrisé.

je suis d'accord.

Si systèmes s
'Arrêtait as init tu pourrais comparer à upstart ou launchd.

Il y a un truc que je trouve assez étrange, quand-même. On sait que ce gars est un gros lourd. On sait que ces bugs sont critiques. On est dans du logiciel libre sous licence libre. Pourquoi il n'y a pas une équipe pour faire un fork (surtout du côté des grosses distribs), corriger les bugs, et renommer le tout SystemB ? Parce que là, je ne vois aucun intérêt à être dans un système libre si c'est pour être coincé dès qu'un gars refuse de changer quelque chose...

Je dirais que c'est parce que il y a RedHat qui est un poids lourd derrière. Pour le remplacer il faudrait qu'une entreprise ait envie d'investir autant que Redhat là dedans.

Mais, du coup, pourquoi RH laisse faire ?

Parceque c'est une societe philantropico-communiste qui cherche le bien de tous

Parce que c'est justement dans leur intérêt d'avoir réussi à introduire un module fondamental et sous leur contrôle dans la plupart des distributions Linux ?

Ce n'est pas la première fois que ce cas se produit. Il s'était déjà passé la même chose avec Ulrich Drepper qui gérait glibc, qui avait le même genre de comportement que Poettering, et qui travaillait aussi pour RedHat. À tel point que Debian avait fini par en avoir marre et avait switché vers eglibc.

Zerosquare (./6958) :
Parce que c'est justement dans leur intérêt d'avoir réussi à introduire un module fondamental et sous leur contrôle dans la plupart des distributions Linux ?

Oui, ça je veux bien le comprendre, mais je parle du fait de laisser à une seule personne, connue pour ses décisions, la gestion d'un truc critique et qui, justement, est réutilisé par tout le monde.
Ils prennent le risque d'un fork et qu'on laisse tomber leur solution...

Non parce qu'ils contrôlent désormais des point clefs du système comme udev. (Qui n'a rien à voir avec initnou la gestion de daemon bien entendu, tout comme logind, leur resolver DNS etc...

Le problème c'est que si tu veux un gnome ou même un KDE tu n'a pas le choix ton bousin dépends que de trop de systemd.