• [^] # Re: Le thread dont vous éte le Mollah

    Posté par (site web personnel) . En réponse au journal udev forké. Évalué à 2.

    les serveurs n'ont pas besoin de systemd (les quelques secondes de gagnées ne valent pas
    la simplicité de corriger le démarrage s'il y a un problème),

    Je sais pas pour toi, mais moi, sur mes serveurs, pouvoir avoir un /tmp séparé par service ( directive privateTmp de systemd ), pouvoir retirer le réseau d'un daemon ( PrivateNetwork ), mettre une partie du FS en readonly voir le faire disparaitre , bref tout ce qui est mis ici : http://0pointer.de/blog/projects/security.html et le faire facilement avec 1 ligne, ça me parait pas mal. Libre à toi de croire ensuite que ton serveur ne va pas en tirer un bénéfice. résumer systemd a "ça boute plus vite", c'est faire preuve d'un sacré manque de curiosité.

    Sinon :

    Mise à jour du noyau à chaud

    Y a ksplice. Grande nouvelle, c'est le merdier car tu dois connaitre la version exacte du noyau que tu as pour faire un patch qui va modifier les structures à la volée. Sinon, tu as le hurd qui propose ça via son architecture de micronoyau.

    Support veille en RAM et veille sur disque fonctionnel

    La veille en ram marche parfaitement sur mon portable lenovo, donc le souci est du coté du hardware,
    pas du software.
    Le suspend hybride existe aussi : http://daniel.hahler.de/use-hybrid-suspend-method-by-default
    Ma suggestion est donc de mieux choisir ton matos.

    Vérification, réduction et agrandissement du système de fichier en ligne

    Resize2fs le fait depuis le kernel 2.6.14, sauf erreur de ma part.XFS le fait aussi depuis longtemps. Et lvm permet de retailler les partitions depuis toujours. Grub 2 propose le but sur une machine en lvm pur ( avec raid et chiffrement, etc ). Toutes les distros supportent lvm et ext2 ou plus. Donc faut juste que tu fasses l'installation comme il faut.

    Ajout et suppression de composant matériel à chaud (y compris processeur et RAM)

    Premier lien sur google pour le cpu hotplug :
    http://www.cyberciti.biz/faq/debian-rhel-centos-redhat-suse-hotplug-cpu/
    Si tu veux tester, il faut par contre du hardware qui le supporte, genre sans doute du hardware virtuel.

    Pareil, memory hotplug, supporté par linux depuis des années :
    http://www.kernel.org/doc/Documentation/memory-hotplug.txt

    Je vais pas énumérer les composants, mais je sais que alsa supporte l'ajour de carte son ( et pulseaudio gére ça aussi dynamiquement, que ça soit un appareil genre apple airport, un écouteur bluetooth ou de l'usb ), qu'on peut rajouter des cartes réseaux de tout type, des periphs d'entrées de tout types, et qu'au final, c'est rarement coté soft que le souci se pose.

    Donc si tu as besoin de rajouter des cpus à chaud, je te propose en effet de virtualiser plus. Ou d'acheter du matos qui supporte ( genre les serveurs haut de gammes IBMs s/390 etc )

    Migration d'un système automatique depuis un disque vers un autre

    Process par process, tu as des trucs genre cryopid

    Pour l’intégration au kernel, il y a des efforts depuis des années :
    http://lwn.net/Articles/478111/
    http://lwn.net/Articles/375855/

    Dragonfly bsd le propose aussi, d'ailleurs :
    http://leaf.dragonflybsd.org/cgi/web-man?command=checkpoint&section=ANY

    Et pour tout un systéme, tu as la migration de vm de qemu/kvm
    http://www.linux-kvm.org/page/Migration

    Donc installe juste tes machines comme noeud d'un cluster ovirt, archipel ou autre, et tu pourras migrer tes systémes. ( alors oui, y a un overhead mais on peut pas tout avoir )

    Globalement, sur toutes les améliorations que tu demandes, toute sauf une sont déjà la. Certaines sont bloqués par d'autres choses genre le matériel ( non existant autre que dans une vm ou sans doute plus cher ) genre l'archi du truc ( le hurd étant pas réputé terrible niveau perf, ksplice étant ultra spécifique à chaque update ).