freem a écrit 5059 commentaires

Mais tu ne refais pas la même chose quand tu sais ce qu'il va arriver par expérience, puisque tu n'es pas dans le même état.

Certes, mais le problème viens du fait que tu ne refais pas dans des conditions identiques :)

Cela dit, bien dit.

klaxonnes-tu?

Surtout quand on voit l'usine à gaz qu'est l'implémentation par debian de rc.d… pour chaque service, ce sont des milliers de lignes de bourne shell qui sont exécutées, réparties dans je ne sais plus combien de fichiers disséminés un peu partout…

Pour le coup, de ce côté, son discours est très étrange…

D'une part, il râle parce qu'avant il fallait jouer avec udev pour avoir des noms fiables:

Le noyau Linux a eu la bonne idée depuis des lustres de nommer les interfaces Ethernet en eth. Premier problème, d'une version à une autre, l'énumération ne se faisait pas forcément dans le même sens.

Puis il râle que udev renomme les interfaces (en accusant une MàJ kernel, quand même…)

Plus récemment, les noms de périphériques ont été changés et ce qui était eth0 a pu devenir au gré d'une mise à jour de noyau enp0s31f6, ce qui était très pratique pour les gens qui utilisaient un firewall bloquant tout par défaut sur une machine à distance. Mais encore, en lisant la documentation et en acceptant d'ouvrir un peu tous les ports le temps de la migration, il était possible de s'en tirer.

Et enfin il râle que systemd re-renomme les interfaces:

Vous noterez qu'il n'y a plus de eth0 mais un lan0. Pourquoi ? Parce que cette saleté de systemd a décidé depuis sa dernière mouture d'entrer en conflit avec le renommage des interfaces par udev

Bon, en fait, je crois que son propos ici c'est que c'est le kernel qui devrais le faire. Ce qui est en soit défendable. Personnellement je ne sais pas vraiment comment udev fait pour exposer les noms des interfaces réseau, donc je ne jugerai pas sur ce point (faudrait que je creuse le sujet un jour).

J'ai trouvé un post qui semble détailler comment faire ici.

En gros, il s'agit d'utiliser la commande --transform de xrandr.

Dans l'exemple donné (qui est compliqué parce qu'il fait d'autres trucs au passage):

• "xrandr ==> la commande elle-même
• "--fb 1920x980" => pas eu besoin chez moi
• "--output eDP-1" => le nom de l'écran affecté. On peut lister les écrans connus avec cette commande: xrandr | awk '$2~/connected/{ print $1 }'
• "--mode 1920x1080" => idem
• "--transform 1,0,0,0,1,-100,0,0,1" => "enlève" les 100 lignes du haut
• "--panning 1920x980" => idem
• "--fb 1920x980" => idem

Bon courage pour trouver la transformation correcte (les joies des transformations matricielles…).

D'un autre côté, si c'est réparable mais que les pièces sont introuvables (ou fournies par un seul fournisseur, ça reviens presque au même)…

Tant que les interfaces ne sont pas standardisées, ça sera toujours la même merde.
En fait, même juste avoir la documentation technique de l'interface (hard & soft, ce qui inclue le protocole de communication le cas échéant) serait déjà une sacrée évolution! On peut toujours rêver…

Pas trop envie de m'étendre sur mon opinion de systemd, ça n'apporterais rien. Je préfère apporter des solutions aux «problèmes» soulevés par cette personne, ça me semble plus constructif.

Je note personnellement que l'auteur du billet n'est pas aussi compétent qu'il veut le faire croire avec Debian.

1: le meta-paquet "init" dépends, au choix, de:

• systemd-sysv aka systemd (oui, le nom est a chier, probablement un héritage du fait que lors de l'introduction ça dépendait de sysv-rc);
• sysvinit-core aka sysvinit qui dépend de sysv-rc;
• runit-init aka… bah, runit, ui dépend de sysv-rc pour une raison simple: il faut du temps pour implémenter un système d'init complet (de mémoire, dans Jessie systemd-sysv aussi en dépendait);

2: si la séparation de / et /usr lui est si chère, pourquoi ne pas conserver cette séparation?

Pour ce qui est du point 1, le seul truc que je peux regretter est l'absence de nosh dans la liste, j'aurait bien aimé qu'on me mâche le boulot avec celui-la, ça m'aurait permis de le découvrir in-situ.
Parmi ses avantages supposés (de mémoire):

• possibilité de convertir les unit systemd en scripts nosh
• un "DSL shell" (pour domain specific language shell, l'appellation est de moi)
• correction du problème "thundering herd solution" qui est l'apanage des héritiers des daemon tools

mais faut que lise la doc, donc la flemme :)

Je reconnais que, pour ne pas avoir systemd installé par défaut (et donc devoir le désinstaller via apt après l'install) et/ou pour conserver la séparation de / et /usr il faut passer par une procédure plus complexe:

• démarrer sur l'iso
• ne pas sélectionner "install" mais "rescue"

Une fois dans le "rescue mode", il faut ensuite faire l'installation de la façon qui se fait sur d'autres distributions, qui ciblent des utilisateurs avancés (ça tombe bien, il semble en être un!): préparer le système cible, utiliser deboostrap avec les paramètres qui vont bien, configurer le système, configurer le bootloader.

Oui, c'est compliqué, mais plutôt que râler, il aurait été plus efficace de rappeler que c'est possible, j'ai émis plusieurs journaux sur ce genre de manipulations, donc en fouillant il devrais même ne pas avoir trop de boulot a faire pour construire son propre script.

Mais non, comme «tous» les «anti-systemd»(1) il préfère râler en ignorant (volontairement?) le fait que systemd est loin d'être obligatoire, surtout sur la distribution dont il parle qui propose quand même 2 alternatives pour ceux qui le veulent!

Et, vraiment? 1Go de RAM pour systemd?
Heureusement que ça n'est pas vrai, parce que sinon cette collection d'outils, qui nécessiterait sur mon système l'usage de 14.4Mio de disque, doit leak quelque chose de bien! Pas crédible.

Oui, systemd est plus gourmand en ressources.
C'est normal: il gère réellement les processus, il ne se contente pas de les lancer et faire comme si ça ne plante jamais!
D'ailleurs, c'est encore plus important sur un système embarqué qui va se retrouvé exposé a des conditions bien éloignée du labo. J'ai déjà vu un système freezer par le simple fait de recevoir un appel téléphonique trop près (bon, dans ce cas, c'était le hard qui partait en couilles, certes, il aurait fallu un watchdog hard, mais bon…)!

Par contre, je serais curieux de savoir la consommation mémoire (réelle) de systemd. Dans le cas de runit compilé avec glibc, j'ai:

ps -orss,vsz,args $(pidof runsv runit runsvdir svlogd)
  RSS    VSZ COMMAND
  716   2152 runit
  736   2312 runsvdir -P /etc/service log: .............................................................................................
  676   2160 runsv getty-tty5
  740   2160 runsv ssh
 1172   2160 runsv eth1
  740   2160 runsv getty-tty2
  740   2160 runsv getty-tty3
  732   2160 runsv getty-tty1
  736   2160 runsv udev
  736   2160 runsv getty-tty6
  732   2160 runsv getty-tty4
  736   2160 runsv eth0
 1248   2160 runsv bumblebeed
  736   2304 svlogd -tt /var/log/ssh
  736   2304 svlogd -tt /var/log/udev
  740   2304 svlogd -tt /var/log/eth1
  672   2304 svlogd -tt /var/log/eth0
  736   2304 svlogd -tt /var/log/bumblebeed

Dans la plupart des instances de runsv, svlogd, runit et runsvdir, RSS chute a 4 dans le cas d'une compilation avec musl. Je ne sais pas pourquoi certaines instances de runsv montent a plus d'1Mo…

Si quelqu'un peut mesurer l'impact de systemd compilé avec glibc ou mieux, si possible, avec musl?

Bon, sur la plupart des machines, ces quelques megs de mémoire consommés ne sont pas gênant, mais je me dis que sur de l'embarqué très serré (genre, avec moins de 64Mo de RAM, comme certains routeurs ou autres) ça peut compter.
Perso, je vois surtout le fait que je serais capable de lire et maintenir le code de runit si besoin est, alors que ce n'est pas le cas pour systemd.

1: dont, techniquement, je fais partie puisque je n'utilise pas cet init. Cela dis, je préférerais utiliser systemd que revenir à sysvinit + rc.d, sans hésitation, surtout sur des machines sur lesquelles je n'ai pas la possibilité d'avoir un accès physique!

Je trouve l'info intéressante perso, sur le plan scientifique. Je ne sais pas a quoi ça sert, certes, mais ça montre qu'on s'améliore, et ça fait rêver. Je crois que c'est important pour les gens qui veulent ou doivent créer de nouvelles choses, de repousser les limites.

tu as oublié une partie du titre de l'article: "et tous les messages problématiques". Pas la peine de lire plus loin.

Merci.
J'allais répondre en long a ce lien, montrant a quel point je suis dépité et amer par rapport a mozilla, jusqu'a lire ça:

Quelles plate-formes sont supportées ?

Short answer is anything Mozilla can run on, then Gecko can too. However, the embedding is concentrating on three primary platforms:

Windows (95? definitely 98 and later)

Tu es sûr que ce lien est… a jour?

Je doute que la boîte ait disparu de son plein gré, donc, tu ne peux qualifier l'obsolescence de programmée.

Ceci étant dit, a l'origine, la raison d'être des brevets était de justement protéger la civilisation de telles pertes, que les plans soient a tout jamais disponibles, et en échange l'inventeur de la méthode était rémunéré. Il me semble évident que les lois actuelles sont contre cet objectif, vu qu'il semble qu'il n'y ai plus d'obligation de donner les fichiers d'origine a une autorité de contrôle, qui soit capable de les rediffuser en cas de mort de l'inventeur.

C'est bien d'ailleurs pour ça que je pense que le libre est important.

En fait, j'ai une question qui est sûrement très bête.

Il m'est arrivé, comme a d'autres ici je pense, de devoir travailler en "mode sans échecs", "mode mono utilisateur", en gros dans des modes dégradés sur lesquels ont peut faire a peu près tout ce qu'on veut, tant qu'on sait se passer de confort.

Dans mon cas, j'ai utilisé linux pour du… disons, embarqué (ni baremetal, ni temps réel) pour des équipements de ville par exemple, qui ont un écran tactile, dédié a une seule application.
Au début, ma boîte du moment est partie sur l'idée d'utiliser electronJS. Au bout de quelques mois, après le départ du développeur qui avait tout fait, on s'est aperçu qu'il y avait de nombreux crashs (oui, je sais) notamment des SIGILL. Ça, et le fait que Xorg et les scripts que j'ai bricolés étaient assez… aléatoires… concernant la gestion de l'orientation de la dalle graphique et celle de la dalle tactile (non, les dev logiciels ne sont pas les rois).
Ça s'est fini a ce que je doive me farcir la gestion de l'UI, et vu que ni Xorg ni SDL ne permettaient de faire les choses facilement, je suis revenu a du bon vieux framebuffer + libinput (tellement plus simple, d'accéder direct a la mémoire et de faire une lib, dans ces cas, que de passer par 36 couches d'abstractions).
Qu'en est-il également des
Tout ça m'a amené a penser qu'une alternative portable et portée à d'autres systèmes serait plutôt sympa, et je me demandais si Haiku offrait ou planifiait ce genre de choses?

Je me pose aussi la question sur la question des syscalls. J'imagine qu'ils sont en C, sinon ça serait se fermer aux autres langages ou leur ajouter une couche de compat? Si c'est du C++, alors, comment vous gérez l'absence de specs d'ABI? N'y aurat-il qu'un seul compilo "autorisé"?

Navigateurs: le navigateur natif WebPositive (utilisant WebKit) et divers navigateurs utilisant QtWebKit (Otter, Dooble, …). Pas de version de Chrome ou Firefox en vue, il faut demander à Google et Mozilla qu'ils se décident enfin à s'en occuper.

Voila qui m'intrigue.

Je comptais repartir derechef, mais… au final, le moteur de chromium et gecko sont moins simples a embarquer, porter et maintenir que webkit?

Peut-être un effet secondaire de la taille des captures par rapport a la taille du texte? N'est-il pas possible d'avoir des miniatures qui lient vers le lien d'une image plus grosse? (vraies questions, même si je repart derechef)

C'est vraiment si moche? Je serais heureux que tu me montre par l'exemple, ça servira potentiellement a plein de gens.

C'est vrai, qui suis-je au fond, pauvre libriste qui ose publier du code si sale que personne ne publie la version correcte?

C'est triste, mais ici, soit les gens mettent des liens githubs, dont le côté libre est discutable, soit on se fait limite démolir pour avoir osé ne pas être parfait..

Pardon mais moi, j'aime pas le libre parce que c'est du code parfait, mais parce que c'est du code que les autres peuvent améliorer. Sans se baser sur une base propriétaire comme github ou gitlab.
Je veux être libre de filer mon code a qui je veux, c'est a dire: tout le monde, même si c'est mauvais, certains apprendront, et moi je lirais leurs articlcles… techniques, et non politiques, ça me changera!

Je me réponds a moi-même, mais, malheureusement, je suis français. Comment je fais pour mettre ce que je publie ici en CC0? Et si un jour je veux juste une licence type BSD-2, je fais comment, je fais un double compte ou bien je me tais?

cette bd me manquais, pardon<<

Bah c'est une mauvaise pratique, tu peux éventuellement le faire pour ton shell courant, mais de manière global (pour une utilisation dans un script) c'est pas une bonne idée.

Une… mauvaise pratique, de montrer mon code a tous, anonymement?

La, il va falloir que tu m'expliques… parce que tu vois, mon code, ici, il a permis potententiellement pleins de trucs.

Déjà, il fait le job. Rien que ça, c'est pas dégueu, l'air de rien.
En plus, il est amélioré par des commentaires, c'est donc utile pour les futurs hackers.
Ah et… il te reste a démontrer qu'il sert a rien… oups! C'est vrai, il y a 0 pôlitique. C'est de la techique pure, et je remercie ceux qui ont dit que même si c'est mauvais un peu de code ça fait du bien. Ce site fut un repaire de geeks voires nerds, cest devenu un repaire de politiciens, et ça me gonfle.

Perso, j'entend changer ça, par la pratique. Je code ou je meurs.

Je plussoie sans plussoier, parce que plus jamais de plussoiements!

Moui, mais une manif du web, doit rester une manif, il faut de matraque, du gilet, jaune ou vert selon la maladie et et du fumigène. C'est logistique toutça…. et si on essayait de voter pour des gens qui au moins promettent de permettre au peuple de les virer en cas de mensonges, de manipulations évidentes?

Par contre la vie normale comme avant sans restrictions cela mettra du temps à se revenir oui.

Et si on se contente de vivre comme avant? Pour une raison ou une autre, la majorité d'entre nous n'a pas subis le cv19. Je crois qu'une fois le risque majeur de transmission toute mesure doit être purement et simplement annulée.

En gros, déjà 2 mois de confinenement, si une autorité digne de confiance… le gouvernementeurs? Non. On oublie… l'oms, déja mieux…. nous donnent des directives, on suivra mieux.

Les français sont des cons? Soit. En même temps, les gouvernants que nous avons élus nous prennent pour des cons (désinformation, le pire c'est que ça a marché sur moi en partie, je m'en veux) et nous tiennent dans cet état de connerie.
Sauf qu'on est un pays de lettrés, en vrai, et on a déjà eu des bienfaits en coupant des têtes étatiques, on nous le rappelle tous les ans… Sommes nous si idiots? Et si oui, quelle frange de population?
Celle des cités? Ben tiens, je vous en prie, venez-y, par ici, vivre 30, 60 voire 90 jours sans sortir de vos 30m2 (la chance) on vous livre!
Mon frère qui répare des ascenceurs m'a sorti ça au tel. Lui, il a terrain, et a cassé le confinnement en allant voir mes parents, hein…

Alors, moi qui vit dans une cité je vous dit clairememt: amenez vos lois et décrets quand vous viderez nos poubellles

il est moins coûteux de fabriquer cette antenne en qualité moyenne et d'effectuer un réglage, que de la fabriquer tellement bien qu'elle n'a pas besoin d'être réglée.

Intéressant, je doute que tu repasses, mais, pourrais tu m'éclairer sur ça?

ça donne une idée du faible surcoût de conception et fabrication d'une puce NFC dans une carte bancaire.

et se dire que la plupart des gens considerent ça sécure: une seule faille, et tout se casse la gueule. IL suffirait de pas la trimballer pour réduire les risques pourtant…

genre, mal formulé… pff je lâche le "scan" quotidien de dlfp parce qu'il y a plus de politique que de science. Ce que tu as formulé me fait mentir, et en plus c'est clair.

… pour les autres, il nous reste la démerde. Comment ça, il nous reste? C'est pas un peu ce qu'on a toujours voulu, un système hackable?

Ton problème, il viens pas de systemd, hé non. Pourtant, moi, j'aime pas sD, je devrais tout lui mettre sur le dos selon les conventions geek du pour ou contre.

Perso, j'ai d'abord été pour, parce qu'il virait manu militari le bordel de rc.d. Il le remplace par des fichiers en mode déclaratif… éparpillés partout! ( en vrai, j'y connaissais que dalle… et c'est systemd qui m'a permis de chercher les alternatives! vive sD, bon ou mauvais, il me fut utile!)

En bref, systemd, a mes yeux, ça remplace juste un peu de shell pourri par du C qui se base sur des fichiers de config a la géométrie qui variera selon le temps.

Je serais moinssé a bloc, je me doute, et je m'en fout. Je veux juste te poser une question: si tu aimes pas systemd, ben, pourquoi que tu l'utilises?
Non, parce que perso, j'aime pas, certes, mais quand j'ai une merde, je me plains pas, pourtant j'utilise debian, la mère d'ubuntu. Ah, ptet parce que j'utilise un autre PID1?
Ben oui, c'est possible, les mainteneurs de debian sont pas des enculés, ce sont des gens biens et d'habiles ingénieurs qui laissent l'option a ceux qui le veulent.

Maintenant, c'est a nous, qui n'utilisons pas systemd de prouver qu'on peut s'en peut s'en passer. Oui cest la loi de la jungle. Mais c'est un peu le principe initial de l'open source, non? Le meilleur fork et gagne!
Reste a prouver que systemd gagnera, mais ça, c'est pour moi ;)

Un robot SMB donc: Slow Mail Bomber :)