Journal Remède au problème démarrage devuan ascii sur raspberry pi 2

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
2
15
jan.
2019

Un petit post pour partager avec vous la résolution d'un petit problème que j'ai rencontré en voulant installer devuan ascii sur mon raspberry pi 2.
J'ai tenté de télécharger l'image adéquate et de l'écrire sur une carte SD, mais une fois la carte insérée dans le raspberry pi, elle ne lui a pas permis de démarrer.

A cet instant, je doutais que le problème vienne de ma carte puisqu'elle m'avait déjà permis de démarrer freebsd.

Du coup je m'y suis pris autrement: j'ai téléchargé l'image de la précédente version, et écrit celle-ci sur ma carte SD. Mon raspberry a correctement démarré.

Ensuite, j'ai effectué un upgrade de version comme indiqué ici; j'ai ajouté ces 4 lignes dans /etc/apt/sources.list et commenté les autres :

deb http://deb.devuan.org/merged ascii main
deb http://deb.devuan.org/merged ascii-updates main
deb http://deb.devuan.org/merged ascii-security main
deb http://deb.devuan.org/merged ascii-backports main

J'ai continué avec un apt-get update, mais j'ai eu un problème de clé GPG (je n'ai plus le message exact, je l'ai perdu dans mon terminal) que j'ai corrigé en adaptant ceci:

gpg --keyserver pgpkeys.mit.edu --recv-key BB23C00C61FC752C | gpg -a --export BB23C00C61FC752C | sudo apt-key add -

J'ai relancé apt-get update, puis apt-get dist-upgrade et un reboot après, je me trouve avec une devuan ascii toute propre.

Je vais en profiter pour faire quelques petites personnalisation, exécuter un apt-get clean et un peu de nettoyage autre, et je récupèrerai la carte SD pour en faire une image réutilisable ultérieurement.

Voila, j'espère que ce petit post pourra servir à d'autres. Sur ce, bonne nuit.

  • # Devuan

    Posté par  . Évalué à 10.

    La solution est simple ! Cesser d’utiliser des OS maintenus par 3 rageux au fond d’un garage et utiliser un OS sérieux, comme Debian.

    Comment ça on est pas vendredi ?

    Ok je => []

    • [^] # Re: Devuan

      Posté par  . Évalué à 3. Dernière modification le 16 janvier 2019 à 09:00.

      Bah, si on écoutait ce genre de discours, jamais il n'y aurait eu d'alternative à Windows, Unix proprios, Mac OS, etc …

      Et pour tout dire, si je n'avais pas eu besoin d'accéder à un disque dur externe utilisant XFS, j'aurais utilisé un système réellement sérieux : freeBSD. Et il est fort probable que d'ici quelques temps je me penche sur l'utilisation de slackware pour remplacer devuan.

      Enfin, utiliser une distribution basée sur un truc qui ressemble de plusen plus à un bloatware immonde (systemd pour ne pas le nommer), ben non, merci. Après chacun fait ce qu'il veut, mais en tout casje remercie les fameux "rageux au fond d'un garage" pour le travail qu'ils font, afin de satisfaire ce qui ne sont pas satisfaits de systemd.

      • [^] # Re: Devuan

        Posté par  . Évalué à 6. Dernière modification le 16 janvier 2019 à 11:34.

        D'accord pour le côté bloat des distro actuelles mais bon Devuan,si on n'arrive déjà pas à passer l'installeur ce qui a aussi été mon cas sur mon PC x86-64, ben ça la fout mal.

        Une distro Linux LTS sans systemd, yep, ça devient dur à trouver.

        pu****, 9 ans déjà qu'on radote sur le même truc et pas d'alternative, faut se rendre à l'évidence, non?

        Ou alors tout le monde est sur OSX ou Win10 et utilisent linux simplement au travers de docker?

        meh.

        ps:
        Et pourtant, j'éspèrais que le bidule resolve des trucs plutôt que de me faire chier: cf. les timeouts infini, gdm/lightdm/et_tutti_bordel,…

        pps: Sérieusement, est-ce que ce renommage d'interface réseau vous a vraiment facilité la vie? Je sais qu'on peut le changer mais ça ne marche que pour ethernet et non le wlan :)

        • [^] # Re: Devuan

          Posté par  . Évalué à 4.

          pu****, 9 ans déjà qu'on radote sur le même truc et pas d'alternative, faut se rendre à l'évidence, non?

          Quid de devuan, slackware, ainsi que des xBSD ? Sinon il était possible jusqu'à relativement récemment de virer systemd d'une debian (c'est ce que j'ai fait sur mes rpi et les raspbian), je ne sais pas si ça peut encore se faire.

          Et non, je ne suis pas du genre à me résigner. S'il y a des alternatives à systemd qui me conviennent, je les soutiendrai. D'ailleurs, j'ai fait un don a Devuan pour les soutenir.

          Et pourtant, j'éspèrais que le bidule resolve des trucs plutôt que de me faire chier: cf. les timeouts infini, gdm/lightdm/et_tutti_bordel,…

          Je me sens moins seul …

          Sérieusement, est-ce que ce renommage d'interface réseau vous a vraiment facilité la vie? Je sais qu'on peut le changer mais ça ne marche que pour ethernet et non le wlan :)

          Moi ça ne m'a pas choqué plus que ça, j'étais habitué a ce genre de nommage avec xBSD et Solaris.

          • [^] # Re: Devuan

            Posté par  . Évalué à 4.

            Quid de devuan, slackware, ainsi que des xBSD ?

            • Ben Devuan j'ai expliqué, on pourrait certes excuser mais pour moi, l'installer doit être irréprochable.

            • slackware: Peter est gentil mais tout une distribution à lui tout seul et il me faut un pkg manager. La quantité n'est certes pas gage de qualité mais 1 seule personne…

            • freeBSD: austères et avec son lot de workaround et un firefox à la ramasse.

            • OpenBSD: manque de support matériel et firefox aussi à la ramasse.

            Le nommage d'interface sur BSD et solaris est tout de même plus prédictible/intuitif.

          • [^] # Re: Devuan

            Posté par  . Évalué à 5. Dernière modification le 16 janvier 2019 à 12:53.

            il était possible jusqu'à relativement récemment de virer systemd d'une debian

            On peut toujours sur la stable actuelle.

            Quid de devuan, slackware, ainsi que des xBSD ?

            Y'a voidlinux aussi, qui est pas mal et qui, contrairement à devuan, ne se base pas sur rc.d (parce que le problème de base, c'est pas sysV, c'est rc.d qui fait semblant de gérer alors qu'il sert quasi à rien).

            est-ce que ce renommage d'interface réseau vous a vraiment facilité la vie?

            Ça dépend des cas. Le cas ou je trouve ça plus simple c'est quand un système dispose de plus d'un connecteur Ethernet: pas besoin de tester au hasard sur quel connecteur il faut brancher le câble (dans mon cas, les interfaces ne sont pas sur le même réseau physique).
            Dans le cas ou il n'y a qu'une seule interface, forcément, le fait que le nom change d'un type de machine à un autre, c'est une gêne: vu qu'il n'y a qu'une seule interface, on s'en fout que le nommage soit déterminé par le branchement (bus, port, etc) et la convention (câble = eth, on part de 0) simplifie la vie.

            • [^] # Re: Devuan

              Posté par  . Évalué à 1. Dernière modification le 16 janvier 2019 à 14:51.

              Y'a voidlinux aussi, qui est pas mal et qui, contrairement à devuan, ne se base pas sur rc.d (parce que le problème de base, c'est pas sysV, c'est rc.d qui fait semblant de gérer alors qu'il sert quasi à rien).

              Quel est le problème avec rc.d ?

              • [^] # Re: Devuan

                Posté par  . Évalué à 8.

                rc.d se contente de lancer les daemons dans un ordre précis, défini par le nom du fichier.
                Ce qui veut dire (si je ne me trompe pas):

                • pas de gestion des dépendances (par example, sur ma Debian, ssh ne vérifie pas que le réseau est accessible);
                • démarrage des daemon en série, ce qui freine le démarrage du système (debian à bien un paquet starpar, mais il a beau être installé, si jamais je n'ai pas de DHCP le boot mets 3 plombes juste à cause de ça…);
                • si un daemon tombe, il n'est pas relancé automatiquement;
                • c'est une question de goût, mais, sérieux, 108 lignes de bourne shell pour gérer mpd (c'est un example, et je n'inclue pas les fichiers inclus)?
                • double fork: les process doivent s'échapper sinon le démarrage est bloqué…

                La plupart des distros ont opté pour systemd, personnellement je préfère runit (malgré que gérer les inter-dépendances soit pénible, il faut que je teste nosh pour ça).

                Pour info, avec rc.d, le script Debian pour lancer isc-dhcp-server (non, ce n'est pas le pire, juste 1 au hasard):

                #!/bin/sh

### BEGIN INIT INFO
# Provides:          isc-dhcp-server
# Required-Start:    $remote_fs $network $syslog
# Required-Stop:     $remote_fs $network $syslog
# Should-Start:      $local_fs slapd $named
# Should-Stop:       $local_fs slapd
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: DHCP server
# Description:       Dynamic Host Configuration Protocol Server
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin

test -f /usr/sbin/dhcpd || exit 0

DHCPD_DEFAULT="${DHCPD_DEFAULT:-/etc/default/isc-dhcp-server}"

# It is not safe to start if we don't have a default configuration...
if [ ! -f "$DHCPD_DEFAULT" ]; then
    echo "$DHCPD_DEFAULT does not exist! - Aborting..."
    if [ "$DHCPD_DEFAULT" = "/etc/default/isc-dhcp-server" ]; then
        echo "Run 'dpkg-reconfigure isc-dhcp-server' to fix the problem."
    fi
    exit 0
fi

. /lib/lsb/init-functions

# Read init script configuration
[ -f "$DHCPD_DEFAULT" ] && . "$DHCPD_DEFAULT"

NAME4=dhcpd
NAME6=dhcpd6

DESC4="ISC DHCPv4 server"
DESC6="ISC DHCPv6 server"

# use already specified config file or fallback to defaults
DHCPDv4_CONF=${DHCPDv4_CONF:-/etc/dhcp/dhcpd.conf}
DHCPDv6_CONF=${DHCPDv6_CONF:-/etc/dhcp/dhcpd6.conf}

# try to read pid file name from config file or fallback to defaults
if [ -z "$DHCPDv4_PID" ]; then
    DHCPDv4_PID=$(sed -n -e 's/^[ \t]*pid-file-name[ \t]*"\(.*\)"[ \t]*;.*$/\1/p' < "$DHCPDv4_CONF" 2>/dev/null | head -n 1)
fi
if [ -z "$DHCPDv6_PID" ]; then
    DHCPDv6_PID=$(sed -n -e 's/^[ \t]*dhcpv6-pid-file-name[ \t]*"\(.*\)"[ \t]*;.*$/\1/p' < "$DHCPDv6_CONF" 2>/dev/null | head -n 1)
fi
DHCPDv4_PID="${DHCPDv4_PID:-/var/run/dhcpd.pid}"
DHCPDv6_PID="${DHCPDv6_PID:-/var/run/dhcpd6.pid}"

test_config()
{
    VERSION="$1"
    CONF="$2"

    if ! /usr/sbin/dhcpd -t $VERSION -q -cf "$CONF" > /dev/null 2>&1; then
        echo "dhcpd self-test failed. Please fix $CONF."
        echo "The error was: "
        /usr/sbin/dhcpd -t $VERSION -cf "$CONF"
        exit 1
    fi
}

check_status()
{
        OPTION="$1"
        PIDFILE="$2"
        NAME="$3"

        if [ ! -r "$PIDFILE" ]; then
                test "$OPTION" != -v || echo "$NAME is not running."
        return 3
        fi

        if read pid < "$PIDFILE" && ps -p "$pid" > /dev/null 2>&1; then
        test "$OPTION" != -v || echo "$NAME is running."
        return 0
        else
        test "$OPTION" != -v || echo "$NAME is not running but $PIDFILE exists."
        return 1
        fi
}

start_daemon()
{
    VERSION="$1"
    CONF="$2"
    NAME="$3"
    PIDFILE="$4"
    DESC="$5"

    shift 5
    INTERFACES="$*"

    test_config "$VERSION" "$CONF"
    log_daemon_msg "Starting $DESC" "$NAME"

    if [ -e "$PIDFILE" ]; then
        log_failure_msg "dhcpd service already running (pid file $PIDFILE currenty exists)"
        exit 1
    fi

    touch /var/lib/dhcp/$NAME.leases

    start-stop-daemon --start --quiet --pidfile $PIDFILE \
        --exec /usr/sbin/dhcpd -- $VERSION -q -cf $CONF $INTERFACES
    sleep 2

    if check_status -q $PIDFILE $NAME; then
        log_end_msg 0
    else
        log_failure_msg "check syslog for diagnostics."
        log_end_msg 1
        exit 1
    fi
}

stop_daemon()
{
    if check_status -q $DHCPDv4_PID $NAME4; then
        log_daemon_msg "Stopping $DESC4" "$NAME4"
        start-stop-daemon --stop --quiet --pidfile $DHCPDv4_PID
        log_end_msg $?
        rm -f "$DHCPDv4_PID"
    fi

    if check_status -q $DHCPDv6_PID $NAME6; then
        log_daemon_msg "Stopping $DESC6" "$NAME6"
        start-stop-daemon --stop --quiet --pidfile $DHCPDv6_PID
        log_end_msg $?
        rm -f "$DHCPDv6_PID"
    fi
}

case "$1" in
    start)
        if test -n "$INTERFACES" -a -z "$INTERFACESv4"; then
                        echo "DHCPv4 interfaces are no longer set by the INTERFACES variable in" >&2
                        echo "/etc/default/isc-dhcp-server.  Please use INTERFACESv4 instead." >&2
                        echo "Migrating automatically for now, but this will go away in the future." >&2
                        INTERFACESv4="$INTERFACES"
        fi
        if test -n "$INTERFACESv4"; then
            echo "Launching IPv4 server only."
            start_daemon "-4" "$DHCPDv4_CONF" "$NAME4" \
                "$DHCPDv4_PID" "$DESC4" "$INTERFACESv4"
        fi
        if test -n "$INTERFACESv6"; then
            echo "Launching IPv6 server only."
            start_daemon "-6" "$DHCPDv6_CONF" "$NAME6" \
                "$DHCPDv6_PID" "$DESC6" "$INTERFACESv6"
        fi
        if test -z "$INTERFACESv4" -a -z "$INTERFACESv6"; then
            echo "Launching both IPv4 and IPv6 servers (please configure INTERFACES in /etc/default/isc-dhcp-server if you only want one or the other)."
            start_daemon "-4" "$DHCPDv4_CONF" "$NAME4" \
                "$DHCPDv4_PID" "$DESC4" ""
            start_daemon "-6" "$DHCPDv6_CONF" "$NAME6" \
                "$DHCPDv6_PID" "$DESC6" ""
        fi
        ;;
    stop)
        stop_daemon
        ;;
    restart | force-reload)
        $0 stop
        sleep 2
        $0 start
        if [ "$?" != "0" ]; then
            exit 1
        fi
        ;;
    status)
        if test -n "$INTERFACES" -a -z "$INTERFACESv4"; then
                        INTERFACESv4="$INTERFACES"
        fi
        if test -n "$INTERFACESv4"; then
            echo -n "Status of $DESC4: "
            check_status -v $DHCPDv4_PID $NAME4 || exit $?
        fi
        if test -n "$INTERFACESv6"; then
            echo -n "Status of $DESC6: "
            check_status -v $DHCPDv6_PID $NAME6 || exit $?
        fi
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|force-reload|status}"
        exit 1
esac

exit 0

                Le fichier run de voidlinux pour dhcpd:

                #!/bin/sh
[ -r conf ] && . ./conf
mkdir -p /var/lib/dhcp/
touch /var/lib/dhcp/dhcpd.leases
exec dhcpd -f ${OPTS:=-4 -q -pf /run/dhcpd4.pid}

        • [^] # Re: Devuan

          Posté par  (site web personnel) . Évalué à 9.

          pu****, 9 ans déjà qu'on radote sur le même truc et pas d'alternative, faut se rendre à l'évidence, non?

          Quand tu écris "se rendre à l'évidence", tu veux dire "se rendre à l'évidence qu'en vrai systemd ça fonctionne bien", c'est bien ça ?

          • [^] # Re: Devuan

            Posté par  . Évalué à 1.

            pu****, 9 ans déjà qu'on radote sur le même truc et pas d'alternative, faut se rendre à l'évidence, non?

            Quand tu écris "se rendre à l'évidence", tu veux dire "se rendre à l'évidence qu'en vrai systemd ça fonctionne bien", c'est bien ça ?

            Entre autre mais qu'aussi rien ne nous fera revenir en arrière.

            Tout systemd n'est pas à jeter, il y a des choses de supervisions qui sont bienvenues MALHEUREUSEMENT dans le cas oú j'ai eu des services recalcitrants, systemd ne m'a jamais aidé et m'a même posé problème avec ses timeouts sans fin et autres services impactés par un truc tout con: ie GDM - dont le service ne porte pas le nom et ne se désactivant pas via systemctl - qui timeout sans fin parce que l'utilisateur avec lequel il devait se logguer avait disparu: zero entrée dans les logs ou stdout, ni audit. C'est en repassant dans tous les fichiers de config que j'ai trouvé le problème.

            Mais journald, la gestion de dépendances tout ça ne m'a aucunement aidé. :/

            • [^] # Re: Devuan

              Posté par  . Évalué à 2.

              rien ne nous fera revenir en arrière.

              Pas même un watchdog qui fasse son job efficacement? Parce que de ce que tu dis, systemd est une vraie merde. Je cite:

              j'ai eu des services recalcitrants, systemd ne m'a jamais aidé et m'a même posé problème

              Pourtant systemd prétend pouvoir tout gérer.

              GDM - dont le service ne porte pas le nom et ne se désactivant pas via systemctl

              GDM… c'est le gestionnaire de session de gnome, non? L'un des DE qui dépendent le plus de systemd je crois?

              qui timeout sans fin

              Tu n'avais, j'imagine, pas accès aux TTY classiques? Il est ou le chargement à la demande? Voire en parallèle?

              zero entrée dans les logs ou stdout, ni audit. C'est en repassant dans tous les fichiers de config que j'ai trouvé le problème.

              Tu sembles dire que les fichiers de conf de systemd sont compliqués à comprendre, pourrais-tu détailler?

              Mais journald, la gestion de dépendances tout ça ne m'a aucunement aidé. :/

              C'est tout de même dommage, journald à pour seul et unique rôle de journaliser les évènements. L'échec du démarrage d'un binaire est la première chose que je loggue quand j'écrit un logiciel… un truc du style

              if( -1 == foobar( ... ) )
{
//si fonction systeme
  fprintf( stderr, __FILE__ "[%d]:\t%s\n", __LINE__, strerror( errno ) );
//sinon expliciter le pre-requis qui a foire
  return false;
}

              Si les types qui s'amusent à faire des allocations dynamiques en boucle sur la stack (c'est pas vraiment la 1ère faille de sécurité avec journald…) sont pas foutus d'utiliser ce genre de trucs, ça fait quand même peur, non? Je veux dire, je suis loin d'être un dev exceptionnel après tout…

              Désolé pour le troll, mais je trouve ta position très amusante. Oui, systemd a de bonne idées. Surtout une: la configuration déclarative. Le reste est trop bordélique, essaie trop de faire le café, et c'est bien le reste qui fait que compte rester le plus loins possible de ce machin.

              • [^] # Re: Devuan

                Posté par  (site web personnel) . Évalué à 10.

                Ok ok, on se paluche sur un cas qui n'a pas marché, avant tellement peu de détails qu'en vrai on ne peut rien en dire.

                Mais en vrai, ce sont quoi les problèmes ?
                Je vais le faire dans l'autre sens. Toutes les machines que j'ai (que j'ai ou tous les serveurs que je lance au taff, et on doit en lancer grosso modo une centaine par jour) sont avec systemd (j'ai même eu du fleet). Et systemd est juste un élément clé. Les services, la gestion de dépendance entre les services, les drop-in pour overrider de la conf, les notifs entre service, journald avec des exporteurs type journalbeat, les logs docker avec driver journald, etc.

                Bref pour le moment, en dehors des trolls sur des cas particuliers, j'ai toujours pas vu en quoi c'était le mal et pourquoi il faudrait s'en éloigner alors que ça juste marche bien.

                Ok, le seul vrai problème que j'ai eu c'est quand Coreos a décidé sur une release mineur de changer la config du format de stockage des logs, qui était incompatible avec ma version courante de journalbeat. De là à incriminer systemd…

                • [^] # Re: Devuan

                  Posté par  . Évalué à 0.

                  Je n'ai pas dis que c'était le mal et qu'il fallait en partir, j'ai même dit que c'est préférable à rc.d.

                  Je pense qu'il adresse bien une grande classe de problèmes, mais comme toutes les solutions il n'est pas parfait, alors il faut arrêter de le mettre sur un piédestal.

                  Quand j'ai lu "rien ne nous fera revenir en arrière" dans le contexte, j'ai compris "systemd forever", c'est du fanatisme, surtout quand celui qui me fait comprendre ça liste une série de problèmes qu'il a eus, factuellement.

                  Par contre, je trouve l'idée d'utiliser des outils pour allouer sur la pile une super mauvaise idée en général, et en particulier pour un logiciel qui tourne en tant que root, accessible via le réseau.

                  Ok, le seul vrai problème que j'ai eu c'est quand Coreos a décidé sur une release mineur de changer la config du format de stockage des logs, qui était incompatible avec ma version courante de journalbeat. De là à incriminer systemd…

                  Ça, c'est clairement pas imputable à systemd, je manque de mauvaise foi sur ce coup :)
                  On pourrait à la rigueur leur repprocher un versionning qui ne parle pas (juste un nombre entier qui s'incrémente, si je ne m'abuse), mais bon, avant de mettre à jour un élément clé, on lit les release note pour moi, donc c'est clairement pas systemd le problème ici.

                  • [^] # Re: Devuan

                    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 18 janvier 2019 à 06:25.

                    On peut lister une série de problème sur à peu près tout, y compris des supers logiciels dont on est "fanatique", ça s'appelle garder son sens critique, c'est pas pour ça que ce sont de mauvais logiciels.

                    Concernant SystemD, je l'utilise depuis 2011, et en tant que développeur, j'en suis très heureux et je pense même que son architecture est une simplification de la situation précédente (c'est dire si j'en suis fan).

                    Je comprends les sceptiques, SysV (et consort) est satisfaisant pour les administrateurs, qui connaissent bien leur système (contrairement aux développeurs). Et à partir du moment où ça juste marche, pourquoi vouloir changer ..

                    C'est la même chose pour D-Bus aussi : un administrateur n'en veut pas, sa machine se configure via des fichiers textes, depuis toujours, alors à quoi ça sert, puis moins il y a d’événements mieux on se porte … à l'inverse un développeur aura besoin de connaitre des événements, et scanner des fichiers c'est clairement pas optimal. D-Bus ne sert quasiment à rien sur un serveur en production (tant mieux) qui va rester toujours au même endroit, mais pour un ordi portable qui switch de réseau, se met en veille, s'éteint et se rallume, c'est différent.

                    Il y a plein de sujet où les administrateurs ont des intérêts divergeant du développeur, il n'y a pas la même surface de contrôle (une application vs le système). Bonne chance à celui qui arrive à satisfaire tout le monde.

                    • [^] # Re: Devuan

                      Posté par  . Évalué à 2.

                      On peut lister une série de problème sur à peu près tout, y compris des supers logiciels dont on est "fanatique", ça s'appelle garder son sens critique, c'est pas pour ça que ce sont de mauvais logiciels.

                      Bien entendu.

                      une simplification de la situation précédente

                      Qui était quoi, dans ton cas?

                      Je comprends les sceptiques, SysV (et consort) est satisfaisant pour les administrateurs, qui connaissent bien leur système (contrairement aux développeurs). Et à partir du moment où ça juste marche, pourquoi vouloir changer ..

                      Je pense que le problème n'est pas juste lié à "if it works, don't fix it".
                      C'est quoi, d'ailleurs, les consorts de sysV? C'est quoi, selon toi, le rôle de sysV? Et c'est quoi, selon toi, le rôle de systemd? Tu es programmeur, donc tu devrais être capable de définir le rôle d'un logiciel de façon précise, pour pouvoir l'implémenter correctement.
                      Et c'est justement ce que moi je n'aime pas avec systemd: ce projet a démarré comme simple init+watchdog, et ça faisait sens. En plus, il promettait de remplacer ces immondes scripts de rc.d par des fichier de déclaration? Génial. Seul inconvénient: pas portable. Bon, ça, ok, pourquoi.

                      Ensuite, je me suis aperçu au fil du temps que non, je n'était pas capable de voir ou ce projet compte s'arrêter, et qu'il compte remlacer tout un ensemble logiciel éprouvé par de nouvelles implémentations inter-dépendantes.
                      C'est ça qui m'a fait chercher des alternatives, et je dois à systemd le fait de connaîtres des alternatives à rc.d.

                      Pour en revenir à la question: pourquoi ne pas l'utiliser s'il marche bien? Parce que, il suffit de lire un tant soit peu pour s'apercevoir qu'à plusieurs reprises des composants de systemd qui n'ont pas à tourner en tant que root ont permis l'escalade de privilège, bugs qui sont liés à l'usage de fonctions dont la simple lecture du rôle me fait froid dans le dos (allouer sur la stack?)!

                      C'est la même chose pour D-Bus aussi

                      Marrant que tu en parles. Récemment, sur mon poste perso sous debian, j'ai du recompiler SDL pour virer le support de DBus parce que ça pourrissait les performances (afficher un message d'erreur à chaque fois qu'on ne trouve pas DBus, même si on ne s'en sert pas… mais… sérieux?). Je pense que le problème vient en pratique de la SDL, hein, mais, je trouve ça cocasse.

                      • [^] # Re: Devuan

                        Posté par  (site web personnel) . Évalué à 2.

                        Qui était quoi, dans ton cas?

                        Pinit ou parallele init : le première init parallèle pour Linux pour la partie init (Mandriva). ça pouvait gérer les dépendances entre scripts, compatible rc.d. Comme bien des choses, c'était super à l'époque, et vite abandonné. Je n'ai pas cherché des alternatives à ça.

                        C'est quoi, d'ailleurs, les consorts de sysV?

                        J'aurais pas dû dire consort, mais compatible. Consort suppose qu'il y a des alternatives à SysV (oui y a BSD, mais c'est la même chose).. mais disons tous les init "compatible" init SysV.
                        Avant SystemD, un fichier init Debian (le cas particulier car compatible BSD), Solaris, Fedora ou Mandriva n'était pas compatible entre eux, mais compatible Init System V. Super…

                        Et c'est quoi, selon toi, le rôle de systemd?

                        on dirait mon Psy.. Le rôle c'est s'occuper du cycle de vie des processus non interactifs de mon système, comme init, cron, at, udev, KSMServer (je connais pas bien le fonctionnement du desktop, mais il s'occupe de lancer les services desktop)… Il se permet également de traquer les changements de configurations. Il est responsable d'une partie de la configuration (le nom de la machine par exemple).

                        C'est ça qui m'a fait chercher des alternatives, et je dois à systemd le fait de connaître des alternatives à rc.d.

                        Très bien, partages tes trouvailles (tu l'as déjà fait dans un autre message)!

                        Par contre si tu critiques SystemD, c'est bienvenu, mais il faut être précis et ne pas hésiter à expliquer.
                        Tu dis "bugs qui sont liés à l'usage de fonctions dont la simple lecture du rôle me fait froid dans le dos (allouer sur la stack?)!" - Ça fait très peur quand on lit ça.. Je suis un peu distant avec le savoir académique, alors, je vais p-e te paraître grotesque, mais on passe notre vie à allouer sur la stack. Il y a même des intrinsic des compilateurs pour allouer sur la stack, c'est sans doute même le meilleur endroit pour allouer. Alors dis nous ce qui en terme de développement est problématique. Parce que "Oh, tu te rends compte, ils allouent sur la stack! Comment osent-ils!!!", moi, ça me fait ni chaud ni froid.

                        Et même, si certaines pratiques de développement seraient mauvaises, ça ne remet pas l'intérêt de SystemD en cause. Il répond à des besoins où nous n'avions pas de solution simple avant. Que ce soit parfait, certainement pas, nécessaire, oui.

                        • [^] # Re: Devuan

                          Posté par  . Évalué à 2.

                          Parce que "Oh, tu te rends compte, ils allouent sur la stack! Comment osent-ils!!!", moi, ça me fait ni chaud ni froid.

                          Je faisait référence à ceci. Oui, on passe notre temps à alouer sur la stack, à chaque appel de fonction même.
                          Par contre, ça se fait très rarement avec des données en provenance directe de l'utilisateur, et la fonction utilisée pour ça ne permets pas de savoir si l'appel à échoué. Les problèmes mémoire sont assez communs comme ça, pourquoi prendre un risque aussi important? La performance de journald est-elle vraiment critique au point de ne pas pouvoir appeller malloc?

                          a ne remet pas l'intérêt de SystemD en cause. Il répond à des besoins où nous n'avions pas de solution simple avant.

                          Comme je l'ai dis, je remercie systemd, du fait qu'il m'a forcé à me pencher sur le fonctionnement du PID 1, et j'ai beaucoup appris ainsi.
                          Et puis, le côté configuration déclarative, franchement, je trouve l'idée super. Ce que je regrette, c'est que le projet ne semble avoir aucune limite dans le NIH, et vue la criticité de tout ça, je tique.

                  • [^] # Re: Devuan

                    Posté par  . Évalué à 0.

                    Quand j'ai lu "rien ne nous fera revenir en arrière" dans le contexte, j'ai compris "systemd forever", c'est du fanatisme, surtout quand celui qui me fait comprendre ça liste une série de problèmes qu'il a eus, factuellement.

                    Tu l'as mal compris.
                    C'est plutôt "en bien ou en mal, il est parti pour rester", surtout vu ses ramifications.

                    Ni fanboy, ni hater.

                    • [^] # Re: Devuan

                      Posté par  . Évalué à 2.

                      Tu l'as mal compris.

                      J'ai noté ça.

                  • [^] # Re: Devuan

                    Posté par  (site web personnel) . Évalué à 3.

                    Quand j'ai lu "rien ne nous fera revenir en arrière" dans le contexte, j'ai compris "systemd forever", c'est du fanatisme, surtout quand celui qui me fait comprendre ça liste une série de problèmes qu'il a eus, factuellement.

                    Ou alors tu peux le comprendre correctement par "rien ne nous fera revenir en arrière" (oui, je copie, mais bon ça veut dire ce que ça dit).

                    Si tu veux plus détaillé : il y A nul, B moyen, C super, une personne dit que suite au passage à B rien ne fera revenir à A, sans absolument rien dire sur C ni dire que B est la fin en soit. Toi tu imagines que B est le saint graal, alors que les gens disent juste que tant que C n'existe pas, il vaut mieux passer à B et ne pas revenir à A, pendant que d'autres (rares de nos jours dans le cas qui nous concerne) disent vouloir rester sur A tant que C n'existe pas (la belle excuse pour ne jamais bouger de A…).

                    Bref, absolument rien à voir avec "systemd forever" et je ne vois pas comment tu peux l'imaginer, juste systemd tant que tu ne proposes rien de mieux (et en pratique, les critiqueurs de systemd veulent juste garder leur vieux truc pire sans proposer mieux).

                    • [^] # Re: Devuan

                      Posté par  . Évalué à 1.

                      C'est pas faux. Sauf:

                      en pratique, les critiqueurs de systemd veulent juste garder leur vieux truc pire sans proposer mieux

                      Si on remets le contexte, il y a deux catégories de gens qui critiquent systemd:

                      • ceux qui veulent rester à rc.d (parce que les cascade d'inclusion de dash, bash, et autres c'est tellement lisible, et devoir se fader 150 lignes de code par service c'est logique);
                      • ceux qui considèrent qu'il y a d'autres solutions moins "tout-en-un", qui font la même chose que ce que j'ai perçu comme le but initial de systemd (à savoir, être un watchdog logiciel, oui, ça remonte, et à l'époque j'aimai systemd) sans avoir à supporter tout le reste, journald inclu, sur lequel j'ai vu passer plusieurs failles exploitables à distance, et les dernières en date sont liées à l'utilisation de code pour allouer dynamiquement sur la stack, qui n'est pas faite pour ça.

      • [^] # Re: Devuan

        Posté par  . Évalué à 10.

        Enfin, utiliser une distribution basée sur un truc qui ressemble de plusen plus à un bloatware immonde (systemd pour ne pas le nommer)

        Je suis preneur d'un comparatif de ressources CPU/MEM/DISK entre devuan et debian, pour savoir à quel point systemd est "bloaté"… ou si c'est juste du FUD.

      • [^] # Re: Devuan

        Posté par  (site web personnel) . Évalué à 3.

        Enfin, utiliser une distribution basée sur un truc qui ressemble de plusen plus à un bloatware immonde (systemd pour ne pas le nommer), ben non, merci.

        Ca me fait juste penser à https://hooktube.com/watch?v=6AeWu1fZ7bY

        Voilà voila.

        • [^] # Re: Devuan

          Posté par  . Évalué à -1. Dernière modification le 20 janvier 2019 à 21:16.

          Cette excellente présentation de Benno n'a rien à voir avec le commentaire auquel tu réponds.

          Je ne sais pas si un projet est né depuis cette discussion.
          Curieux de voir comment FreeBSD va attaquer le problème. Après ils veulent un superviseur de ressources/services intelligent, pas une usine à gaz aux mille ramifications façon systemd

    • [^] # Re: Devuan

      Posté par  (site web personnel) . Évalué à -2.

      Je vais faire mon chieur mais l'équipe de debian est très loin d'être blanche comme neige et est aussi composée d'une palanquée d'incompétents.

      git is great because linus did it, mercurial is better because he didn't

      • [^] # Re: Devuan

        Posté par  . Évalué à 8.

        Tu pourrais au moins argumenter un peu… par exemple en citant l'usage de ls dans un script shell utilisé par dpkg (/usr/share/initramfs-tools/hooks/fsck, ligne 14), ou mentionner le fait que rc.d, c'était le bordel, y'avait des dépendances dans tous les coins du disque, et qu'avec systemd, ben… la dernière fois que j'ai regardé, c'était pareil.

        Maintenant, le fait est que Debian a énormément de contributeurs, ce qui augmente les chances d'avoir des «incompétents» qui contribuent, d'autant que je doute que la majorité soit payée pour faire ces contributions.
        On peut aussi parler du fait que Debian est une distribution avec un nombre de logiciels franchement impressionnant, et qu'il est possible de faire sans trop d'effort le yoyo entre les versions majeures de Debian sans ré-installer from scratch, ce qui me fait plutôt penser qu'il doit y avoir une palanquée de gens compétents.

        Perso, je dirais juste que Debian, à force de vouloir être universelle, n'est bonne que sur les machines avec de grosses ressources. Et il faut reconnaître qu'il y a pas besoin de sortir de Saint-Cyr pour l'administrer.

        • [^] # Re: Devuan

          Posté par  . Évalué à 6.

          Très bonne critique, constructive.

          Perso, je dirais juste que Debian, à force de vouloir être universelle, n'est bonne que sur les machines avec de grosses ressources.

          Effectivement, la volonté d'activer « toutes les options possibles » dans chaque logiciel, afin de pouvoir satisfaire le maximum de besoins utilisateurs, pousse parfois à avoir des logiciels un peu plus lourd. Cependant, ça tourne bien ici sur ARMv5 à 400 MHz et 128 Mo de RAM.

          • [^] # Re: Devuan

            Posté par  . Évalué à 4.

            Cependant, ça tourne bien ici sur ARMv5 à 400 MHz et 128 Mo de RAM.

            Pour être honnête, j'ai fais tourner Debian sur un vieux coucou i586 cadencé 700MHz avec moins de 100Mo de RAM sans rien recompiler, et je parle bien de stretch (l'actuelle stable).
            Par contre, ce ne sont clairement pas les logiciels installés par défaut… et un des gouffres présent, c'est Xorg, dont on ne peut se débarrasser pour privilégier des applications en framebuffer, vu que sous Debian, je n'ai pas souvenir d'avoir pu faire tourner netsurf ou une application basée sur la SDL sans X: c'est cassé. Ou plutôt, il faut compiler la SDL pour inclure le support des framebuffer (j'ai du le faire au taf, j'en ai profité pour désactiver tout le bloat qu'il y a dans cette lib d'ailleurs, notamment le support foireux de DBus).

            • [^] # Re: Devuan

              Posté par  . Évalué à 3.

              Par contre, ce ne sont clairement pas les logiciels installés par défaut… et un des gouffres présent, c'est Xorg, dont on ne peut se débarrasser pour privilégier des applications en framebuffer, vu que sous Debian, je n'ai pas souvenir d'avoir pu faire tourner netsurf ou une application basée sur la SDL sans X: c'est cassé. Ou plutôt, il faut compiler la SDL pour inclure le support des framebuffer (j'ai du le faire au taf, j'en ai profité pour désactiver tout le bloat qu'il y a dans cette lib d'ailleurs, notamment le support foireux de DBus).

              Ah c'est pour ça :o

              Je me souviens d'avoir fait tourner certains softs dans le TTY grâce au framebuffer : fbi, fbterm, vlc, mplayer, w3m-img (avec un intérêt relatif, vu que dans tmux ça ne marchait plus il me semble)… mais aussi que j'avais essayé de faire tourner certains jeux dont la description du .deb mentionnait qu'ils pouvaient utiliser le framebuffer… sans succès.

              *splash!*

              • [^] # Re: Devuan

                Posté par  . Évalué à 3.

                avec un intérêt relatif, vu que dans tmux ça ne marchait plus il me semble

                En même temps, tmux ne gère que du texte je pense… je ne suis pas sûr, mais je pense que tmux/screen se qualifient plus d'émulateurs de terminal (embarquant un gestionnaire de fenêtre) qu'autre chose. Cela dit, ça me fait me demander s'il existe des gestionnaire de fenêtre pour le mode framebuffer? Techniquement, ça me semble pas impossible, je suppose qu'il "suffirait" d'allouer des buffer et de faire pointer les applications fb sur ces buffer plutôt que le véritable fb… par contre je pense que ça serait une belle usine à gaz :/

                • [^] # Re: Devuan

                  Posté par  . Évalué à 2.

                  En même temps, tmux ne gère que du texte je pense…

                  En fait quand j'utilisais w3m dans tmux dans un TTY, les images s'affichaient, mais elles clignotaient tout le temps. Je crois que c'était pareil pour smplayer, je ne sais plus trop.

                  *splash!*

    • [^] # Re: Devuan

      Posté par  . Évalué à 2. Dernière modification le 17 janvier 2019 à 15:32.

      J'aurai plutot pensé à GNewSense

  • # Devuan ASCII

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    J'ai mis longtemps à comprendre que « ASCII » c'était le nom de la version (Devuan 2.0) et pas un qualificatif de la version (en opposition à une version Unicode, par exemple).

    C'est assez curieux comme choix de nom : ASCII, c'est quand même une norme antique, spécifique (ne gère à priori que l'anglais), très limitée, mais qui s'est tellement infiltrée partout qu'on a du mal à s'en débarrasser (cf les dizaines d'autres systèmes de codage de caractères plus ou moins compatibles). Je ne sais pas quel était l'intention des créateurs de Devuan, le message qu'ils comptaient faire passer, en choisissant un nom pareil pour leur distribution.

    En ce qui me concerne, je ne trouve pas ça très vendeur.

    La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Devuan ASCII

      Posté par  (site web personnel) . Évalué à 6.

      Pareil, encore des gens qui restent bloqués dans le passé. Moi systemd je ne peux plus m'en passer, en deux lignes je crée des deamon et je automount des disques, j'adore. Je gagne un temps fou avec mes clients.

    • [^] # Re: Devuan ASCII

      Posté par  . Évalué à 2.

      C'est assez curieux comme choix de nom

      Ça va, ils auraient pu faire pire, ils auraient pu l'appeller BSOD, bricolage en revanche eu été faire de la pub au logiciel qu'ils ne veulent justement pas utiliser… Je trouve ça amusant de reprocher un nom qui certes fait référence à un ancien standard (mais, standard, au moins) et de plébisciter derrière un logiciel qui lui évoque la bidouille pour gérer les parties clé d'un système.
      Pour ce qui est du nom, je ne sais pas quand tu as regardé, ça a peut-être changé, mais là, sur la page d'accueil c'est écrit:

      Now Devuan ASCII offers an upgrade from Devuan Jessie as well as a transition from Debian 9 (Stretch) that avoids unnecessary entanglements and ensures Init Freedom.

      Devuan aliases its releases using minor planet names as codenames. Devuan file names follow this release naming scheme.

      En gros, il suffit de lire 3 lignes de plus pour savoir d'où le nom vient.
      Et puis, je le trouve amusant moi: il colle à leur taxonomie tout en faisant référence a l'informatique. Accessoirement, contrairement à bien des encodages, ASCII est compatible UTF-8.

      Je pense qu'il y a plus a reprocher à Devuan que leur choix de noms et de ne pas utiliser systemd, mais pour ça, il faut l'essayer.

      • [^] # Re: Devuan ASCII

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Y'a 1516 astéroïdes dont le nom commence pas A dans la liste que tu donnes…

        La connaissance libre : https://zestedesavoir.com

        • [^] # Re: Devuan ASCII

          Posté par  . Évalué à 0.

          Et donc? Y'en a un qu'ils ont trouvé à propos, ils l'on choisit, et alors?

          Je dirais même que, Ascii, pour un satellite, c'est débile, bordel c'est un standard sur 7 bits quoi, comment peut-on nommer un satellite comme ça?

          Faudrait p'tet penser à arrêter de se concentrer sur les apparrences un jour… la plupart d'entre nous est probablement adulte, et pourtant on passe plus de temps a critiquer des apparences, noms, libellés,etc qu'a agir…
          En plus, ici, on a un public plutôt orienté technique, alors vraiment, si vous voulez enfoncer devuan, faites-le avec un peu d'arguments, de véritables statistiques que vous pouvez détourner proprement…

      • [^] # Re: Devuan ASCII

        Posté par  . Évalué à -2.

        Devuan c'est tout de même pas terrible.
        J'aurais préfèré un truc plus fonctionnel, évocateur. Ça peut tenir du marketing ou de la masturbation mais un nom bien choisi peut faire la différence. Sur le long terme, on tend à accépter le nom initial si le logiciel rencontre un succès mais avec toute la concurrence actuelle, le coût d'un tel developpement, je suis d'avis qu'il faille bien choisir son nom d'OS à destination du public.

        Rah, si seulement on avait un OS complet appelé Linux.

        • [^] # Re: Devuan ASCII

          Posté par  . Évalué à 2.

          Rah, si seulement on avait un OS complet appelé Linux.

          Bah t'inquiètes pas. Si ça continue comme ça, tu auras bientot un système complet avec une seule comande : systemctl. Tu utuiliseras st=ystemctl pour tout : application bureautique, navigateur, IDE, interface graphique, traitement multimédia, enfin tout quoi.

        • [^] # Re: Devuan ASCII

          Posté par  . Évalué à 1.

          Devuan c'est tout de même pas terrible.

          Je te rejoins, la parenté est trop présente. D'un autre côté, je pense que c'est le but, malgré l'évidente polémique. Cela dit, à la base, c'était debian-fork, je crois. C'est moins pire de nos jours donc.

          J'aurais préfèré un truc plus fonctionnel, évocateur.

          Hum… cites moi un seul nom de distro qui soit «fonctionnel, évocateur» s'il te plaît? Chapeau rouge? Deborah Ian? Linux du vide? Super-linux (Arch)?

          Rah, si seulement on avait un OS complet appelé Linux.

          Y'a moyen, si tu parviens a faire intégrer busybox dans le sourcetree de linux…

          • [^] # Re: Devuan ASCII

            Posté par  . Évalué à -1.

            Hum… cites moi un seul nom de distro qui soit «fonctionnel, évocateur» s'il te plaît? Chapeau rouge? Deborah Ian? Linux du vide? Super-linux (Arch)?

            Aucuns, c'est pour ça que ça sonne nerd.

            Y'a moyen, si tu parviens a faire intégrer busybox dans le sourcetree de linux…

            *BSD, quelqu'un ? Pas besoin de troller.

            Bon arrêtez de frapper, je me tais

            • [^] # Re: Devuan ASCII

              Posté par  (site web personnel) . Évalué à 5. Dernière modification le 20 janvier 2019 à 11:38.

              Hum… cites moi un seul nom de distro qui soit «fonctionnel, évocateur» s'il te plaît? Chapeau rouge? Deborah Ian? Linux du vide? Super-linux (Arch)?

              Software und System-Entwicklung Linux, la distrib pour développeurs germanophones donc.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.