xcomcmdr a écrit 3541 commentaires

max-laptop% ldd /usr/bin/vim
   linux-vdso.so.1 (0x00007fffb087c000)
   libm.so.6 => /usr/lib/libm.so.6 (0x00007f5df9cba000)
   libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x00007f5df9a55000)
   libacl.so.1 => /usr/lib/libacl.so.1 (0x00007f5df984c000)
   libgpm.so.2 => /usr/lib/libgpm.so.2 (0x00007f5df9645000)
   libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f5df9441000)
   libperl.so => /usr/lib/perl5/core_perl/CORE/libperl.so (0x00007f5df90b1000)
   libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f5df8e94000)
   libc.so.6 => /usr/lib/libc.so.6 (0x00007f5df8aec000)
   libattr.so.1 => /usr/lib/libattr.so.1 (0x00007f5df88e7000)
   /lib64/ld-linux-x86-64.so.2 (0x00007f5df9fbb000)
   libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f5df86b0000)
max-laptop% ldd /usr/bin/vi
   linux-vdso.so.1 (0x00007fff281fe000)
   libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x00007f2f4dda5000)
   libc.so.6 => /usr/lib/libc.so.6 (0x00007f2f4d9fd000)
   /lib/ld-linux-x86-64.so.2 (0x00007f2f4e00a000)

C'est décidé, je passe à vi ! ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Qu’est-ce que tu ne comprends pas dans « without much processing » ?

Le fait que le format "texte" a toujours besoin d'être "décodé", tout comme les formats "binaires" (parce qu'il en est un) montre que cette séparation est très artificielle.

Le format binaire du journal de journald, il suffit de le documenter, et on pourra implémenter différents "lecteurs" compatibles. Comme on a documenté les différents types d'encodages.

(et puis franchement, vu qu'on peut activer la copie vers syslog en 3 secondes, l'intérêt de ce n-ième troll sur journald est limité…)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Des bons outils auront moins tendance à te lâcher dans les situations difficiles. Faire le choix d'un format binaire que peu d'outils savent manipuler, surtout pour une chose aussi cruciale que les logs, ça témoigne d'un manque d'expérience

Ou pas. D'une part, à l'usage on se rend compte que journald permet de chercher les infos pertinentes bien plus rapidement qu'avec du bidouillage avec grep & co.

En plus, les raisons pour le choix du format binaire ont été expliqués de nombreuses fois.

Et enfin pour les gens qui ne sont toujours pas content, la copie vers syslog s'active en une ligne :

systemctl enable syslog-ng && systemctl start syslog-ng

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Bine sur que si. Tu confonds un terme qui a une définition bien précise et le fait que tout est codé sous forme de bits.

Une définition bien précise ? Que nenni !

Ton fichier texte (qui est un fichier binaire) peut être encodé en ascii, utf-8, etc… Dire "fichier texte" tout seul ne renseigne en RIEN !

without much processing,

Ah, diantre ! Je croyais que plain text = transparent. On dirait que non. ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Un format binaire ne répond à aucun des mes usages.

Le format texte, ça ne veut rien dire. C'est un format binaire, avec un encodage spécifique.
There Ain't No Such Thing As Plain Text.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Et y'a de toutes façons le petit bouton à droite pour virer les tuiles, et revenir au nouvel onglet bien vide d'antan, une bonne fois pour toutes.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

je n'arrive pas à afficher mon site d'information préféré qui n'a rien à voir avec le boulot

linuxfr ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Non il ne sert même pas à ça. D'abord, le démarrage en parallèle des services, upstart le faisait déjà, et c'était même possible avec SysV sous Archlinux.

Le démarrage (relativmement) plus rapide de systemd est un effet de bord de l'architecture logicielle de systemd, pas un but du projet.

Un des buts premiers de systemd est de fournir un système d'init qui offre un ensemble d'outils en espace utilisateur pour utiliser et profiter des control groups.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

https://lists.debian.org/debian-ctte/2014/02/msg00376.html

(NSFW)
:o

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

sans CLA, systemd d'aurait pas de raison d'être et tout le monde aurait travaillé à rendre Upstart meilleur.

Euh j'en doute. Systemd est très différent d'Upstart.

Upstart et launchd sont deux inspirations de systemd, cependant.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Debian et systemd se marrient ?!
Mais quid de la garde de Debian/kFreeBSD ?! ;-)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Exemple de debianisme dans systemd : /etc/hostname

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Rien qu'entre le serveur graphique et une TTY, ça me prend près de 4s pour qu'un de mes écrans se rallume, l'autre étant plus long encore.

C'était le cas sur une nvidia avant (GeForce 9300M GS, pilotes proprios). Depuis que je suis sur une intel 4000HD, le passage TTY <-> Xorg est instantané ! :o

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Les exécutables sont bien plus gros, mais en aucun cas moins rapides.

Pour Archlinux, c'est prévu depuis longtemps d'inclure les symboles de debug par défaut mais on dirait que ça pose problème.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

J'ai pas à recompiler tout le système pour déboguer UN programme, quelque soit le système d'exploitation.

Qu'est ce c'est que ces bêtises, franchement !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Wut ?

Y'a des gens qui sont jamais contents…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Euh, c'est rien de bien sorcier.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Si une recompilation ne suffit pas, je pense que l'exemple de la sdl est le plus parlant :
Il y a toujours les paquets sdl pour la version 1.x (sdl, sdl_net, lib32-sdl, …), et les paquets sdl2 pour la SDL2 (sdl2, sdl2_net, lib32-sdl2, …)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

je pense que c’est surtout aux développeurs que le système rolling release pose des problèmes.

Dans mon expérience, pas vraiment.
- on a la chance d'avoir des versions récentes de bibliothèques, au lieu d'une version (trop) vieille
- quand on installe une bibliothèque, on a pas à s'emmêler les pinceaux avec des paquets -dev à installer à part, il y a tout ce qu'il faut de base (exemple : j'installe la sdl, j'ai aussi les fichiers d'en-tête avec).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Si on fait une conversion ext3 -> ext4, on n'obtient pas un fsck rapide, comme le remarque Ted Ts'o dans les commentaires du lien.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Non mais vraiment, ext4 est plus rapide pour fsck

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Edit : Ah, et d'ailleurs, je pense à une chose : le seul moment où j'ai l'impression que le démarrage est trop long, c'est quand fsck fait son check des disques, et là je vois pas comment on pourrait raccourcir (enfin, peut-être, j'en sais rien).

C'est vachement plus court en ext4, et encore plus sur un SSD.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ce n'est pas ce que j'ai dit.

Il est juste rare qu'un bug provienne d'un patch concocté par un mainteneur du paquet x ou y.

[troll] Je préfère ça à une Debian/Ubuntu avec des patchs de tous les côtés qui apportent plus de problèmes qu'autre chose (comme un kernel qui plante au démarrage alors que ça fonctionne bien sur les autres distributions). :p [/troll]

Quant à LFS, euh non rien à voir. Quand tu as installé Arch, tu as au moins (entre autres), linux, grub, pacman, systemd, netctl, un compte root, et bash (tout ce qui fait partie du méta-package 'base', notamment).

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Si, et bien souvent ce sont des bugs upstream, Arch ayant pour forte politique de ne rien patcher du tout à moins que ça ne fonctionne/compile pas.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Non. Le liens que tu donne dis de faire le téléchargement à un moment et l'installation de la mise à jour à un autre moment.

pacman -Syu fait les deux à la suite, et c'est ce qui est recommandé.

Tu peut avoir une coupure de courant, tu peut choisir pour simplifier les mises à jour de passer en runlevel 1 ou 2 (ou équivalent dans le système d'init que tu utilise), etc. Et puis ça permet de gérer tous les cas que ni toi ni moi ne voyons. Être fiable ce n'est pas gérer tous les cas qu'on a vu vite fait comme ça au travers de commentaire sur linuxfr.

Tu peux aussi avoir une météorite qui tombe sur ta maison. Ou Bowser qui vient pour détruire tout ton quartier.

Qu'on se mettent bien d'accord. On parle au moment de la MAJ de :

télécharger la page d'accueil archlinux.org
écrire une ligne du genre : mise à jour des informations de MAJ /etc/archlinux-update.txt

Ah, ok. Pourquoi pas…

On retombe sur le dénigrement et le snobisme. C'est pas la faute de la distrib' c'est l'utilisateur qui est trop con pour s'en servir.

Tant qu'on dira "Arch m'a planter" sans preuve (ou pire quand on pose quelques questions on se rend compte que l'utilisateur n'a rien compris), oui ce sera l'utilisateur qui sera à blâmer, en toute logique.

Donc finalement le commentaire plus haut a raison ? Si on fait pas ces MAJ assez fréquemment on crève ?

Parfois, oui : http://allanmcrae.com/2012/07/updating-arch-linux-from-a-core-install/
(le dépôt d'Allan McRae n'existe plus, donc mettre à jour une installation de Arch avec une glibc trop vieille est quasi-impossible, pour ne pas dire impossible).

Dans le même genre, si tu prends un très vielle ISO de Arch et qu'après l'installation tu essaie de mettre à jour, tu risques d'avoir beaucoup, beaucoup de problèmes (enfin surtout avec cette fameuse update de la glibc).

Enfin, le mieux dans ce dernier cas est de faire une netinstall.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)