Ce week-end j'ai mis à jour Kubuntu sur le PC portable de mon boulot à la nouvelle version 15.04. Mise à part Plasma 5, la grande nouveauté, apportée par Debian, est le remplacement d'Upstart par Systemd qui gère non seulement l'initialisation mais aussi la gestion du matériel et des services.
J'ai déjà eu une expérience avec Systemd lorsque ArchLinux a commencé à remplacé son système d'init que j'appréciais bien par Systemd. En dehors des débuts assez chaotiques de son intégration dans ArchLinux, et mis à part les avantages de gestion qu'apporte ce nouveau système clé, il a réussi à donner un gros coup de vieux à mon PC portable personnel déjà bien vieillissant, un Toshiba Satellite A40 Pro et ceci dès le démarrage. En effet, j'avais des temps de démarrage bien supérieur à ce que j'avais avec l'ancien système ; à sa décharge, j'avais optimisé ce dernier. Par contre, l'arrêt est quasi-instantané … J'ai fini par remplacé ArchLinux sur ce vieux PC portable par Slackware et depuis il s'en porte bien mieux.
Mais revenons à mon PC portable du boulot, un Asus G74S. A la maison, il est fréquent que mes PC soient démarrés pour une utilisation ponctuelle, puis ensuite arrêtés. Avec un disque dur, j'utilisais l'hibernation pour ce faire. Or, celui-ci sous GNU/Linux a souvent fonctionné, la plupart du temps, au petit bonheur la chance. Il en est de même avec mon PC portable du boulot. Le remplacement de son disque dur par un SSD a été un véritable bonheur puisqu'il a permis, à lui seul, un démarrage quasi-immédiat de mon PC, renvoyant ainsi aux oubliettes l'hibernation (disons mon usage de l'hibernation). Mais hélas, la loi de Parkinson selon laquelle "tout gain de productivité est aussitôt mangé par la monté en complexité de l'administration" (ou du système), est revenu au pas de charge au travers de Systemd. Grâce à lui, j'ai pu retrouvé les grandes joies des longs démarrages ; mais bon, j'ai un arrêt là aussi quasi-immédiat. Bref, c'est un aspect probablement dérisoire pour certains (voir beaucoup) d'entre vous, mais c'est un point important pour moi.
Alors, certains d'entre vous dirons que ça vient de l'intégration de Systemd dans (K)ubuntu (ou Debian) ; peut-être, mais la coïncidence avec mon expérience sous ArchLinux est étonnante. A côté de ceci, mis à part quelques détails (par exemple les fichiers de définition des unités dans /usr/lib/systemd/system ; ben oui, les mettre dans un /etc/systemd c'est trop old school), l'utilisation de Systemd, pour ce que j'en fait, reste pour l'instant positive.
# Debian 8
Posté par tuxicoman (site web personnel) . Évalué à 1. Dernière modification le 28 avril 2015 à 00:52.
T'as essayé la version non buggée d'Ubuntu?
Chez moi, sur un SSD, je suis sur le bureau en moins de temps qu'il n'en faut.
[^] # Re: Debian 8
Posté par Jarvis . Évalué à 5.
Pour alimenter le troll, on a la réaction de Lennart sur l'intégration de systemd par Canonical et par debian ?
[^] # Re: Debian 8
Posté par needs . Évalué à 1.
Tout est dit.
[^] # Re: Debian 8
Posté par nono47 . Évalué à -1.
C'est pas KISS kubuntu ?
jessie rule the world !
:=)
[^] # Re: Debian 8
Posté par Le Gab . Évalué à -3.
Chez moi aussi en SSD mais même en HDD, le boot sur Ubuntu pre-systemd était relativement rapide, moins de 50 sec.
Même si je conseille un SSD, ça ne devrait pas être la condition pour avoir un système qui démarre en dessous de la minute, Upstart et autres le faisaient très bien sans.
De toute façon, on ne sait pas ce qu'est systemd, vendu en premier lieu comme accélérant les temps de démarrage sur "desktop", fait par un gars qui bosse dans la partie "server" et finalement, systemd s'avère faire même le café et bientôt qui sait, gestion de paquets.
Il a muté en tellement de chose que de s'arrêter à la promesse du temps de démarrage n'est pas la bonne façon de l'évaluer.
Je ne suis pas anti-systemd, je l'accepte parce que des gars plus intelligents l'approuvent mais je ne sais pas ce que c'est réellement.
[^] # Re: Debian 8
Posté par Renault (site web personnel) . Évalué à 4.
Tu ne sais pas ce qu'il fait réellement mais tu dis en gros que c'est de la merde ? Pas mal.
systemd fonctionne rapidement et bien, tout dépend de son intégration et des services à lancer (certains n'ont pas été bien adaptés, ça viendra avec le temps).
[^] # Re: Debian 8
Posté par GnunuX (site web personnel) . Évalué à 5.
Si on repart du premier poste de Lennart : http://0pointer.net/blog/projects/systemd.html , je pense que tu cherche un peu a réinventer l'histoire.
[^] # Re: Debian 8
Posté par ohm . Évalué à 5.
Je t'invite à consulter les plus gros mythes concernant systemd où l'auteur explique en second point que la vitesse n'est jamais entrée en considération. Je n'ai jamais vu un débat aussi pollué que sur systemd, que ce soit du côté du pour ou du contre.
[^] # Re: Debian 8
Posté par Moonz . Évalué à -1.
Ce qui est rigolo, c’est que le même auteur a écrit exactement l’inverse (« As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast ») sur le lien donné sur le message juste au-dessus du tien.
[^] # Re: Debian 8
Posté par Renault (site web personnel) . Évalué à 6.
Si tu lis bien ces propos, tu comprendrais que, selon lui, un bon système d'init fait les choses rapidement. C'est plus vu comme une conséquence d'une bonne architecture que comme le but même du projet.
Et quand les unités de systemd sont corrects, c'est très rapide. Bien entendu parfois il y a des bogues, mais ça arrivait avant systemd aussi.
# systemd-analyze
Posté par antoyo . Évalué à 10.
Tu peux regarder avec la commande :
systemd-analyze
Tu peux aussi lancer la commande :
systemd-analyze blame
[^] # Re: systemd-analyze
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
Merci pour les commandes. J'ai ça en sortie : (je n'ai gardé que les plus gourmands)
28.281s postgresql@9.4-main.service
26.382s gpu-manager.service
26.327s NetworkManager.service
7.389s NetworkManager-wait-online.service
1.508s systemd-udev-settle.service
510ms dev-disk-by\x2duuid-ffbb6afb\x2d3411\x2d4967\x2d9a58\x2da363d3c8f3bc.device
335ms systemd-fsck-root.service
334ms mnt-data.mount
183ms systemd-fsck@dev-disk-by\x2duuid-729c1b97\x2de122\x2d4995\x2d881a\x2dd7855c972675.service
167ms systemd-udevd.service
148ms ModemManager.service
130ms systemd-journal-flush.service
123ms systemd-backlight@backlight:acpi_video0.service
123ms systemd-random-seed.service
123ms systemd-rfkill@rfkill1.service
121ms binfmt-support.service
120ms accounts-daemon.service
100ms avahi-daemon.service
Bon, apparemment c'est PostgreSQL qui prend le plus de temps à démarrer. Ensuite vient la gestion de la carte graphique et celui du réseau. Faut que je regarde comment Systemd les lance (en // ou séquentiellement). Pour PostgreSQL, que j'utilise essentiellement dans les tests, je pourrais ne le lancer qu'explicitement (à la connexion en arrière plan). Ensuite, certains services, comme le modem, peuvent être désactivés.
[^] # Re: systemd-analyze
Posté par Boa Treize (site web personnel) . Évalué à 10.
C'est super suspect ces trois services qui nécessitent tous comme par hasard la même grosse durée… Ça sent le timeout, l'attente de l'évènement (probablement réseau) qui les débloque tous d'un coup. Reste à trouver ce que c'est. Une résolution de nom qui ne se passe pas bien, peut-être ?
[^] # Re: systemd-analyze
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Comment savoir que ça vient bien d'un timeout ? Je ne vois rien dans les logs avec journalctl (bon d'un autre côté je ne sais pas très bien encore m'en servir).
Pour la résolution de nom, je ne vois pas. J'ai ce problème quelle que soit le site où je suis (pas les mêmes serveurs DNS), problème que je n'ai pas lorsque je démarre ma distribution avec Upstart.
[^] # Chercher dans les logs
Posté par Sylvain Blandel . Évalué à 3.
Tu peux afficher l'état de chaque unité avec systemctl :
systemctl --allTu peux filtrer les unités affichées selon leur état. Quelques exemples :
systemctl --all --state=failedsystemctl --all --state=not-foundL'outil journalctl affiche les logs. Pour n'afficher que les logs depuis le dernier démarrage :
journalctl -bPour filtrer les logs selon leur criticité, c'est le paramètre
-pPar exemple :journalctl -p warningLorsque tu as repéré l'unité déconnante, tu peux afficher uniquement les logs de cette unité, avec le paramètre
-u:journalctl -u machin.serviceToutes ces options sont cumulables.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: systemd-analyze
Posté par NilugeKiWi . Évalué à 5.
Voire démarrer PostgreSQL à la demande, à la première connexion au serveur par un client, ce que permet systemd.
[^] # Re: systemd-analyze
Posté par Miguel Moquillon (site web personnel) . Évalué à 4.
Je pense que ceci se fait via les unités de type Socket. Hors, il apparaît que, pour que cela marche, il faut que Systemd et le service s'entendent sur le type de fichier de descripteur socket. Or il semblerait que ce ne soit pas le cas avec PostgreSQL (l'ouverture est déléguée à postmaster avec PostgreSQL il me semble).
Cf. No system.d socket for PostgreSQL service
[^] # Re: systemd-analyze
Posté par antoyo . Évalué à 3.
En ce qui me concerne, quand j’ai remarqué que NetworkManager prenait autant de temps à démarrer, je suis passé à connman qui démarre beaucoup plus rapidement. Si tu n’as pas besoin de certaines fonctionnalités avancés de NetworkManager, tu pourrais passer à une autre solution.
[^] # Re: systemd-analyze
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Malheureusement, j'ai besoin de fonctionnalités "avancées" de NetworkManager comme la prise en compte de VPN.
# démarrage lent ? → systemd-analyze
Posté par leovilok . Évalué à 9. Dernière modification le 28 avril 2015 à 00:55.
Si ton démarrage est vraiment lent et que tu cherche à l'optimiser regarde du coté de systemd-analyze, il te dira ce qui met le plus de temps. En plus tu peux faire des jolis graphiques SVG avec
systemd-analyze plot > file.svg.edit : grillé
# New school
Posté par Sylvain Sauvage . Évalué à 10.
Le principe retenu est que les fichiers livrés par la distribution sont dans
/usret les fichiers locaux (créés de rien ou modifiés de ceux de/usr) sont dans/etc.Le gros avantage est que
/etc/systemdn’est pas rempli de tout un tas de fichiers qu’on ne touchera jamais, noyant ceux que l’on veut tripoter.L’inconvénient est qu’on doit savoir où trouver les fichiers au début.
Mais bon, c’est pas comme si c’était déjà ce qui est fait par d’autres (xorg.conf.d p.ex.)…
[^] # Re: New school
Posté par Xaapyks . Évalué à 2.
Et en général y a pas à aller tripoter /usr/lib/systemd, ni /etc/systemd à la main, 99% de la configuration se fait avec systemctl.
OP ne sait pas de quoi il parle, mais bon c'est à la mode de cracher sur systemd…
[^] # Re: New school
Posté par Albert_ . Évalué à -9.
Oh mon dieu, un newbie qui se plainds que son systeme fonctionne moins bien alors que on lui a change une brique fondamentale… Quel hone franchement il devrais crier de joie d'avoir ce nouveau truc hyper hype et ne pas se plaindre que ca prend trios plombes a demarre. Il devrait d'ailleurs en profiter pour prendre un cafe il en aura besoin pour lire les 500 pages de docs.
[^] # Re: New school
Posté par groumly . Évalué à 2.
Laisse moi reformuler:
Encore un blaireau qui a tres probablement foutu la grouille dans son init, tout en croyant etre un expert linux parce qu'il a copier/coller un curl | bash depuis les forums ubuntu. Alors certes, ca boote plus vite, mais ca aurait explose en plein vol meme sans systemd de toutes facons, parce qu'il a modifie les init scripts a la truelle.
Mais comme c'est tendance de faire son hipster facon "les vieilles technos c'etait vachement mieux", il a decide de venir passer pour un guignol sur linuxfr en etalant bien son incompetence complete.
Il se fait remballer a juste titre par les 2 du fonds qui suivent, pendant qu'albert, fidele a lui meme, amuse la gallerie en se ridiculisant.
Mieux, non?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: New school
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
C'est sensé, mais les mettre dans
/usr/libest une faute, pour des fichiers indépendants de l'architecture : leur place est dans/usr/share.[^] # Re: New school
Posté par lockidor . Évalué à 1.
Si je peux me greffer sur la conversation, quelle est la différence entre
/usr/localet/usr?Sur les BSD, ça permet de séparer les fichiers du système et ceux installés par les ports IIRC, mais la majorité des distros Linux n'ayant pas cette philosophie, quelle est leur finalité ?
[^] # Re: New school
Posté par Tom D . Évalué à 5.
Il y a souvent plusieurs réponses pour ce genre de question. La mienne est que /usr est pour les applications/outils installés par le gestionnaire de paquet de la distribution, /usr/local est pour les applications/outils installés depuis les sources ou via un installeur qui n'utilise pas le gestionnaire de paquet (quoique dans ce dernier cas, c'est souvent /opt qui est utilisé).
# La même
Posté par afby . Évalué à 1.
Upgrade de la bête, et boom, j'ai du prendre au moins 1s au démarrage !
En prime Abiword s'ouvre au chargement de ma session ^
[^] # Re: La même
Posté par afby . Évalué à 2.
Auto réponse pour abiword : https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/1432271
# MDR :-)
Posté par root_rtfm . Évalué à 2.
:-)
Finalement le "vieux truc" fonctionne très bien…
[^] # Re: MDR :-)
Posté par Raoul Volfoni (site web personnel) . Évalué à 5.
Ah ben c'est mamie qui va être contente…
[^] # Re: MDR :-)
Posté par karteum59 . Évalué à 0.
C'est encore maintenu Slackware ?
Désolé, ce n'est pas destiné à être un troll mais une vraie question : par exemple sur http://www.slackware.com/ la dernière news date de novembre 2013 et parle de 14.1, donc je m'interroge (notamment pour les upgrades de sécurité).
[^] # Re: MDR :-)
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
Ben oui, c'est maintenu. j'ai de temps en temps des mises à jour. Par contre, ce n'est pas la distrib qui va être la plus à jour ni non plus celle qui sera la plus active. Mais ça marche et c'est simple à gérer.
[^] # Re: MDR :-)
Posté par gouttegd . Évalué à 5.
Ce ne sont pas les news qu’il faut regarder, c’est les Changelogs. Résultat : dernière activité le 26 avril au soir, et une grosse mise à jour quelques jours plus tôt.
Oui, Slackware est toujours vivante, et non, Debian n’est pas la plus ancienne distribution GNU/Linux en activité. :P
# Troll
Posté par barmic . Évalué à 10.
Donc tu fais un journal pour nous dire que SysvInit tu l'aimais donc tu as passé du temps pour l'optimiser et que systemd que tu n'aime pas n'est pas aussi rapide out-of box que ton chère sysvinit optimisé.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Troll
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Ben non, tout faux. Je m'en fou de l'init sysV ou BSD comme je m'en fou de Systemd. Si tu penses au paragraphe sur ArchLinux, c'est juste que celui-ci me permettait facilement et rapidement de déclarer les services que je voulais et comment les lancer (en // ou séquentiellement) ; rien de compliquer. Lorsque Systemd est arrivé, celui-ci active tout en fonction de ce qu'il détecte et ensuite c'est à toi de dire ce que tu veux ou non et ceci m'avait paru bien plus chiant à faire, d'autant plus qu'à l'époque j'avais d'autres préoccupations que de passer du temps dessus, sachant en plus que ma femme me tannait pour que le PC revienne aussi véloce qu'avant (j'ai préféré donc le passer à Slackware).
Pour ce qui est ensuite du journal, il me permet de faire part de mon désarroi et de me libérer de celui-ci : l'introduction de Systemd m'a donné l'impression de revenir des années en arrière et là, contrairement avec ArchLinux, je n'avais rien touché à la conf d'Upstart (d'ailleurs je ne sais même pas comment il gère le truc). Voilà c'est tout. Après, comme le suggère des commentaires ci-dessous, il faut que je tâte d'un peu plus près les unités gérées par Systemd pour voir ce qui cloche, et comme le PC est avant tout utilisé par moi, je n'aurai pas ma femme sur le dos pour me presser.
[^] # Re: Troll
Posté par hervé Couvelard . Évalué à 0.
non, pas du tout. Il a fait un journal pour expliquer que systemd qui devait déchirer tout, être révolutionnaire, et être aimé par tout le monde parce que celui qui n'aime pas est un gros con rétrograde est en fait un soft comme les autres, qui a ses avantages et ses inconvénients, nécessite une nouvelle courbe d'apprentissage ou tu ne peux pas capitaliser un savoir que tu as acquis précédemment, et qui n'est pas si miraculeux que cela : on pouvait s'y attendre.
Si on commence maintenant à accuser les intégrateurs dans les distributions c'est que l'on est arrivé au bout du truc. Avant c'était les utilisateurs qui étaient trop cons, maintenant si cela ne marche pas/mal ce n'est pas de la faute du soft mais de son intégration : les intégrateurs devant faire le travail de finition.
A sa décharge c'est vrai que débian/ubuntu n'aurait pas du l'intégrer s'il n'était pas prêt pour eux, mais a sa charge l'intégration de tout un tas de services externes (qui sont donc abandonnés par ceux qui les faisaient) oblige les distributions à l'intégrer sauf à tout maintenir, ce qui n'est pas possible.
C'est la quadrature du cercle. Cela va être la merde pendant quelques temps (2-5 ans) et ça prendra un rythme de croisière jusqu'à ce qu'on invente encore un nouveau truc : espérons que ca ira bien mieux.
Maintenant ce qui est sur c'est que tout le monde, enfin ceux qui veulent pouvoir faire eux même leurs paquets pou toutes les distributions et ceux qui font du proprio, veut une uniformisation (et d'ailleurs c'est un des avantages attribué à systemd : cette obligation d'uniformisation) des distributions car la diversité semble être le mal.
Il suffit d'attendre et observer ce qui se passe. Maintenant cela me semble évident que choisir d'intégrer tout un tas de truc à l'intérieur du même soft est un pari que le reste du monde suivra. Lorsque c'est un lambda qui veut faire son soft, on l'accuse de diviser les forces et on l'exhorte à contribuer à ce qui existe déjà, mais pour systemd on trouve que c'est une bonne chose que de tout faire en interne, mais c'est la vie. une sorte de religion qui a pris comme axiome que c'est bien et que ceux qui sont un peu critiques sont des rétrogrades.
[^] # Re: Troll
Posté par Dr BG . Évalué à 5.
Mouais, mais c'est pas très scientifique. On met à jour toute une distribution, mais c'est à cause de systemd que c'est plus lent. S'il n'avait mis à jour que systemd pourquoi pas, mais là… surtout qu'Ubuntu permet d'utiliser Upstart s'il préfère.
[^] # Re: Troll
Posté par hervé Couvelard . Évalué à -4.
cette réponse ne l'est pas plus scientifique.
[^] # Re: Troll
Posté par Miguel Moquillon (site web personnel) . Évalué à 8. Dernière modification le 28 avril 2015 à 12:10.
Merci de l'info. J'ai donc été à la recherche d'info pour utiliser Upstart à la place de Systemd déjà pour vérifier que mon problème ne vient pas finalement de Systemd comme tu sembles le suggérer.
J'ai trouvé cet article qui explique comment démarrer temporairement ma distribution avec Upstart.
Hé bien, le résultat ne s'est pas fait attendre, je retrouve mon démarrage d'avant ! ça change la vie. Donc, je peux confirmer que la lenteur vient de Systemd ou, peut être plus exactement, de certains services gérés par lui.
[^] # Re: Troll
Posté par xcomcmdr . Évalué à 4.
Enfin à terme Upstart va disparaître, déjà qu'il n'est plus maintenu et qu'il n'est plus l'init par défaut. Régler le problème avec systemd serait plus pérenne.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Troll
Posté par hervé Couvelard . Évalué à 5.
ouais régler le problème serait plus smart, encore faudrait-il ne pas prendre ceux qui ont ces problèmes et qui le disent comme des emmerdeurs.
[^] # Re: Troll
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Oui je suis d'accord. Revenir à Upstart n'est pas la solution.
[^] # Re: Troll
Posté par Albert_ . Évalué à -2.
C'est pas nouveau c'est ce qui s'est passe avec pulseaudio ou tous les integrateurs sauf celui de RH (on se demande pourquoi…) etaient des incompetents.
[^] # Re: Troll
Posté par barmic . Évalué à 3.
Qui accuse qui ? J'ai juste dis qu'il semble faire un jugement biaisé : comparer le résultat d'un logiciel au quel il s'est investi avec un logiciel au quel il a très peu touché.
Pour le reste, je te laisse avec ta paranoïa, vous avez l'air de vous amuser.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Troll
Posté par hervé Couvelard . Évalué à 4.
Quelle paranoïa ?
Lorsque je réponds à un post, il m'arrive, je l'avoue, d'élargir un peu car je ne considère pas mon interlocuteur comme le centre du monde, et que ce que j'écris n'est pas "contre la personne", mais en réponse à un argument qui me semble un peu faible. D'ailleurs il a changé de démarrage pour upstart, donc même distribution,mêmes logiciels et paff tout va bien, donc il n'avait pas forcément tord.
Tu ne lis jamais que si un logiciel ne tourne pas bien chez moi(tm) c'est que dans ma distribution il n'a pas été intégré comme il faut ? que ce n'est pas la faute du logiciel ? Moi je le vois régulièrement comme argument. C'est juste plus gênant lorsque c'est un truc au coeur de la machine et du démarrage.
Je crois que tu ne comprends pas trop bien ce que je dis, peut être que je saute des étapes dans mes raisonnements et qu'il te manque des éléments. Tu ne peux pas imaginer une seule seconde qu'un logiciel puisse avoir des dysfonctionnements sur une installation ? tu ne peux pas imaginer qu'il traîne des bugs dans systemd ? tu ne peux pas imaginer que d'autres logiciels pilotés par systemd, puisse avoir des soucis de démarrage parce que il manque un truc ou un test ou une manière particulière de le lancer ? Tu n'arrives pas à imaginer ça ? Peut être que postgresql avec sytemd ça marche mal pour tout plein de raisons que l'on a pas encore identifiées et que peut être qu'il y a un truc dans systemd qui manque ou qui n'est pas optimisé pour ce type de bdd ?
Je ne pense pas avoir dit que systemd est une merde qu'il faut éviter, je dis juste qu'il est possible que ce ne soit pas le saint graal parfait qui résout tous les soucis.
Par exemple, devant ce soucis particulier, on peut se demander s'il faut modifier posgresql ou systemd, je n'ai pas de réponses et je m'en cogne grave dans l'absolu, je suis arrivé à un age ou je sais vivre ma vie sans me faire chier avec ceux qui ne sont pas d'accord avec moi. Il faudrait savoir pourquoi ça passe mal avec postgresql, pour le moment je n'ai pas systemd car il n'était pas proposé au moment de l'installation. Le jour ou je devrais le faire,je gèrerais et je trouverais probablement une solution, comme démarrer à la demande par exemple ou en allant boire un café le temps que ma machine démarre, cela me rappellera win95. Mais si un mec fais un journal pour raconter son expérience et qu'on lui explique que c'est un peu un abrutis de venir se "plaindre", ça va pas faire avancer le chimiliblick, ce que j'en pense.
Moi, ce qui me hérisse c'est cette manière de tomber à bras raccourcis sur celui qui est un peu critique vis à vis de systemd. Mais le bon coté des choses, c'est que cela m'a poussé à ouvrir mon blog et mettre mes astuces et mes tutoriels dessus : en moins de 1 ans, je suis passé de j'ai pas envie de me faire chier avec un blog, j'ai toujours les forums pour raconter ma vie et expliquer mes astuces alors que j'avais tenu presque 10 ans.
Il faut voir le bon coté des choses.
# Espece d'hérétique !!
Posté par totof2000 . Évalué à -2.
Cesse donc de blasphémer ainsi contre systemd, mécréant !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.