Quoi, des IPCs sur un serveur. Mais aucune boite n'oserait proposé ça. Ah si, Sun l'a fait avec rpc. Et aussi Microsoft avec Samba, dans une moindre mesure. Et puis, des IPCs dans unix, ben y a que ça. Et puis, des interfaces RESTs aussi. Et puis des appels à distances erlang pour ejabberd.
Soit on fait un systeme sans meta data ( genre signaux, /dev/initctl ), soit on fait un truc plus riche car on a des trucs plus riche à gérer. À partir de la, reprendre l'existant est semble t'il meilleur que repartir de 0.
Le fait de compiler en désactivant les assertions est aussi possible, IIRC. Donc ( si je me trompe pas ) c'est charge aux distros de rendre systemd plus tolérant.
# Un systéme d'ipc sur un seveur OMG
Posté par Misc (site web personnel) . En réponse au journal systemd est un "bloat". Évalué à 8.
Quoi, des IPCs sur un serveur. Mais aucune boite n'oserait proposé ça. Ah si, Sun l'a fait avec rpc. Et aussi Microsoft avec Samba, dans une moindre mesure. Et puis, des IPCs dans unix, ben y a que ça. Et puis, des interfaces RESTs aussi. Et puis des appels à distances erlang pour ejabberd.
Soit on fait un systeme sans meta data ( genre signaux, /dev/initctl ), soit on fait un truc plus riche car on a des trucs plus riche à gérer. À partir de la, reprendre l'existant est semble t'il meilleur que repartir de 0.
Concernant l'assertion, il s'agit d'un vrai bug corrigé :
http://cgit.freedesktop.org/systemd/commit/?id=a133bf10d09f788079b82f63faa7058a27ba310b
Le fait de compiler en désactivant les assertions est aussi possible, IIRC. Donc ( si je me trompe pas ) c'est charge aux distros de rendre systemd plus tolérant.