Anthony Jaguenaud a écrit 1957 commentaires

Et bien, je ne trouve pas du tout, je trouve un 0400 bien plus lisible qu'un S_IRUSR | S_IWUSR

Je comprends, puisque S_IRUSR | S_IWUSR devrait être 0600, non ? :-p

C'est plus le rapport d'une anecdote qu'une charge contre systemd. La charge contre systemd, elle vient dans les commentaires, ce n'est pas l'objet du journal.

Moi ce qui m’a surpris, c’est la réaction le Lennart que je traduirai par : « Quoi ? personne n’a essayé sans les cgroup ? »
Après, ils ont une suite de tests automatique, si j’ai bien compris, donc ajouter un test ou au moins ça vautre pas et hop c’est réglé.

C'est parfait ! Comme ça, ça donne du code vraiment portable !

Bah c’est pas grave, systemd n’est pas prévu pour fonctionner avec autre chose que Linux.

Sauf que dans un cas le noyau te dit : "Heu je ne peux pas monter root" et dans l'autre ton init se vautre sans rien te dire, puisqu'il fait un segfault.

Il faut tester le retour de asprintf

Non, sous Linux malloc n'échoue jamais (voir partie 6). Enfin sauf si un boulet demande au noyau d'allouer réellement les pages demandées…

En soit c'est bug et ça ce n'est pas dramatique, ça se corrige.

Le problème c'est que le logiciel plante. Pour un system d'init, ça semble peu robuste. Si par erreur tu compiles ton noyau et n'inclus pas les cgroup, erreur bête, ben ton PC ne démarre pas correctement. Ce qui semble génant, d'autant que le cas est géré proprement ailleurs dans le code.

Ça semble évident que si la performance est le principal critère, que tu développes une architecture adaptée. Mais dans 99% des cas, les performances sont suffisante en faisant attention à ce qu’on fait. Pour un tri, on peut choisir le tri à bulle pour des petites quantités, mais sinon un bon quicksort c’est mieux.
Mon propos était surtout sur le codage. Si l’architecture ne répond pas au besoin, de toute façon, tu es mal.

On peut optimiser ce genre de chose en C par exemple, je mets côte à côte des champs de structure proche pour le sens, voir des structure de structure. Mais on peut aussi déstructurer pour mettre côte à côte les éléments souvent accédé ensemble… ça rend la structure moins lisible, mais comme les champs on de grande chance d’être sur la même ligne de cache, on gagne en performance. On peut aussi faire du prefetch ça évite de trop déstructurer. On peut aussi éloigner les éléments accédés par des thread différents, surtout si on défini des affinités sur les CPU/cœur.

Mais rendre le code moins lisible doit toujours venir en dernier recours, après l’architecture et le choix des algorithmes ayant les complexités les plus efficaces pour le problème traité.

Je suis d'accord avec toi, j'ajouterai juste qu'il ne faut pas se focaliser sur les perfs au début. C'est à la fin d'un projet qu'il faut voir si les perfs conviennent ou non. Dans le second cas, il faut faire du profiling pour chercher où gagner des perf. Il vaut mieux gagner 1% de perf dans une routine utiliser 50% du temps que 30% dans une utilisé 1% du temps. Ca semble évident, mais ça ne l'ai pas lors de l'analyse.
Sur les perf, le cache joue mais pas que. J'avais benchmark une petite routine il y a une dizaine d'année sur un power PC. Au premier passage elle prenait 2µs. A partir du second 1.8µs le code était dans le cache instruction. Au 18ième passage, on passait d'un coup à 800ns, dû à la mise en route de la prédiction de branchement et au non vidage des caches.

Une chose me semble évidente, c'est qu'un compilateur fera toujours mieux que nous. Sauf peut-être à passer 2 mois sur 50 lignes de code.

Le point que tu rates dans l'analogie, c'est que moi, utilisateur et pas développeur, je veux avoir mon mot à dire sur les outils des développeurs (que je ne rémunère pas qui plus est), et je leur demande d'en chier parce que je ne veux pas avoir à faire à leurs nouveaux outils.

Le point que tu rates dans ton analogie, c’est qu’on parle bien d’IDE, je t’aide : Integrated Development Environment. Donc oui, pour un développeur je ne trouve pas ça déconnant.
Pour un admin système, il y a plusieurs niveau. Mme Michu, elle s’en fout, elle ouvrira pas de fichier systemd. L’admin de base fera confiance à sa distrib, avec peut-être une modif ici ou là, mais ce sera un copier/coller d’un forum.
L’admin expert, lui, avoir une machine de turing pourrait l’aider, mais pas forcément tout le temps.

Au départ, je ne voulais pas réagir, car les pro-systèmed sont largement majoritaire, et que ceux si ont tendance à insulter directement les autres. Mes réactions n’ont eu pour but que de relever des arguments que je trouve non pertinent, (le beau code parce qu’il utilise des extensions d’un compilateur…) en aucun de mettre en doute la sacro-sainte parole.

Ça me rappelle une étude sur les utilisateurs d’apple dont la marque éveillait dans le cerveau les mêmes zones que la foi. Et j’ai parfois l’impression que c’est pareil pour les pro-systemd. On ne peut argumenter ne serait-ce qu’un cas sans en prendre plein la tronche gratos. C’est quoi la prochaine étape, venir nous démolir la tronche ?

J’aimerai vraiment pouvoir discuter dans ce débat sereinement. Systemd apporte des évolutions sympas, tout le monde n’en ressent pas le besoin, et certains critique sa vampirisation de truc comme udev. Est-ce un délit ? Devrait-ce être un délit ? Faut-il prévenir l’exécutif ?

Dans le débat, si on prend les mots violent, de dénigrement et qu’on classe cela entre les pro et les anti, car apparemment on a pas le droit d’être juste perplexe, je suis certain de savoir de quel côté est la violence des mots.

sur ce à la prochaine.

Sinon moi je ne fais pas de développement, alors ce serait bien qu'on arrête de passer du temps sur ces absurdités de IDE et autre RAD et qu'on revienne à des choses simples et prouvées telles que Emacs/Vim, un Makefile fait à la main, et la compilation en ligne de commande dans un autre terminal. Ça a marché pendant des années, c'est le summum de la souplesse parce qu'il n'y a aucun cas de figure qui ne soit pas faisable, alors qu'un outil d'aide au développement peut mettre des restrictions à cause de conventions ou de la logique interne.

Je trouve ton analogie excellente. Dans un cas, tu as un produit globalement fini, mais limité par design. De l'autre tu as un outil tellement ouvert qu'il a l'air inaccessible.

Que certains préfère une solution plutôt que l'autre justifie-t-il de traiter les minoritaires de relou, réfractaire, etc. ?

Salut,
Pour aider la mise à jour de OSM, y-a-t-il une application adroid ayant une interface très simple, utilisable en conduisant.
Du genre :

1. Choix d'une couche (ex: vitesse limite)
2. Affichage de l'information actuelle en fonction de la couche en cours.
3. Un affichage des limitations possibles.
4. On appuie directement sur la limitation de vitesse en cours, et au moment des changement.

OSM tracker n'est pas mal, mais je n'ai pas trouvé comment faire en conduisant en sécurité.

Chez moi aussi, pas de ralentissement…

Par contre, dans dolphin, la recherche n'a pas l'air au top… du coup c'est activé, mais mes amis reste find et grep.

Je me vois mal faire du ssh client sur un serveur mail ou web.

Mais telnet oui. euh… OK, tu évites bien soigneusement de répondre à la question, c'est un signe.

Non, tu n'as pas compris la réponse. Je t'invite a essayer : telnet www.google.fr 80 puis GET index.html (ou quelque chose de proche).

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…

C'est amusant, il y a deux cas :
* Les scripts c'est pourri par ce que quand on connaît pas ça semble compliqué.
* Systemd c'est simple.

Sauf que moi, je connais et comprends les scripts. Le fait que les métadonnées ne pouvait être destinées qu'à un outil client te semble évident parce que tu connais l'outil. Admettre que tout n'est pas limpide pour quelqu'un qui ne connais pas l'outil est trop dur pour votre égo ?

gentoo utilise des « runlevel » nommé par exemple.

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

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

a 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.

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

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/

on est d'accord que c'est positif?
Ta tournure de phrase laisse penser que c'est négatif pour une fonctionnalité qui participe à la stabilité d'un OS en production

Bah, oui je suis un peu dubitatif.
Ok, ça apporte de la stabilité au système, mais il y a le risque de masquer un bug, qui pourra avoir d'autres effets de bord moins visibles mais plus grave à long terme…

Je pense que nous ne parlons pas exactement de la même chose… Je parle de : Processus Zombie.

Toi tu me parles d'un démon type apache qui démarre 20 processus fils. Et dans certains cas, si on tue le père, certains fils peuvent migré vers le nouveau père supérieur (PID1) sans être tué. Si c'est ça, systemD fait office de garde pour les bugs des démons du système. Bug qui seront encore plus difficile à repérer puisque masqué par cette fonctionnalité.

Ai-je bien compris ?

Tu as déjà essayé de compiler Linux avec autre chose que GCC?

Non. Mon propos était juste de relever un argument fallacieux, et pas de dire que c'était mal. Je t'aide :

Le code est aussi plus moderne et agréable que ce que j'ai pu lire ailleurs. Par exemple, ça utilise largement des fonctionnalités de gcc…

Pour justifier un code /moderne et agréable/, ça utilise des spécificité du compilateur. Je trouve la justification mauvaise je ne réagissais que la dessus.
Je comprends la phrase comme : Pour avoir un code moderne et agréable il faut faire fi des standard et utiliser les extensions de gcc.

Par exemple, ça utilise largement des fonctionnalités de gcc

Je ne suis pas certain que ça prouve que le code est génial…

• Si tu veux laisser le langage gérer ta RAM utilise java ;
• Utiliser des extension d'un compilateur empêche d'utiliser les autres… pas très libre dans l'esprit

Oups, un zombie

Sous UNIX, et c'est vrai sous Linux, tout processus qui se termine devient Zombie. Ensuite, c'est à son père de récupérer la valeur de retour. Une fois fait, le processus est réellement déchargé de la mémoire. Si le père en question meurt, c'est au /grand-père/ de lire les valeurs de retour. Et ainsi de suite jusqu'au PID 1 Dieu et maître, père de tous qui doit acquiter tout les zombies qui lui arrive.

Tout ça pour dire que dire que les processus Zombies sont une marque de mauvais système d'init me semble capilotracté.

Pardon, ma femme est prof des écoles, directrice de son école. Et je t'affirme que ceci est du délire. Ce qui a été demandé c'est d'éviter les stéréotypes par ex : si en maternelle un enseignant a besoin d'un pompier, pourquoi prendre un homme ? Ce qui est demandé c'est de proposer une image avec une femme, une autre fois avec un homme.

Faut arrêter le délire.

Cette manie d'oublier Slackware… Linux ce n'est pas que Debian/*buntu/RedHat.

Cette manie d’oublier gentoo… Linux ce n’est pas que Debian/*buntu/RedHat/Slackware ;-)

En fait, je répondais uniquement pour :

Je commence à configurer jack, et je découvre que le cgroup qui m'intéresse n'est pas dans le kernel Debian. Je ne souhaite pas utiliser un kernel temps réel car avec les cgroups je peux obtenir la même chose, du temps réel pour mes applications audio, et en même temps avoir la stabilité à toute épreuve d'un kernel vanilla.

J’ai cru comprendre, que tu avais besoin que « jack » soit exécuté en priorité. Donc je proposais une solution sans les cgroups, ni de noyau RT, les noyaux Linux intègrent automatiquement (il me semble) les schedulling de POSIX. Je ne connais pas les cgroups, et pour une fois, je ne voulais pas entrer dans une discussion systemD… juste t’apporter une solution potentielle. J’ai déjà utilisé ça pour jouer à un jeu en attendant la mise à jour de KDE sur ma gentoo ;-)

Le scheduler temps réel est intégré. Il suffit d'utiliser schedtool.

$ schedtool -F -p  30 <pid>

La seule chose, c'est que le noyau sera prioritaire sur ton process.

Pour jouer aux jeux windows, il faut avoir une machine sous windows et envoyer en streaming sur la machine SteamOS. Savez-vous si on peut suggérer une installation de WINE aux petits oignons dans steamOS ?
Je ne suis pas sûr que ce soit dans leur intérêt.