La bonne question, c'est : quel est le prochain morceau un peu vieillissant du système que Lennart va pourrir ?
Moi je parierais sur le shell, je le sens bien nous sortir lesh (LEnnart's SHell) qui casserait tous les scripts POSIX mais qui serait tellement plus bien mieux et qui serait par défaut sur Fedora parce qu'on s'apercevrait que pour systemd, les trucs existants ne sont pas suffisant donc il faudra un shell, et donc ça sera une dépendance obligatoire de systemd ! Dans lesh, toutes les commande usuelles (ls, mkdir, ps, etc) seront des commandes interne pour éviter d'augmenter le numéro de PID, mais bien sûr incompatibles au niveau des options avec les commandes POSIX, sinon c'est pas drôle.
Ou alors, il va s'attaquer à cron et at, pour fusionner les alarmes utilisateurs et les alarmes systèmes, avec un système de droits particuliers pour pas mélanger les deux (ben oui, il faut bien créer le problème pour le résoudre). Ce daemon gèrera en fait tout le temps sur le système et donc la mise à jour du temps via NTP pour ne pas perturber les alarmes. Et puis comme il y a des problèmes avec tzdata en ce moment, il va reproposer un autre truc pour ça, et obliger l'ISO et les gouvernements à s'aligner sur son idée (ben quoi, c'est ça le chemin vers maître du monde !), en tout cas, ça sera implémenté dans sa solution globale.
# Et après ?
Posté par rewind (Mastodon) . En réponse au journal Lennart casse les logs!. Évalué à 9.
La bonne question, c'est : quel est le prochain morceau un peu vieillissant du système que Lennart va pourrir ?
Moi je parierais sur le shell, je le sens bien nous sortir lesh (LEnnart's SHell) qui casserait tous les scripts POSIX mais qui serait tellement plus bien mieux et qui serait par défaut sur Fedora parce qu'on s'apercevrait que pour systemd, les trucs existants ne sont pas suffisant donc il faudra un shell, et donc ça sera une dépendance obligatoire de systemd ! Dans lesh, toutes les commande usuelles (ls, mkdir, ps, etc) seront des commandes interne pour éviter d'augmenter le numéro de PID, mais bien sûr incompatibles au niveau des options avec les commandes POSIX, sinon c'est pas drôle.
Ou alors, il va s'attaquer à cron et at, pour fusionner les alarmes utilisateurs et les alarmes systèmes, avec un système de droits particuliers pour pas mélanger les deux (ben oui, il faut bien créer le problème pour le résoudre). Ce daemon gèrera en fait tout le temps sur le système et donc la mise à jour du temps via NTP pour ne pas perturber les alarmes. Et puis comme il y a des problèmes avec tzdata en ce moment, il va reproposer un autre truc pour ça, et obliger l'ISO et les gouvernements à s'aligner sur son idée (ben quoi, c'est ça le chemin vers maître du monde !), en tout cas, ça sera implémenté dans sa solution globale.
D'autres idées ?