Je pense de plus en plus à implémenter un init pour les BSDs avec les
mêmes possibilités qu'offre systemd. En effet, celui-ci offre des
avantages que l'on ne peut plus négliger pour un OS moderne.
Parmi ces avantages, on peut noter, par exemple, la possibilité
d'implémenter un monitoring de daemon évolué par rapport
à ce que permet l'init de BSD, la possibilité de gérer l'hard dans
l'init lui-même, d'avoir une journalisation digne de ce nom au format
binaire, s'il vous plait, de gérer des containers, etc. J'arrête là,
les avantages apporté par cet init qui, de fait, sont bien trop
nombreux pour qu'un humain ordinaire puisse tous les énumérer.
Certes, il reste peut-être quelques petites erreurs de jeunesse, qui
seront, à ne pas douter, rapidement corriger, les mainteneurs de systemd
étant particulièrement réceptifs aux corrections de bugs, mais tout
celà ne devrait pas empêcher une bonne intégration dans un système BSD,
d'autant plus si l'on implémente from scratch.
Pourquoi from scratch ? Le problème est que systemd est sous licence
GNU LGPL 1.2, et quand bien même il existe des logiciels sous
licence GNU dans le coeur des principaux BSDs, il serait préférable
d'utliser une vrai licence libre.
Enfin il reste le choix du premier BSD pour commencer cette
implémentation. Le choix de FreeBSD est évident. C'est le seul à
posséder un système de type MAC digne de ce nom grâce à Trusted BSD, ce
qui, de facto, démontre sans aucun doute que c'est le système le
plus sécurisé de la famille BSD.
Cependant, je ne suis pas assez familiarisé avec cet init
extraordinaire, d'où ma demande sur fcold aux divers spécialistes
des Linux qui ont très certainement d'autres arguments en faveur de
systemd, des conseils sur comment bien implémenter un journal binaire,
ce genre de choses, quoi.
A noter, si je ne crosspote pas avec fcob, c'est bien pour leur laisser
l'agréable surprise lorsque le nouvel init sera commité pour la
prochaine release de FreeBSD (la 11.1 donc).
Le Thu, 13 Oct 2016 16:43:06 +0000 (UTC), Bruno Ducrot écrivait :
On 2016-10-11, JKB wrote:
Je te propose de déjà te pencher sur le nfs de FreeBSD (la partie lockd) pour qu'elle soit conforme aux specs :-P
Je n'ai pas vraiment cherché s'il y avait un problème, du coup je ne saurais dire. Aurais-tu un lien sur cette non conformité, par hasard ?
/var/log/message sur mes serveurs NetBSD par exemple. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Thu, 13 Oct 2016 16:43:06 +0000 (UTC),
Bruno Ducrot <ducrot@echo.fr> écrivait :
On 2016-10-11, JKB wrote:
Je te propose de déjà te pencher sur le nfs de FreeBSD (la partie
lockd) pour qu'elle soit conforme aux specs :-P
Je n'ai pas vraiment cherché s'il y avait un problème, du coup je ne
saurais dire. Aurais-tu un lien sur cette non conformité, par hasard ?
/var/log/message sur mes serveurs NetBSD par exemple.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Thu, 13 Oct 2016 16:43:06 +0000 (UTC), Bruno Ducrot écrivait :
On 2016-10-11, JKB wrote:
Je te propose de déjà te pencher sur le nfs de FreeBSD (la partie lockd) pour qu'elle soit conforme aux specs :-P
Je n'ai pas vraiment cherché s'il y avait un problème, du coup je ne saurais dire. Aurais-tu un lien sur cette non conformité, par hasard ?
/var/log/message sur mes serveurs NetBSD par exemple. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
JKB
Le Thu, 13 Oct 2016 16:08:22 +0000 (UTC), Bruno Ducrot écrivait :
On 2016-10-12, Nicolas George wrote:
Bruno Ducrot , dans le message , a écrit :
avec en prime des features en moins).
Et aussi quelques features en plus, hein. Parce que bon, les logs avec tous les services en vrac et les timestamps écrits en anglais, ça fait plus de vingt ans que c'est évident que c'est débile.
Certes, mais au moins c'est RFCisé.
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce que le nombre de fois où un systemd m'a planté un serveur ne se compte plus. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Thu, 13 Oct 2016 16:08:22 +0000 (UTC),
Bruno Ducrot <ducrot@echo.fr> écrivait :
On 2016-10-12, Nicolas George wrote:
Bruno Ducrot , dans le message
<slrnnvrs5c.2nlp.ducrot@poup.poupinou.org>, a écrit :
avec en prime des features en moins).
Et aussi quelques features en plus, hein. Parce que bon, les logs avec tous
les services en vrac et les timestamps écrits en anglais, ça fait plus de
vingt ans que c'est évident que c'est débile.
Certes, mais au moins c'est RFCisé.
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce
que le nombre de fois où un systemd m'a planté un serveur ne se
compte plus.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Thu, 13 Oct 2016 16:08:22 +0000 (UTC), Bruno Ducrot écrivait :
On 2016-10-12, Nicolas George wrote:
Bruno Ducrot , dans le message , a écrit :
avec en prime des features en moins).
Et aussi quelques features en plus, hein. Parce que bon, les logs avec tous les services en vrac et les timestamps écrits en anglais, ça fait plus de vingt ans que c'est évident que c'est débile.
Certes, mais au moins c'est RFCisé.
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce que le nombre de fois où un systemd m'a planté un serveur ne se compte plus. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Nicolas George
JKB , dans le message , a écrit :
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce que le nombre de fois où un systemd m'a planté un serveur ne se compte plus.
Parce que des scripts d'init moisis qui empêchent un serveur de démarrer, ça n'arrive jamais, bien sûr. C'est quand même impressionnant jusqu'où peut aller la mauvaise foi des fanatiques.
JKB , dans le message <slrno01ftn.vjd.jkb@rayleigh.systella.fr>, a
écrit :
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce
que le nombre de fois où un systemd m'a planté un serveur ne se
compte plus.
Parce que des scripts d'init moisis qui empêchent un serveur de démarrer, ça
n'arrive jamais, bien sûr. C'est quand même impressionnant jusqu'où peut
aller la mauvaise foi des fanatiques.
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce que le nombre de fois où un systemd m'a planté un serveur ne se compte plus.
Parce que des scripts d'init moisis qui empêchent un serveur de démarrer, ça n'arrive jamais, bien sûr. C'est quand même impressionnant jusqu'où peut aller la mauvaise foi des fanatiques.
Doug713705
Le 14-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<5800f38d$0$7106$) :
JKB , dans le message , a écrit :
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce que le nombre de fois où un systemd m'a planté un serveur ne se compte plus.
Parce que des scripts d'init moisis qui empêchent un serveur de démarrer, ça n'arrive jamais, bien sûr. C'est quand même impressionnant jusqu'où peut aller la mauvaise foi des fanatiques.
Faire planter != Empécher de demarrer Et franchement, un script d'init qui empèche un service de démarrer Ok, mais qui empèche le serveur de démarrer, je n'ai jamais vu. Par contre les bugs de systemd sont trop nombreux pour les lister tous ici et ça c'est un _fait_. Après ça marchouille, il ne faut pas dire que ça ne fonctionne pas du tout. Ici j'ai des centaines de VMs sous CentOS7 sur lesquelles systemd ne pose pas de problème mais il faut dire que chaque VM ne propose gnéralement qu'un seul service bien précis, genre reverse-proxy, serveur http, et autres trucs moches "professionnels" (comprendre vendus une fortune par des grosses boites américaines) en Java (en plus des qques services systeme genre snmp). Ceci dit, j'ai déjà vu des units systemd ne plus savoir où ils en sont et te raconter que le service est demarré quand ce n'est pas le cas ou être incapables de demarrer un service. Du coup, ça remet pas mal en question le concept qui dit que systemd permet d'avoir une meilleure vue de l'état des services. Soit, si l'unit est écrit avec les pieds, ce n'est pas de la faute de systemd mais cette remarque est également valable pour init. Il n'y aucune raison pour laquelle un script d'init bien fait ne soit pas capable de bien décrire le status d'un service. Et systemd ne pourra pas pallier le codage avec les pieds. L'idée de départ étant érronnée, il y a peu de chance que le projet atteigne son but ! -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 14-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<5800f38d$0$7106$426a74cc@news.free.fr>) :
JKB , dans le message <slrno01ftn.vjd.jkb@rayleigh.systella.fr>, a
écrit :
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce
que le nombre de fois où un systemd m'a planté un serveur ne se
compte plus.
Parce que des scripts d'init moisis qui empêchent un serveur de démarrer, ça
n'arrive jamais, bien sûr. C'est quand même impressionnant jusqu'où peut
aller la mauvaise foi des fanatiques.
Faire planter != Empécher de demarrer
Et franchement, un script d'init qui empèche un service de démarrer Ok,
mais qui empèche le serveur de démarrer, je n'ai jamais vu.
Par contre les bugs de systemd sont trop nombreux pour les lister tous
ici et ça c'est un _fait_.
Après ça marchouille, il ne faut pas dire que ça ne fonctionne pas du
tout. Ici j'ai des centaines de VMs sous CentOS7 sur lesquelles systemd
ne pose pas de problème mais il faut dire que chaque VM ne propose
gnéralement qu'un seul service bien précis, genre reverse-proxy, serveur
http, et autres trucs moches "professionnels" (comprendre vendus une
fortune par des grosses boites américaines) en Java (en plus des qques
services systeme genre snmp).
Ceci dit, j'ai déjà vu des units systemd ne plus savoir où ils en sont
et te raconter que le service est demarré quand ce n'est pas le cas ou être
incapables de demarrer un service.
Du coup, ça remet pas mal en question le concept qui dit que systemd
permet d'avoir une meilleure vue de l'état des services.
Soit, si l'unit est écrit avec les pieds, ce n'est pas de la faute de
systemd mais cette remarque est également valable pour init.
Il n'y aucune raison pour laquelle un script d'init bien fait ne soit
pas capable de bien décrire le status d'un service.
Et systemd ne pourra pas pallier le codage avec les pieds. L'idée de
départ étant érronnée, il y a peu de chance que le projet atteigne son
but !
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 14-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<5800f38d$0$7106$) :
JKB , dans le message , a écrit :
Et ça n'empêche pas un serveur d'être redémarré à distance. Parce que le nombre de fois où un systemd m'a planté un serveur ne se compte plus.
Parce que des scripts d'init moisis qui empêchent un serveur de démarrer, ça n'arrive jamais, bien sûr. C'est quand même impressionnant jusqu'où peut aller la mauvaise foi des fanatiques.
Faire planter != Empécher de demarrer Et franchement, un script d'init qui empèche un service de démarrer Ok, mais qui empèche le serveur de démarrer, je n'ai jamais vu. Par contre les bugs de systemd sont trop nombreux pour les lister tous ici et ça c'est un _fait_. Après ça marchouille, il ne faut pas dire que ça ne fonctionne pas du tout. Ici j'ai des centaines de VMs sous CentOS7 sur lesquelles systemd ne pose pas de problème mais il faut dire que chaque VM ne propose gnéralement qu'un seul service bien précis, genre reverse-proxy, serveur http, et autres trucs moches "professionnels" (comprendre vendus une fortune par des grosses boites américaines) en Java (en plus des qques services systeme genre snmp). Ceci dit, j'ai déjà vu des units systemd ne plus savoir où ils en sont et te raconter que le service est demarré quand ce n'est pas le cas ou être incapables de demarrer un service. Du coup, ça remet pas mal en question le concept qui dit que systemd permet d'avoir une meilleure vue de l'état des services. Soit, si l'unit est écrit avec les pieds, ce n'est pas de la faute de systemd mais cette remarque est également valable pour init. Il n'y aucune raison pour laquelle un script d'init bien fait ne soit pas capable de bien décrire le status d'un service. Et systemd ne pourra pas pallier le codage avec les pieds. L'idée de départ étant érronnée, il y a peu de chance que le projet atteigne son but ! -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Nicolas George
Doug713705 , dans le message <ntrh8b$lm4$, a écrit :
Il n'y aucune raison pour laquelle un script d'init bien fait ne soit pas capable de bien décrire le status d'un service.
Euh, si... À commencer par le fait qu'il n'y a aucun endroit pour le faire.
Doug713705 , dans le message <ntrh8b$lm4$1@golgoth99.redatomik.org>, a
écrit :
Il n'y aucune raison pour laquelle un script d'init bien fait ne soit
pas capable de bien décrire le status d'un service.
Euh, si... À commencer par le fait qu'il n'y a aucun endroit pour le faire.
Doug713705 , dans le message <ntrh8b$lm4$, a écrit :
Il n'y aucune raison pour laquelle un script d'init bien fait ne soit pas capable de bien décrire le status d'un service.
Euh, si... À commencer par le fait qu'il n'y a aucun endroit pour le faire.
Doug713705
Le 15-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<5802112c$0$3324$) :
Doug713705 , dans le message <ntrh8b$lm4$, a écrit :
Il n'y aucune raison pour laquelle un script d'init bien fait ne soit pas capable de bien décrire le status d'un service.
Euh, si... À commencer par le fait qu'il n'y a aucun endroit pour le faire.
Parce que d'après toi il n'est pas possible de retrouver les PID des processus liés à un service, ni de vérifier si ces processus sont toujours actifs ou non ? Je ne dis pas que c'est toujours simple mais c'est tout à fait possible et ce ne doit pas être si simple que ça avec systemd puisque on constate qu'il existe des units incapables de déterminer l'état du service qui leur est associé. Bref, tu veux bien croire qu'il est possible de mal coder un unit systemd mais tu ne veux pas croire qu'il est possible de bien coder un script d'init BSD. De mon coté je pense que dans les deux cas le codeur est y pour beaucoup et le système d'init pour très peu. Et pour rajouter une couche: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet -- Oh, papa ! y a du sang chez les meinhof Mais fais gaffe à la dernière goutte On est des milliers dans nos boxes A te préparer la déroute,Oh, papa... -- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout
Le 15-10-2016, Nicolas George nous expliquait dans
fr.comp.os.linux.debats
(<5802112c$0$3324$426a74cc@news.free.fr>) :
Doug713705 , dans le message <ntrh8b$lm4$1@golgoth99.redatomik.org>, a
écrit :
Il n'y aucune raison pour laquelle un script d'init bien fait ne soit
pas capable de bien décrire le status d'un service.
Euh, si... À commencer par le fait qu'il n'y a aucun endroit pour le faire.
Parce que d'après toi il n'est pas possible de retrouver les PID des
processus liés à un service, ni de vérifier si ces processus sont
toujours actifs ou non ?
Je ne dis pas que c'est toujours simple mais c'est tout à fait possible
et ce ne doit pas être si simple que ça avec systemd puisque on constate
qu'il existe des units incapables de déterminer l'état du service qui
leur est associé.
Bref, tu veux bien croire qu'il est possible de mal coder un unit
systemd mais tu ne veux pas croire qu'il est possible de bien coder un
script d'init BSD. De mon coté je pense que dans les deux cas le
codeur est y pour beaucoup et le système d'init pour très peu.
Et pour rajouter une couche:
https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
--
Oh, papa ! y a du sang chez les meinhof
Mais fais gaffe à la dernière goutte
On est des milliers dans nos boxes
A te préparer la déroute,Oh, papa...
-- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout
Le 15-10-2016, Nicolas George nous expliquait dans fr.comp.os.linux.debats (<5802112c$0$3324$) :
Doug713705 , dans le message <ntrh8b$lm4$, a écrit :
Il n'y aucune raison pour laquelle un script d'init bien fait ne soit pas capable de bien décrire le status d'un service.
Euh, si... À commencer par le fait qu'il n'y a aucun endroit pour le faire.
Parce que d'après toi il n'est pas possible de retrouver les PID des processus liés à un service, ni de vérifier si ces processus sont toujours actifs ou non ? Je ne dis pas que c'est toujours simple mais c'est tout à fait possible et ce ne doit pas être si simple que ça avec systemd puisque on constate qu'il existe des units incapables de déterminer l'état du service qui leur est associé. Bref, tu veux bien croire qu'il est possible de mal coder un unit systemd mais tu ne veux pas croire qu'il est possible de bien coder un script d'init BSD. De mon coté je pense que dans les deux cas le codeur est y pour beaucoup et le système d'init pour très peu. Et pour rajouter une couche: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet -- Oh, papa ! y a du sang chez les meinhof Mais fais gaffe à la dernière goutte On est des milliers dans nos boxes A te préparer la déroute,Oh, papa... -- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout
Nicolas George
Doug713705 , dans le message <ntt5cr$ebr$, a écrit :
Parce que d'après toi il n'est pas possible de retrouver les PID des processus liés à un service, ni de vérifier si ces processus sont toujours actifs ou non ?
De manière fiable et avec juste des scripts shell ? Non, clairement ce n'est pas possible.
Bref, tu veux bien croire qu'il est possible de mal coder un unit systemd mais tu ne veux pas croire qu'il est possible de bien coder un script d'init BSD.
Exactement. On peut construire un immeuble branlant en briques, mais un immeuble solide en paille non.
Doug713705 , dans le message <ntt5cr$ebr$5@golgoth99.redatomik.org>, a
écrit :
Parce que d'après toi il n'est pas possible de retrouver les PID des
processus liés à un service, ni de vérifier si ces processus sont
toujours actifs ou non ?
De manière fiable et avec juste des scripts shell ? Non, clairement ce n'est
pas possible.
Bref, tu veux bien croire qu'il est possible de mal coder un unit
systemd mais tu ne veux pas croire qu'il est possible de bien coder un
script d'init BSD.
Exactement. On peut construire un immeuble branlant en briques, mais un
immeuble solide en paille non.
Doug713705 , dans le message <ntt5cr$ebr$, a écrit :
Parce que d'après toi il n'est pas possible de retrouver les PID des processus liés à un service, ni de vérifier si ces processus sont toujours actifs ou non ?
De manière fiable et avec juste des scripts shell ? Non, clairement ce n'est pas possible.
Bref, tu veux bien croire qu'il est possible de mal coder un unit systemd mais tu ne veux pas croire qu'il est possible de bien coder un script d'init BSD.
Exactement. On peut construire un immeuble branlant en briques, mais un immeuble solide en paille non.
Jo Engo
Le Sat, 15 Oct 2016 12:46:46 +0000, Nicolas George a écrit :
De manière fiable et avec juste des scripts shell ? Non, clairement ce n'est pas possible.
qu'est-ce qu'il a sh qui te déplaît ? Il sent le pâté ? Peux-tu donner un exemple (reproductible) de plantage, s'il te plaît ? Je n'ai pas trouvé d'immeubles en paille par contre des baraques très loin de la hutte. Ceci explique peut-être cela. -- Travailler donc pour la gloire, et qu'un solide gain Ne soit jamais l'objet d'un illustre écrivain. -+- Nicolas Boileau, Art poétique -+-
Le Sat, 15 Oct 2016 12:46:46 +0000, Nicolas George a écrit :
De manière fiable et avec juste des scripts shell ? Non, clairement ce
n'est pas possible.
qu'est-ce qu'il a sh qui te déplaît ? Il sent le pâté ?
Peux-tu donner un exemple (reproductible) de plantage, s'il te plaît ?
Je n'ai pas trouvé d'immeubles en paille par contre des baraques très
loin de la hutte. Ceci explique peut-être cela.
--
Travailler donc pour la gloire, et qu'un solide gain
Ne soit jamais l'objet d'un illustre écrivain.
-+- Nicolas Boileau, Art poétique -+-
Le Sat, 15 Oct 2016 12:46:46 +0000, Nicolas George a écrit :
De manière fiable et avec juste des scripts shell ? Non, clairement ce n'est pas possible.
qu'est-ce qu'il a sh qui te déplaît ? Il sent le pâté ? Peux-tu donner un exemple (reproductible) de plantage, s'il te plaît ? Je n'ai pas trouvé d'immeubles en paille par contre des baraques très loin de la hutte. Ceci explique peut-être cela. -- Travailler donc pour la gloire, et qu'un solide gain Ne soit jamais l'objet d'un illustre écrivain. -+- Nicolas Boileau, Art poétique -+-
The Mover
Doug713705 a écrit :
Et pour rajouter une couche: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
MWWAAARRRFFFFFFFFF "The Linux ecosystem has fallen behind other operating systems in writing secure and robust software. While Microsoft was hardening Windows and Apple was developing iOS, open source software became complacent." Fcold c'est que des bobos qui veulent nous empêcher de kiffer la vibes avec notre GUI. -- http://youmightnotneedjs.com
Doug713705 a écrit :
Et pour rajouter une couche:
https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
MWWAAARRRFFFFFFFFF
"The Linux ecosystem has fallen behind other operating systems in writing
secure and robust software. While Microsoft was hardening Windows and Apple
was developing iOS, open source software became complacent."
Fcold c'est que des bobos qui veulent nous empêcher de kiffer la vibes avec
notre GUI.
Et pour rajouter une couche: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
MWWAAARRRFFFFFFFFF "The Linux ecosystem has fallen behind other operating systems in writing secure and robust software. While Microsoft was hardening Windows and Apple was developing iOS, open source software became complacent." Fcold c'est que des bobos qui veulent nous empêcher de kiffer la vibes avec notre GUI. -- http://youmightnotneedjs.com
Jo Engo
Le Sat, 15 Oct 2016 16:36:03 +0000, The Mover a écrit :
GUI
à part ça systemd est par défaut dans bubuntu 16.04, du coup je rigole moins que vous (vais me faire un petit netbsd sur ma prochaine machine) -- On a le droit de dire du mal des femmes; on n'a pas le droit de dire le mal d'une femme. -+- Alexandre Dumas (1802-1870) -+-
Le Sat, 15 Oct 2016 16:36:03 +0000, The Mover a écrit :
GUI
à part ça systemd est par défaut dans bubuntu 16.04, du coup je rigole
moins que vous (vais me faire un petit netbsd sur ma prochaine machine)
--
On a le droit de dire du mal des femmes;
on n'a pas le droit de dire le mal d'une femme.
-+- Alexandre Dumas (1802-1870) -+-
Le Sat, 15 Oct 2016 16:36:03 +0000, The Mover a écrit :
GUI
à part ça systemd est par défaut dans bubuntu 16.04, du coup je rigole moins que vous (vais me faire un petit netbsd sur ma prochaine machine) -- On a le droit de dire du mal des femmes; on n'a pas le droit de dire le mal d'une femme. -+- Alexandre Dumas (1802-1870) -+-
