xcomcmdr a écrit 3537 commentaires

Moui bof. La FAT32 sur un SSD c'est assez naze :
- va falloir utiliser fstrim régulièrement sous Linux (Quant à Windows, je sais pas comment il va faire le triming… à moins qu'il laisse ce boulot au firmware du SSD), alors qu'ext4 le supporte tout seul avec l'option de montage discard
- sur la plupart des SSD pas trop chers (ceux de 64 Go aujourd'hui, quoi), le système de fichiers FAT32 prend bien trop de place à lui tout seul. Et plus la partition est grande, plus c'est pire.

Sans compter tous les autres problèmes de la FAT32 (fichiers > 4 Gio pas possibles, pas de journal, pas de chiffrage, pas de droits sur les fichiers, …).

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

 Dire "Faudrait ptet defragmenter, mais c'est du SSD, ne pas faire ça trop souvent"

C'est tout à fait inutile sur un SSD, sauf si tu réduire sa durée de vie tout à fait inutilement !!

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

Chez moi il ne consomme rien du tout, même sur un vieux Pentium 3…

tu peux dire à systemd-coredump de faire comme avant systemd/journald.

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

Ouais donc le problème ne vient pas de Firefox.

Et c'est simple comme bonjour :
- prendre un thème sur le Web (par exemple sur gnome-look.org, http://shimmerproject.org/ pour Albatross/Greybird, ou dans les paquets de ta distrib)
- le décompresser dans ~/.themes
- le sélectionner dans le gestionnaire de paramètres -> Apparence -> Style

Et c'est réglé !

(s'il ne s'affiche pas, c'est qu'il n'a pas été désarchivé comme il faut : ~/.themes/Greybird : OK - le sélecteur de style ne regarde pas plus loin que ~/.themes// pour un fichier index.theme - ~/.themes/Greybird/Greybird : pas OK !)

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

Même quand j'étais sous Xfce, Firefox n'était jamais moche : à part la décoration de la fenêtre, y'a aucune différence avec la version Windows depuis longtemps.

Sous KDE, il ne jure pas non plus avec le reste :
http://pix.toile-libre.org/upload/original/1406615918.png

Je dirais qu'il te manque un bon thème unifié pour GTK2 et GTK3 tel que Greybird ou Albatross, ou qu'il un y a un problème avec ta config…

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

Je trouve dommage que tout le paysage des distributions Linux se tourne vers systemd.

T'as eu la même réaction quand SysV s'est imposé ?

Peut-être que systemd s'impose car il est bien meilleur que SysV. Par exemple, plus besoin de maintenir des scripts : on prend l'unit file upstream et c'est plié.

Il reste peu, aujourd'hui, de distributions qui ne l'utilise pas (ou pour lesquels ce n'est pas prévu). On perd de la diversité et du choix.

De la diversité pour un système d'init. Comment dire… Tout ce que je demande à un système d'init (en gros), c'est que la machine boot sans problème. Au delà, qu'il soit SysV ou systemd importe peu.

Et puis là c'est pas de la diversité : c'est revenir sur SysV. Si au moins c'était un init nouveau, là il y aurait une vraie diversité.

Et que penses-tu de Mir alors ? Tu crois que c'est une chance d'avoir autre chose que Wayland pour le futur des serveurs d'affichage ? Deux APIs, deux serveurs d'affichages concurrents, deux fois plus de bugs potentiels : youpi… ;-)

Je pense qu'au contraire qu'avoir systemd partout permet :
- d'avoir une seule API pour l'init
- de même pour l'usage des cgroups par l'user-space
- d'éviter d'écrire 1000 fois a peu près le même script d'init pour le service X (1 fois par distribution. Et encore, 1000, c'est loin du compte du nombre de distribs).

Dans les faits, cela devient pénible pour une distribution de faire sans systemd de nos jours.

Faut croire que c'est pas tellement le cas vu que Crux, Gentoo, Slackware, Ubuntu (jusqu'à la 14.04 au moins, qui a 5 ans de support), la dernière Debian stable (d'ailleurs systemd a été choisi pour d'autres raisons que sa "pénibilité" supposée : après tout les arguments autres que techniques n'avaient pas leur place dans la discussion) et d'autres font bien sans.

Et je ne vais pas revenir sur les problèmes que cela pose avec udev, etc.

Bah systemd est très dépendant d'udev, et puis bon le seul "problème" c'est de pouvoir compiler udev sans systemd.

Les forks c'est bien, sauf quand on s'appelle eudev et qu'on a pas parlé à l'upstream avant de forker udev en "eudev". C'est sûr que si on coopère pas, rien ne changera.

systemd, ses outils (dont udev) sont développés ensemble, et sont sur un VCS commun à la BSD. Mais ça ne plaît pas à BSDiste. Et ça ne plaît pas aux linuxiens. Faut croire que le problème, c'est peut-être pas systemd…

Pour l'etc, je ne vois pas… (je suis pas devin ;-) )

Sinon, j'ai techniquement pas mal de reproches envers systemd.

Dommage que ce soit toujours les même arguments répétés 1000 fois et réfutés 1000 fois. :/
Honnêtement, pour la plupart de tes griefs, je me suis renseigné 30 secondes pour savoir que c'était faux…

D'une part, il en fait beaucoup trop en tant que PID 1 (oui, je suis au courant pas tout n'est dans le PID 1, et heureusement d'ailleurs).

"Mon" /sbin/init (systemd) ne fait guère de plus que SysV, il me semble (non seulement d'après la page de man, mais en lançant /sbin/init --help on voit qu'on a pas grand chose de compliqué :

max-laptop% /sbin/init --help
systemd [OPTIONS…]

Starts up and maintains the system or user services.

-h --help Show this help
--test Determine startup sequence, dump it and exit
--dump-configuration-items Dump understood unit configuration items
--unit=UNIT Set default unit
--system Run a system instance, even if PID != 1
--user Run a user instance
--dump-core[=0|1] Dump core on crash
--crash-shell[=0|1] Run shell on crash
--confirm-spawn[=0|1] Ask for confirmation when spawning processes
--show-status[=0|1] Show status updates on the console during bootup
--log-target=TARGET Set log target (console, journal, syslog, kmsg, journal-or-kmsg, syslog-or-kmsg, null)
--log-level=LEVEL Set log level (debug, info, notice, warning, err, crit, alert, emerg)
--log-color[=0|1] Highlight important log messages
--log-location[=0|1] Include code location in log messages
--default-standard-output= Set default standard output for services
--default-standard-error= Set default standard error output for services

Ou du moins, il n'y a rien de surprenant.

D'ailleurs, quand j'interagis (rarement, d'ailleurs) avec systemd, j'utilise en fait /usr/bin/systemctl

Cela a plusieurs conséquences: une étant que, en étant complexe il y a plus de risques de plantages et en tant que PID 1 ça ne pardonne pas puisqu'il n'y a personne pour récupérer l'orphelin;

Euh, ce n'est pas mon impression. Extrait du man :

--crash-shell
Run shell on crash.
(bon sauf que j'ai pas pu crasher systemd pour tester)

Et puis tant qu'on parle de fiabilité : quand je m'étais planté dans mon inittab, SysV empêchait le système de démarrer. C'était tellement mieux, SysV à ce niveau ?
J'ai jamais eu cette impression.

Quant à la sécurité de SysV : euh, quelle sécurité ? La sécurité d'avoir des scripts shells exécutés par root, sans usage des control groups qui plus est ?

Et puis bon, face à la complexité du kernel, de Firefox, ou de Xorg, systemd (le PID 1 pas si compliqué que ça en fait…) c'est rien du tout du tout du tout. Mais le kernel et Xorg ne sont pas des cibles de choix : après tout, ce n'est pas systemd. ;-)

une autre, le fait que certaines mises-à-jour de systemd demandent du coup un redémarrage.

Euh… lesquelles ?
J'ai jamais été obligé de redémarrer. Et pour profiter de la nouvelle version les mises à jours du kernel ou de Xorg nécessitent elles aussi un redémarrage : rien d'anormal là dedans (oui pour Xorg on peut "juste" redémarrer Xorg : mais c'est plus rapide pour moi de redémarrer tout court…).

Les logs binaires, je trouve ça vraiment stupide.

Bah d'un point de vue sécurité, c'est les logs textuels le plus "stupide" :
- N'importe qui ayant accès aux logs peut les modifier et effacer ses traces (ce qui n'est pas le cas avec journald)
- on ne peut pas mettre un core dump ou un dump de firmware avec les logs. Oh, on peut mettre ça à côté, mais ce n'est pas dans le journal binaire, le même journal qu'on veut pouvoir être lisible avec journalctl sur un autre système et authentifier facilement.
- on a pas un standard de notation des dates/heures, ce qui est particulièrement énèrvant quand on a des tonnes de logs
- Perso, je trouve bien plus vite les erreurs avec journald qu'avec des fichiers textes (pas besoin de me souvenir comment fonctionne awk, sed, & co.). Au bout d'un moment, avoir une abstraction qui m'évite cette peine a du sens.

Je veux les logs produits par Firefox ? Aucun problème :

max-laptop% journalctl /usr/bin/firefox
-- Logs begin at sam. 2014-01-11 18:57:59 CET, end at lun. 2014-07-28 21:31:10 C
févr. 25 20:06:54 max-laptop firefox[2419]: getaddrinfo*.gaih_getanswer: got typ
févr. 25 20:06:54 max-laptop firefox[2419]: getaddrinfo*.gaih_getanswer: got typ
-- Reboot --
mars 31 06:45:20 max-laptop firefox[2152]: getaddrinfo*.gaih_getanswer: got type
mars 31 06:45:20 max-laptop firefox[2152]: getaddrinfo*.gaih_getanswer: got type
-- Reboot --
avril 07 07:27:44 max-laptop firefox[2193]: getaddrinfo*.gaih_getanswer: got typ
avril 07 07:27:44 max-laptop firefox[2193]: getaddrinfo*.gaih_getanswer: got typ
lines 1-9/9 (END)

Je veux les logs du boot précédent ? OK :

max-laptop% journalctl -k -b -1
-- Logs begin at sam. 2014-01-11 18:57:59 CET, end at lun. 2014-07-28 21:42:15 C
juin 15 07:47:32 max-laptop kernel: Initializing cgroup subsys cpuset
juin 15 07:47:32 max-laptop kernel: Initializing cgroup subsys cpu
juin 15 07:47:32 max-laptop kernel: Initializing cgroup subsys cpuacct
juin 15 07:47:32 max-laptop kernel: Linux version 3.14.6-1-ARCH (nobody@var-lib-
juin 15 07:47:32 max-laptop kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux
juin 15 07:47:32 max-laptop kernel: e820: BIOS-provided physical RAM map:
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x000000000009e000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000020000000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000020200000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000040004000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000040005000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c97a5000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9da6000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9da9000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dbf000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dc5000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dc7000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dd1000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9f28000-0x0000000
juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9f2c000-0x0000000
lines 1-23

Les exemples du manuel sont pas mal aussi.

Aux pros de awk/sed & co. : Bravo, mais il y a des gens qui sont de simples mortels. Désolé de vous décevoir.

Oui, je sais qu'aujourd'hui on peut encore envoyer vers syslog mais… pour combien de temps encore?

Euh, tu nous fais du FUD maintenant ?

Personne ne peut répondre à ce genre de questions, à part les auteurs de systemd ! D'ailleurs, tu leur a posé la question ?

Et à part ça, t'es au courant que c'est un logiciel libre, tout de même ?

Surtout qu'il te donne plus d'informations dans ton syslog que ne le fait SysV (parce que journald démarre plus tôt que ne peut le faire syslog, et que journald enregistre la sortie standard et la sortie d'erreurs de tout service système) : rien n'est caché à syslog. En rien, on ne te force d'utiliser journald.

Sinon, il y a aussi tout le bloat: systemd incluant notamment, un serveur http, de quoi servir des codes QR, etc.

C'est optionnel à la compilation, et d'ailleurs sur Archlinux ce n'est même pas compilé.

Le support de la génération de codes QR par journald (et non systemd) c'est environ 116 lignes.

Y'a pas de quoi fouetter un chat, surtout quand on sait à quoi ça sert.
(en gros, c'est une option pour ne pas avoir à copier des clés de vérification que l'utilisateur pourrait trouver trop longues).

Quant au serveur http (cela semble être systemd-journald-gatewayd) embarqué :
- il est embarqué (ou pas, si on le compile pas) pour éviter une dépendance
- sa compilation n'est pas activé par défaut
- son code est réduit au minimum
- il permet d'envoyer le journal de journald à travers le réseau. Rien de révoltant là non plus (on faisait pareil avec SysV)
- même s'il est compilé, il faut l'activer pour l'utiliser ou le désactiver si on en veut pas, comme n'importe quel autre service.

Je pense que systemd fait trop de choses.

Euh ouais… Tout comme le kernel monolithique linux, Xorg le très mauvais middle-man (c'est les devs Xorg qui le disent eux-mêmes !), ou Firefox si on en croit certains (c'est vrai que je largement mets moins de temps à compiler linux qu'à compiler Firefox), si on va par là…

Et c'est vrai que quand j'ai découvert (par exemple) que systemd s'occupait de l'ACPI, je me suis dit qu'il faisait trop de choses. Mais ça a du sens sur un système embarqué (c'est un marché ou systemd semble être utilisé)
Ou si on veut pas utiliser de bureau : j'imaginerais bien un système utilisateur léger avec un WM de son choix, et systemd pour l'ACPI (pas xfce4-power-manager ni rien de tout ça !). :)

Niveau sécurité, je pense que systemd est également un problème. On a déjà vu passer quelques CVE concernant systemd mais à mon avis, cette tendance ne va aller qu'à la hausse puisque, vu son importance, il est une cible de choix.

Ce qui compte, c'est pas la tellement taille du code, c'est sa qualité. Sinon, on utiliserait tous nginx au lieu d'Apache (ben oui moins de code = plus de sécurité. Autant éteindre l'ordi et le débrancher : il y aura zéro code, donc un maximum de sécurité ;-) ).

En parlant de qualité, avec des suites de tests et une convention de style de code assez détaillée, c'est bien plus que pas mal de projets…

Et j'ai du mal à imaginer qu'il n'y ait jamais eu de CVE avec SysV. Ou Xorg. Ou Linux. Ou Firefox. Ou Apache… Ou nginx.

Ceci dit, je ne pense pas que du mal de systemd. J'ai juste relevé les points que je trouve négatifs, puisque tu le demandais.

Et je t'en remercie.

Pour en rire : voici les six étapes de systemd (linux conf.au 2014). ;-)

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

Bah euh c'était une vraie question. :(

J'avais compris que c'était systemd qui t'avait poussé à changé de distrib', et j'étais curieux de savoir pourquoi.

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

Je n'aime pas QT car ça ressemble beaucoup aux MFC que j'ai trop pratiqué. C'est un avis personnel.

Je vois pas du tout en quoi.

A la limite on pourrait rapprocher Qt de WPF (QML permet de décrire une UI avec un langage déclaratif, tout comme XAML, et on peut rapprocher les bindings QML vers C++ des bindings XAML vers XAML/C#). Dans les deux on peut aussi utiliser les événements, mais ce n'est pas obligé.

MFC ça se rapprochait plus de "faire une GUI avec la Xlib", du peu de ce que je sais des deux (les deux utilisent principalement les événements, les deux reçoivent un événement de type WM_PAINT de la part du serveur d'affichage pour mettre à jour leurs graphismes). Bref, assez bas niveau, et les deux datent d'avant l'accélération graphique, ce qui fait que typiquement les fenêtres étaient dessinées par le CPU.

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

s/système/systemd

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

C'était quoi le problème avec système sous arch ?

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

Le forum, ni le google+ ne sont des sources officiels.

1. De quel droit ?

2.C'est un dev Arch qui parle ici, c'est donc une source officielle.

3.Si tu as un lien donne-le. Je vais pas aller fouiller la mailing-list.

Euh si, justement (le 04/04/2012 d'après git)

Il s'agit d'udev, pas de dbus.

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

Non, c'est parce que systemd allait leur donner moins de maintenance et de problèmes que SysV :

https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Et dbus n'a pas été incorporé au projet systemd, que je sache. Donc, je vois pas pourquoi ça "forcerait" à migrer vers systemd.

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

Les mainteneurs des distributions n'ont guère le choix en vérité vu les interactions entre systemd et le reste du système (prononce Gnome)

Merci de ne pas ré-écrire l'histoire avec du bullshit. Beaucoup de distributions sont passés à systemd bien avant que Gnome ne s'en serve, parce que systemd était déjà une bien meilleure option que SysV.

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

JF Copé est le roi des trolls. Son nombre de conneries à la minute (CLM) est absolument sans pareil.

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

Je n'utilise pas Classic Theme Restorer ou n'importe quoi de ce genre, et j'ai un navigateur utilisable.

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

Et ?

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

Pour apprendre l’algorithmie, l'assembleur ne me semble pas vraiment indiqué, de même pour le C.

Parce que apprendre à programmer avant de savoir ce qu'est un algorithme ça donne de la merde que d'autres auront le malheur de devoir nettoyer.

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

(Et si quelqu'un dit que C est plus facile que l'assembleur c'est qu'il ne sait programmer ni l'un ni l'autre!)

Ah bon, pourquoi avoir inventé le C alors ?

Le C est plus facile dans le sens où il te fait gagner du temps (et le temps, c'est du code).

Si l'assembleur était si facile que ça, on y serait resté.

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

J'ai toujours trouvé KDE remplie de bug que ce soit la version 3 ou 4 sans vouloir troller

Pareil, mais depuis la 4.13 plus rien à ce niveau, perso (Intel HD4000).
Pour la version 3.X, la 3.5.10 était aussi très stable chez moi (à l'époque j'utilise une ATI Radeon 9600 Pro).

Les bugs les plus récurrents étaient pour moi (en version 3 ou 4) un crash de KWin, de l'application à la fermeture, et de nepomuk.

Ça dépend aussi de la distro. Kubuntu, par exemple, s'est beaucoup amélioré (ils sont beaucoup plus proche de l'upstream qu'avant).

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

Si ton GPU est utilisé à 100% pour faire de l'ombre autour des fenêtres, c'est un mauvais GPU.

Genre, une GeForce 2…

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

Mauvais GPU, changer GPU.

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

Je vois pas l'intérêt de la notation hongroise dès lors qu'on a un IDE moderne, quel que soit le langage.
Et surtout pas dans l'exemple i_counter : ouais, c'est sûr qu'un compte sera pas un string, hein.

99% du temps la notation hongroise, c'est Captain Obvious (aka Captain Noise pour du code).

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

je choisirait javascript comme premier langage pour donner le gout de la programmation à des étudiants qui n'y connaissent rien.

Ou pour les en dégoûter, au choix.

En tout cas, on a trouvé comment faire des amoureux de Javascript : en faire leur premier langage. :/

Quitte à vouloir faire du Javascript à la fin, autant préférer CoffeeScript.

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

Au moins aussi facile que Python, et c'est un langage où on se répète très peu.

On peut aussi faire très rapidement des logiques du genre "de 23 à 45, afficher 'truc'" avec l'opérateur .. (son nom m'échappe pour le moment).

C'est un des exemples qui montre que la syntaxe Ruby ne se met pas en travers de la productivité. On montre aussi souvent celui-ci exemple :

 var=2
 4.times do |x| 
   puts x=x*var
 end

4.times do |x| … Une simplicité enfantine! Quand on m'a montré ça pour la première fois j'ai fait "wooh!" :)

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

Franchement rien. Linux est une très bonne plateforme pour développer.

Ou pas. Certains préfèrent XCode ou Visual Studio à n'importe quel IDE sous Linux, et je les comprends.

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