Moonz a écrit 3621 commentaires

N’importe quel développeur système et/ou administrateur sait que 0600 c’est "lecture-écriture pour l’utilisateur, rien pour les autres". Demander d’expliciter ça ce serait un peu comme demander d’expliciter i++ en i = i + 1 (puis râler parce que 1 est une valeur magique et qu’il faudrait définir une constante LOOP_INCREMENT)

Tu copies la réponse de Microsoft sur le boot sur un autre OS, la ;-).

Je ne comprend pas du tout votre analogie. Depuis quand Microsoft interdit le dual-boot ?

Il faut voir les objectifs du projet. systemd a ouvertement choisi de privilégier l’unification/uniformisation (/run obligatoire n’en est qu’un des aspects), une intégration forte avec le reste de l’écosystème et la maintenabilité (supporte uniquement toolchain, libs et kernel « standards » et récents) au prix de la portabilité et de la souplesse. On peut ne pas être d’accord avec la pertinence à long terme de ces choix, mais il est clair que hardcoder des chemins est totalement cohérent avec ces choix.

Ils n’ont pas fait l’économie d’une tonne de #ifdef dans le code pour le plaisir de réintroduire leurs propres constantes derrière…

self/maps est virtuel mais /proc ne l’est pas. Tu peux très bien faire (en root) :

mkdir /processes
mount -t proc proc /processes

Ou que systemd n’est pas fait pour toi.

• l'opposé du retour de get_ctty_devnr si ce retour est positif

Je pense que tu viens de trouver un bug dans systemd, je mettrai ma main au feu qu’il devrait renvoyer la valeur de retour de get_ctty_devnr si ce retour est négatif.

Tu voudrais quoi ? Une option de compilation SYSTEMD_RUN_PATH ? Quel en serait l’intérêt, à quelle problématique cela répondrait ?

Les blocks avec {} ou pas suivant si il y a plusieurs lignes ou pas, c'est aussi le coding style utilisé pour le kernel. Mais personne ne parle de code spaghetti pour le kernel. Et le niveau d'imbrication ne me semble pas non plus extraordinaire.

Heu, le if (flag_file) me semble pas très catholique même pour les guides de style acceptant de ne pas mettre d’accolades pour les blocs mono-instruction.

4 return, alors qu'il y a un free(p) qui traine

p est alloué par asprintf, donc aucun problème, il ne fuite jamais.

D'après ce que je comprends, la sémantique de ce que retourne la fonction dépend du fait que la fonction ait rencontré une erreur ou non. Bof, hein. sqrt(4) renvoie 2, mais sqrt(-4) renvoie -1, parce que -1 est un code d'erreur.

C’est une convention très répandue en programmation système en C de renvoyer -errno en cas d’erreur, sans aller chercher très loin c’est le cas de FUSE par exemple.

Des magic values 0700, 0600.

Ce n’est pas "magique", c’est les permissions, et à peu près tout le monde fait comme ça.

Et puis, nous sommes linuxiens, nous sommes libristes, et donc plus universalistes que communautaristes, plus Stéphane Laborde que Lionel Dricot.

Vachement sympathique pour Dricot et son implication dans le logiciel libre, il sera ravi d’apprendre qu’il n’est pas libriste…

J’en sais rien non plus mais si ça permet d’avoir une meilleure éducation partout à long/moyen terme je ne vois pas où est le problème.

Ben tiens, « réactionnaire réfractaire au changement qui veut pas changer ses habitudes » c’est pas une insulte ?

PERSONNNE ne vous oblige à l'utiliser

De fait la principale inquiétude des « anti-systemd primaires réactionnaires » comme moi n’est pas tant systemd en lui même (qui est un soft que j’aime bien) que le processus de vampirisation de tout l’écosystème linux derrière (udev, dbus, logind, bientôt wayland) qui va rendre la possibilité de concurrence bien plus complexe.

http://code.activestate.com/recipes/578528-type-checking-using-python-3x-annotations/

Les développeurs web étant rarement payés à la ligne il y a peu d’intérêt à Java dans ce monde là.

Non. Et alors ? on parlait des scripts d’init dans le sysv des distribs Linux des années 2000 non ?

Par curiosité, c’est quoi l’intérêt de lancer Firefox avec systemd ?

Plains toi aux autotools pour avoir lancé cette « mode » (probablement pour pouvoir tourner sur des systèmes antédiluviens). [ "$VAR" = "" ] ça marche très bien (et tu as un raccourci [ -z "$VAR" ] si tu as une âme de perleux).

Je tourne sous ArchLinux et j’avais ce bug jusqu’à la semaine dernière (bon, pas une journée, mais plusieurs minutes quand même pour l’arrêt)

Pour faire tourner un site statique avec Apache, il y aura uniquement les PID d'Apache dans votre containers et rien de plus (dans d'init, pas de Bash, de SSH…)

Est-ce que le processus qui tourne dans le conteneur est le PID 1 ? Si oui, je suppose qu’il est possible de lancer systemd ?

En fait ma question est plus : si on suppose que mon application est un service PHP/nginx/postgres, est-ce que je dois distribuer trois conteneurs (myapp-phpfpm, myapp-postgres, myapp-nginx) ou un seul myapp ?

Un container contient le binaire, pour le reste, il est préférable d'injecter la configuration, de monter de l'extérieur les répertoires contenant les données (DB généralement) et les logs

Est-ce que ce n’est pas un peu opposé à l’idée « déploiement en une commande » ?

Peu etre par ce que ces projets avaient d'autres problemes ?

launchd et smf étaient utilisés par Apple et Sun (oui, quand ils s’appelaient encore Sun). initng était parfaitement utilisable et très bien supporté par certaines distribs comme Gentoo.

Peu etre par ce que systemd ne fonctionne pas sur BSD, et par ce que personne n'a encore pris le temps d'implementer un equivalent ?

initng et launchd fonctionnaient sous BSD avant même que la première ligne de code de systemd soit écrite…

Et qu'ils ont d'autres raisons cachées ?

Pourquoi cachées ?

systemd gère mieux les cgroups et le multi-seat que n’importe quel autre de ses concurrents. Il a un système de templating extrêmement pratique. Il est aussi le projet qui exporte le plus de choses aux autres applications, d’où l’utilisation de cette API par Gnome, d’où une meilleure expérience utilisateur sur le desktop avec systemd.

Ça en fait des raisons largement suffisantes pour expliquer sont adoption massive, sans avoir à aller chercher des raisons comme « maintenir des scripts shell c’était trop dur », tu ne penses pas ?

Il y avait des tas de projets d’init bien avant systemd qui avaient pour simple but de remplacer les scripts init par des fichiers de conf et qui n’ont pas été adoptés par les mainteneurs (smf, launchd, upstart, pour n’en citer que les plus connus). Si la raison pour laquelle les mainteneurs ont choisi systemd c’est la simplicité de la maintenance des scripts, explique moi donc :

• pourquoi ils n’ont pas choisi un de ces projets il y a des années ? parce que le bash de 2009 était maintenable mais le bash de 2014 ne l’est plus ?
• pourquoi slackware, maintenu par une seule personne donc en première ligne pour les questions de difficulté de maintenance, veut retarder le plus possible son adoption ? masochisme ?
• pourquoi les BSD n’abandonnent pas les initscripts si c’est une telle charge de travail à maintenir ?

Vraiment, j’aimerais que tu m’expliques comment tu arrives à réconcilier ta théorie « les distribs migrent vers systemd parce que les .unit c’est plus maintenable que des scripts bash » avec ces faits.

Je vois que vous avez une haute estime des mainteneurs

Il ne t’est pas venu à l’esprit que ceux qui ont décidé de passer à systemd l’ont fait pour d’autres raisons que « c’est trop dur de maintenir des scripts shell » ?

(semi-troll: de toute façon c’est pas un pauvre script shell qui va faire peur à quelqu’un qui maintient des paquets deb/rpm quand on voit la simplicité de ces derniers…)

Oh mon Dieu, des bugs et des failles dans un logiciel, quelle horreur qui n’arrive que dans les projets inmaintenables !

Heureusement que systemd, étant bien codé lui, n’a aucun bug ni aucune faille de sécurité.

Aucun souci, sauf quand il faut tuer le processus. Oups, un zombie.

Heu, par définition (ou à moins d’un très grave bug dans le pid 1), si tu as un zombie c’est que ton processus est pas géré par le système d’init…

Aucun souci, sauf quand t'as oublié de gérer les fichues runlevels (heureusement qu'on n'utilise plus ça avec systemd)

Tu as les target qui ont exactement le même « problème » (qui n’en est pas un : si tu spécifies pas quand tu veux que ton script démarre ça me paraît normal que le système d’init le démarre pas, que ce soit systemd ou sysvinit)

Moi, j'en ai marre qu'on dise qu'avant c'était trop génial, que c'était simple et que ça faisait tout ce qu'on attend d'un OS moderne, non ça ne n'était pas simple, au contraire, et non ça ne faisait pas ce qu'on attend d'un OS moderne.

Il faut arrêter avec la mauvaise foi un peu.

Les initscripts ont été maintenus pendant des dizaines d’années sans aucun souci. Les BSD d’ailleurs n’ont pas l’air d’avoir envie de s’en départir, on devrait en déduire que ce sont des gros masochistes qui aiment le code inmaintenable ? (dans ce cas il faudra m’expliquer la décision de OpenBSD de sortir apache pour des raisons de trop grossos difficultés niveau maintenabilité tout en ne disant rien pour les initscripts…) Sans compter Slackware, distribution d’une seule personne qui a maintenu sans aucun souci tous les initscript de la distrib sans gros souci…

C’est pas parce que t’aime pas le shell que c’est pas maintenable, désolé. Sinon moi aussi je peux le faire : SAP essaie de s’éloigner de Windows donc j’en déduis qu Windows c’est pas maintenable.

Alors que les commandes de cron, à chaque je dois relire le manuel tellement c'est cryptique.

Je vois pas en quoi @hourly /usr/local/bin/myjob c’est cryptique.

Et je vois encore moins en quoi séparer ça en deux fichiers de plusieurs lignes est une avancée pour la simplicité d’utilisation et la maintenabilité.

Chaînes immutables = obligation d'en créer une nouvelle si on veut la modifier, pas d'effet de bord entre les fonctions ou entre les threads

Cet argument pourrait s’appliquer à tout objet…