mknodes fonctionne toujours e la même manière. Et tu peux modifier ton initrd pour le faire inside, ça fonctionne toujours aussi, ça. Tu peux donner un exemple précis ? Parceque la généralité est fausse, mais il est probable que tu ai des exemples bien vrais.
Cas typique, quand on branche une clef USB sur un Linux je veux les actions suivantes :
- Création d'un device basé sur un identifiant unique de la clef (par exemple son numéro de série)
- Scan de la clef pour chercher la présence d'un certificat
- Validation du certificat et démontage du device
- Montage du device sur un emplacement device précis en read only.
- montage du FS de la clef à un endroit précis.
Le truc de base qui te permet d'avoir un certificat à un emplacement fixe pour que Java puisse le chopper facilement. Et là c'est devenu une galère intégrale. Sur chaque variante de Linux il faut écrire un code différent, contourner les règles udev du système, parfois blacklister des devices. Et après avoir écrit deux pages de scripts, de règles udev et de contournements tu as généralement une mise à jour toute con qui vient te foutre ton système en l'air.
Tout ce dont j'ai réellement besoin c'est d'un moyen de pouvoir à DBus, HAL, Gnome, et tout un tas d'automounter : "vos gueule, vous touchez pas aux block devices". Mais ce moyen n'existe pas. Je peux dire à Udev de ne pas traiter l'ensemble des clef USB de marque Toto construite avant 2008, mais je ne peux pas dire à HAL de ne pas lancer d'évènement, je ne peux pas dire à DBus d'ignorer ces évènements si ils sont lancer et de ne pas les retransmettre. C'est juste gavant.
on peut utiliser soit le fichier de config à l'ancienne,
Dans pas mal de distribs, on ne peut plus. Tu peux faire ce que tu veux dans ton xorg.conf, le système en prendra en compte une partie, ou rien. D'autres parties ont étés éclatés à gauche et à droite (mention spéciale à monitor.xml sous ubuntu), d'autres encore sont régénérées à tous les boots, à peu près quoi que tu fasses.
Sans compter la cerise sur le gateau, dans les distribs "modernes" pour le desktop (Fedora, Ubuntu, OpenSuse de mémoire) si pendant que tu testes ta config le serveur X ne démarre pas, immédiatement un machin chose va se lancer automatiquement pour refaire ta config tout seul comme un grand ET ECRASER TOUTES TES MODIFS.
En plus en cas de mise à jour un peu importante de X11, le machin chose (qui est chiant à trouver, chiant à gicler) est réinstallé et lancer en mode forcé au prochain reboot. Et une fois de plus tu es bon pour refaire toute ta config.
Je crois que X11 sous Fedora c'est le seul truc qui m’ait fait dire que je regrettais les macros M4 de sendmail.
gni ? udev est génial pour ça. Pourquoi cherches tu à le remplacer ?
Mais je veux pas le remplacer, CF plus haut. J'adore udev. Maintenant si le couple HAL(ou devicekit)+DBus pouvait fermer sa gueule et le laisser bosser, ca me ferait vraiment plaisir. Et devine quoi ? SystemD dialogue avec DBus/HAL ou DBus/devicekit, pas à coup de probes sur les devices mappings.
_Ouf, networkmanager n'est pas aussi envhaissant que kms et xrandr. Suffit de le virer du boot (il y a vraiment des gens l'utilisant ici ??) _
Perso j'en suis là, je vire cette saleté dès que j'ai les mains dessus. Le problème c'est en prise de main à distance, gicler network manager à distance ca demande beaucoup de concentration pour ne rien oublier qui empêchera le réseau de remonter. Maintenant RHEL et Fedora râlent pas mal quand tu leur arraches NM. Et à la mauvaise installation du mauvais package il revient en force.
Je sens juste que ça va être de plus en plus dur de s'en passer, et ça m'énerve parce que c'est un truc qui ne me sert à rien et qui me bloque tout le temps...
non, le boot systemd prend en condition des spécifités du noyau linux, et c'est bien normal
Je n'ai pas dit que la solution SystemD n'utilisait pas de spécificité Linux, j'ai dit que dans le cadre d'un init ces spécificités étaient inutiles. Pire elles sont dangereuses, la tentation est grande de faire dans SystemD des opérations qui devraient être faite par le daemon lui même. Quand je vois les fonctionnalités de SystemD je me dis que pour faire fonctionner un serveur logique autrement que comme l'a voulu le packageur ca va devenir coton. Vrai beaux jeu de pistes en prévision.
[^] # Re: Ça sent le réchauffé...
Posté par Kaane . En réponse au journal The destructive desktop — Linux in trouble?. Évalué à 10.
mknodes fonctionne toujours e la même manière. Et tu peux modifier ton initrd pour le faire inside, ça fonctionne toujours aussi, ça. Tu peux donner un exemple précis ? Parceque la généralité est fausse, mais il est probable que tu ai des exemples bien vrais.
Cas typique, quand on branche une clef USB sur un Linux je veux les actions suivantes :
- Création d'un device basé sur un identifiant unique de la clef (par exemple son numéro de série)
- Scan de la clef pour chercher la présence d'un certificat
- Validation du certificat et démontage du device
- Montage du device sur un emplacement device précis en read only.
- montage du FS de la clef à un endroit précis.
Le truc de base qui te permet d'avoir un certificat à un emplacement fixe pour que Java puisse le chopper facilement. Et là c'est devenu une galère intégrale. Sur chaque variante de Linux il faut écrire un code différent, contourner les règles udev du système, parfois blacklister des devices. Et après avoir écrit deux pages de scripts, de règles udev et de contournements tu as généralement une mise à jour toute con qui vient te foutre ton système en l'air.
Tout ce dont j'ai réellement besoin c'est d'un moyen de pouvoir à DBus, HAL, Gnome, et tout un tas d'automounter : "vos gueule, vous touchez pas aux block devices". Mais ce moyen n'existe pas. Je peux dire à Udev de ne pas traiter l'ensemble des clef USB de marque Toto construite avant 2008, mais je ne peux pas dire à HAL de ne pas lancer d'évènement, je ne peux pas dire à DBus d'ignorer ces évènements si ils sont lancer et de ne pas les retransmettre. C'est juste gavant.
on peut utiliser soit le fichier de config à l'ancienne,
Dans pas mal de distribs, on ne peut plus. Tu peux faire ce que tu veux dans ton xorg.conf, le système en prendra en compte une partie, ou rien. D'autres parties ont étés éclatés à gauche et à droite (mention spéciale à monitor.xml sous ubuntu), d'autres encore sont régénérées à tous les boots, à peu près quoi que tu fasses.
Sans compter la cerise sur le gateau, dans les distribs "modernes" pour le desktop (Fedora, Ubuntu, OpenSuse de mémoire) si pendant que tu testes ta config le serveur X ne démarre pas, immédiatement un machin chose va se lancer automatiquement pour refaire ta config tout seul comme un grand ET ECRASER TOUTES TES MODIFS.
En plus en cas de mise à jour un peu importante de X11, le machin chose (qui est chiant à trouver, chiant à gicler) est réinstallé et lancer en mode forcé au prochain reboot. Et une fois de plus tu es bon pour refaire toute ta config.
Je crois que X11 sous Fedora c'est le seul truc qui m’ait fait dire que je regrettais les macros M4 de sendmail.
gni ? udev est génial pour ça. Pourquoi cherches tu à le remplacer ?
Mais je veux pas le remplacer, CF plus haut. J'adore udev. Maintenant si le couple HAL(ou devicekit)+DBus pouvait fermer sa gueule et le laisser bosser, ca me ferait vraiment plaisir. Et devine quoi ? SystemD dialogue avec DBus/HAL ou DBus/devicekit, pas à coup de probes sur les devices mappings.
_Ouf, networkmanager n'est pas aussi envhaissant que kms et xrandr. Suffit de le virer du boot (il y a vraiment des gens l'utilisant ici ??) _
Perso j'en suis là, je vire cette saleté dès que j'ai les mains dessus. Le problème c'est en prise de main à distance, gicler network manager à distance ca demande beaucoup de concentration pour ne rien oublier qui empêchera le réseau de remonter. Maintenant RHEL et Fedora râlent pas mal quand tu leur arraches NM. Et à la mauvaise installation du mauvais package il revient en force.
Je sens juste que ça va être de plus en plus dur de s'en passer, et ça m'énerve parce que c'est un truc qui ne me sert à rien et qui me bloque tout le temps...
non, le boot systemd prend en condition des spécifités du noyau linux, et c'est bien normal
Je n'ai pas dit que la solution SystemD n'utilisait pas de spécificité Linux, j'ai dit que dans le cadre d'un init ces spécificités étaient inutiles. Pire elles sont dangereuses, la tentation est grande de faire dans SystemD des opérations qui devraient être faite par le daemon lui même. Quand je vois les fonctionnalités de SystemD je me dis que pour faire fonctionner un serveur logique autrement que comme l'a voulu le packageur ca va devenir coton. Vrai beaux jeu de pistes en prévision.