gnumdk a écrit 7486 commentaires

C'est ça qui est une très bonne chose.

Wai, ben je veux pas être pessimiste, mais je pense que Webkit a gagné.

Donc en gros ca concerne uniquement le IE de Metro que personne de normalement constitué ne vas utiliser ? (sur pc).

Wai, ok, une fausse nouvelle donc, non ?

Les notes sont stockées au format maildir.

[gnumdk@arch ~]$ find .local/share/notes/ 
.local/share/notes/
.local/share/notes/tmp
.local/share/notes/new
.local/share/notes/Linux
.local/share/notes/Linux/tmp
.local/share/notes/Linux/new
.local/share/notes/Linux/new/1321867675.R183.arch
.local/share/notes/Linux/new/1318504784.R865.archlinux
.local/share/notes/Linux/new/1318504739.R110.archlinux
.local/share/notes/Linux/new/1335272906.R652.arch
.local/share/notes/Linux/new/1318504819.R36.archlinux
.local/share/notes/Linux/cur
.local/share/notes/Windows
.local/share/notes/Windows/tmp
.local/share/notes/Windows/new
.local/share/notes/Windows/new/1334743119.R782.arch
.local/share/notes/Windows/cur
.local/share/notes/cur

C'est le format par défaut. Mais il y'a aussi un plugin akonadi pour tout stocker dans une fichier de type mailbox (je pense).

J'ai longtemps utilisé basket puis le jours ou je suis passé de KMail à Kontact, je me suis intéressé à KJots.

Il est très complet et fonctionne bien. Je crois que je ne lui connais qu'un seul bug (de ce que j'ai pu trouver), il n'affiche pas d'icone à coté du noms de la note lors d'une réutilisation du dossier de notes (lors d'une réinstallation ou changement d'OS par exemple)… Bug mineur donc, j'arrive même pas à me motiver à faire un bug report pour ça.

a) J'ai toujours dix services à maintenir

FAUX, 1 seul!

Après, pour le reste, vu qu'on ne sait pas ce que tu fais, c'est un peu compliqué de savoir la validité de tes propos…

Donc je ne sais pas ce que j'ai réussi à démontrer, mais toi j'ai une petite idée.

Bon, je vais pas batailler, tu n'as pas l'air de comprendre…

dhcpcd\@.service C'EST UNE SEUL UNIT!

DONC:
quand je rajoute une interface en cours de route (bonjour les VM) je fais systemctl start dhcpcd@eth42.service et hop.

Tu comprends mieux là ? T'as pas 1 unit par interface!

Au final au lieu d'un script toto.sh que l'on peut appeler comme on veut (par exemple
/etc/init.d/toto.sh config1) on se retrouve avec une horreur immonde. Si on a dix fichiers de
config il faut créer 10 services

J'avais pas vu celle là!

Donc avant, y'avait un script avec des arguments… Si on veut, parce que je vois pas comment ca peut être fonctionnel ton truc, depuis quand sysvrc passe autre chose que start/stop comme argument au boot ? Allez, pour te faire plaisir, on va dire que ca fonctionne (même si dans la vraie vie, à moins de foutre les appels en dur dans rc).

Et maintenant y'a ca:
dhcpcd\@.service qu'on appelle comme cela: systemctl start dhcpcd@eth0

Et qu'on peut activer au boot avec le paramètre voulu:
systemctl enable dhcpcd@eth0

En gros, tu viens de démontrer qu'avant c'était pourri et que maintenant c'est générique. Bravo…

40 dépendances pour les units

Tu peux m'expliquer ce que tu racontes ? C'est à mourir de rire! Tu critiques les autres parce qu'ils ne savent pas ce dont ils parlent et toi tu racontes absolument n'importe quoi.

Tes 40 dépendances, dedans y'a des variables et des démons pour la plupart facultatifs qui offrent des interfaces dbus qui pour l'instant sont utilisés par personne. En gros, tu parles mais sans même essayer de comprendre. Mais c'est sur que c'est plus compliquer de comprendre un truc qu'on utilise pas.

Grosso modo systemd fonctionne avec deux méthode de chiffrement,

Pour l'instant… Genre, tu vas nous pointer une erreur architectural qui fait que ce sera toujours le cas ?

Donc pour débloquer des certificats systemd-ask-password ne marche pas.

«Right now this is used exclusively for encrypted harddisk passphrases but later on this is likely to be used to query passphrases of SSL certificates at Apache startup time as well.»

En gros, c'est utilitaire qui pour l'instant ne répond pas à ton besoin ce qui est logique vu que pour l'instant, dans son état actuel, il n'est pas fait pour.

une horreur immonde. Si on a dix fichiers de config il faut créer 10 services

C'est tellement mieux un script bash avec un case à ralonge…

systemctl start toto@config0
systemctl start toto@config1
systemctl start toto@config2
…
systemctl start toto@config9

Puis ensuite bien sur aller éditer 10 liens symboliques à la main

Ben, pour un mec qui parle de shell, t'as pas l'air de bien savoir comment ca fonctionne si tu penses vraiment avoir besoin de faire 10 actions pour lancer tes 10 configs ou les rendre actives.

• le /usr distant (au revoir les terminaux léger)

J'aimerai bien savoir comment tu peux mettre ces deux parties ensemble? Genre ou est obligé de monter un /usr à part pour faire un boot réseau ?

Si un service fait semblant d'être démarré alors qu'il ne l'est pas, ce n'est pas la
faute au système de démarrage, mais au service en lui même.

TOUS les services font comme cela, entre le moment ou ils rendent la main et le moment ou ils écoutent sur leur socket, y'a forcément un laps de temps plus ou moins long en fonction du service.

Mais si tu penses vraiment que c'est pas normal, je te propose de faire un bug report aux devs de openssh (sshd) qui fait un fork() avant d'ouvrir quelque socket que ce soit.

Comment systemd après avoir démarrer le démon

Je vais pas poster mon lien sur les "sockets activations" tous les 3 commentaires…

openrc n'est pas un init

Relis mon commentaire, c'est exactement ce que je dis…

on utilise des scripts…

Wai, enfin dans systemd aussi tu peux utiliser des scripts hein… Ce que je fois, c'est que openrc se base sur des variables et fonctions prédéfinies…

La différence c’est que openrc lance le démon. Alors que systemd, s’installe sur la
socket pour démarrer le service quand il sera demandé (si j’ai bien compris). Il y a
une différence de philosophie.

Uniquement si tu l'as configuré comme cela…

Si le démon postgress rend la main au script avant d’être opérationnel, c’est un problème de postgress

Et cette affirmation elle sort d'ou ? Jamais le fait qu'un service rende la main ne veut dire qu'il est opérationnel, sauf dans tes rêves…

Tu forks pas une fois ton programme en train de fonctionner mais avant.

Wai, enfin la pour le coup, openrc se rapproche de systemd dans la syntaxe et le principe (de base)…

Les gens qui crachent sur systemd le font pour conserver les initscripts de leur distribution, pas sysvinit.

Donc si ils sont logiques, ils doivent aussi trouver que openrc c'est de la grosse merde ;)

à chaque fois tu te retapes un clone complet du repo.

Oui, enfin il suffirait que les packageurs pensent à rajouter --depth 1 à la commande de clone (en tout cas pour git) et ca poserait moins de problèmes…

On a remplacé un principe simple par une usine a gaz

Et comme d'habitude, zéro argumentation… On sens le mec qui aime parler de ce qu'il ne connait pas…

C'est typiquement le genre de truc qui font que je déteste autant Windows.

Parce que tu essayes de nous faire croire que tu a déjà essayé de savoir comment fonctionne le système d'init de Windows ?

La doc de systemd me donne mal à la tête.

Mwai, enfin cette phrase, ca fait vraiment gros noobz qui a la flemme et qui veut qu'on lui pré-mâche le travail…

Les mecs comme ça, aujourd'hui ils ont 50 ans et sont complètements largué en informatique parce que se mettre à la page, c'est vraiment trop compliqué.

En quoi systemd répond à ça ?

http://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation

ce n'est pas la faute au système de démarrage, mais au service en lui même.

[gnumdk@arch ~]$ grep sleep /etc/rc.d/*|wc -l                                                                   
37

Ben, doit y en avoir des services codés par des incompétents…

C'est vraiment le truc qui m'a fait lâcher BSD… Au bout d'un moment, ça devient une perte de temps qu'on pourrait consacrer à d'autres choses…

Ce qui me gène dans systemD c’est l’éloignement de 1 outil qui fait une chose, mais
qui la fait bien.

Moi ce qui me gène, ce sont les gens qui ressorte cette phrase alors qu'ils ne l'ont jamais compris. Cette philosophie n'a de sens que pour le shell, pouvoir faire des choses complexes en assemblant des commandes.

Donc, quand tu fais un programme, essaye qu'il ne fasse qu'une tache et donc si t'as autre chose à faire, fais un second programme… Ce sera utile un jour à quelqu'un.

Mais pour un SGBD, un environnement de bureau ou un système d'init, cela n'a aucun sens.

Mwai, c'était surtout un gros troll déguisé…

Moi, dans une boulangerie, je prend la baguette la moins chère, si elle est dégueulasse (95% du temps), alors c'est une boulangerie de merde.

/etc/init.d/monscript start

# systemctl start monscript.service

C'est vrai que c'est une horrible complexification…

un lien dans /etc/rcN.d vers le script en question avec tous les scripts qui
commencent par K pour arret, et S pour start et un chiffre indiquant l'ordre de
démarrage.

# systemctl enable monscript.service

tas de fichiers de conf dans tous les sens avec des liens partout,

Roh le foutage de gueule!

[root@arch gnumdk]# systemctl  enable sshd.service
ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'
ln -s '/usr/lib/systemd/system/sshdgenkeys.service' '/etc/systemd/system/multi-user.target.wants/sshdgenkeys.service'

Soit deux liens alors qu'avant:

[gnumdk@tina ~]$ find /etc/rc*.d -name *ssh*
/etc/rc6.d/K25sshd
/etc/rc3.d/S55sshd
/etc/rc5.d/S55sshd
/etc/rc1.d/K25sshd
/etc/rc2.d/S55sshd
/etc/rc0.d/K25sshd
/etc/rc4.d/S55sshd

J'aimerai bien savoir ou se trouve le bordel…

J'ai été étonné de voir qu'ils suivaient les évolutions de par exemple Firefox,
proposant des mises à jour régulières des dernières versions

Mwai, enfin c'est Canonical qui fait cela hein ;)

http://packages.ubuntu.com/precise-updates/firefox

Jamais entendu quelqu'un dire malle pour désigner le coffre d'une voiture, que ce soit sur Toulouse ou Bordeaux.