gnumdk a écrit 7492 commentaires

vim pour du Latex pour la mise en page mais sinon dans un bete fichier texte, c'est beaucoup mieux!

Y'avait des cours de Latex à L'univ de Lille3 Sciences Humaines et Sociales en 2004 quand j'étais informaticien là bas…

Aucune, c'est aussi du flan, y'a juste moins de gens qui ont une chance d'intercepté ta correspondance…

ArchLinux ?

C'est quoi les applications ?

Parce que dans KDE 3.5, il fallait sélectionner la langue dans kcontrol, il n'y avait pas de detection des locales (sauf patch sous Kubuntu et suse et mandriva).

En fait, t'es un comique ou juste un boulet ?

Pour les cas particuliers, y'a ce qu'il faut pour lancer des scripts shells mais je suis sur que 100% des services fournis par Fedora n'utilise pas ce genre de truc, c'est juste au cas ou…

Pour affirmer cela, tu peux me garantir que systemd n'aura aucun bogue

Et tu peux m'affirmer que y'a aucun bug dans le binaire de bash ?

Toi, t'as jamais installé un soft proprio sous Debian ;)

C'est quoi la différence avec l'init actuel qui démarre Apache?

Ben, tu peux espérer planter systemd en lui envoyant n'importe quoi … Après, vu que systemd ne fait que passer la main sans lire ce qu'on lui envoie, ca doit être très limité, sauf si il fait mumuse avec identd comme on l'a vu avec xinetd…

vgchange -a y juste avant la détection le montage des disques parce qu'il y a un
bug et qu'il faut l'effectuer comme ça pour que ça fonctionne. (rcS toussa).

Il y'a déjà tout ce qu'il faut pour faire des opérations avant le lancement d'un service dans systemd: ExecStartPre=tonscriptbash.sh

Donc systemd saura tout seul comme un grand comment les softs sont censés démarré
ou dépendra d'une conf/ajout/… qui sera tout aussi plantogène ?

Non, systemd propose un fichier de conf qui fonctionne sur toutes les distribs…
Pas un script écrit pour RH qui fonctionne que sous RH… C'est si dure que ça à comprendre ?

tu peux m'expliquer comme systemd va automagiquement gérer ça ?

Euh, facile, en gardant une syntaxe stable dans le temps, c'est la promesse de systemd… Sinon, c'est sur, si tu enlèves cette partie, il ne sert plus à rien…

fermé vu qu'on ne peut rien modifier

Allez, vas y expliques moi cette partie, t'as l'air de vachement t'y connaitres pour lancer de telles affirmations…

et en plus on peut la modifier très facilement à la main si on veut que ca
s’exécute après un script maison par ex …

Comme avec systemd, amis du je blahblahte sans savoir de quoi je parle, bonjour…

Bon, il serait peut être temps de regarder ce que fait systemd au lieu de raconter n'importe quoi…

Ca va rien changer, tu vas pas avoir à débuger systemd si ton systeme boot pas, tu vas vérifier la conf, vérifier les scripts BASH de pre-init de service…

C'est quand même deux poids deux mesures, non ?

Tu peux très bien avoir une version de MacOSX et pas avoir envie de payer la mise à jour avec ta nouvelle machine…

C'est plutot respectueux des clients…

Tu prends un vote qui a peut être 15 ans d'existence :) Les "vrais" chiffres ^{^}

Personnellement, j'ai toujours trouvé que les scripts chez Debian était
globalement propre et concis.

Regarde ceux d'un BSD/ArchLinux/… et on en reparle ;)

C'est toute cette chaîne qui fait qu'en pratique, quasiment personne je pense ne
modifie en serveur écrit en C.

Mais pourquoi tu veux modifier systemd, faut quand même qu'on m'explique… A ce moment là, on peux aussi cracher sur l'init SysV, c'est du C aussi…

Tu vas me dire que ton noyau boot avec init=/bin/bash et des scripts persos? ?

Donc tu pense que le code compilé en C ne sera pas codé avec les pieds ?

Le code de systemd, il est codé une fois, les scripts de démarrage de soft de MERDE PROPRIO A LA CON QUI MARCHE PAS, j'en ai plein ma tabatière…

Si ils dépendent d'un fichier qui n'est pas installé sur ton système, systemd ne
vas rien changer sur ce point.

Systemd veut forcer la standardisation, donc y'aura pas de fichier pas installé

Au lieu de rien dire, répond à la question…

C'est quoi la différence entre ce que fait inetd et ce que fait systemd ? Il utilise tous les deux un fichiers de conf pour lancer un service, et j'ai jamais vu personne geuler…

Arrête, il est collector ce mac, faut le revendre sur ebay, les fanboys vont se battre :)

pour rendre simples les modifs éventuelles pour adapter le programme au
contexte.

Donc en gros, ce que tu dis, inetd c'est de la grosse merde, il fallait faire ça avec des scripts shell ? Attention, y'en a un paquet de soft dans le genre…

Mwai, enfin les services dans systemd, j'imagine qu'il sont pas codé en C, tu peux tout aussi bien les adapter à tes besoins…

Genre dans systemd, y'a:
ExecStartPre=

qui te permet de lancer un script avant le lancement du service et donc de faire tout ce que tu veux…

Donc je vois pas ce que ca change…

Avec un SSD, on passe des checks bios au login instantanément.

T'as déjà eu une machine comme ca ?
- Avec un init standard BSD: c'est faux
- Avec upstart: c'est plus rapide mais c'est faux
- Avec systemd: c'est plus rapide mais c'est faux

Et genre, comment RH va dominer la planète GNU/Linux grâce à ce truc ?

Tu comprends pas que si Suse s'oriente vers ce truc, y'a une bonne raison ? C'est qu'il est écrit pour répondre à une demande, celle du monde propriétaire qui s'en bas la race du libre et qui demande juste un moyen de simplifier le fonctionnement de la gestion des services sous Linux.

Mais j'ai pas encore entendu dire que Linus avait prévu de rendre le noyau "systemd compatible only"

Idem, le fait de virer SysV pour systemd ne me gène pas plus que cela, je ne vois vraiment pas ce que cela va changer…

L'exemple du "je peux modifier mon script shell" est le pire de tous, quand tu as besoin de faire cela, c'est justement parce que ce script shell a été codé avec les pieds, qu'il utilise des trucs qui ne sont pas en rapport avec ton système… Du coup, systemd prend tout son sens…

Après, j'avoue resté amoureux de l'init BSD, just KISS…