En pratique, les russes parlent pas super bien anglais, et les gens d’Amérique du sud ne sont pas tous anglophones. Ceci dit, au delà du problème, moi, j'attends toujours :
1) les volontaires pour traduire les rapports de bugs dans une langue que je comprends ( des tentatives ont été faites, mais les gens qui râlent sont rarement ceux qui veulent donner du temps pour aider )
2) les cours de langues bénévoles et qui ne vont pa réduire mon temps de contribution pour que je puisse dialoguer avec tout le monde.
Car le coeur du souci est la, est ce que le temps d'un développeur est plus précieux que celui d'un utilisateur ?
Ou plutôt, combien de gens sont prêt à accepter d'entendre "non, je ne peux pas coder ça avant 2 ans ou répondr eà ton bug, car je suis parti apprendre l'espagnol, le chinois et le russe à temps plein"
La question que je me pose c'est ce que vont faire MIB (et consors ? il me semble qu'il y en a d'autres),
communauté indépendante très active, qui je pensais allait suivre mageia et finalement ne l'a pas fait.
MIB, c'est des têtes de pioches incapable de bosser en équipe si bosser en équipe veut dire "avoir des contraintes techniques au delà de leur compétences" ( exemple, utiliser un vcs digne de ce nom, comprendre pourquoi faut faire un paquet avec des patchs séparés, respecté les licences comme la GPL )
Donc en gros, avant, ils voulaient pas travailler avec la distro d'origine soit disant pour des raisons "c'est une entreprise", mais en fait, c'est faux. La preuve, en changeant le nom et la structure, ça n'a rien changé.
Et quand je vois leurs méthodes ( pas de bts, pas de suivi des paquets, systéme de build à la mano, modif sans raisons des specs, etc, etc ), je pense que de toute façon, la seule façon de bosser avec eux est de descendre le niveau de rigueur et donc de qualité.
De plus, tout les dépôts tierces parties publiques existent juste pour surcharger les paquets de la distro de base, principalement pour des raisons de politiques de packaging. Par exemple, dire "on fait pas de mises à jours de version disruptives dans une version stable", ou "on distribue pas des softs qu'on a pas le droit de distribuer", ou "on patche pas n'importe comment le kernel". Quand les gens sont pas foutus de suivre des règles choisis afin d'obtenir un but visé ( et je précise bien "but visé" car les régles sont pas mauvaises ou bonnes en elles mêmes, c'est juste des choix faits ), c'est pas un fork qui va changer grand chose, les gens seront toujours pas d'accord
avec le but, donc avec les méthodes pour l'obtenir.
Et il y a aussi le coté "j'ai mon propre dépôt" plus que "je bosse dans la masse".
Ce qu'il y a de nouveau, c'est la tentative de passer par du crowdsourcing autour de la popularité d'Ubuntu.
Et franchement, 1 million de dollar, ç'est d'un coté beaucoup ( si j'avais ça, je serais content ), et de l'autre, c'est 3 fois rien pour faire tenir une boite sur la durée. Quand je vois le temps et les tarifs pour les prototypes autour du GTA 4, et ce genre de projet, je me dit que le portable risque d'être soit obsolète à la sortie, soit de jamais sortir.
Et commencer par donner les prix sans avoir de prototypes, ça me parait curieux comme méthode ( no noteras qu'au contraire, aucune date de sortie n'est donné ).
Et du coup, je me pose des questions sur la boite. Fondé par un serial entrepreneur qui a fait 1 boite de voip il y a 7 ans et pas grand chose d'autres ?
Est ce que c'est juste moi qui connait pas l'industrie, ou est ce qu'on est face à un 2eme mark shuttleworth qui va investir dans un projet qui va tout changer ?
De ce qu'on m'a expliqué, le souci est que même dans ton bon droit, ça coute vachement cher d'aller au tribunal juste pour montrer que tu n'as rien fait.
En pratique, je conseille souvent de faire 2 niveau de bootloaders. 1 qui est sous le contrôle de l'admin, qui chainload vers X grubs pour chaque distribution ( installer sur la partoche racine de la distribution ).
Chaque distribution gére son bootloader sur sa partoche ( genre les mises à jours noyau ) et l'admin gère à la mano le grub primaire qui bascule sur les autres. Comme ça, il le change que si il y a une nouvelle distribution.
j'ai vu, mais j'avais pas lu tout le commentaire, tu as caché lvm à la fin :p
Je suis loin d'être un expert mais l'avantage c'est pas d'éviter de remplir la partition racine (/) ?
Ben remplir / en soit, ça veut pas dire grand chose. En fait, l'impact, c'est que si / est plein, alors tu peux supposer que tout en dessous est plein aussi, et donc, tu peux pas écrire dans /tmp, /var, /home sauf si ils sont séparés. Donc au final, il faut se dire "quel répertoire je suis susceptible de remplir et quel impact ça va avoir".
Remplir tout ton disque, ça peut empêcher divers choses :
- plus de logs en local
- des daemons qui se relance pas ( pas moyen d'écrire dans /var/lock ) ( même si avec /run en tmpfs, ç'est plus un souci )
- des opérations diverses qui échouent ( genre plus de place dans /tmp, gcc va pas marcher )
Donc à partir de la, tu évalues. Et par exemple, si tu fais un /var séparé, tu va toujours avoir le souci d'avoir des risques sur le fait d'avoir trop de log en cas de souci. Pire encore, tu va quand même impacter ta base postgresql si l'espace est partagé ( ie, pas de /var/lib/postgresql séparé ). Et tes daemons vont quand même se planter au lancement.
Alors qu'avec un / assez grand, tu évites pas les emmerdes, mais tu évites la gestion. Si tu veux éviter les emmerdes, c'est pas limiter l'espace qu'il faut faire, c'est surveiller la consommation ( munin, cacti, nagios, etc ).
Ensuite, je sais qu'il y a des gens qui préfèrent une autre façon de faire, ils ont le droit, j'ai pas la vérité absolu :) ( et y a sans doute des cas ou un contrôle plus fin est meilleur au final )
Je suis surpris que personne ne parle de LVM. Moi, en général, je fais juste / et /home ( et la swap ) en LVM, en mettant 8 et 20g, et quand j'ai besoin de plus, je retaille. Du coup, ça implique d'avoir un /boot hors du lvm ou de faire confiance à l'initrd ou grub2 pour booter en lvm directement ( et je suis un peu frileux, je laisse l'installeur faire le choix par défaut ).
Et on va me dire "pourquoi un /home de 20g si tu as surement plus ?". Parce que les données, c'est comme les gaz, ça prends toute la place qu'on leur donne. Si je me mets un /home de 500g, j'ai du coup besoin de faire un backup de 500g.
Avec du lvm, si j'ai des besoins, je rajoute à chaud ce qu'il me faut, à grand coup de lvextend et resize2fs.
Et je sépare pas toujours /var/ /usr/, /usr/local, /opt/. J'ai franchement pas vu trop l’intérêt au fil des années. Si /var est plein parce que les logs prennent toute la place, bah, avoir de la place sur /usr va pas m'aider. Si jamais tout est plein, je peux me logger quand même via un ssh. Donc au final, je pense qu'avoir des emmerdes de temps en temps ( car j'ai eu des partoches pleines comme tout le monde ) est un compromis acceptable par rapport au temps que je passe pas à optimiser à mort les partitions ou à me dire "ça, c'est plein, faut que j'agrandisse la partition"
Mais le fait de tout mettre dans /usr va peut être me faire changer d'avis, si on peut du coup faire des systèmes à peu de frais en dupliquant /usr entre des containeurs ( ceci dit, avec mount -o bind, on a pas besoin de partition non plus ).
ça marchait encore en 2.4 ( vu que je m'en suis servi il y a longtemps ), mais je confirme que ça a disparu y a une paire d'années déjà ( quand exactement, je sais pas )
En fait, soit je comprends pas ce que tu dis, soit j'ai une vision trop globale de selinux ( à mon avis, je pense que je comprends pas )
Si tu prends l'integration de selinux dans postgresql, on voit qu'on peut compartimenter au sein d'un programme ( en l'occurence, postgresql ) l'accés à des données internes ( en l'occurence, les bases ). Sauf erreur de ma part, ça se fait pas au niveau du filesystem, mais bien en interne : http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture
Du coup, si je pige bien, ce qui fait la spécificité de capsicum ( qui va aussi séparer les objets manipulé ), c'est le fait que la source primaire de la politique appliqué sur les objets soit le programme lui même ( via son code ), et pas une base de référence externe ( en l'occurence pour selinux, la politique compilé dans le kernel ).
Du coup, ça me fait me poser plus de questions, dans le sens ou séparer ton process en composant ( ie ce que le papier appelle "logical applications" ) reviens plus ou moins à refaire le travail de l'os ( qui sépare tout sous forme de process ), mais sans avoir les couts de communications ? Et dans ce cas, si tu part du principe que les différents composants, c'est comme les process, j'ai le sentiment qu'on a pas un truc si différent de l'existant, et que ça évite juste de refaire les outils ?
Sinon, c'est quoi la différence par rapport à apparmor, ou selinux ? Autant je voit le point de détail technique qui distingue apparmor de selinux ( path based vs attribut based ), autant je vois pas encore la différence fondamental entre capsicum et les 2 autres, car ça semble globalement faire pareil ( ie dire "tu as droit à ça ou pas à ça avec des objets de tel groupe" ).
Mon script est assez courant en fait (Utilisé par pas mal de gens qui ont soit un modem ADSL en usb soit une config
réseau sécurisé) et c'est un des gros points de ralage contre systemd.
Si c'est un gros point de ralage, tu va sans doute pouvoir donner des urls de tout ces gens qui ralent, voir un rapport de bug, qu'on puisse parler de trucs concrets, pas de "j'ai ce problème vague, et à chaque fois qu'un mec file une solution je sort un autre problème vague".
Figure toi que c'est ce que j'ai essayé de faire. Et systemd aime pas du tout la blague -
pour lui network ca veut dire pleins de choses et son comportement est étrange quand ça ne se passe pas comme prévu.
et
Mais j'ai besoin de network, c'est dans mon script network que je veux que TCP/IP arrive plus tard.
Et systemd est incompatible avec ce comportement.
Visiblement "avoir besoin de network", ça veut dire une chose bien précise pour toi, mais pas pour le reste du monde. Donc "avoir besoin de network", ça veut dire quoi pour toi ?
Pour systemd ( et j'aurais tendance à dire pour les systéme d'init depuis des années ), ça veut dire que le sous système network est la, genre tu as l'interface lo qui est disponible à minima, et un programme qui peut avoir besoin d'une interface réseau non spécifique va réussir à se lancer, et raisonnablement supposer que le routage marche pour aller sur internet ou le réseau local, si besoin.
( à noter que les softs qui dépendent d'une interface particulière ou qui doivent gérer des choses quand une ip arrive le font via un hook dans /etc/ )
pour la maintenance, non je pige toujours pas. Quand je fait ça, je modifie la config, et je fait un reload. Puis ensuite, je remets la config, et je fait un reload. Je vois même pas ce que systemed vient faire la, à part le fait que tu as du modifier les scripts d'init pour faire plus que ce qu'ils proposent de base. Donc si tu es parti sur "je refait les scripts d'init plutot que de faire un script de maintenance à part", oui, systemd n'a pas pour vocation de supporter tout ce que les gens ont pu faire de non standard.
Ça fait des années qu'on dit aux gens "faut passer par service car il nettoie l’environnement avant de lancer un script", si tu le fait pas et que tu rajoutes exprès des communications entre ton shell sous forme de variable et le script d'init, désolé, mais tu fais les choses de façon porcasse. Sinon, service ( la commande ) supporte des helpers scripts dans /usr/libexec/initscripts/legacy-actions ( au moins sur une fedora ), peut être que ça va répondre à tes besoins.
Et si tu doit faire les choses à la main vite fait, pour changer la config, un des trucs merveilleux d'unix, c'est "cp". Sinon, un autre truc merveilleux qu'on fait, c'est "puppet". Tu coupes puppet, tu changes ta config, tu fixes le truc, tu lances puppet, ta config se remets d'équerre ( si ta config puppet est bien faite, bien sur ). C'est un chouia plus moderne, mais ça marche pas mal pour gérer des gros clusters.
Bien sur, peut être que tu gères tes 40 services à la mano sans ça et que ça marche, mais ça veut pas dire que c'est efficace. La preuve, tu es obligé d'écrire des scripts d'init customs juste pour ça, ce qui est tant à démontrer que les scripts sysV ne répondent pas à tes besoins, vu que tu dois les patcher ( et genre,en patcher 40, ç'est pas rien ).
Enfin, pour ton truc qui lance des services super long à démarrer au point de confondre systemd, vu que la suggestion "utilise le fichier pid" semble pas te plaire, je propose plus simplement "sépare ton script en plusieurs unités systemd". Comme ça, tu as les dépendances ( genre le process qui fait le sync va déclencher automatiquement le demon ), systemd surveille un process à la fois. Je suis sur que ça va pas te plaire non plus, mais bon, j'aurais au moins tenté.
Et pour terminer, pour la partie sur sshd et tomcat. Si je comprends bien, c'est que tu veux dans certains cas que restart relance tout ( stop, start ), et dans d'autres cas, que ça relance rien ?
Pour sshd, c'est fait de base par la distro, via pam. Chaque process sshd est migré vers un autre cgroups à la connexion. Comme je suppose que tu va me dire "j'utilise pas pam" ( car j'ai bien compris que forcément, les trucs qui marchent sont interdit en faveur des solutions maisons chez toi ), l'autre méthode est de mettre KillMode=none ( ou KillMode=process ), et de tuer ce que tu veux quand tu fait le stop.
Pour tomcat, je suppose (parce que comme d'hab, tu dit rien de précis donc faut deviner), que le souci vient du fait que quand tu relances tomcat, tu veux pas relancer chaque appli qui tourne à l'intérieur mais faire les choses de façon plus fine. Pour ça, pareil, je pense qu'il faut traiter chaque applications comme un service séparé, et trouver le moyen d'intégrer ça à systemd ( par exemple, avoir un script dans ExecStart/ExecStop permet de le faire sans casse et je suis sur que tu as deja le scripts qui existe pour faire ça ).
Je crois que le souci est qu'on a pas l'air d'accord sur le mot "boilerplate", donc je vais donner ma définition, puis toi la tienne, et la, je vais pouvoir répondr eà ta question, car la, je la comprends pas.
Pour moi, le boilerplate, c'est tout les trucs inutiles que tu est obligé de copier partout mais que tu ne touche pas
Dans le cas d'un script d'init, c'est :
- la déclaration ". /etc/init.d/functions" ou équivalent, qu'on retrouve partout
- le gros case pour la lecture des arguments,
- la fonction restart, qui, sauf cas particulier, fait toujours start, stop
- la gestion des pids, des lockfiles, etc qu'on refait tous à la main à chaque fois
- la fonction qui affiche les actions du script.
tout ça, c'est des trucs qui sont, à défaut d'être pareil partout tout le temps, souvent copié coller, et ce que j'appelle le boilerplate. Si jamais je veux pouvoir dire "je lance tel truc dans un chroot", l'architecture actuel a base de shell fait que ça va sans doute coincer ( entre les scripts qui utilise une fonction shell spécifique, et ceux qui le font pas , par exemple ).
Donc voila, à toi de me dire ce que tu appelles "boilerplate", et me dire ce que ta question veux dire.
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)
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
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 ).
Suffit de lui demander, il traine sur irc ( genre, freenode, nick mezcalero ), il a un compte google plus, un email ( voir plusieurs ). tu peux aussi le trouver à des confs IRL genre le FOSDEM.
Ceci dit, aussi loin que je me souvienne, il avait déjà le même caractère quand il était étudiant ( au vue de la page http://0pointer.de/lennart/projects/atitvout/ vu que j'avais ça sur mon portable de l'époque )
En fait, c'est toujours pareil, tu dit "tel truc est déprécié", la plupart des gens font rien. Tu retires, ça crie de partout.
les scripts réseau de rh sont aussi ceux qui sont utilisés par les autres distros rpm-based, donc ça a migré également.
Les debians utilisent ifup, un executable, donc je suppose qu'il fait direct les appels aux ioctls ( comme NetworkManager, au passage ). j'ai trouvé encore des appels à la commande "route" ceci dit dans un script.
J'ai rien pigé au script de gentoo, donc je peux pas dire, mais je pense que ça a du être migré.
Au final, les distributions ont fait leur taf. Ce qui coince, c'est toujours pareil, c'est le reste du monde. Et qui doit faire le travail pour que d'autres puissent ne rien faire ? Les distributions… ( et souvent gratuitement, avec le sourire )
Il va pas démarrer, en effet. D'ailleurs, il y a eu des soucis avec lxc au début, car lxc utilise aussi les cgroups, et il y a eu clash sur l'usage en simultané des 2 ( souci corrigé depuis ).
Ceci dit, j'ai pour le moment vu personne se plaindre de ça à part toi, et bien que la remarque soit valable et génante pour ton usage, je pense qu'il y a donc un choix à faire sur ce que tu supportes en tant que distribution, et pour la plupart, l'usage en VPS est minoritaire AMHA.
Et arch aussi. Et tu noteras qu'il y a des distros commerciales comme Ubuntu qui n'ont pas suivi.
Donc on trouve grosso modo dans ceux qui proposent pas :
- Debian qui ne bascule pas car ils ont des raisons techniques ( kfreebsd, hurd )
- slackware et autres pour des questions de minimalisme
- gentoo qui le propose en option ( à la méthode gentoo )
- mint, parce que mint fait 0 devs sur la plateforme et fait juste de la repompe de ubuntu
- openembedded, pas de probléme avec hurd/kfreebsd, pas de souci de minimalisme => proposé en option comme gentoo
Du coté des autres distros à but commerciales, tu as :
- Ubuntu, qui le propose pas car ils ont leurs propres trucs, à savoir upstart ( upstart qui a été intégré dans RHEL et Fedora, mais personne ne va crier au complot dans ce cas la, car c'est juste quand un truc a du succès qu'il y a complot )
En gros, pour chaque distro qui propose pas, on trouve une raison de pas le faire.
Regardons maintenant les distros qui proposent :
- opensuse, mageia, fedora, mandriva, rosa => pas de souci techniques comme Debian ( ie linux only ), pas de souci de minimalisme comme lfs ( ie, udev, dbus sont déja la ), pas de système de boot maison aussi avancé comme Ubuntu
curieusement, aucune des raisons des autres ne s'appliquent. Donc la question est de savoir pourquoi est ce que :
- les distros n'ont pas décidé de faire leur truc
- les distros n'ont pas décidé de garder les anciens initscripts
Alors le 1, c'est simple, parce que ça coute des ressources. Et le 2, c'est simple, parce que personne n'a vraiment envie de s'occuper d'une grosse pile de trucs bash pour avoir en plus moins de fonctionnalités. Pour le moment, ça va, mais si dans 1 ou 2 ans, faut intégrer des nouveautés, ça devient vite galère.
Et peut être que l’intérêt est juste la, c'est de proposer un système qui correspond plus au besoin des mainteneurs ( genre, tu sais, les gens qui te file gratuitement leur boulot sous la forme d'une distribution ) et que c'est pour ça que les distros y passent ? Et parce que du coup, ça laisse du temps pour faire autre chose.
conclusion, on a une paire de distros qui n'ont pas de raisons de refuser un truc, pas envie de se taper le cout de maintenance du à une divergence, trouve des avantages à basculer et qui, du coup, bascule dessus.
1) les services avec des actions en plus ( genre, postgresql, dump de la db via le script d'init ).
C'est une chose qui fait pas stricto sensu parti du script d'init. En général, ça a été mis dedans parce le script d'init a besoin de la config du daemon, et sans doute pour des questions d'ergonomie et d'affordance ( ie, pour le modèle mentale de l'utilisateur, le script est la porte d'entrée sur la manipulation du daemon, un dump de la db est une manip de ce genre donc on rajoute la fonction )
Avec systemd, tu doit faire un script à part ( vu que tu peux pu intégrer ça dans le script principal ). Il y a un emplacement spécifique quand tu utilise ça avec service pour garder l'intégration ( genre service pgsql dump va appeler /XXX/pgsql/dump ). La différence entre "j'écris du code que je mets avec un case en plus dans un script" et "j'écris du code que je mets dans un fichier à un endroit spécifique" est pas flagrante. En fait, tu peux juste garder ton script d'init qui fait appel à ton 2eme script.
2) les services qui ne sont pas des daemons classiques. Exemple, tu as un truc à lancer au démarrage, mais c'est pas vraiment un daemon, c'est juste la configuration de l'affichage sur un ecran lcd 4" du nom de la machine ( le seul exemple que j'ai trouvé qui ne soit pas géré autrement ). En gros, tu doit lancer une paire de commande pour charger le matos, et lancer ce que tu veux écrire. Ben ça, oui, tu peux lancer un script shell, ou un programme en C. Ou tu peux lancer les commandes à la suite dans le fichier systemd, avec plusieurs lignes Execstart, en précisant "c'est normal si il reste aucun process à la fin" et "ne fait pas de tracking de PID". IE pour les actions spécifiques, rien n'empeche de faire encore du shell. Après tout, si le but est de lancer des softs, personne ne va vérifier si le soft est en C, en python, en perl, en bash ou autre. Donc pareil, si tu codes bien, tu as fichier que tu appelles depuis un script classiques ou systemd.
Maintenant, en pratique, j'ai du mal à voir ce qui requiert des dizaines de commandes spécifiques au boot, à part le réseau et perso, je pense que ça peut sans doute être mieux intégré et de plus haut niveau que sous la forme d'un script shell.
Mais du coup, est ce que tu penses à autre choses pour "besoins non spécifiques" ?
Bah, faut leur dire de mettre à jour leur site web :
"Ubuntu Server LTS is maintained with security updates and bug fixes for up to 60 months (five years) and Ubuntu Desktop LTS for up to 36 months (three years). However, stability doesn't need to mean stagnant systems."
[^] # Re: qui parle anglais
Posté par Misc (site web personnel) . En réponse à la dépêche Quoi de neuf chez Mandriva ?. Évalué à 3.
En pratique, les russes parlent pas super bien anglais, et les gens d’Amérique du sud ne sont pas tous anglophones. Ceci dit, au delà du problème, moi, j'attends toujours :
1) les volontaires pour traduire les rapports de bugs dans une langue que je comprends ( des tentatives ont été faites, mais les gens qui râlent sont rarement ceux qui veulent donner du temps pour aider )
2) les cours de langues bénévoles et qui ne vont pa réduire mon temps de contribution pour que je puisse dialoguer avec tout le monde.
Car le coeur du souci est la, est ce que le temps d'un développeur est plus précieux que celui d'un utilisateur ?
Ou plutôt, combien de gens sont prêt à accepter d'entendre "non, je ne peux pas coder ça avant 2 ans ou répondr eà ton bug, car je suis parti apprendre l'espagnol, le chinois et le russe à temps plein"
[^] # Re: Éclaircissement
Posté par Misc (site web personnel) . En réponse à la dépêche Quoi de neuf chez Mandriva ?. Évalué à 6.
MIB, c'est des têtes de pioches incapable de bosser en équipe si bosser en équipe veut dire "avoir des contraintes techniques au delà de leur compétences" ( exemple, utiliser un vcs digne de ce nom, comprendre pourquoi faut faire un paquet avec des patchs séparés, respecté les licences comme la GPL )
L'interaction avec certains d'entre eux est très difficile ( voir http://forum.mandriva.com/fr/viewtopic.php?f=137&t=125111 , https://qa.mandriva.com/show_bug.cgi?id=52856 ), qui sont de mauvaise foi sans borne, s'énervent pour un rien, glissent des attaques sans fondements.
Donc en gros, avant, ils voulaient pas travailler avec la distro d'origine soit disant pour des raisons "c'est une entreprise", mais en fait, c'est faux. La preuve, en changeant le nom et la structure, ça n'a rien changé.
Et quand je vois leurs méthodes ( pas de bts, pas de suivi des paquets, systéme de build à la mano, modif sans raisons des specs, etc, etc ), je pense que de toute façon, la seule façon de bosser avec eux est de descendre le niveau de rigueur et donc de qualité.
De plus, tout les dépôts tierces parties publiques existent juste pour surcharger les paquets de la distro de base, principalement pour des raisons de politiques de packaging. Par exemple, dire "on fait pas de mises à jours de version disruptives dans une version stable", ou "on distribue pas des softs qu'on a pas le droit de distribuer", ou "on patche pas n'importe comment le kernel". Quand les gens sont pas foutus de suivre des règles choisis afin d'obtenir un but visé ( et je précise bien "but visé" car les régles sont pas mauvaises ou bonnes en elles mêmes, c'est juste des choix faits ), c'est pas un fork qui va changer grand chose, les gens seront toujours pas d'accord
avec le but, donc avec les méthodes pour l'obtenir.
Et il y a aussi le coté "j'ai mon propre dépôt" plus que "je bosse dans la masse".
[^] # Re: ip6table dans Freebox ?
Posté par Misc (site web personnel) . En réponse au sondage Utilisez vous IPv6 ?. Évalué à 6.
Sinon, tu mets un firewall sur chaque bécane.
Ou tu mets une passerelle sous ton controle, pas du matos loué ou tu as pas assez la main.
[^] # Re: Padfone / Motorola Webtop
Posté par Misc (site web personnel) . En réponse au journal NexPhone : votre smartphone devient tablette, ordinateur portable et PC. Évalué à 3.
Ce qu'il y a de nouveau, c'est la tentative de passer par du crowdsourcing autour de la popularité d'Ubuntu.
Et franchement, 1 million de dollar, ç'est d'un coté beaucoup ( si j'avais ça, je serais content ), et de l'autre, c'est 3 fois rien pour faire tenir une boite sur la durée. Quand je vois le temps et les tarifs pour les prototypes autour du GTA 4, et ce genre de projet, je me dit que le portable risque d'être soit obsolète à la sortie, soit de jamais sortir.
Et commencer par donner les prix sans avoir de prototypes, ça me parait curieux comme méthode ( no noteras qu'au contraire, aucune date de sortie n'est donné ).
Et du coup, je me pose des questions sur la boite. Fondé par un serial entrepreneur qui a fait 1 boite de voip il y a 7 ans et pas grand chose d'autres ?
Est ce que c'est juste moi qui connait pas l'industrie, ou est ce qu'on est face à un 2eme mark shuttleworth qui va investir dans un projet qui va tout changer ?
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par Misc (site web personnel) . En réponse au journal Le codec audio libre Opus désormais normalisé. Évalué à 4.
De ce qu'on m'a expliqué, le souci est que même dans ton bon droit, ça coute vachement cher d'aller au tribunal juste pour montrer que tu n'as rien fait.
[^] # Re: Enfin !
Posté par Misc (site web personnel) . En réponse au journal H-48 avant le nouveau choc sur la planète high-tech. Évalué à 4.
Ou quand les autres le font, ou quand les distros linux le font sur les libs.
Ceci dit, c'est bien le souci, c'est que Apple n'est pas mieux que le reste de l'industrie, loin de l'excellence qu'on imagine d'une boite comme ça.
[^] # Re: Mes commentaires...
Posté par Misc (site web personnel) . En réponse au journal Un fstab bien configuré pour un ordinateur « de bureau ». Évalué à 4.
En pratique, je conseille souvent de faire 2 niveau de bootloaders. 1 qui est sous le contrôle de l'admin, qui chainload vers X grubs pour chaque distribution ( installer sur la partoche racine de la distribution ).
Chaque distribution gére son bootloader sur sa partoche ( genre les mises à jours noyau ) et l'admin gère à la mano le grub primaire qui bascule sur les autres. Comme ça, il le change que si il y a une nouvelle distribution.
[^] # Re: Mes commentaires...
Posté par Misc (site web personnel) . En réponse au journal Un fstab bien configuré pour un ordinateur « de bureau ». Évalué à 2.
Grub2 supporte luks ( en théorie ), donc ça devrait passer. ( et lvm, et le raid aussi )
[^] # Re: LVM ?
Posté par Misc (site web personnel) . En réponse au journal Un fstab bien configuré pour un ordinateur « de bureau ». Évalué à 5.
j'ai vu, mais j'avais pas lu tout le commentaire, tu as caché lvm à la fin :p
Ben remplir / en soit, ça veut pas dire grand chose. En fait, l'impact, c'est que si / est plein, alors tu peux supposer que tout en dessous est plein aussi, et donc, tu peux pas écrire dans /tmp, /var, /home sauf si ils sont séparés. Donc au final, il faut se dire "quel répertoire je suis susceptible de remplir et quel impact ça va avoir".
Remplir tout ton disque, ça peut empêcher divers choses :
- plus de logs en local
- des daemons qui se relance pas ( pas moyen d'écrire dans /var/lock ) ( même si avec /run en tmpfs, ç'est plus un souci )
- des opérations diverses qui échouent ( genre plus de place dans /tmp, gcc va pas marcher )
Donc à partir de la, tu évalues. Et par exemple, si tu fais un /var séparé, tu va toujours avoir le souci d'avoir des risques sur le fait d'avoir trop de log en cas de souci. Pire encore, tu va quand même impacter ta base postgresql si l'espace est partagé ( ie, pas de /var/lib/postgresql séparé ). Et tes daemons vont quand même se planter au lancement.
Alors qu'avec un / assez grand, tu évites pas les emmerdes, mais tu évites la gestion. Si tu veux éviter les emmerdes, c'est pas limiter l'espace qu'il faut faire, c'est surveiller la consommation ( munin, cacti, nagios, etc ).
Ensuite, je sais qu'il y a des gens qui préfèrent une autre façon de faire, ils ont le droit, j'ai pas la vérité absolu :) ( et y a sans doute des cas ou un contrôle plus fin est meilleur au final )
[^] # Re: Unity = Compiz Fusion ?
Posté par Misc (site web personnel) . En réponse au sondage Quel gestionnaire de fenêtres utilisez‐vous ?. Évalué à 1.
mais à terme, ça va passer sur llvmpipe, comme gnome-shell. Voir :
http://fedoraproject.org/wiki/Features/Gnome_shell_software_rendering
http://www.iloveubuntu.net/unity-2d-removed-ubuntu-1210-default
http://ubuntu.5.n6.nabble.com/Unity-Going-Forward-td4987911.html
# LVM ?
Posté par Misc (site web personnel) . En réponse au journal Un fstab bien configuré pour un ordinateur « de bureau ». Évalué à 6.
Je suis surpris que personne ne parle de LVM. Moi, en général, je fais juste / et /home ( et la swap ) en LVM, en mettant 8 et 20g, et quand j'ai besoin de plus, je retaille. Du coup, ça implique d'avoir un /boot hors du lvm ou de faire confiance à l'initrd ou grub2 pour booter en lvm directement ( et je suis un peu frileux, je laisse l'installeur faire le choix par défaut ).
Et on va me dire "pourquoi un /home de 20g si tu as surement plus ?". Parce que les données, c'est comme les gaz, ça prends toute la place qu'on leur donne. Si je me mets un /home de 500g, j'ai du coup besoin de faire un backup de 500g.
Avec du lvm, si j'ai des besoins, je rajoute à chaud ce qu'il me faut, à grand coup de lvextend et resize2fs.
Et je sépare pas toujours /var/ /usr/, /usr/local, /opt/. J'ai franchement pas vu trop l’intérêt au fil des années. Si /var est plein parce que les logs prennent toute la place, bah, avoir de la place sur /usr va pas m'aider. Si jamais tout est plein, je peux me logger quand même via un ssh. Donc au final, je pense qu'avoir des emmerdes de temps en temps ( car j'ai eu des partoches pleines comme tout le monde ) est un compromis acceptable par rapport au temps que je passe pas à optimiser à mort les partitions ou à me dire "ça, c'est plein, faut que j'agrandisse la partition"
Mais le fait de tout mettre dans /usr va peut être me faire changer d'avis, si on peut du coup faire des systèmes à peu de frais en dupliquant /usr entre des containeurs ( ceci dit, avec mount -o bind, on a pas besoin de partition non plus ).
[^] # Re: noatime, noexec
Posté par Misc (site web personnel) . En réponse au journal Un fstab bien configuré pour un ordinateur « de bureau ». Évalué à 2.
ça marchait encore en 2.4 ( vu que je m'en suis servi il y a longtemps ), mais je confirme que ça a disparu y a une paire d'années déjà ( quand exactement, je sais pas )
[^] # Re: Capsicum
Posté par Misc (site web personnel) . En réponse au journal Un article sur le sandboxing de Chrome sous Linux. Évalué à 2.
En fait, soit je comprends pas ce que tu dis, soit j'ai une vision trop globale de selinux ( à mon avis, je pense que je comprends pas )
Si tu prends l'integration de selinux dans postgresql, on voit qu'on peut compartimenter au sein d'un programme ( en l'occurence, postgresql ) l'accés à des données internes ( en l'occurence, les bases ). Sauf erreur de ma part, ça se fait pas au niveau du filesystem, mais bien en interne :
http://wiki.postgresql.org/wiki/SEPostgreSQL_Architecture
Du coup, si je pige bien, ce qui fait la spécificité de capsicum ( qui va aussi séparer les objets manipulé ), c'est le fait que la source primaire de la politique appliqué sur les objets soit le programme lui même ( via son code ), et pas une base de référence externe ( en l'occurence pour selinux, la politique compilé dans le kernel ).
Du coup, ça me fait me poser plus de questions, dans le sens ou séparer ton process en composant ( ie ce que le papier appelle "logical applications" ) reviens plus ou moins à refaire le travail de l'os ( qui sépare tout sous forme de process ), mais sans avoir les couts de communications ? Et dans ce cas, si tu part du principe que les différents composants, c'est comme les process, j'ai le sentiment qu'on a pas un truc si différent de l'existant, et que ça évite juste de refaire les outils ?
[^] # Re: Capsicum
Posté par Misc (site web personnel) . En réponse au journal Un article sur le sandboxing de Chrome sous Linux. Évalué à 2.
Attends, tu aurais pu relancer le troll systemd avec juste ça :
http://lwn.net/Articles/507067/
Sinon, c'est quoi la différence par rapport à apparmor, ou selinux ? Autant je voit le point de détail technique qui distingue apparmor de selinux ( path based vs attribut based ), autant je vois pas encore la différence fondamental entre capsicum et les 2 autres, car ça semble globalement faire pareil ( ie dire "tu as droit à ça ou pas à ça avec des objets de tel groupe" ).
[^] # Re: Questions
Posté par Misc (site web personnel) . En réponse au journal Linux from scratch face à udev. Évalué à 2.
Si c'est un gros point de ralage, tu va sans doute pouvoir donner des urls de tout ces gens qui ralent, voir un rapport de bug, qu'on puisse parler de trucs concrets, pas de "j'ai ce problème vague, et à chaque fois qu'un mec file une solution je sort un autre problème vague".
et
Visiblement "avoir besoin de network", ça veut dire une chose bien précise pour toi, mais pas pour le reste du monde. Donc "avoir besoin de network", ça veut dire quoi pour toi ?
Pour systemd ( et j'aurais tendance à dire pour les systéme d'init depuis des années ), ça veut dire que le sous système network est la, genre tu as l'interface lo qui est disponible à minima, et un programme qui peut avoir besoin d'une interface réseau non spécifique va réussir à se lancer, et raisonnablement supposer que le routage marche pour aller sur internet ou le réseau local, si besoin.
( à noter que les softs qui dépendent d'une interface particulière ou qui doivent gérer des choses quand une ip arrive le font via un hook dans /etc/ )
pour la maintenance, non je pige toujours pas. Quand je fait ça, je modifie la config, et je fait un reload. Puis ensuite, je remets la config, et je fait un reload. Je vois même pas ce que systemed vient faire la, à part le fait que tu as du modifier les scripts d'init pour faire plus que ce qu'ils proposent de base. Donc si tu es parti sur "je refait les scripts d'init plutot que de faire un script de maintenance à part", oui, systemd n'a pas pour vocation de supporter tout ce que les gens ont pu faire de non standard.
Ça fait des années qu'on dit aux gens "faut passer par service car il nettoie l’environnement avant de lancer un script", si tu le fait pas et que tu rajoutes exprès des communications entre ton shell sous forme de variable et le script d'init, désolé, mais tu fais les choses de façon porcasse. Sinon, service ( la commande ) supporte des helpers scripts dans /usr/libexec/initscripts/legacy-actions ( au moins sur une fedora ), peut être que ça va répondre à tes besoins.
Et si tu doit faire les choses à la main vite fait, pour changer la config, un des trucs merveilleux d'unix, c'est "cp". Sinon, un autre truc merveilleux qu'on fait, c'est "puppet". Tu coupes puppet, tu changes ta config, tu fixes le truc, tu lances puppet, ta config se remets d'équerre ( si ta config puppet est bien faite, bien sur ). C'est un chouia plus moderne, mais ça marche pas mal pour gérer des gros clusters.
Bien sur, peut être que tu gères tes 40 services à la mano sans ça et que ça marche, mais ça veut pas dire que c'est efficace. La preuve, tu es obligé d'écrire des scripts d'init customs juste pour ça, ce qui est tant à démontrer que les scripts sysV ne répondent pas à tes besoins, vu que tu dois les patcher ( et genre,en patcher 40, ç'est pas rien ).
Enfin, pour ton truc qui lance des services super long à démarrer au point de confondre systemd, vu que la suggestion "utilise le fichier pid" semble pas te plaire, je propose plus simplement "sépare ton script en plusieurs unités systemd". Comme ça, tu as les dépendances ( genre le process qui fait le sync va déclencher automatiquement le demon ), systemd surveille un process à la fois. Je suis sur que ça va pas te plaire non plus, mais bon, j'aurais au moins tenté.
Et pour terminer, pour la partie sur sshd et tomcat. Si je comprends bien, c'est que tu veux dans certains cas que restart relance tout ( stop, start ), et dans d'autres cas, que ça relance rien ?
Pour sshd, c'est fait de base par la distro, via pam. Chaque process sshd est migré vers un autre cgroups à la connexion. Comme je suppose que tu va me dire "j'utilise pas pam" ( car j'ai bien compris que forcément, les trucs qui marchent sont interdit en faveur des solutions maisons chez toi ), l'autre méthode est de mettre KillMode=none ( ou KillMode=process ), et de tuer ce que tu veux quand tu fait le stop.
Pour tomcat, je suppose (parce que comme d'hab, tu dit rien de précis donc faut deviner), que le souci vient du fait que quand tu relances tomcat, tu veux pas relancer chaque appli qui tourne à l'intérieur mais faire les choses de façon plus fine. Pour ça, pareil, je pense qu'il faut traiter chaque applications comme un service séparé, et trouver le moyen d'intégrer ça à systemd ( par exemple, avoir un script dans ExecStart/ExecStop permet de le faire sans casse et je suis sur que tu as deja le scripts qui existe pour faire ça ).
[^] # Re: Trop d'honneurs...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 5.
Je crois que le souci est qu'on a pas l'air d'accord sur le mot "boilerplate", donc je vais donner ma définition, puis toi la tienne, et la, je vais pouvoir répondr eà ta question, car la, je la comprends pas.
Pour moi, le boilerplate, c'est tout les trucs inutiles que tu est obligé de copier partout mais que tu ne touche pas
Dans le cas d'un script d'init, c'est :
- la déclaration ". /etc/init.d/functions" ou équivalent, qu'on retrouve partout
- le gros case pour la lecture des arguments,
- la fonction restart, qui, sauf cas particulier, fait toujours start, stop
- la gestion des pids, des lockfiles, etc qu'on refait tous à la main à chaque fois
- la fonction qui affiche les actions du script.
tout ça, c'est des trucs qui sont, à défaut d'être pareil partout tout le temps, souvent copié coller, et ce que j'appelle le boilerplate. Si jamais je veux pouvoir dire "je lance tel truc dans un chroot", l'architecture actuel a base de shell fait que ça va sans doute coincer ( entre les scripts qui utilise une fonction shell spécifique, et ceux qui le font pas , par exemple ).
Donc voila, à toi de me dire ce que tu appelles "boilerplate", et me dire ce que ta question veux dire.
[^] # Re: Le thread dont vous éte le Mollah
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 2.
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 :
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.
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.
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.
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 )
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§ion=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 ).
[^] # Re: Le thread dont vous éte le Mollah
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 6.
Soit on fait les init à zero et ça rale "le binaire est trop gros et bloated".
Soit on le fait pas, et on rale "le binaire est mal écrit".
Du coup, y a vraiment l'impression qu'écrire en C, c'est jamais possible de faire du code qui soit vu comme beau par les codeurs C.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 3.
Suffit de lui demander, il traine sur irc ( genre, freenode, nick mezcalero ), il a un compte google plus, un email ( voir plusieurs ). tu peux aussi le trouver à des confs IRL genre le FOSDEM.
Ceci dit, aussi loin que je me souvienne, il avait déjà le même caractère quand il était étudiant ( au vue de la page http://0pointer.de/lennart/projects/atitvout/ vu que j'avais ça sur mon portable de l'époque )
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 2.
En fait, c'est toujours pareil, tu dit "tel truc est déprécié", la plupart des gens font rien. Tu retires, ça crie de partout.
les scripts réseau de rh sont aussi ceux qui sont utilisés par les autres distros rpm-based, donc ça a migré également.
Les debians utilisent ifup, un executable, donc je suppose qu'il fait direct les appels aux ioctls ( comme NetworkManager, au passage ). j'ai trouvé encore des appels à la commande "route" ceci dit dans un script.
J'ai rien pigé au script de gentoo, donc je peux pas dire, mais je pense que ça a du être migré.
Au final, les distributions ont fait leur taf. Ce qui coince, c'est toujours pareil, c'est le reste du monde. Et qui doit faire le travail pour que d'autres puissent ne rien faire ? Les distributions… ( et souvent gratuitement, avec le sourire )
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 1.
Il va pas démarrer, en effet. D'ailleurs, il y a eu des soucis avec lxc au début, car lxc utilise aussi les cgroups, et il y a eu clash sur l'usage en simultané des 2 ( souci corrigé depuis ).
Ceci dit, j'ai pour le moment vu personne se plaindre de ça à part toi, et bien que la remarque soit valable et génante pour ton usage, je pense qu'il y a donc un choix à faire sur ce que tu supportes en tant que distribution, et pour la plupart, l'usage en VPS est minoritaire AMHA.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 3.
Et arch aussi. Et tu noteras qu'il y a des distros commerciales comme Ubuntu qui n'ont pas suivi.
Donc on trouve grosso modo dans ceux qui proposent pas :
- Debian qui ne bascule pas car ils ont des raisons techniques ( kfreebsd, hurd )
- slackware et autres pour des questions de minimalisme
- gentoo qui le propose en option ( à la méthode gentoo )
- mint, parce que mint fait 0 devs sur la plateforme et fait juste de la repompe de ubuntu
- openembedded, pas de probléme avec hurd/kfreebsd, pas de souci de minimalisme => proposé en option comme gentoo
Du coté des autres distros à but commerciales, tu as :
- Ubuntu, qui le propose pas car ils ont leurs propres trucs, à savoir upstart ( upstart qui a été intégré dans RHEL et Fedora, mais personne ne va crier au complot dans ce cas la, car c'est juste quand un truc a du succès qu'il y a complot )
En gros, pour chaque distro qui propose pas, on trouve une raison de pas le faire.
Regardons maintenant les distros qui proposent :
- opensuse, mageia, fedora, mandriva, rosa => pas de souci techniques comme Debian ( ie linux only ), pas de souci de minimalisme comme lfs ( ie, udev, dbus sont déja la ), pas de système de boot maison aussi avancé comme Ubuntu
curieusement, aucune des raisons des autres ne s'appliquent. Donc la question est de savoir pourquoi est ce que :
- les distros n'ont pas décidé de faire leur truc
- les distros n'ont pas décidé de garder les anciens initscripts
Alors le 1, c'est simple, parce que ça coute des ressources. Et le 2, c'est simple, parce que personne n'a vraiment envie de s'occuper d'une grosse pile de trucs bash pour avoir en plus moins de fonctionnalités. Pour le moment, ça va, mais si dans 1 ou 2 ans, faut intégrer des nouveautés, ça devient vite galère.
Et peut être que l’intérêt est juste la, c'est de proposer un système qui correspond plus au besoin des mainteneurs ( genre, tu sais, les gens qui te file gratuitement leur boulot sous la forme d'une distribution ) et que c'est pour ça que les distros y passent ? Et parce que du coup, ça laisse du temps pour faire autre chose.
conclusion, on a une paire de distros qui n'ont pas de raisons de refuser un truc, pas envie de se taper le cout de maintenance du à une divergence, trouve des avantages à basculer et qui, du coup, bascule dessus.
C'est vraiment bien foutu ce complot
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 1.
Tu appelles quoi "besoin particulier" ?
À vue de nez je pense que tu veux dire 2 trucs :
1) les services avec des actions en plus ( genre, postgresql, dump de la db via le script d'init ).
C'est une chose qui fait pas stricto sensu parti du script d'init. En général, ça a été mis dedans parce le script d'init a besoin de la config du daemon, et sans doute pour des questions d'ergonomie et d'affordance ( ie, pour le modèle mentale de l'utilisateur, le script est la porte d'entrée sur la manipulation du daemon, un dump de la db est une manip de ce genre donc on rajoute la fonction )
Avec systemd, tu doit faire un script à part ( vu que tu peux pu intégrer ça dans le script principal ). Il y a un emplacement spécifique quand tu utilise ça avec service pour garder l'intégration ( genre service pgsql dump va appeler /XXX/pgsql/dump ). La différence entre "j'écris du code que je mets avec un case en plus dans un script" et "j'écris du code que je mets dans un fichier à un endroit spécifique" est pas flagrante. En fait, tu peux juste garder ton script d'init qui fait appel à ton 2eme script.
2) les services qui ne sont pas des daemons classiques. Exemple, tu as un truc à lancer au démarrage, mais c'est pas vraiment un daemon, c'est juste la configuration de l'affichage sur un ecran lcd 4" du nom de la machine ( le seul exemple que j'ai trouvé qui ne soit pas géré autrement ). En gros, tu doit lancer une paire de commande pour charger le matos, et lancer ce que tu veux écrire. Ben ça, oui, tu peux lancer un script shell, ou un programme en C. Ou tu peux lancer les commandes à la suite dans le fichier systemd, avec plusieurs lignes Execstart, en précisant "c'est normal si il reste aucun process à la fin" et "ne fait pas de tracking de PID". IE pour les actions spécifiques, rien n'empeche de faire encore du shell. Après tout, si le but est de lancer des softs, personne ne va vérifier si le soft est en C, en python, en perl, en bash ou autre. Donc pareil, si tu codes bien, tu as fichier que tu appelles depuis un script classiques ou systemd.
Maintenant, en pratique, j'ai du mal à voir ce qui requiert des dizaines de commandes spécifiques au boot, à part le réseau et perso, je pense que ça peut sans doute être mieux intégré et de plus haut niveau que sous la forme d'un script shell.
Mais du coup, est ce que tu penses à autre choses pour "besoins non spécifiques" ?
[^] # Re: open source ou toute autre solution déjà développée
Posté par Misc (site web personnel) . En réponse à la dépêche Modification du code des marchés publics italien imposant l’usage du logiciel libre. Évalué à 3.
Ce qui voudrait donc dire qu'un autre organisme peut payer pour l'utiliser :)
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 2.
Bah, faut leur dire de mettre à jour leur site web :
"Ubuntu Server LTS is maintained with security updates and bug fixes for up to 60 months (five years) and Ubuntu Desktop LTS for up to 36 months (three years). However, stability doesn't need to mean stagnant systems."
C'est aussi ce que je trouve ailleurs :
http://vlinux-freak.blogspot.fr/2011/10/ubuntu-support-life-cycle.html
Ceci dit, tu as raison dans le sens ou c'est contraire à ce que dit la press release
http://www.canonical.com/content/ubuntu-1204-feature-extended-support-period-desktop-users
ou sur :
http://www.ubuntu.com/business/desktop
Du coup, est ce qu'il y a une version spécifiquement supporté plus longtemps ou c'est juste le site web qui est pas du tout à jour ?