ariasuni a écrit 3200 commentaires

J’imagine que tu peux ouvrir un rapport de bug.

Écrit en Bépo selon l’orthographe de 1990

Je complète le trou (j’ai oublié de compléter avant d’envoyer):

Ou utiliser systemd qui gère tout ce merdier à ta place tout en te permettant [d’avoir un script lisible et portable].

Écrit en Bépo selon l’orthographe de 1990

D'un pauvre script rc.M ou tu rajoutais ton /usr/local/bin/pg_ctl start -D /pathmabase, maintenant il te faut pondre un script complet start/stop/restart/magrandmereenstring avec des contraintes moisies pour gérer des cas que tu pouvais déjà gérer avant.

T’as pas dû en écrire beaucoup des unités systemd… Je vais prendre l’exemple d’Arch qui proposait un «init à la BSD» que l’on cite souvent ici comme un exemple de bon systèmes d’initialisation.

 kdm.service:

[Unit]
Description=K Display Manager
After=systemd-user-sessions.service

[Service]
ExecStart=/usr/bin/kdm -nodaemon

[Install]
Alias=display-manager.service

ancien script kdm:

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

PID=$(pidof -o %PPID /usr/bin/kdm)
case "$1" in
  start)
    stat_busy "Starting KDE Desktop Manager"
    [ -z "$PID" ] && /usr/bin/kdm &>/dev/null
    if [ $? -gt 0 ]; then
      stat_fail
    else
      add_daemon kdm
      stat_done
    fi
    ;;
  stop)
    stat_busy "Stopping KDE Desktop Manager"
    [ ! -z "$PID" ]  && kill $PID &> /dev/null
    if [ $? -gt 0 ]; then
      stat_fail
    else
      rm_daemon kdm
      stat_done
    fi
    ;;
  restart)
    $0 stop
    sleep 3
    $0 start
    ;;
  *)
    echo "usage: $0 {start|stop|restart}"
esac
exit 0

Un autre au hasard, iptables.service:

[Unit]
Description=Packet Filtering Framework

[Service]
Type=oneshot
ExecStart=/usr/bin/iptables-restore /etc/iptables/iptables.rules
ExecReload=/usr/bin/iptables-restore /etc/iptables/iptables.rules
ExecStop=/usr/lib/systemd/scripts/iptables-flush
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

avec /usr/lib/systemd/scripts/iptables-flush:

#!/bin/bash
#
# Usage: iptables-flush [6]
#

iptables=ip$1tables
if ! type -p "$iptables"; then
  echo "error: invalid argument"
  exit 1
fi

while read -r table; do
  tables+=("/var/lib/$iptables/empty-$table.rules")
done <"/proc/net/ip$1_tables_names"

if (( ${#tables[*]} )); then
  cat "${tables[@]}" | "$iptables-restore"
fi

ancien script iptables.rc:

#!/bin/bash

# source application-specific settings
[ -f /etc/conf.d/iptables ] && . /etc/conf.d/iptables

# Set defaults if settings are missing
[ -z "$IPTABLES_CONF" ] && IPTABLES_CONF=/etc/iptables/iptables.rules

. /etc/rc.conf
. /etc/rc.d/functions

case "$1" in
    start)
        if [ ! -f "$IPTABLES_CONF" ]; then
            echo "Cannot load iptables rules: $IPTABLES_CONF is missing!" >&2
            exit 1
        fi
        stat_busy "Starting IP Tables"
        if [ "$IPTABLES_FORWARD" = "1" ]; then
            echo 1 >/proc/sys/net/ipv4/ip_forward
        fi
        if ck_daemon iptables; then
            /usr/sbin/iptables-restore < $IPTABLES_CONF
            if [ $? -gt 0 ]; then
                stat_fail
            else
                add_daemon iptables
                stat_done
            fi
        else
            stat_fail
        fi
        ;;
    stop)
        stat_busy "Stopping IP Tables"
        if ! ck_daemon iptables; then
            fail=0
            for table in $(cat /proc/net/ip_tables_names); do
                iptables-restore < /var/lib/iptables/empty-$table.rules
                [ $? -gt 0 ] && fail=1
            done
            if [ $fail -gt 0 ]; then
                stat_fail
            else
                rm_daemon iptables
                stat_done
            fi
        else
            stat_fail
        fi
        ;;
    restart)
        $0 stop
        $0 start
        ;;
    save)
        stat_busy "Saving IP Tables"
        /usr/sbin/iptables-save >$IPTABLES_CONF
        if [ $? -gt 0 ]; then
            stat_fail
        else
            stat_done
        fi
        ;;
    *)
        echo "usage: $0 {start|stop|restart|save}"
esac
exit 0

Note au passage la duplication de code pour gérer les commandes start, stop etc et l’affichage de l’usage de la commande. Et des exemples comme ça j’en ai à la pelle. Alors bien sûr tu peux faire ton script shell de deux lignes complètement moisi… Ou utiliser systemd qui gère tout ce merdier à ta place tout en te permettant .

C'est bien le seul argument qui me semble intéressant au sens large dans tout ce qui a été dit pour nous vendre systemd dans ce thread. Ça reste léger et ne me concerne pas.

L’interopérabilité des distributions, point ô combine critiqué, et sûrement le plus gros défaut de l’écosystème de GNU/Linux, ça vaut le pas.

Écrit en Bépo selon l’orthographe de 1990

Donc selon toi, Linux est d'un usage marginal en dehors du serveur

Pas selon moi, selon les stats de user agent de tous les serveurs Web de la planete.
Android n'est pas Linux en tant qu'OS : c'est linux en tant que noyau. D'ailleurs, je n'ai pas l'impression que systemd soit à l'ordre du jour.

Pourquoi limiter à GNU/Linux? systemd ne dépend que de Linux à ce que je sache. Et on pourrait très bien imaginer que Android passe à systemd, et il y aura sûrement des systèmes d’exploitation mobile avec systemd à l’intérieur qui vont débarquer (Ubuntu Touch, Jolla…).

il faudrait empêcher d'agir ceux qui veulent le rendre plus accessible

Excuse moi, mais j'ai du mal a voir ce que viens faire dans l'accessibilité un gestionnaire de boot, lanceur de services réseau et autre joyeusetés bien loin des préoccupations de l'utilisateur lambda qui ne veut pas aligner 2 lignes de code

Rendre un système plus accessible, ça veut dire:

• plus rapide
• plus sécurisé
• plus automatisé

Oh magie, c’est ce que fait systemd en démarrant les services en parallèles (et le reste il y a des exemples dans la dépêches).

Pourquoi le séparer du reste

Parce que partout en informatique on considère comme bonne pratique de séparer les choses qui n'ont pas le même rôle ?
Il me semble qu'il y a des différences entre démarrer des services réseau à la demande, effectuer des taches à temps défini, monter des périphériques ou configurer des interfaces réseau. Apparemment la modernité considère que non :D

Source de systemd. Oh c’est magnifique, plein d’utilitaires qui font une chose et qui le font bien, qui combiné entre eux font un logiciel complet appelé systemd.

Pourquoi vouloir d'un bidouillage

L'init d'un Unix un bidouillage ? Une sacrée bidouille alors… Que dire alors de tout le reste !

Peut-être pas quand il a été créé. Mais comme expliqué plusieurs fois dans les commentaires par moi-même et d’autres, il a beaucoup de défauts qui était réglé par systemd, ou alors il faisait les mêmes choses de manière beaucoup plus propre puisque les mainteneurs l’on choisi en remplacement.

lorsqu'on peut intégrer proprement

Proprement ? Dans un SPOF

Source?

nécessitant une maitrise poussée du bousin pour savoir ce qu'il va faire implicitement ? Moi qui croyait que l'implicite n'était pas vraiment une bonne chose dans un système un tantinet complexe…

En quoi c’est implicite? Pour le lancement par socket il y a des unités .socket, pour un lancement au démarrage il y a des .service.

une prise en charge officielle

Officielle de quoi ?

Du démarrage par socket.

Source?

Pour la définition, je te donne la mienne afin d'avoir une base de discussion, si tu en as une : envoie.

Non, la définition je l’ai recopié parce que j’ai répondu paragraphe par paragraphe.

Quand à démarrer apache/php et mysql, ça tient avec une ligne par commande, donc pas 3 comme j'ai dit mais 2 (si tu utilises mod_php).
Mais il est vrai que c'est beaucoup plus compliqué à force de vouloir faire des trucs qui prennent en compte les cas particuliers de chaque installation / distribution.

En quoi c’est plus compliqué avec systemd?

Écrit en Bépo selon l’orthographe de 1990

Leaky abstractions. Il aurai mieux fallu ne rien abstraire du tout, tout expliciter et tout rendre configurable. Les systèmes magiques c'est peut-être mignons pour les desktop, mais ça n'a rien à faire sur un serveur.

systemd est flexible, il ne t’empêche pas faire ta configuration perso. Mais il offre des options sympathique pour les usages courants.

Le problème, c'est juste que beaucoup de ces contraintes posent des problèmes au niveau du démarrage. Le service buggé qui supporte pas les changement d'heure doit être lancé après un ntpdate, et aucun autre logiciel ne doit changer l'heure après que l'autre ai démarré. Pareil pour l'autre contrainte qui implique de connaître tout les cwd des processus et les fichiers qu'ils peuvent garder ouvert.

En quoi c’est pas possible avec systemd?

Ça veut dire regarder absolument tout les logiciels qui tournent (même l'init) et savoir ce qu'ils font tous. S'il font tous ce que je demande, c'est cool. S'ils ne font pas ce que je demande, il va falloir que je les patche, et je préfère patcher du shell script plutôt que de patcher du C.

On peut modifier toutes les unités systemd et les surcharger avec d’autres fichiers, donc je vois absolument pas pourquoi tu aurais besoin de patcher le système d’init (à moins qu’il soit codé avec le cul). C’est bien ça l’avantage avec systemd: on est pas obligé de toucher au code pour le faire fonctionner comme on veut.

Écrit en Bépo selon l’orthographe de 1990

Ceci étant dit, le problème n'est pas tant que systemd existe, mais que d'autres softs de plus haut niveau se basent uniquement dessus, rompant donc avec la portabilité POSIX/UNIX. Donc par exemple si GNOME décide de se baser sur systemd, mais sans offrir une couche de compatibilité "dégradée", je trouve ça extrêmement gênant, et ce, même si personnellement je n'ai plus touché de BSD depuis quelques années.

Faut se plaindre à GNOME pour qu’ils fournissent un mode dégradé et/ou à ta distribution pour qu’ils implémentent l’API comme le fait faisait Ubuntu. Ou tu n’as qu’à utiliser KDE. :p

Écrit en Bépo selon l’orthographe de 1990

Ce n’était pas évident pour moi non plus. Mais je suis un peu neuneu.

Bah vu que systemd ne comprends ni les descriptions en anglais ni les pages de man, ces métadonnées ne pouvait être destinées qu’à un outil client…

Pour l’avantage, certaines distribution utilise aussi des « runlevels » nommé, oups, ce n’est pas une exclusivité.

Je ne savais pas. Source? Dans tous les cas, dépend des distributions (comme la définition des runlevels d’ailleurs), tandis que les cibles de systemd sont bien flexibles et bien définies.

Ton script non plus. L'endroit est le même sur toutes les distributions pour systemd. Léger avantage systemd encore une fois.

Ben si, /etc/init.d/

Bah sous Arch Linux c’était dans /etc/rc.d/ par exemple.

Écrit en Bépo selon l’orthographe de 1990

Perso, je ne comprend pas ce que font les 2eme, 3eme et dernière lignes.

2e et 3e ligne c'est pour systemctl ça me parait évident.

La dernière ligne, c'est pour indiquer l'équivalent du runlevel (mais bien plus puissant) côté systemd. Sauf qu'au lieu d'avoir des numéros imbitables, on a directement le nom. Léger avantage systemd.

Ensuite, ce fichier je ne sais pas où le mettre.

Ton script non plus. L'endroit est le même sur toutes les distributions pour systemd. Léger avantage systemd encore une fois.

Donc non ce n'est pas limpide : il faut se taper une doc supplémentaire \o/

En connaissant simplement le principe des cibles (target) de systemd, on devine facilement ce que fait l'unité. Par contre le script est cryptique, même si on sait on peut oublier, c'est plus dur avec des champs bien nommés.

Écrit en Bépo selon l’orthographe de 1990

Or, le desktop c'est marginal pour linux. […] Or, le cas général d'utilisation de Linux (l'OS) c'est le serveur […]

Donc selon toi, Linux est d'un usage marginal en dehors du serveur (Ubuntu? SteamOS? Android?), et il faudrait empêcher d'agir ceux qui veulent le rendre plus accessible?

Or, globalement, en info, on va vers l'intégration de fonctionnalités qui n'ont rien a faire dans le soft (par ex : inetd fusionné avec le gestionnaire de boot dans le cas systemd) et on a tendance a présenter ça comme un progrès : désolé de ne pas être d'accord.

Un gestionnaire de service et un système pour démarrer les services à la demande ça n'a rien à voir? Pourquoi le séparer du reste si c'est utilisé partout danr systemd et que ça permet d'avoir une syntaxe simple? Pourquoi vouloir d'un bidouillage lorsqu'on peut intégrer proprement avec une prise en charge officielle toutes les fonctionnalités d'un gestionnaire de service moderne dans le gestionnaire de service?

Une usine a gaz c'est un truc qui nécessite trop de ressources pour le mettre en œuvre par rapport à l'usage qui en est fait. S'il faut se palucher en plus la doc de systemd pour démarrer 3 pauvres services sur un LAMP alors que 3 lignes de shell suffisent, alors c'est une usine a gaz.

Source?

Écrit en Bépo selon l’orthographe de 1990

Je n'ai pas rencontré ce problème avec un Samsung Galaxy S2. Pour Firefox, je pense que c'est dû à la police par défaut, Clear Sans.

Tu peux fournir une capture d'écran, qu'on se fasse une idée de la taille du texte?

Écrit en Bépo selon l’orthographe de 1990

Oui, enfin, dans les deux cas, si tu veux vraiment savoir, il faut lire la doc, histoire de savoir exactement ce que tu fais.

Je vois pas, vraiment. On peut difficilement faire plus limpide que l'exemple cité.

[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
# démarrer après l'initialisation du réseau
After=network.target

# on sait tout de suite quand est exécutée chaque commande
[Service]
ExecStart=/usr/sbin/named -f -u bind
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

# Unité démarrée pour la cible «multi-user», donc lors d'un démarrage normal.
[Install]
WantedBy=multi-user.target

Écrit en Bépo selon l’orthographe de 1990

Visiblement ce n'est pas ce qu'on a décidé chez les dévs de PA. Ils ont décidé que passer à la lib suivante c'est mieux et tant pis si les utilisateurs se retrouvent avec une put… de régression.

Est-ce que tu peux lire la dépêche s'il te plait? PulseAudio 5 est compatible BlueZ 4 et BlueZ 5.

Écrit en Bépo selon l’orthographe de 1990

Bon en fait c’est bien un problème de KDE parce que ça marche sous GNOME, et j’ai pu le régler en faisant (en root):

sudo echo 'Y' > /sys/module/video/parameters/brightness_switch_enabled

Écrit en Bépo selon l’orthographe de 1990

qui doit être plus court et lisible que l'unit de systemd

Euh?

. /etc/rc.d/rc.subr

Uh?

pexp="named: [priv]"

Uh??

rc_cmd $1

Uh???

Dans l’unité systemd, on comprend clairement à quoi sert chaque ligne. Là, visiblement non.

Écrit en Bépo selon l’orthographe de 1990

On peut résumer tout ça à:

With great power comes great responsibility.
(Stan Lee)

Écrit en Bépo selon l’orthographe de 1990

C’est clairement indiqué que c’est pour les configurations simples.

Écrit en Bépo selon l’orthographe de 1990

Tu sais que tu peux t’améliorer au fil du temps? Tu sais que tu peux avoir fait un peu de la merde une fois et faire un truc pas mal voire bien ensuite? Tu sais que Lennart Poettering n’est pas le seul à bosser sur systemd, mais qu’il y a des dizaines et des dizaines de développeurs qui bossent dessus?

Écrit en Bépo selon l’orthographe de 1990

Première capture:

Deuxième capture:

Note également le «Ce contenu est-il ou ?». Les mots «pertinent» et «inutile» ont disparu depuis 1 ou 2 jours (je suppose depuis la dernière modification que tu mentionnes), que ça soit sur le navigateur d’Android ou Firefox mobile (mais même en redimensionnant la vue sur bureau je n’ai pas ce comportement).

Note: sur les captures ce n’est pas le navigateur par défaut d’Android mais c’est il utilise le même moteur, de ce fait les comportements sont identiques (j’ai testé).

Écrit en Bépo selon l’orthographe de 1990

Quand je modifie la luminosité avec xbacklight ça fonctionne correctement, je pense que KDE ne détecte pas le changement de luminosité parce qu’il vient du BIOS. Ou un truc comme ça.

Écrit en Bépo selon l’orthographe de 1990

Tu te rends compte que tu juges la qualité du code de systemd en regardant celui d'Avahi?

Écrit en Bépo selon l’orthographe de 1990

Si par "luminosité" vous parlez de la backlight

Bah si je le modifie avec les touches du clavier, il y a pas trente milles possibilités.

de la doc peut être trouvée ici. Cela dit, contrairement à ce qui est dit sur le Wiki, on peut avoir à la fois un dossier intel_backlight et acpi_video0 avec une carte Intel. Les deux contiennent des fichiers gérant la backlight et peuvent faire effet. Cependant, les modification de la backlight dans le dossier acpi_video0 sont pris en compte dans le dossier intel_backlight, mais le contraire non.
Si lors du réglage de la backlight le DE ne voit pas e différence de niveau, je dirais que c'est parce qu'il surveille le mauvais fichier.

Merci pour ces infos, je jetteraient à nouveau un œil sur ce problème un peu plus tard.

Écrit en Bépo selon l’orthographe de 1990

systemd n'est pas un/ne possède pas de remplaçant à iptables car ça n'a rien a voir, si ce n'est que l'on peut activer l'unité iptables pour charger ses règles iptables au démarrage.

Écrit en Bépo selon l’orthographe de 1990

1. Quand je change la luminosité, dans le plasmoïde le niveau indiqué ne change.
2. Je ne sais pas si ça a un rapport avec systemd.

Écrit en Bépo selon l’orthographe de 1990

Quand j'augmente ou diminue la luminosité avec les touches de l'ordi, KDE crois que je suis toujours à l'ancienne luminosité.

Écrit en Bépo selon l’orthographe de 1990

Pas sur Arch Linux visiblement.

Écrit en Bépo selon l’orthographe de 1990