freem a écrit 4934 commentaires

Oui, evidemment, si tu utilises une appli kde ou gnome, elle sera aussi lourde peu importe le bureau sous lequel tu l'utilises.
Et si tu utilises une appli d'un autre bureau, ca sera comme si tu avais charge les deux bureaux, donc si gnome utilisais une appli xfce gnome sera plus lourd que xfce, vu qu'elle chargera son bureau pour se lancer, via les cascades de .so (je trouve dll plus pertinent comme nom, c'est pareil mais sous un autre os).

Par contre, utiliser juste kde ou juste xfce ou juste gnome, c'est pas la meme chanson.
Et pour le taf proprement dit, on utilisera generallement chromium, firefox, libreoffice, solvespace, freecad, etc. Pas le DE justement.

La majorite de ces applications uilisent gtk (malheureusement) mais gtk est utilisee par xfce et gnome de toute facon, donc pas de surcout (selon les versions de dependances).

Un commentaire, ca doit expliquer la raison d'etre d'un code illogique au 1er abordS (2 abords: metier et technique).
La plus grosse partie des "doc" doxygen & co est effectivement auto-generee, et donc inutile.souvent, ca decrit les parametres, qui ont deja un nom parlant.
Perso, je prefere decrire l'intention du bloc de code, ses pre-conditions et post-conditions, et si possible le faire en code, a coups d'assert() ou autres verifiables par le compilo.
Les intentions des parametres sont tres souvent dans leur nom apres tout.§

Pour les langages qui peuvent pas, c'est simple: je ne les utilise pas. Je considere que l'absence d'analyseur statique gratuit, libre et de qualite decente est un element de preuve qu'un langage est a eviter.
C et Cpp ont ca, java en a, pascal probablement.

En tout cas la 4.18 est dans sid.

Le prochain freeze est prévu pour le 12 février 2023, donc ça va être serré, mais d'un autre côté XFCE est un DE qui est stable, contrairement à, par exemple, Gnome (donc chaque version semble contenir son lot de programme réécrit, de fonctionnalités suprimées ou ajoutées), donc je dirais que ce n'est pas impossible que la 4.18 finisse dans la prochaine stable: il reste 2 mois, et il me semble qu'un paquet doit être dans unstable pendant au moins 3 semaines avant de pouvoir passer en testing?
Si ce n'est pas le cas, il y a de bonnes chances que ça tombe dans les backports de toute façon, donc je pense que tu pourras en profiter.

Mon avis sur XFCE est que c'est le DE le plus équilibré que j'aie testé: assez de fonctionnalités pour les tâches de base, des performances correctes.
LXDE n'est pas mal (et serait mon choix si je n'utilisais pas i3), mais reste plus axé pour les bricoleurs, les programmes sont moins inter-connectés, donc plus facilement remplaçable, mais pour ça il faut chercher les programmes qui offrent un avantage par rapport à ceux présents.
KDE et Gnome sont… lourds. Toutes les machines n'ont pas encore de SSD pour le système, donc ça peut encore se sentir. Même si c'était le cas, la question de la RAM, du CPU et du GPU reste présente: les ressources sont pour faire tourner le bureau, ou pour faire tourner blender, freeCAD, solvespace, LO, clang?

Un bureau, pour moi, c'est surtout l'endroit ou je peux mettre mes outils pour travailler, pas un objet de décoration. Ce qui est valide pour le meuble, comme pour le paradigme logiciel.
Et XFCE en est un bon example.

Alors, pour m'etre fait" prendre a parti" (gentiment en vrai, discussions interessante in fine) sur IRC il y a quelques mois, je veux juste preciser que non, les voxels n'ont rien a voir avec les cubes de minecraft & co (ce que je croyais a l'epoque).
Cette techno est en fait assez ancienne, on trouve des voxels depuis au moins 20 ans a priori, principalement pour le rendu de sols (pas forcement carre ou cubique, hein).

Le rapport avec le sujet, c'est que low-poly et voxels n'ont rien a voir. Pire, ils sont opposes selonmes lectures: le low poly est utilise poyr des raisons de performances, alors que le voxel n'est pas utilise pour les modeles "fins" (les entites quoi) parce que ca coute trop cher, justement.

un code de CB (autrement plus intéressant pour les "méchants") c'est 10000 possibilités seulement et ça suffit car tu ne peux pas essayer plus de 3x.

Et dans ce monde ultra-sécurisé ou la banque mets en place une double authentification (qui casse plus les… qu'autre chose) il ne faut pas oublier qu'une CB est utilisable sans code dans de nombreuses situations: péages (autoroutes, ponts), ou depuis quelques années, sans contact.

J'espère que l'auteur du journal à désactivé le sans contact de sa CB, ça serait cohérent avec ce type de peur (perso je l'ai fait, je préfère de loin taper mon code à 4 chiffres. Même si d'un autre côté je paie souvent en liquide, qui manque totalement de protection, excepté le fait que ça ait une limite physique qui est entièrement sous mon contrôle).

pire, je trouve que les liens sans rapport ont plus de commentaires en fait

Du coup compare a blender c'est quoi le point?j ai lu, mais a priori pas ccocmpris

Desole de te le dire, mais ca fait longtemps (on peut trouver des aveux que ce n'est pas fait par les moderateurs, et difficile de le repprocher, poster un lien prend 5s, le trouver et le moderer est surement de l'ordre de 5min) que l'on sait que les liens ne sont que censes etre moderes et en rapport avec la ligne editoriale, contrairement aux journaux qui eux ne sont pas soumis a la ligne editoriale (mais toujours moderes).

clang-tidy sait faire. Dans ce lien, ctrl+f sur "modernize".

A l'origine (dans les années 2010) ça s'appelait clang-modernise. L'intérêt, pour répondre au message ci-dessus, c'est de pouvoir bénéficier des nouvelles syntaxes, ce qui rend le code clairement plus lisible.

Typiquement:

for( std::vector<int>::const_iterator it = foo.begin(); it != foo.end(); ++it )
{
  printf( "%d\n", *it );
}

Peut devenir en C++ moderne:

for( auto i : foo )
{
  printf( "%d\n", i );
}

Pour moi, il n'y a pas photo. Et je n'ai pas cité std::bind1st ou std::bind2nd…

Quant à la doc, je ne la trouve pas vraiment pauvre, moi. Au pire on peut facilement trouver des articles sur le sujet.

Ceci étant dit, moderniser une base de code sans connaître le langage me semble assez peu pertinent quand même.

s/l'init/le framework/

:p

Heureusement qu'on peut réécrire les valeurs des variables, manquerait plus que ça!
Mais bon, c'est exactement la même chose pour la ligne de commande, on peut réécrire ou modifier les paramètres passés de manière tout aussi simple, sinon plus.

Chez moi, aptitude indique ~4.5megs pour installer python3.9. Enfin, en partie, je n'ai pris que python3.9-minimal, libpython3.9-minimal et libpython3.9-stdlib.
Décompressé, vu que c'est la valeur que tu donnes, ça nous fait environ 15 megs. Toujours selon aptitude.
Du coup en fait c'est une sacrée optimisation, non? :D

D'ailleurs, j'ai envie de dire que c'est toujours mieux qu'électronJS. Typiquement, VS Code semble peser 130 megs. Compressés. Et si ma mémoire est bonne, la bouse^WW le frontal graphique qui avait été construit dans mon précédent taf étais dans les 80 megs bien compressés (et sans les ressources graphiques ni les trads, hein).

Après, comme dit par barmic, wasm me semble plus intéressant pour balancer du code executable isolé, par exemple pour des plugins ou des mods d'un jeu. Il doit bien y avoir d'autres exemples… après, si l'idée est d'avoir de la performance, effectivement utiliser du code python est un choix étrange.

Ah, ok.

Oui, effectivement, ne pas hard-coder ce qui n'a pas besoin de l'être… bon, c'est un peu le B.A. BA du métier, ça, non? Ne serait-ce que pour le dev lui-même, ça simplifie tellement les choses sur le moyen terme…

Je veux dire… rendre configurable, faire du code qui fait une chose et la fait bien, documenter ses dépendances, etc etc… normallement un dev qui a, disons, 2-3 ans de métier (donc après ses études) devrais se l'être fait enseigner par les collègues non? Parce que j'imagine que les écoles ne le font pas toutes (la mienne le faisait pas, en même temps les profs… bon, no comment, rien de bon a ressasser ça)

Deux programmes différents utilisant la même variable (même nom, ça peut aller très vite, quand on a plein de programmes) de manière différente.

Si ton but c’est le minimalisme, tu peux déjà commencer avec systemd, car il est possible de désactiver les services mis en place par défaut

En plus je crois que systemd intègre bootchartd, ou un truc du genre, pour avoir des graph de quoikibouf du temps de boot? Je me base sur de vieux souvenirs de lecture… p'tet utilisable avec d'autres outils?

Et ce n'était pas faisable avec, disons, tcpd, ça? Je crois qu'il y a un autre daemon qui fait le même type de trucs, mais impossible de me rappeler le nom… Pure curiosité, hein. Je troue personnellement logique que ce type de fonctionnalités aille dans le gestionnaire de daemon (pas dans l'init, cependant, mais c'est une autre histoire).

Tout ce temps que tu aura passé à mesurer les kio utilisés par systemd, pour ensuite les comparer à sysvinit, openrc et ruinit

A peu près 5 minutes par système (et encore. De toute façon j'avais déjà un dual-boot entre ma debian custom et une debian normalle, pour cause qu'il faut tout une stack logicielle pour faire tourner un vulgaire soft de video-conf sur firefox… et je crois que ça merdait sur chromium aussi? Je sais plus), un jour que j'étais curieux de vraiment savoir.

Tout ça pour la satisfaction de "j'ai un système minimaliste" c'est l'inverse du minimalisme numérique1

J'ai un PC qui a moins de 200 megs de ram. Il tourne très bien merci. Mais pas si je gâche 30 megs pour l'init.
Honnêtement, je conserve cette machine juste parce que. A l'origine, parce qu'elle dispose encore de connecteurs P-ATA, et y'a même du SCSI et un lecteur de bande. Je me disais "on sait jamais, une connaissance pourrait me demander de récup des données…".
Cet argument est maintenant caduc, mais je garde la machine pour le fun :)
Chose que j'assume d'ailleurs. Je pense avoir bien indiqué que l'impact de RSS était négligeable sur les machines modernes.

Ce dont tu parle est plus de l'éco-conception ou conception responsable

Je vois ton point. Je suppose que ça marche aussi.

Pas pour l'immense quantité de gens qui ne vont jamais les lire de toute façon :D

Pour les autres, je sais pas, je trouve que les deux ont leurs côtés sympa. Je ne crois d'ailleurs pas que les deux soient en conflit.

Pour moi, garder les logs bruts de chaque daemon pendant un certain temps, isolés les uns des autres (important ça), puis uploader sur une machine centrale juste les infos qui sont réellement utiles pour avoir des métriques, c'est pas déconnant.

De cette façon, la BDD ne grossit pas pour rien (pas de données inutiles) et est plus simple a explorer ou manipuler, mais quand ça part vraiment en sucette, les logs bruts sont toujours accessibles sur les machines émettrices (exemple de cas d'usage vécu: 250+ systèmes dont la connexion se fait via 2G/3G/4G en forfaits limités et avec une qualité réseau aléatoire dans l'espace et dans le temps).

Je ne sais pas si systemd répond à un besoin utilisateur

Je dirais que si. Le système d'unit de systemd est plus simple a hacker que l'horreur sans nom qu'il y a encore dans debian pour les rc.d.
Petit example avec mpd en fin de message (parce que c'est LONG rc.d!).
C'est juste indiscutablement plus simple, le jour ou l'on a besoin de bricoler un daemon pour soi. Et je n'aime pas systemd, hein!
En gros:

• systemd: 49 lignes
• init.d: 108 lignes, et je n'ai pas eu le courage d'aller compter les trucs sourcés
• runit, pour l'instance de runsvdir qui démarre quand je me log en tant que user et pas quand je boote le système, pour le fun: 35 (c'est moi qui ai plus petite, nanananèèreeeee)

Il est possible de lancer des daemon sans être root! Sans DE! Et un watchdog, comme ça quand ça plante ou qu'on ferme par erreur, ça redémarre. Typiquement: le client lourd pour les mails que les gens qui bossent continuent de préférer globalement aux interfaces web.

Dernier: avantage théorique, avec systemd on devrais pouvoir démarrer plus vite parce que tout simplement si le PC est hors réseau, certains services qui requièrent le réseau ne chercherons pas à démarrer. Je sais pas, moi, le logiciel de backup par exemple, ou syncthing, ou le client mail… Reste à voir si c'est mesurable.

Ensuite la question est: quelle est la limite entre un utilisateur et un mainteneur sur un système GNU/Linux? Vu que je maintiens mes scripts d'init DIY, que suis-je?

Systemd:

[Unit]
Description=Music Player Daemon
Documentation=man:mpd(1) man:mpd.conf(5)
Documentation=file:///usr/share/doc/mpd/html/user.html
After=network.target sound.target

[Service]
Type=notify
EnvironmentFile=/etc/default/mpd
ExecStart=/usr/bin/mpd --no-daemon $MPDCONF

# Enable this setting to ask systemd to watch over MPD, see
# systemd.service(5).  This is disabled by default because it causes
# periodic wakeups which are unnecessary if MPD is not playing.
#WatchdogSec=120

# allow MPD to use real-time priority 40
LimitRTPRIO=40
LimitRTTIME=infinity

# for io_uring
LimitMEMLOCK=64M

# disallow writing to /usr, /bin, /sbin, ...
ProtectSystem=yes

# more paranoid security settings
NoNewPrivileges=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
# AF_NETLINK is required by libsmbclient, or it will exit() .. *sigh*
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK
RestrictNamespaces=yes

[Install]
WantedBy=multi-user.target
Also=mpd.socket

[Socket]
ListenStream=%t/mpd/socket
ListenStream=6600
Backlog=5
KeepAlive=true
PassCredentials=true

[Install]
WantedBy=sockets.target

sysvinit+rc.d sous debian:

#!/bin/sh

### BEGIN INIT INFO
# Provides:          mpd
# Required-Start:    $local_fs $remote_fs
# Required-Stop:     $local_fs $remote_fs
# Should-Start:      autofs $network $named alsa-utils pulseaudio avahi-daemon
# Should-Stop:       autofs $network $named alsa-utils pulseaudio avahi-daemon
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Music Player Daemon
# Description:       Start the Music Player Daemon (MPD) service
#                    for network access to the local audio queue.
### END INIT INFO

. /lib/lsb/init-functions

PATH=/sbin:/bin:/usr/sbin:/usr/bin
NAME=mpd
DESC="Music Player Daemon"
DAEMON=/usr/bin/mpd
MPDCONF=/etc/mpd.conf

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

if [ -n "$MPD_DEBUG" ]; then
    set -x
    MPD_OPTS=--verbose
fi

PIDFILE=$(sed -n 's/^[[:space:]]*pid_file[[:space:]]*"\?\([^"]*\)\"\?/\1/p' $MPDCONF)

mpd_start () {
    log_daemon_msg "Starting $DESC" "$NAME"

    if [ -z "$PIDFILE" ]; then
        log_failure_msg \
            "$MPDCONF must have pid_file set; cannot start daemon."
        exit 1
    fi

    PIDDIR=$(dirname "$PIDFILE")
    if [ ! -d "$PIDDIR" ]; then
        mkdir -m 0755 $PIDDIR
        if dpkg-statoverride --list --quiet /run/mpd > /dev/null; then
            # if dpkg-statoverride is used update it with permissions there
            dpkg-statoverride --force --quiet --update --add $( dpkg-statoverride --list --quiet /run/mpd ) 2> /dev/null
        else
            # use defaults
            chown mpd:audio $PIDDIR
        fi
    fi

    start-stop-daemon --start --quiet --oknodo --pidfile "$PIDFILE" \
        --exec "$DAEMON" -- $MPD_OPTS "$MPDCONF"
    log_end_msg $?
}

mpd_stop () {
    if [ -z "$PIDFILE" ]; then
        log_failure_msg \
            "$MPDCONF must have pid_file set; cannot stop daemon."
        exit 1
    fi

    log_daemon_msg "Stopping $DESC" "$NAME"
    start-stop-daemon --stop --quiet --oknodo --retry 5 --pidfile "$PIDFILE" \
        --exec $DAEMON
    log_end_msg $?
}

# note to self: don't call the non-standard args for this in
# {post,pre}{inst,rm} scripts since users are not forced to upgrade
# /etc/init.d/mpd when mpd is updated
case "$1" in
    start)
        mpd_start
        ;;
    stop)
        mpd_stop
        ;;
    status)
        status_of_proc -p $PIDFILE $DAEMON $NAME
    ;;
    restart|force-reload)
        mpd_stop
        mpd_start
        ;;
    force-start)
        mpd_start
        ;;
    force-restart)
        mpd_stop
        mpd_start
        ;;
    force-reload)
    mpd_stop
    mpd_start
    ;;
    *)
        echo "Usage: $0 {start|stop|restart|force-reload}"
        exit 2
        ;;
esac

Mon runit à moi, pour le fun, qui est contrôlé par une instance utilisateur de runsvdir (je sais, systemd aussi le peut):

#!/bin/sh

die()
{
    printf "%s\n" "$@" | tee ./down
    exit 1
}

SVNAME="$(basename $(pwd))"
HAS_LOG="$(test -d "$(pwd)/log" && printf "yes")"
exec 0<&-
exec 2>&1
set -xe
test -f conf && . ./conf

if test "$0" = "run"
then
    if test "$SVNAME" = "log"
    then
        SVLOG="$(basename $(dirname $(pwd)))"
        SVNAME="${SVLOG}/${SVNAME}"
        AUTO_ROTATE="${AUTO_ROTATE:="no"}"
    fi
    test "yes" = "${AUTO_ROTATE}" -a "yes" = "$HAS_LOG" && \
        sv alarm "$(pwd)/log"
fi

export DATADIR="/dev/shm/$(id -u)/"

#!/bin/sh

. ../../common

echo "Starting $SVNAME"

exec mpd --no-daemon ~/.config/mpd/mpd.conf --stderr 2>&1

J'ai 7 process avec systemd comme prefixe sur mon portable dans ps fax.
J'ai 114 threads dans le kernel qui apparaissent dans ps fax

Et combien de thread les process systemd ont-ils chacun?
De mémoire quand je m'étais amusé à vérifier ce genre de trucs, ils n'en avaient pas des masses, mais n'ayant pas de systemd sous le coude, je me permets de poser la question.
Il est aussi possible que init ne soit pas préfixé de systemd-, et vu que dans systemd c'est un seul process qui fait, euh… pas mal de choses, ça pourrais biaiser?

Mais logiquement, si on veux réduire la complexité, c'est pas forcément au niveau de l'OS qu'il faut commencer.

Très clairement: c'est au niveau du bureau.
Ensuite viens le système de gestion des daemon (systemd, daemon-tools, runit… peu importe), puis le navigateur web, puis le noyau.
Dans cet ordre, parce qu'il est plus simple de bricoler un bureau qu'un watchdog, ou un watchdog qu'un navigateur, ou un navigateur qu'un kernel.
Le plus bloaté de la liste étant, de loin, le navigateur web.

De toute façon le nombre de processus ou de thread n'indique pas vraiment le taux de bloat d'un système je pense. Ou alors, runit est vraiment très, très, très bloaté:

% pstree -paT | grep -e runsv -e svlogd -e runit | wc -l
50

Il faut savoir que pour chaque daemon qui tourne, j'ai en pratique 3 processus minimum: son gestionnaire, son logger, et le daemon lui-même (plus ses enfants s'il en a).

systemd irais à l'encontre d'un « minimalisme numérique ».

En fait, il suffit de peser les processus pour savoir si tu peux garder les guillemets.
Mesure de la RSS de systemd, puis mesure de la RSS utilisée par un concurrent valable (non, pas sysVinit). Selon mes mesures, qui sont assez vieilles, systemd est clairement plus lourd, d'un ordre de grandeur.
Alors, certes, on parle ici de concurrents dont l'ordre de grandeur est de quelques megs de RSS (si lié dynamiquement à glibc, sinon ce sont quelques centaines de kilos) à systemd qui étais, de mémoire, dans les 30 ou 40 megs.
Je parle ici de "juste systemd-init" comparé à "runit + runsvdir + tous les runsv + tous les svlogd", pour être fair play.
Systemd ayant une augmentation de RSS par nouveau daemon quasi nulle, alors que runit nécessite 2 process par daemon journalisé, chacun pesant 4Kio avec linkage statique ou vers muslc, ou ~650Kio en linkage dynamique glibc.
Systemd dépend, de mémoire, explicitement de glibc, je ne sais pas s'il est possible de lier statiquement.

Évidemment, ces valeurs sont absolument négligeables de nos jours, je ne remets pas ça en cause, mais systemd est clairement plus lourd que sa concurrence.
Il a aussi plus de fonctionnalités, certaines des plus utiles, telles que l'activation par sockets et les dépendances.

Il est donc indéniable que systemd n'est pas minimaliste. Tout comme il est a mon avis indéniable que systemd est meilleur sur tous les points que sysvinit+rc.d (et ce point la pourrais me mener au bûcher, je sais).

le BASH/SH/*SH c'est juste une syntaxe horrible, avec aucune robustesse, et quand quelqu'un le maîtrise bien, le relire c'est juste mission impossible

C'est l'un des rares arguments valables pour systemd, sauf que… ben, les unit systemd ne semblent pas si simples que ça non plus.
Peu importe que ça soit vrai ou pas, peut-être sera-tu intrigué par ces alternatives comme je l'ai été (mais jamais assez pour tester le code sur mes machines perso!):

• dinit, le dernier que j'ai "trouvé" en faisant le zombi sur IRC. Il me semble qu'il utilise une syntaxe déclarative, comme systemd.
• s6 qui utilise son propre DSL, justement parce que comme tu l'as pointé, bourne shell est loin d'être sympa.

Bon, après, mon script runit le plus compliqué, et de très, très loin, c'est celui qui démarre udevd-systemd, programme qui existait bien avant systemd (donc, ses défauts ne proviennent pas de systemd), que voici:

#!/bin/sh
. /etc/runit/common

need()
{
    i=0
    while ! test -e "$1"
    do
        sleep "0.$i"
        test "$i" = 9 || i=$((i+1))
    done
}

mkdir -p /run/udev
rm -f /run/udev/control #just in case
rm -f /run/udevd_ready #just in case
(
    need /run/udev/control # not sure we really need to wait for it
    echo "Trigger+settle:"
    udevadm --debug trigger --type=subsystems --action=add
    udevadm --debug trigger --type=devices --action=add
    udevadm --debug settle
    >/run/udevd_ready
    echo "Done: trigger+settle"
) &

echo "Starting $SVNAME"
exec env - PATH="$PATH" /lib/systemd/systemd-udevd -N late

Quant à sa dépendance, qui est un truc que je source de partout:

#!/bin/sh

#this file provides some automatic features for runit daemons
#notably it:
#* provides the variable SVNAME, which is the name of the daemon dir
#* provides the die() function
#* sources an existing ./conf file
#* automatically rotates logs on startup if there are logs and AUTO_ROTATE=yes
#* redirects stderr to stdout
#* enables some shell verbosity and safeties (-xe)

die()
{
    printf "%s\n" "$@" | tee ./down
    exit 1
}

SVNAME="$(basename $(pwd))"
HAS_LOG="$(test -d "$(pwd)/log" && printf "yes")"
exec 0<&-
exec 2>&1
set -xe
test -f conf && . ./conf

if test "$0" = "run"
then
    if test "$SVNAME" = "log"
    then
        SVLOG="$(basename $(dirname $(pwd)))"
        SVNAME="${SVLOG}/${SVNAME}"
        AUTO_ROTATE="${AUTO_ROTATE:="no"}"
    fi
    test "yes" = "${AUTO_ROTATE}" -a "yes" = "$HAS_LOG" && \
        sv alarm "$(pwd)/log"
fi

On est très loin, je pense, des horribles scripts que l'on vois pour rc.d dans debian, notamment, pas vrai?
D'ailleurs sur ce système j'ai un peu fait les trucs en mode organique, du coup s'pas super clean…

La quasi totalité des autres daemons sont lancés ainsi:

#!/bin/sh

. /etc/runit/common

test -e /run/sshd || mkdir /run/sshd

echo "Starting $SVNAME"
exec /usr/sbin/sshd -D -e

Comme tu le vois, c'est très simple, et ça ne gère pas l'un des autres avantages de systemd: la gestion des dépendances. D'un autre côté, en pratique ce n'est pas gênant, surtout sur un desktop. Je fais aussi tourner mon Xorg de cette façon, mais i3 n'aime pas trop mon humour, il faut que je trouve la motivation pour utiliser un truc un peu moins monolithique pour avoir vraiment ce que je veux. Notamment, avoir les entrées contrôlées par leur propre daemon, au lieu d'avoir le WM qui fait tout: son job, c'est les fenêtres, par les raccourcis clavier, après tout.
Mais bon, je comprend que des gens qui ont autre chose a faire ne s'amusent pas avec ça :) (sur un bureau, du moins)

Ça me parait plus générique et flexible que d'avoir en effet des fichiers de logs spécifiques pour chaque application.

Marrant, j'ai l'opinion exactement inverse (sur cet aspect d'avoir un fichier unique).
Sur le système lui-même, je préfère avoir un processus qui log par processus qui tourne. Comme ça, si l'un des loggers se ramasse, seul ce qu'il faisait est possiblement erroné/corrompu.
Puis, comme centraliser, extraire des données, tout ça, c'est quand même plus simple dans un flux unique, tu as un autre processus qui, lui, va avoir un accès en lecture seule a tous ces fichiers de logs journalisés, et en faire un truc plus simple à utiliser.

Autrement dit, chaque instance de daemon à son propre logger, qui est le seul autorisé à écrire dans son dossier de log. D'autres process sont, en revanche, autorisés à y lire (ça, ça serait l'idéal, en vrai j'ai toujours eu la flemme de faire un user par instance de logger, j'avoue, mais au moins c'est techniquement trivial à faire, et ce depuis facile 20 ans).

Un cas qui m'est arrivé, c'est un daemon qui se met à log BEAUCOUP TROP (sur un système embarqué). Avec un rsyslog, la rotation aurait pourri les logs du système entier (ou alors il aurait fallu une configuration bien capillo-tractée, et je perds assez mes cheveux comme ça).
Avec un stockage dédié par instance, seule une instance voit ses logs détruits par la rotation. Du coup, en analysant les journaux des autres applications qui causaient avec, on a pu avoir des indices pour reproduire et régler le bug.

Le regroupage de log pour en faire un truc plus utile au quotidien, c'est la tâche d'un outil tiers, qui ne détruit pas ses sources de données.
Le jour ou une donnée manque, ça permets d'aller interroger les journaux bruts, avec plus de facilité que s'ils étaient dans un flux unique (puisque par instance).

On peut évidemment me répondre de remonter toutes les données en vrac. Mais ça génère le problème suivant: quid des connexion à volumétrie limitée, type 20 megs / mois?
Réponse: on passe en hors-forfait pour rien.

Gère SIGTERM correctement. Et spécifie quand ton service/application est ready.

Je me demande combien d'applications savent que la seule façon à peu près fiable de gérer les signaux UNIX, c'est le self-pipe?
Et que même le self-pipe peut casser en cas d'utilisation de multi-thread…

Pour le reste, les variables d'environnement pour la config, moi ça me paraît une très mauvaise idée: tu parles d'avoir plusieurs instances d'un daemon dans un environnement, non? Pour la mise en échelle… des paramètres de ligne de commande me paraissent nettement plus simple moi. Qu'ils soient remplis par un programme qui les lise depuis un fichier de conf ou autre chose, peu importe, mais c'est le seul moyen que je voie qui permette d'éviter les collisions.

Ne pas stocker dans des fichiers parce que c'est local, préférer FTP & co? Idem, pas cohérent. Si je stocke dans un fichier "local", ça peut très bien être un montage NFS ou SSHfs, SMB, ou autre. C'est donc bien plus neutre qu'utiliser une base de données, qui elles auront bien souvent leurs p'tites APIs et autres qui diffèrent avec les autres. Ce qui ne veut bien entendu pas dire que les BDD sont à bannir, loin de la, elles ont leur usage.

Dans l'ensemble, de ce que j'ai compris de ce que tu dis, ces 12 "règles" semblent être bien trop vagues pour être utilisables comme règles.

Après des gens qui voient ça comme une religion a ne surtout pas blasphémer, c'est parce que l'humain est un stupide singe overclocké

Selon Tux dans FreedroidRPG, la solution dans ce cas la, c'est de faire boire une bouteille de refroidissant industriel cul-sec à la personne en surchauffe :)

PS: j'avais un peu plus détaillé, mais le brouteur à lamentablement crash, donc j'ai refait en condensé.
J'avais notamment un passage pour tancer tous ces foutus daemons qui croient que le double-fork, le fichier de PID et syslog, c'est l'état de l'art… et qui donc forcent à utiliser l'option --debug quand elles la proposent, pour pouvoir tourner dans un runit, daemon-tools, ou autre du même acabit.
Probablement que les admin du millénaire dernier considéraient que c'est une excellente idée de faire 400 km pour aller rebooter un système, plutôt qu'il ne le fasse de lui-même et essaie d'uploader un rapport sur le problème ou de laisser prendre la main à distance. C'est plus sûr… (et pendant ce temps, un usager est bloqué, possiblement physiquement, possiblement en danger corporel, mais au moins le réseau est en sécurité?)

 un message posté sur un forum l’est instantanément

Sur pas mal de forums, le ou les 1ers messages d'une personne sont en attente de validation… Du coup non?