freem a écrit 5059 commentaires

Il y avait bien le film Hackers.

J'ai ri.
Je pense ne l'avoir vu la 1ère fois qu'après l'arrivée du 56K chez moi, et a ce moment je connaissais déjà 3 langages de programmation, y compris l'asm, justement pour désassembler innocemment les programmes des autres :)

Mac Gyver

Ah oui tiens. On pourrait ajouter Géo Trouvetout du coup, j'imagine. Pareil, le «métier d'inventeur» me fascinait. Mais bon, que ce soit Mac Gyver ou Géo Trouvetout, ce n'étaient pas des informaticiens. Mac, surtout, est pas super souvent au bureau XD

Dans les deux cas il y a quand même pas mal la notion de créer des objets, donc ça serait plus des modèles d'électronicien, d'électricien, de mécanicien… pas d'informatique.

Dans mon cas, je me souviens exactement quand j'ai décidé de devenir dev. 0 informaticien dans la famille et les connaissances, le seul lien que j'avais avec l'ordinateur était quelques jeux vidéo sur le PC familial, et une NES morte des années plus tôt.
J'ignorais tout de ce qu'étais écrire un programme avant d'arriver en 2nd, ou un prof que je n'aimais pas (d'habitude, je suis allergique a tout ce que cette catégorie de prof essaie de m'inculquer…) nous a appris les grandes lignes de QBasic (une version périmée depuis 15 ans à ce moment). Peu de temps après je squattais les PCs du CDI (au lieu de la bibliothèque) et un camarade m'apprenais à utiliser les mails et google, et on a écumé le web francophone pour choper des bouts de code et tutoriels pour faire des trucs graphiques sympa.
Si modèle j'ai eu, il est super bien planqué… même les livres (incluant pas mal de SF) que j'ai lus jusque la ne mentionnaient probablement pas d'informaticiens (j'en ai pas souvenir).

Perso, je ne pense pas que l'on ait besoin d'un modèle pour décider de sa carrière. Si ça avait été le cas, j'aurai été électricien ou aurait bossé sur les chantiers. Ce qui ne me déplairait pas, honnêtement, et ça finira peut-être même ainsi, mais mon choix de l'informatique… nope. Surtout avec toute l'insistance autour de moi pour que je "lâche l'ordinateur".

Je pense en fait que pouvoir choisir son métier sans modèle, ça s'applique à tous les domaines. Je ne pense pas que mon ascensoriste de frère ait eu un modèle: il à fait de l'électrotech parce que c'était ce qui le saoulait le moins au lycées, et à trouvé un taf avec des hauts et des bas (comme il dit). Point final.

En fait, je me demande même si ceux qui choisissent leurs métiers par rapport à un modèle, ça serait pas une minorité?
Est-ce si déconnant que ça de choisir une orientation simplement par rapport à des problématiques d'apprécier ou non les longues études, d'apprécier ou non l'activité d'un domaine, de la facilité à trouver un boulot dans un domaine?
Sans pour autant marcher dans les traces d'un «modèle» (le seul de ma fratrie qui à potentiellement "suivi" un modèle, c'est celui qui en a eu marre de l'interim et fait un CAP d'électricien, encore que, finalement il est plus maçon qu'autre chose donc ça colle toujours pas).

Si utiliser un lanceur est assez rare sous Linux

Unvanquished n'est pas le seul jeu que je connaisse qui ait ça… planeshift, ryzom, notamment, utilisent également des lanceurs, idem pour des jeux proprio que j'ai pu voir et qui ont besoin de MàJ fréquentes.
J'en ai vu d'autres, mais je ne me rappelle plus leurs nom, les autres laissant l'utilisateur se démerder lui-même et appeler son admin pour installer les paquets systèmes.
Et veut-on vraiment des jeux aussi volumineux qu'unvanquished dans son /usr?
Pas moi.
Certains paquets balancent les données dans /var, d'autres /usr/games, mais voila, dans tous les cas il faut être admin et avoir une partoche dédiée sinon une MàJ qui ajoute un peu trop de contenu, et ça va vite, fait péter le système, surtout avec la tendance moderne à fusionner / et /usr.

Je vois.

La cli est répétable et scriptable ce qui ne fonctionne généralement pas bien dès qu'on utilise du curses

Du coup, tu considères que les outils comme fdisk rentrent dans les TUI ou non? (à noter qu'il existe sfdisk en pure CLI et que je préfère largement, mais je le soupçonne moins connu, ainsi que cfdisk (découvert à l'instant pour raison de typo) qui est clairement un TUI)
Parce que si oui, une partie de tes outils sont scriptables via, par exemple, expect.

Idéalement, je préfère le GUI au TUI, sauf si j'ai besoin de pouvoir faire tourner l'appli sur une machine distante. Et pour traiter de grosses quantités d'informations une fois, je préfère les UI au CLI. Quand j'ai besoin d'automatiser ou de reproduire, j'utilise l'UI pour identifier les données et les actions à effectuer, ainsi que pour tester rapidement si j'arrive au résultat escompté, et ensuite j'utilise la ligne de commande pour faire mon script.
Pour de petites tâches ponctuelles, la CLI est effectivement souvent ce que je vais utiliser.

D'ailleurs, c'est bien pour ça que j'aime zsh: "cd d/p/t" -> "cd devel/projects/tools" est devenu vital pour moi. Une seule tab, pas d'addon. Simple (histoire de parler un peu du nal quand même).

Mais du coup, est-ce bien catholique tout ça? Non, parce que je trouve que ça a un côté impie moi..

Oups, en effet.

TUI quoi? Hum… d'ailleurs, tu as essayé d'utiliser sed pour éditer tes fichiers? Ou bien ed, peut-être? Je suis curieux.

… mais non.

À la place, l'article indique un certain nombres de problèmes certes intéressants, mais qui n'expliquent pas l'incendie qui à eu lieu.
Le seul point qu'éventuellement une conformité nickel aurait pu améliorer c'est que les salles de batteries auraient pris feu moins vite, et que les pompiers auraient pu mieux intervenir, ce qui aurait peut-être pu circonscrire les dégâts.

Il est à noter que l'article mentionne que, au moment de l'inspection, certains des points d'anomalie étaient déjà en cours de correction, notamment, "le bassin de confinement des eaux d'extinction" était "travaux en cours dès parution de l'arrêté préfectoral", ce qui me semble quand même indiquer un effort réel pour être conforme, surtout quand on voit le prix des travaux indiqués par l'article: au moins 2.9 millions d'euros.
Je n'ai pas lu les rapports du coup, les points cités par le JDN ne me semblant que peu liés à l'incident (principalement liés au risque foudre, je ne connais pas son importance dans la région en question, mais je ne crois pas que l'incendie était lié à un orage, si?), et vu qu'on a un manque (voire absence totale?) de recul sur la situation des autres, ça me semble pas pertinent.

Sinon: je préviens les autres lecteurs, ce lien semble partir en couille chez moi, le JS force à télécharger automatiquement des PDF dans le même onglet, du coup il faut se battre à coup de retour arrière et arrêt de chargement de la page pour espérer lire tout.

Mais ca aidera pas d'oublier que la plupart des applications sont beaucoup plus complexes, que ce soit pour les fonctionnalités ou la sécurité.

Je ne sais pas si c'est la plupart, vraiment.
Après, le problème c'set que je ne sais pas comment il mesure, notamment, il n'est dit nulle part si c'est la mémoire résidente, ou la mémoire partagée qui est affichée. C'est vraiment très, très différent, même si 150Mo c'est de toute façon trop pour un clavier à mon avis.

Perso, quand je mesure, je préfère me concentrer sur le RSS, la mémoire résidente réservée à l'application en question. C'est bien souvent plusieurs ordres de grandeur en-dessous, et je pense plus révélateur, même si le VSZ permets d'estimer un peu le besoin de l'application si elle était seule sur le système.
De toute façon, les 2 sont à prendre avec des pincettes.

Sous Linux, avec l'OOM Killer activé, malloc ne retourne jamais NULL. Et donc les applications n'ont aucune chance de pouvoir intercepter et traiter l'erreur. Elles se font tuer directement

C'est un peu (mais alors vraiment «un peu» hein, pas beaucoup) plus subtil que ça.
De mémoire, l'overcommit à 3 réglages:

0
Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default.

1
Always overcommit. Appropriate for some scientific applications. Classic example is code using sparse arrays and just relying on the virtual memory consisting almost entirely of zero pages.

2
Don’t overcommit. The total address space commit for the system is not permitted to exceed swap + a configurable amount (default is 50%) of physical RAM. Depending on the amount you use, in most situations this means a process will not be killed while accessing pages but will receive errors on memory allocation as appropriate.

Trad grossière:

0: rejet des demandes ridicules, c'est à dire supérieure à un seuil réglable.
1: plus de mémoire? Rien à foutre, en voici.
2: pas d'overcommit, mon préféré pour tout système sur lequel je fais des trucs que j'ai pas envie de perdre pour cause de freeze.

Après, il paraît, mais j'ai plus le lien, qu'ils ont corrigé le problème de l'oomkiller qui se déclenchait trop tard. Perso, je m'en fout, j'ai toujours considéré cette feature comme un appel à coder comme des porcs, chose que je ne considère pas normale. Perso, je préfère un système prévisible, qui ne tuera pas au hasard une application critique parce qu'elle ose accéder à un espace mémoire que le noyau lui à pourtant réservé ni ne partira en thrashing.

Bref, c'est une galère?

Juste pour information, je précise pour le lecteur intéressé par Fortran :

Merci pour les correctifs!

1. Il est effectivement déconseillé, sauf exception, en calcul numérique d'utiliser ce test d'égalité avec des réels flottants,

C'est valable pour tous les langages, en fait. C'est quoi déjà… la norme IEEE? Un truc du genre? Bref, avec laquelle il faut éviter ce genre de choses.

Les compilateurs Fortran afficheront d'ailleurs en général un avertissement pour un tel test.

Idem pour C et C++, mais bon, c'est peut-être plus récent, ça ne serait pas surprenant.

le calcul numérique c'est l'art d'obtenir un résultat valable en calculant faux.

De toute manière, une fois qu'on passe dans le monde réel, les résultats sont systématiquement approximés quand il y a trop de chiffres. De mémoire, la notation ingénieur qu'on m'apprenais au lycée était du genre: 123,45 * 10^6.
Le souci, c'est qu'a ma connaissance, peu de langages ont un opérateur et un typage adapté aux flottants (en vrai, à ma connaissance, aucun, mais elle est si limitée qu'elle est sûrement fausse, j'ai donc approximé en "peu" à la place :p).

Ça dépend.

Il y a l'impression de particulier et d'administration, pour lesquelles une qualité grossière fait largement le boulot.
Ça, ça marche plutôt pas mal avec des pilotes libres.

Il y a l'impression professionnelle, pour la com' en gros, qui doit être propre. C'est un métier à part entière, qui inclue la mise en page, les couleurs, etc. Je ne sais pas si c'est pointu, je ne connais pas.

Puis, il y a les interfaces utilisateur pour imprimer. Et la, c'est la cata. De ce que j'en sais, autant dans le libre que le non-libre.

Par contre, il me semble que ce dont parle l'auteur, c'est bien d'avoir vraiment une imprimante open-hardware, et… bon, bah… ça m'a pas l'air si simple que ça.
Les imprimantes 3D, leurs utilisateurs savent qu'ils vont bricoler avec, que c'est un usage spécifique, qu'il faut des étapes entre le dessin et l'impression (compilation en gcode, via slic3r par exemple).
Cette complexité réelle est probablement vraie aussi pour les imprimantes papier:

• il y a autant d'axes après tout, sur du jet d'encre… (la cartouche bouge sur les 3 axes relativement à la feuille)
• pire, on mélange les couleurs (le multi-mat existe sur la prusa, mais c'est pas du mélange)
• et pour finir, on se prend pas la tête avec une génération de g-code, d'autant qu'on ne voudrait pas exposer ça à l'utilisateur

Par contre, il doit être possible de convertir une imprimante 3D en écrivain automatique, il suffirait de remplacer la tête par des stylos, après tout, pour avoir un truc théoriquement exploitable :D

J'oubliais:

À la fois quand on calcul une fonction trigonométrique, la seule façon rationnelle c'est d'utiliser les radians. Sinon il faut convertir.

Et les conversions, c'est irrationnel?
Pour moi, ce qui est irrationnel, c'est d'optimiser avant d'avoir un code lisible et facile à comprendre.
Hors, je trouve qu'il est plus simple de comprendre:

aim.angle += 45;
if ( aim.angle == 90 ) then
 ...
end if

que

aim.angle += PI / 4;
if ( abs( aim.angle - PI / 2 ) <= epsilon( aim.angle ) ) then
  ...
end if

Bon, évidemment, ça va dépendre du domaine, mais ce bout de code tout à fait rencontrable dans la vie réelle (peut-être pas actuellement avec fortran, mais justement, fortran n'est pas vraiment le langage le plus simple à rencontrer je dirais). Toute ressemblance directe avec un truc sur lequel je bosse est purement fortuite, bien sûr.

J'ai essayé en fortran, pas l'habitude, désolé si la syntaxe est pas bonne. Je me suis "inspiré" (méchamment copié à ce stade) d'un stackoverflow sur la très célèbre question de la comparaison des flottants, version fortran.

des gens n'ayant pas encore oublié le programme de mathématique de collège

Justement. Au collège, je ne savais même pas qu'il existait d'autres unité d'angles que le degré.

On peut toujours utiliser abiword et gnumeric pour de la petite bureautique

On n'en parle pas assez, mais ils sont vraiment très bien en plus, ces logiciels. Ils répondent largement aux besoin de monsieur tout-le-monde, et sont, au moins en terme de poids de stockage, nettement plus léger que leurs versions LO (important en campagne, avec un réseau de merde).

Bon, on l'a déjà vu ce lien, comme dit plus bas, et dans l'ensemble, je ne dirais pas être d'accord avec tout, mais la boulimie des programmes me paraît quand même évidente.

Pour le citer:

L’application clavier de Google consomme constamment 150 Mo de mémoire. Est-ce qu’une application qui dessine 30 caractères sur un écran est réellement cinq fois plus complexe que Windows 95 tout entier ?

Perso, je ne crois pas a ton argument de la sécurité la :)

Tiens, example tout con, à mon dernier taf, mon patron voulait une sorte de Kiosque (mobilier urbain), un truc con hein, qui remplace un afficheur 4 lignes 20 colonnes, un pavé tactile 12 touches et 4 sets de 3 diodes, juste utiliser un écran tactile 800 par 600 à la place (bon, et se débarrasser d'une liaison RS232 ainsi que d'un équipement à la stabilité douteuse, je pense).

La première tentative à été d'utiliser ÉtronJS (c'est de la ça exactement que viens ma haine pour cette merde, et c'est la seule «tech» à déclencher en moi un sentiment de dégoût, même systemd j'arrive à le défendre et accepterais de l'utiliser si payé pour, c'est dire!), ce qui implique donc d'avoir Xorg.
Ben, entre les SIGILL, les plantages non identifiés, les freezes, les 80Mio de stockage compressé (et donc de transfert sur des petits forfaits de moins d'une 100aine de megs/mois) et autres emmerdes causées par le Xorg, ça a été un fiasco.
Ça ressemblait probablement à cette fameux appli clavier de google…

La 2nde solution à été de passer par la SDL2 en mode framebuffer. Pas franchement terrible non plus, parce que cette lib invite les gens à l'over-engineering, on le sent, que ça gère l'OpenGL, vraiment.
Sauf qu'en fait, on s'en foutait, de l'OpenGL, on voulait un truc simple et rapide. Et le pire, c'est que ça gérait même pas correctement la dalle tactile!
Bref, le code "final" était… pas réutilisable.

La 3ème (et dernière à ma connaissance, j'irai passer sur une borne pour vérifier, un de ces 4) solution à été:

• libinput parce que le tactile c'est chiant
• /usr/include/linux/fb.h
• implémentation manuelle des fontes PSF1 et PSF2
• implémentation manuelle des rotations (obligé, la dalle tactile avait 270° de rotation, la graphique 90°) et d'une transparence simple en software (rendu d'une image complète de 800x600 inférieure à 20ms sauf si abus de widgets transparents)

Au final, ma solution ne marcherait pas pour une UI classique, forcément, pas de problème a partager l'espace avec d'autres applications, par exemple.

Par contre:

• le code de la lib est lisible en entier en moins d'une journée (surface d'attaque)
• un développeur junior est capable de comprendre comment elle fonctionne (vérifié) avec peu d'aide (maintenabilité…)
• la taille de l'application avec images et symboles debug est inférieure à 10megs (je prend large, ça date, et oui je mesurais, pour cause de contraintes réseau: faut l'envoyer, en 2G dans l'Eure, le binaire hein…),
• ça juste marche.
• moins de fonctionnalités potentielles: fontes PSF1 et PSF2 uniquement, faut oublier les anti-alias, les vidéos, les pdf, les fondu… qui ne sont peut-être pas si utiles que ça?
• moins de 20Mio de RAM allouée (Beaucoup moins. Je prend large, parce que j'ai plus accès et que je me base sur ma mémoire)
• moins de 2 mois pour avoir la lib et les premières versions de l'application fonctionnelles (pas parfaites, mais fonctionnelles, ce qui était le but premier: avoir un truc qui marche, vite, parce que les clients commençaient à râler fort, très, très fort)

Tout ça, malgré un code au final pas opti du tout (tant sur la RAM que sur le CPU, je sais ou il est possible d'optimiser sévèrement… à commencer par ne pas refaire une image qui n'a pas été changée, ou mettre à jour sur les zones altérées…)

Si le code était libre, je te mettrai au défi de trouver une faille de sécurité dans la lib qui gérait les widgets (donc, le rendu et les entrées, c'est codé en C++ donc moins de fuites mémoire potentielles qu'en C :p).

En terme de temps de rendu, afficher une trame et faire le job derrière en mono-process, mono-thread, c'était moins de 20ms, à cause de la transparence et des rotations (ça coûte cher, très cher, une transposition de tableau quand, comme moi, on n'a jamais sérieusement touché aux matrices et seulement 10 ans avant). Juste la rotation, c'était moins de 10ms (oui, la transparence à été implémentée avec un if sur chaque pixel, histoire de tuer le CPU). À peu près (pour 480K pixels, hein) les deux tiers du temps comparé à:

les éditeurs de textes modernes ne peuvent pas le faire en 16 ms.

Je ne connais pas ses règles, mais force est de constater qu'il existe des programmes pour faire (mieux) le boulot à sa place, parce que faire confiance à l'oomkiller du noyau, c'est s'exposer au thrashing.

Personnellement, je désactive l'overcommit, ce qui est une solution comme une autre.
D'autres ont implémenté et utilisent earlyoom, qui est sûrement une meilleure solution puisque ça évite que des veaux comme les navigateurs webs ne se «ferment» régulièrement parce que malloc commence subitement à faire son job et que les devs ont pas vérifié son retour, ou alors ont juste fait un if( NULL == ( lol = maloc( ul ) ) ){ abort(); } en appellant ça de la gestion… (ça, c'est quand c'est bien foutu, après tout, sinon c'est segfault par déréférencement de nullptr).

M'enfin, je suis d'accord: il est prévisible, l'oomkiller: il attend que ton système deviennent inutilisable (non, tu peux pas, dans ce cas, basculer sur un TTY pour tuer un truc toi-même: j'ai bien dit inutilisable) avant d'intervenir. De toutes les occurrences de l'oomkiller, en fait, ce comportement en décrit 95%. Expérience pure debian, donc peut-être que d'autres distro le configurent mieux, j'en sais.

Oui, et surtout… il est bien plus facile de visualiser 90° que PI/2 rad. Ou est-ce PI/4? Je me souviens jamais, tellement j'utilise souvent les radians. Bon, je suis pas vraiment un matheux, je le reconnais.

un flottant, avec le risque d'erreurs d'arrondi

D'ailleurs, je me pose tout le temps la question, au point d'en être arrivé à fuir les flottants autant que faire se peut, c'est quoi qu'il faut utiliser pour tester une égalité? Je veux dire, la valeur qu'il faut utiliser pour dire "+- foo", c'est combien?

PI cumule les tares : il est irrationnel

C'est limite un truc que j'ai tendance à appliquer aux matheux de manière générale XD /me ->[]

Voila qui serait une BELLE innovation qui pourrait faire le buz !

Pas une innovation, d'autres le font déjà, et depuis longtemps.

Ben, tu prends aussi des trucs système qui vérifie si systemd existe avant de lancer la tâche, ça complique évidemment les choses

Pas vraiment. Le problème de balancer un one-liner proviens du fait que cron exécute directement un shell, j'imagine. En soit, je trouve que c'est déjà une erreur, moi, il ne devrais pas être nécessaire de passer par /bin/sh comme intermédiaire. Oui, ça impliquerais que les scripts seraient des fichiers séparés, probablement one-liners, mais ça éviterais ce cas précis (tout en supprimant une couche d'exécution, cela dit, puisque ce serait alors uniquement le noyau qui ferait l'exécution, qu'il fera de toute façon).

Mon reproche est plutôt de la sorte de mélopée qui précède la commande: un nombre variable de nombres, qui peuvent parfois être des astérisques.
Je comprend bien que je ne suis pas un habitué des crontabs, mais voila, je trouve 0 * * * * incompréhensible moi. Quand je lis ça, j'ai besoin d'aller lire la page du manuel. En soit, ce n'est pas un drame de devoir aller lire la doc, mais voila on ne parle pas vraiment d'une doc super claire. Ah, pardon, peut-être celle-ci… nope, celle-la? Ah, oui, enfin!
La description de la partie la moins lisible est au milieu du bouzin, et ça deviens fun quand on commence à jouer avec les intervalles et les listes.
J'allais dire qu'il n'y a même pas d'exemple, ce qui eut été faux:

EXAMPLE CRON FILE         top
       # use /bin/sh to run commands, no matter what /etc/passwd says
       SHELL=/bin/sh
       # mail any output to `paul', no matter whose crontab this is
       MAILTO=paul
       #
       CRON_TZ=Japan
       # run five minutes after midnight, every day
       5 0 * * *       $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
       # run at 2:15pm on the first of every month -- output mailed to paul
       15 14 1 * *     $HOME/bin/monthly
       # run at 10 pm on weekdays, annoy Joe
       0 22 * * 1-5    mail -s "It's 10pm" joe%Joe,%%Where are your kids?%
       23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday"
       5 4 * * sun     echo "run at 5 after 4 every sunday"

La, on commence a voir à quel point tout ça est lisible, en effet. Oui, c'est ironique.
C'est concis, ça oui, clairement, mais lisibilité s'en ressens pas mal, je trouve. Après, oui, je suis d'accord, ma solution custom (et dégueu) n'est pas idéale non plus, systemd n'est pas non plus parfait, chacun à ses forces, mais je préfère vraiment éviter cron, j'ai toujours peur qu'il me pète à la gueule.

dans systemd, tu dois te taper 10 lignes réparties dans 2 fichiers au minimum.

Je reconnais ne pas connaître les détails pour systemd, c'est peut-être moins concis, certes, je n'ai personnellement pas de bonne solution pour ça (ne faisant que très très rarement des planification de tâches, et jamais avec systemd).
Par contre, pour cron, j'ai ce genre de choses:

% cat /etc/cron.d/e2scrub_all 
30 3 * * 0 root test -e /run/systemd/system || SERVICE_MODE=1 /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron
10 3 * * * root test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r

Désolé, mais… j'ose espérer que systemd à quand même une config plus lisible.
Je préfère un truc verveux (bon, que ça soit coupé en 2 fichiers c'est dommage par contre) plutôt qu'un one-liner illisible sans être lourdement commenté (encore, ici, «la chance!» seul root est utilisé, donc tout s'aligne, et il n'y a que 2 lignes…).

Les rares fois ou je dois utiliser cron, je lis le manuel, plusieurs fois pour être sûr, puis j'écris une ligne, et je la relis plusieurs fois, en comptant les espaces…
Idéalement, je teste sur plusieurs périodes (jours/heures… pour les semaines ou les mois, c'est pas possible, et je crois qu'il peut pas gérer les années) que ça fonctionne vraiment, et dans tous les cas, je serre les fesses de pas m'être raté.

Le tout, alors que fonctionnellement le but est simplement de gérer des processus et leurs journaux, ce qui est très clairement du ressort d'outils comme systemd ou les daemontools (sauf que eux n'ont pas cette fonctionnalité, sauf peut-être nosh?).
J'ai beau ne pas être fan de systemd, il me semble difficile de considérer que sysVinit+rc.d+cron est une solution magnifique.
daemontools|runit + cron est un peu moins bancal, mais on se tape quand même le fait que les gestionnaires de processus sont incapables de planifier la gestion de processus, ce qui est pourtant leur coeur de métier…

En pratique, si ma machine est censée fonctionner non-stop, plutôt qu'installer cron, je préfère faire ça:

#!/bin/sh
#./run

# une "lib" de 26 lignes que je me suis faite
. /etc/runit/common

echo "starting $SVNAME"

test -e ./conf || die "config not found"

exec $COMMAND

#!/bin/sh
#./finish

. /etc/runit/common
test -e ./conf || die "config not found"

sleep $PERIOD

#./conf
PERIOD="1d"
COMMAND="foobar"

Ces fichiers sont placés dans un dossier type /etc/sv/task_$foo, qui contiens un sous dossier log, qui contiens un fichier run qui est un symlink vers /etc/runit/log.run.
Du coup, ça fait pas mal de monde pour de simple tâches planifiées.

Le résultat est moins bon et moins puissant qu'avec systemd (en plus ça pourrit mon arbo de processus :/) ou cron (sans parler d'anacron!), mais…
Comparé à cron, j'ai nettement plus confiance dans le fonctionnement ainsi qu'une meilleure facilité pour consulter les journaux d'une tâche spécifique.

Par chance je n'ai que rarement besoin d'y avoir recours. Sinon, le poids sur le système pourrais devenir problématique (dans le cas de runsvdir, il lance à chaque fois un processus pour gérer le daemon lui-même, et un autre pour les logs, ça fait donc 2 processus constants pour des tâches qui ne nécessitent des ressources que ponctuellement. Ce n'est pas énorme, mais c'est tout de même dommage de gaspiller, et ça ne se mets pas à l'échelle, contrairement à cron ou… systemd.)

Ici, je pense que systemd gagne haut la main.

Pas systemd, certes, mais j'utilise le même genre de choses.

Pour être plus explicite, voici mon .xinitrc actuel, bien que je pense migrer certaines choses vers ~/.profile ou équivalent, voire trouver une meilleure solution, plus portable, parce que les shell sont des horreurs de ce point de vue:

export SVDIR=$HOME/.config/services
runsvdir -P $SVDIR ............................................................ &
xrandr --output HDMI-3 --right-of HDMI-2
#urxvtd -o &
#unclutter -idle 2 -jitter 2 &
setxkbmap fr 
#(pidof mpd > /dev/null || mpd --no-daemon ~/.config/mpd/mpd.conf --stderr) &
xosview &
#claws-mail &
#/bigfiles/$USER/contrib/quassel/build/quasselclient &
numlockx on
exec ssh-agent chpst -P i3

Toutes les lignes zombifiées (d'ailleurs, c'est l'occasion de les virer, je devrais peut-être également ajouter xosview, je ne sais pas trop, il n'est pas vraiment critique à mon usage…), en fait, elles sont maintenant gérées par runsvdir.

Cela permets une vraie facilité de gestion et d'intégration, totalement indépendante de mon gestionnaire de fenêtres ou de mon bureau, ainsi que des avantages propres à diverses catégories d'outils:

• mpd: tendance à planter quand interruption de connexion réseau (locale ou distance) lors de écoute de webradio;
• unclutter: conflits avec certains jeux et applications qui capturent la souris;
• toute application que je pourrais fermer par accident alors que j'ai besoin de la présence continuelle, telle que le MUA ou le client IRC, ou encore urxvtd;

Au final, avec le temps je m'aperçois que j'utilise de plus en plus le mécanisme de gestion des daemon de mon système pour des tâches liées à l'utilisateur.
Ce n'est pas spécifique à systemd (puisque je n'utilise pas), de fait, mais je trouve ce type d'usage très pertinent et puissant, peu importe l'implémentation. Par contre, rien de tout ça n'est aisément réalisable avec l'ancêtre sysVinit et cette pile de shell qu'est rc.d (sans parler de la taille des scripts à écrire! beurk!).

Sur mon serveur perso, j'ai simplement créé une service runsvidir par mon utilisateur, ce qui semble être un équivalent de systemd --user, vu que pas de session interactive sur le serveur.

Tant qu'a avoir un outil qui gère les processus, je dirais que d'y intégrer le planificateur de tâche (qui gère des processus) fait clairement sens.
Surtout quand on voit la gueule de la config de cron…