J'ai lu beaucoup de commentaires aigris, qui à mon avis, reflètent une incompréhension de ce qu'est Archlinux. Je détaille donc ici mon point de vue sur cette distribution que j'utilise depuis 3ans.
Archlinux est…
…Communautaire
J'ai lu beaucoup de commentaires qui accusent les développeurs de "ne pas respecter les utilisateurs", de "faire tout pour les embetter" et d'autres absurdité du même genre. Il me semble important de rapeller que Archlinux est développé par des bénévoles. Ces bénévoles n'ont aucun compte à rendre aux utilisateurs. Ils développe quelque chose qui leur plait et ils décident de partager leur travail.
Si un développeur décide d'arrêter un projet, et que personne ne le reprend, il meurt. C'est ce qui es arrivé à AIF. Dire que c'est pas normal que AIF ne soit plus maintenu n'a aucun sens, on ne peut pas forcer quelqu'un à faire bénévolement ce qu'il ne veut pas faire ! De plus la majorité des projets Archlinux étant sous GPL, je cite :
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
C'est assez clair.
Maintenant, on peut en effet trouver qu'il y a trop de bug, ou qu'une maj n'a pas été assé testé. Je reviens au point important de ce paragraphe : Arch est COMMUNAUTAIRE. Donc, si on trouve qu'il y a trop de bugs, bah, il suffit de passer en testing, aider à tester, reporter des bugs, et même parfois porposer des patchs. Dans le monde de l'opensource, la seule critique constructive est celle qui propose, celle qui fait avancer.
…KISS
je cite le wiki (bon ok, c'est pas une référence puisque c'est moi qui l'ai écrit aussi :>) :
Il y a bien sûr plusieurs façons d'être simple : la simplicité selon ArchLinux, c'est une conception sans complications (techniques), sans superflu et dont le code reste simple et élégant.
Jamais ArchLinux ne prendra l'initiative de cacher ou d'interfacer des fonctionnalités ou des possibilités à l'utilisateur. Si un outil de configuration doit exister, la philosophie d'ArchLinux est de laisser son développement aux auteurs du logiciel.
Ainsi, si la convivialité n'est pas primordiale. C'est la simplicité du code et la simplicité de maintenance.
Point IMPORTANT ; archlinux est une distribution KISS et non un OS KISS. C'est pour ça qu'elle est une rolling release. Archlinux délivre à l'utilisateur ce que les développeurs du logiciel ont créé, avec le moins de modifications possibles. Arch fournit aussi la dernière version stable du logiciel, et évite autant que possible de backporter des patchs vers des versions anciennes et d'en assurer le support. Parce que c'est le mode de développement d'une distribution le plus simple techniquement, et qu'il n'apporte pas de complexité dans le processus.
Donc, demander de maintenir grub1 est absurde. C'est vouloir que Archlinux soit ce qu'elle n'est pas, parce que maintenir grub1, c'est ajouter des patchs, ajouter du code, et donc ne pas être KISS.
…pas centré sur l'utilisateur
Archlinux à certe pour but de développer ses propres outils d'administration pour faciliter la vie des utilisateurs, et de founir des fichiers de confs simples et lisibles. Mais celà vient après le KISS. Et conserver rc.conf c'est ne pas être KISS, du moins en intégrant systemd dans les dépôts. Il faut écrire un parser de rc.conf et écrire un wrapper à systemd.
Donc, la KISSitude prévaut sur la convivialité. Si des outils de confs existent, ils doivent être fournis par usptream. De même, les fichiers de configurations ne sont pas modifiés.
…ce que vous en faîtes
Parce que Arch est KISS, et qu'elle fournit des outils simples, comme Arch Build System, l'administrateur en fait ce qu'il veut. Par exemple, le paquet grub ne s'arrête pas subitement de marcher, il est toujours compilable par n'importe qui, et ce, simplement.
De même, le processus de boot de archlinux est extrêment simple, et maintenir rc.conf peut être réalisé par n'importe qui assez motivés pour le faire. Les initscripts ne s'arrêtent pas de marcher subitement. Il n'y a que quelques paquets à modifier.
conclusion
Pour finir, je ne crois pas que archlinux soit en train de perdre sa nature. Elle continue à respecter ses principes dans un monde de l'opensource qui devient sans cesse plus complexe
# Distrib pour developpeur
Posté par cedric . Évalué à 7.
ArchLinux fait pour moi parti de ces distribs qui sont ideals pour les developpeurs. Respect de l'upstream. Pas de patch aleatoire. Pas de paquet casse comme sur Ubuntu et Gentoo qui empeche la compilation. Pas de separation paquet de developpement/paquet princicipal. Possibilite de suivre directement le svn/git/… Excellente documentation.
Alors forcement, si c'est une distrib pour les developpeurs, c'est logique qu'elle suive ce que les developpeurs font et qu'elle aille vers ce qu'ils preferent.
[^] # Re: Distrib pour developpeur
Posté par batousky . Évalué à 9.
C'est triste ton avis sur Gentoo.
[^] # Re: Distrib pour developpeur
Posté par Sylvain Decremps . Évalué à 4.
Pas de paquet cassé il faut le dire vite, j'ai tué 2 arch en faisant une mise à jour basique (et oui un joli glibc 2.16 qui a foiré … et ça se compte en jours), quand même cocasse de se trouver sur un système où on sait pertinemment qu'on ne peut PLUS rien lancer …
J'ai aussi souvenir d'une version de ruby 1.9 alors même qu'elle n'avait pas été déclaré stable (et plusieurs programmes ne se lançaient plus)
Pour moi c'est de l'up-to-date à outrance, au point de faire des faux pas de temps en temps, mais respect je ne peux en dénombrer que 2 (je ne compte pas les problèmes de transition devfs à sysfs :D erreur de jeunesse).
[^] # Re: Distrib pour developpeur
Posté par Enjolras . Évalué à 5.
n'accuse pas Archlinux de ta propre incompétence…
Cela dit des majs qui foirent, ça existe. libjpeg6 par exemple :>
[^] # Re: Distrib pour developpeur
Posté par FluffyHamster . Évalué à 4.
As tu lu les instructions sur la mailist / le site officiel concernant cette mise à jour ? Dans mon cas j'ai du bidouiller mes deux systèmes différemment pour réussir la mise à jour, mais toutes les informations étaient dispos et très bien détaillés. Et la mise en garde contre le cassage de système était la également !
Quand on a un système cassé (bon, ça peut arriver…), on boot sur un livecd arch, on chroot et on réinstalle le paquet problématique. C'est également quelque part dans le wiki.
[^] # Re: Distrib pour developpeur
Posté par Thom (site web personnel) . Évalué à 4.
Franchement la mail-list, c'est pas le meilleurs coin pour ça avec ces pas loin de 200 à 300 messages par jour…
Par contre, oui dans l'absolue, faut lire le site officiel ou le site français pour voir ce qu'on va devoir faire.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: Distrib pour developpeur
Posté par FluffyHamster . Évalué à 2.
Non, la mailist [arch-dev-public] a un volume de mail très faible et est parfaitement indispensable pour les utilisateurs du dépôt testing (la preuve).
Le site officiel est mis à jour lors ce que les paquets litigieux atteignent core ou extra, avec les instructions qui ont été débattus au préalable sur la mailist.
[^] # Re: Distrib pour developpeur
Posté par Ambroise . Évalué à 1.
Encore mieux, tu peux t'abonner à la liste « arch-announce » qui ne sort que un message de temps en temps (on en est à 3 sur juillet).
C'est pas ce que je considère comme surchargé.
[^] # Re: Distrib pour developpeur
Posté par potate . Évalué à 2.
Ou si on aime manger du rss : http://www.archlinux.org/feeds/news/
[^] # Re: Distrib pour developpeur
Posté par hitmanu . Évalué à -4.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: Distrib pour developpeur
Posté par hitmanu . Évalué à -2.
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: Distrib pour developpeur
Posté par pikapika . Évalué à 0.
j'ai jamais eu autant de paquets petés que sur arch avec segfault aléatoires et bugs divers, presque pire que gentoo, c'est dire
au bout de six mois, je suis retourné sous debian, qui, à défaut d'être géniale, a au moins le mérite de marcher décemment
[^] # Re: Distrib pour developpeur
Posté par Reihar . Évalué à 3.
Des paquets, paquets, ou des trucs qui viennent d'AUR ?
[^] # Re: Distrib pour developpeur
Posté par pikapika . Évalué à 0.
les deux
et celui qui m'a moinssé changera pas grand chose à ça
[^] # Re: Distrib pour developpeur
Posté par gnumdk (site web personnel) . Évalué à 3. Dernière modification le 26 juillet 2012 à 00:20.
Ben tu dois pas avoir de chance alors parce que moi je n'au aucun problème sous Arch, ca fonctionne au poil, tout le temps… J'ai même délégué les mises à jour à Apper pour faire Ubuntu like…
[^] # Re: Distrib pour developpeur
Posté par pikapika . Évalué à 0.
j'ai encore tenté recemment, et au bout de quelques mois, l'upgrade de pacman a tout défoncé a cause de dependances circulaires et de l'introduction de paquets signés, j'ai fini par lacher l'affaire definitivement, j'avais pas trouvé de solutions qui marche sur le net
[^] # Re: Distrib pour developpeur
Posté par pikapika . Évalué à -8.
big up aux distros fanboys qui moinssent
[^] # Re: Distrib pour developpeur
Posté par gnumdk (site web personnel) . Évalué à 2.
J'ai quand même l'impression que tu as du faire une conneries, rien à voir avec des distros fan boys… Parce que bon, j'ai 4 arch qui tourne avec des besoins différents et des confs différentes (systemd) et j'ai eu aucun problème… Après, quand on installe des paquets depuis AUR, il faut savoirr ce que l'ont fait pendant les upgrades, c'est sur…
[^] # Re: Distrib pour developpeur
Posté par pikapika . Évalué à 1.
c'etait un systeme minimal au cas ou, donc pas de folie et pas de "conneries" et le distro fanboy etait pas pour toi
apres tous les sytemes petent, seulement mon experience de arch a pas été glorieuse
[^] # Re: Distrib pour developpeur
Posté par Reihar . Évalué à 0.
Deps circulaires ? On est pas sous debian là ;)
[^] # Re: Distrib pour developpeur
Posté par claudex . Évalué à 8.
Une distribution qui n'a pas les symboles de debbuggage n'est pas une distribution pour développeurs de mon point de vue.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Distrib pour developpeur
Posté par Enjolras . Évalué à 3.
Il y a eu des dicussion pour founrir les symboles à part, mais en fait, c'est tellement simple de re-compiler avec les symboles de debug que ça ne sert à rien.
[^] # Re: Distrib pour developpeur
Posté par paulez (site web personnel) . Évalué à 1.
Sauf que quand tu veux déboguer un programme qui utilise de nombreuses librairies (au hasard Evolution) là tu dois recompiler des dizaines de paquet et ça devient peu pratique ;-)
L'outil dans Fedora qui installe automatiquement les paquets de symboles nécessaires pour lire une backtrace est génial pour ça, c'est le seul truc qui me manque vraiment sous Arch !
[^] # Re: Distrib pour developpeur
Posté par Enjolras . Évalué à 2.
Ça fait longtemps que c'est en discussion, mais ça ne s'est toujours pas concrétisé. Si tu veux vraiment que ça arrive, vas mettre ton grain de sel sur le bug.
[^] # Re: Distrib pour developpeur
Posté par cedric . Évalué à 2.
En meme temps l'utilite de ces packages est tres limite, car la premiere chose dont tu as besoin si tu veux faire une session de debuggage correct, c'est d'etre sur la derniere version du trunk du projet (ou de la branch stable). Recuperer les symboles de debuggage sur un truc ancestral, je vois pas l'interet.
Ce qui serait plus utile, c'est d'avoir une version de developpement et une version de production pour les bibliotheques. La version de developpement activant tous les checks evitant les plantages et donnant des informations precisent aux developpeurs. La version de production prenant tous les raccourcis et pouvant amener des jolis SEGV plutot qu'un morne message d'erreur.
Ca serait deja plus utile pour les developpeurs utilisant ces bibliotheques. A la rigueur pour faciliter le debogage la version de dev devrait inclure les symboles de debug. Mais bon, je ne connais aucune distrib qui fait ca…
[^] # Re: Distrib pour developpeur
Posté par claudex . Évalué à 5.
Je ne vois pas pourquoi tu as besoin de la dernière version. Quand je développe mon appli en Qt et que ça se vautre, je suis bien content d'avoir les symboles de Qt de la version que j'utilise, pas d'une version qui sortira plus tard.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Distrib pour developpeur
Posté par du64 . Évalué à 0.
J'ai utilisé Archlinux sans être développeur,elle est aussi facile qu'une autre distribution.
Seul reproche c'est abs,il faut faire un paquet par exemple pour le kernel,la config du kernel par defaut tout activé.
Une fois installé slim ne démarré pas.Il me semble aussi qu'il y a les drivers nvidia beta par defaut?
La je suis sous gentoo que je connais depuis le début,c'est beaucoup plus facile par exemple d'installer vanilla-sources(kernel du kernel.org brut).C'est plus facile sous gentoo de choisir les versions
# CQFD
Posté par JPEC . Évalué à 4.
Très bon résumé de la situation ! Arch Linux garde sa ligne de conduite (ses principes) et continue d'évoluer… Tout simplement!
# KISS
Posté par Olivier Filipe . Évalué à 4.
Pour info KISS (Keep it Simple, Stupid) c'est "une ligne directrice de conception qui préconise de rechercher la simplicité dans la conception et que toute complexité non nécessaire devrait être évitée"
Merci wikipedia!
[^] # Re: KISS
Posté par Reihar . Évalué à -1.
Voir aussi : Rasoir d'Occam.
[^] # Re: KISS
Posté par arnaudus . Évalué à 2.
Voir aussi : rien à voir.
[^] # Re: KISS
Posté par lapada . Évalué à 1.
Voir aussi : ignorance et cuistrerie.
Rasoir d'Ockham sur Wikipedia.
Au cas où les moinsseurs n'auraient pas compris cuistrerie :
[^] # Re: KISS
Posté par arnaudus . Évalué à 10.
Je maintiens : ça n'a rien à voir. Mon commentaire était peut-être succinct, mais le KISS est un principe de minimalisme (appliqué à la conception d'artefacts), alors que le rasoir d'Occam est un principe de parcimonie (adapté à la conception de modèles explicatifs). Le rasoir d'Occam est un axiome de la logique scientifique, il ne peut pas être remis en cause. Le KISS est un concept de design vaguement fumeux, qui utilise la notion de "simplicité" sans vraiment la définir, et il peut évidemment être remis en cause—c'est un choix, une convention de développement.
Le seul point commun entre les deux repose sur l'idée qu'un système simple est plus élégant et plus facile à manipuler (en gros, ça exclut certains concepts artistiques), mais ça s'arrête là. L'assimilation du KISS avec le rasoir d'Occam est trompeuse, car elle pourrait faire croire que, par exemple, les choix de développement de Gnome sont plus rationnels que ceux de KDE, ce qui est profondément stupide.
En particulier, on peut très bien défendre le point de vue que l'ergonomie d'un artefact se doit d'être intuitive, et pas simple. Parfois, une interface simple est intuitive, mais souvent, elle ne l'est pas. Un bon exemple est celui du volant pour diriger un véhicule. Étonamment, c'est assez intuitif de tourner le volant pour tourner les roues, mais le dispositif mécanique sous-jacent est terriblement complexe, et nécessite de transformer un mouvement circulaire en mouvement linéaire grâce à une crémaillère. Clairement, ce n'est pas KISS du tout. Un autre exemple, plus près de l'informatique, est la pratique assez étrange d'allumer un ordinateur grâce à un interrupteur, et de l'éteindre de manière purement "informatique". Ça a l'air assez intuitif pourtant, même les grand-mères trouvent "normal" de ne pas utiliser le même bouton pour allumer et éteindre un ordinateur, mais là encore, ça n'est pas KISS : le principe du KISS demanderait qu'il y ait une unique interface, et que la seule manière d'éteindre un ordinateur serait d'appuyer sur le même interrupteur que pour l'allumer.
Le rasoir d'Occam consiste à préférer une explication simple à une explication complexe. Par exemple, je clique sur "éteindre mon ordinateur", et l'ordinateur s'éteint. On peut se demander si mon action a entrainé l'extinction de l'ordinateur, ou s'il s'est éteint parce qu'il y a eu une panne d'électricité au même moment. Si je n'ai pas moyen de répliquer l'expérience, le rasoir d'Occam impose de choisir la première solution, qui ne fait pas intervenir de cause extérieure (la panne d'électricité). La rasoir est un critère de décision, il ne précise rien quant au design d'une interface.
D'ailleurs, il y a des cas où le KISS et le rasoir d'Occam sont en contradiction dans la construction d'un modèle. Par exemple, un pot de fleur tombe de ma fenêtre, et 2 secondes plus tard, je l'entends se briser par terre. À la question "à quelle distance du sol le pot était-il 1 seconde après le début de sa chute", le KISS et le rasoir d'Occam imposent deux résultats différents. Le KISS impose un modèle simple, probablement un modèle linéaire. Occam impose un modèle avec le moins de causes possibles, typiquement, un modèle d'accélération constante sans frottement. On voit bien que la diminution du nombre de causes ne mène pas nécessairement à un modèle plus simple.
[^] # Re: KISS
Posté par lapada . Évalué à -1.
Je maintiens : ça a à voir.
Le KISS promeut la simplicité dans la conception et le développement des logiciels.
Le rasoir d'Occam promeut la simplicité dans la conception et le développement des théories (philosophiques, physiques, ce que tu veux).
Les erreurs de ta part :
Tu peux bien sûr insister sur les différences, n'empêche que le commentaire en question insistait sur les ressemblances.
Le commentaire ne les mettait pas sur le même niveau, ce que tu fais, en voulant les appliquer aux mêmes domaines, et qui est erroné.
Sinon, la recherche de la simplicité n'est pas plus éternelle dans les modèles scientifico-philosophiques que dans le développement logiciel. Des deux côtés, se réduire au minimum et rechercher la simplicité jusqu'à l'austérité peut en vérité largement complexifier (et non pas compliquer) les tâches.
Le KISS s'applique au départ au développement, pas à l'interface utilisateur, comme tu le supposes avec l'exemple de ton volant. Cf Arch.
[^] # Re: KISS
Posté par arnaudus . Évalué à 2.
La simplicité et la parcimonie sont deux notions distinctes. Ce qui est simple n'est pas nécessairement parcimonieux, et vice-versa. D'où ma remarque : ça n'a pas grand à voir.
Je ne vois pas pourquoi le KISS s'appliquerait au développement en priorité, il s'applique au design en général (Wikipédia mentionne la naissance du concept dans le domaine de l'aviation). Mais justement, je suis d'accord avec ton exemple, c'était exactement mon objectif avec l'exemple du volant de voiture : il est tout à fait légitime de privilégier l'ergonomie à la simplicité, et donc de rejeter le principe du KISS.
De toutes manières, à mon avis, personne ne fait exprès d'obfusquer quelque chose. Les choses deviennent complexes parce qu'elles sont construites sur l'existant, parce qu'on a essayé de faire simple sans y arriver, parce que ce qui parait simple pour quelqu'un ne l'est pas pour quelqu'un d'autre, ou simplement parce qu'un algo efficace n'est pas forcément simple. C'est bien beau de gueuler KISS!, mais qu'est-ce que c'est qu'un code simple? Est-ce que function DoThis(); function DoThat() est plus simple que function Do(doThis = TRUE) ? Est-ce que déporter tous les algos dans des fonctions bien cachées dans internal.cpp pour ne garder que la structure du programme quand on lit le code est plus simple que de programmer gentiment en explicitant les instructions?
[^] # Re: KISS
Posté par lapada . Évalué à 0.
Le rasoir d'Occam ne se limite pas à la parcimonie. Je t'invite à relire la page wikipédia, que les moinsseurs n'ont sûrement pas lu non plus. Et à compter tant qu'à faire le nombre d’occurrences du mot simplicité.
[^] # Re: KISS
Posté par lapada . Évalué à 1.
http://linuxfr.org/nodes/94959/comments/1371023
[^] # Re: KISS
Posté par MTux . Évalué à 0.
Faire du KISS avec du Linux, ils sont bien méritants.
Surtout quand on commence à parler des bidules de RedHat.
# Nope
Posté par mathieui (site web personnel) . Évalué à -6.
Ah ? Depuis quand ?
Non, ça en fait partie.
Pourquoi ?
Pourquoi ?
Ouais, vim. Si ce n’est pas éditable à la main → bloat.
Comment ?
[^] # Re: Nope
Posté par Enjolras . Évalué à 4.
Tu connais pacman ?
Non, un fichier de conf lisible n'a rien à voir avec le KISS. Si tu dois écrire un wrappper de 300 lignes pour exposer ce fichier de conf simple, c'est pas KISS, c'est bloat.
Parce que justement, si tu veux intégrer systemd avec rc.conf, il faut écrire des wrappers.
C'est pas à arch de choisir avec quel outil tu fais ta conf. vim, emacs ce que tu veux. Et si les développeurs GNOME ou grub on décidé qu'il fourniraient d'autres fichiers de conf, tu vas pas demander aux devs Arch de pas les packager…
Bah, oui, autant que possible, les fichiers de conf fournis par les paquets ne sont pas patchés.
[^] # Re: Nope
Posté par mathieui (site web personnel) . Évalué à 4.
Jusqu’à preuve du contraire, systemd n’est ni le système d’init par défaut, ni le préféré, ni le majoritaire ; partant de là, je vois assez mal en quoi on devrait écharper le rc.conf juste parce qu’il faut faire plaisir aux gens qui l’utilisent. Si tu veux utiliser systemd, tu peux coder ton wrapper, utiliser celui que les gens mettent gracieusement à ta disposition ou utiliser les 52 fichiers de conf différents de systemd au lieu du rc.conf, ça me fait ni chaud ni froid. Par contre, viens pas pourrir mes fichiers de configuration pour te faciliter la vie ; tu utilises systemd, c’est ton problème.
J’ai dit ça où ?
[^] # Re: Nope
Posté par Enjolras . Évalué à 4.
Sauf que les devs ont décidé se supporter systemd officiellement. Et comme ils ont pas eu envie de coder le wrapper, pour garder les choses simples, ils ont viré rc.conf. Stou.
[^] # Re: Nope
Posté par FluffyHamster . Évalué à 6.
En parlant de ça, voila un extrait du débat actuel sur la mailist dev-public de Arch :
En gros, va falloir t'y faire a systemd…
[^] # Re: Nope
Posté par gnumdk (site web personnel) . Évalué à 3.
Perso, j'ai migré que sur mon portable et j'ai pas grand chose à dire…
J'avais peur que systemd lance trop de service par défaut mais sous Arch, les seuls service par défaut lancé était logind et journald dans mes souvenirs…
J'ai du rajouter networkmanager, dbus et kdm à la main (enfin, il me semble)
Ensuite, à l'utilisation, je ne trouve pas la commande systemctl super pratique avec ses nom à rallonge, c'est le seul reproche que je fait à systemd.
[^] # Re: Nope
Posté par Reventlov . Évalué à 3.
Je rebondis sur le commentaire de mathieui. Pourquoi vouloir maintenir une configuration par défaut compatible avec deux systèmes d'init, dont un est par défaut non installé ? Le split de rc.conf est utile pour les gens qui utilisent systemd, mais pourquoi imposer ça à tout le monde quand le système d'init de archlinux par défaut n'est pas systemd, et quand ce dernier est loin d'être majoritaire ? Ça oblige le système d'init par défaut actuel à appeler les binaires de systemd pour comprendre cette nouvelle configuration.
Comme l'a dit Ionut Biru (un développeur de ArchLinux) dans la mailing-list:
Je trouverais ça plus logique que de modifier l'init actuel pour lui faire bouffer la syntaxe de configuration de systemd, pour trouver, par exemple, /usr/lib/systemd/systemd-remount-fs à la place de mount -o rw,remount / dans le /etc/rc.sysinit (et après, on prétend que c'est kiss).
[^] # Re: Nope
Posté par Enjolras . Évalué à 1. Dernière modification le 25 juillet 2012 à 16:00.
Personne n'a prétendu que systemd était KISS.
Pourquoi ? La réponse est encore une fois simple : parce que personne n'a semble-t-il envie de le faire. C'est pas la peine de débattre des heures la dessus… Tu peux essayer d'inciter des devs à le faire, le faire toi même, postuler comme TU et le mettre dans community, que sais-je.
Ce que tu trouves logiques, au fond OSEF, à moins que tu ne le fasse, ou que tu trouves quelqu'un pour le faire à ta place.
[^] # Re: Nope
Posté par zeb . Évalué à 1.
Je suis d'accord avec Biru. Je suis en train de reviser le Beginner's guide, et avoir un Archlinux en limbo, entre initscripts et systemd, entre un rc.conf centralise et une serie de fichiers de conf distincts ne me rend pas la tache facile. La config officielle utilise maintenant les multiples fichiers de systemd (eux-memes en partie issus de Debian), alors que initscripts est toujours utilise et rc.conf est toujours supporte. Vouloir etre compatible est certainement un bonne chose, mais en ce moment on s'eloigne du KISS de depart. Mais j'ai confiance que ca devrait se resoudre quand la transition sera faite.
D'ailleurs, vous etes invites a tester et corriger le Beginner's guide: https://wiki.archlinux.org/index.php/Beginners'_Guide/Installation.
[^] # Re: Nope
Posté par Enjolras . Évalué à 1.
Tout le monde est d'accord avec ça, c'est évident -_- ! C'est toujours mieux d'avoir le choix.
Mais la le problème c'est que personne ne veut maintenir deux implémentations. Donc la question est :
Puisqu'on veut une seule implémentation, et qu'on veut systemd, alors, doit-t-on garder rc.conf ? On s'éloigne du KISS, mais ce n'est pas la faute d'arch. C'est la faute de Red Hat. Et ça tu peux pas y faire grand chose…
Il n'y a que 3 solutions :
Tu dis qu'on doit avoir le choix, donc l'option 1 va à l'encontre de tes principes.
Les devs ont trouvé que l'option 2 était trop de boulot, même si c'est a priori une bonne option.
L'option 3 est celle choisie.
Au passage, tu es invité à contribuer au wiki français et pas aux pages internationalisées du wiki .org que tout le monde aimerait bien supprimer.
[^] # Re: Nope
Posté par Anonyme . Évalué à 4.
Autant je suis d’accord sur l’utilisation du premier « on », autant le second devrait être remplacé par « je » ou « une partie des utilisateurs d’Arch ». Mais bon, ces modifications rendraient ta phrase idiote puisqu’il faudrait plutôt se poser la question : doit on prévoir l’utilisation de SystemD ?
[^] # Re: Nope
Posté par Enjolras . Évalué à 0.
je me demande si on doit fournir chromium et firefox. Founir que firefox pourrait suffire.
Tiens et d'ailleurs, à quoi bon fournir KDE, seule une partie des utilisateurs Arch le veulent.
Puis tant qu'on y est, on peut aussi virer vim et nano, il y a emacs.
Et, et et…
[^] # Re: Nope
Posté par Anonyme . Évalué à 0.
Y a que toi qui parle de virer des trucs.
Moi j’ai juste sous-entendu qu’il ne fallait pas s’occuper des utilisateurs de systemd, c’est à eux de gérer leur merde.
[^] # Re: Nope
Posté par Renault (site web personnel) . Évalué à 10.
Ça tombe bien car les développeurs de Archlinux semblent vouloir de systemd.
Du coup c'est toi qui va devoir gérer ta merde d'avant car personne dans les officiels, apparemment, ne souhaite continuer le travail actuel.
[^] # Re: Nope
Posté par zeb . Évalué à 1.
Je parlais de la documentation principale en Anglais, je ne m'occupe pas des traductions, desole :)
[^] # Re: Nope
Posté par B16F4RV4RD1N . Évalué à 1.
mais justement, on ne veut pas de ce truc tout pourri…
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Nope
Posté par Anonyme . Évalué à 0.
C’est pas que c’est tout pourris, c’est même pas forcément mauvais comme système d’init.
Le plus gros problème que je vois c’est que, au mieux, c’est complètement inutile pour 99% des utilisateurs.
[^] # Re: Nope
Posté par Enjolras . Évalué à 5.
TU ne veux pas.
Votre argument se retourne contre vous "je veux avoir le choix de ne pas utiliser systemd, pourquoi si seule une partie de la communauté veut systemd ça devrait m'impacter ?"
peut devenir :
"je veux avoir le choix d'utiliser systemd, pourquoi le fait qu'une partie de la communauté ne veut pas avoir systemd devrait m'impacter ?"
[^] # Re: Nope
Posté par B16F4RV4RD1N . Évalué à 2.
sauf qu'au lieu d'avoir le choix entre les 2, cela va vite se résumer à devoir subir systemd
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Nope
Posté par Marotte ⛧ . Évalué à 3.
Utiliser Debian
Utiliser FreeBSD
Forker (participer à un fork d') Archlinux
Il reste un choix mais tu as raison. Combien de temps avant que FreeBSD implémente les cgroups et fanotify et intègre systemd ?
D'un autre coté il faut reconnaître que systemd apporte des fonctionnalités :
J'utilise pas mais j'imagine que les cgroups c'est important pour la sécurité de certains environnements.
Je pense que ça peut être utile dans certains cas. Plus de 1% des gros systèmes de prod à mon avis.
Ça on avait déjà mais je suppose que c'est lié à :
Avec l'init SysV j'ai eu parfois des comportements bizarres en modifiant l'ordre des liens pour obtenir le comportement voulu (dernier exemple en date : démarrer postgressql, attendre qu'il soit prêt pour lancer snort) et bien même en les "éloignant" bien, en mettant postgres avant, il arrive que snort se gauffre sur : pas de base de données dispo et il faut le lancer à la main.
J'ai l'impression que l'ordre des liens dans les /etc/rcX.d n'ordonne que le lancement des scripts, vu qu'il en lance plusieurs à la fois il se peut (si mettons le 12 est très long) que le service du script 99 est démarré avant celui du 12 ? Il y a peut-être quelque chose que j'ignore sur le système d'init que j'utilise actuellement mais j'ai quand même l'impression que systemd essaye de répondre à un vrai problème de l'init SysV…
[^] # Re: Nope
Posté par B16F4RV4RD1N . Évalué à 2.
justement, archlinux utilise (mais plus pour longtemps du coup) l'init BSD, donc les problèmes de SysV et ses pseudo résolutions ne le concernent en rien.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Nope
Posté par Marotte ⛧ . Évalué à 2.
Je ne connais vraiment pas assez l'init BSD pour juger mais si tu me dis qu'elle permet "un contrôle des services elaboré, transactionnel, basé sur des dépendances" c'est chouette. Ça veut dire que ça va rester dans FreeBSD et par delà dans Debian s'ils laissent pas tomber GNU/kfreeBSD.
[^] # Re: Nope
Posté par gentildemon . Évalué à 2.
Dans Debian GNU/kfreeBSD, seul le noyau change et les logiciels sont recompilés pour, mais ça ne te donne pas un init BSD.
[^] # Re: Nope
Posté par gnumdk (site web personnel) . Évalué à 3.
Je vois pas en quoi l'init BSD répond au problème du monsieur… Il a le même bug de conception que SysV
[^] # Re: Nope
Posté par gnumdk (site web personnel) . Évalué à 3.
Non, c'est juste que ce n'est pas parce ce que le process a rendu la main au script qu'il est vraiment en train d'écouter sur le port le concernant… Donc, si vraiment il est très lent et qu'un process suivant ouvre le port en question, ca plante.
[^] # Re: Nope
Posté par Marotte ⛧ . Évalué à 2. Dernière modification le 25 juillet 2012 à 23:03.
Je crois avoir saisi au moins une partie du problème…
Si je veux écrire un daemon qui soit lançable par systemd je devrais faire dépendre mon daemon de D-Bus et/ou d'autres bibliothèques (ou écrire un wrapper) ? Alors qu'avec les init SysV et BSD on est plus libre vu qu'on utilise le shell, on peut donc lancer n'importe quel programme ?
[^] # Re: Nope
Posté par gnumdk (site web personnel) . Évalué à 5.
Non, tu n'as rien compris…
[Unit]
Description=Show some information over KDM
After=kdm.service
[Service]
ExecStart=/usr/local/bin/play_with_kdm.sh
StandardOutput=syslog
[Install]
WantedBy=graphical.target
Je peux t'assurer que ce script shell ne dépend pas de dbus ni de systemd ;)
[^] # Re: Nope
Posté par navaati . Évalué à 5.
Houlala, ya des gens qui imaginent des trucs aussi fous à propos de systemd oO ? Je comprends que certain y résistent…
Donc, non, pas du tout, pour lancer un daemon avec systemd, dans le cas le plus simple, y suffit d'un fichier du style :
Et c'est tout (ça remplace les initscripts).
Ce fichier tout simple va considérer que les ressources mises à disposition par le service le sont instantanément (c'est le cas avec la socket-activation, par exemple), et que le daemon ne fork pas, mais on peut aussi rajouter une ligne
Type=forkingpour dire que les ressources sont dispos une fois que le daemon a forké, enfin il ya tout un tas de variantes, par exemple unType=dbuspour considérer que le lancement est fini quand le daemon a pris un nom sur le bus (et là aussi, le daemon n'a pas à forker). Savoir quand est-ce qu'un service a fini son démarrage est important pour ordonner les dépendances.Un support spécifique de systemd est requis si on veut utiliser la feature de socket-activation (mais ça casse pas trois pattes à un canard, ça consiste à aller lire dans des variables d'env quels sont les numéros des file descriptors déjà ouverts par systemd, rien de bloat), ou la feature de notification (en mettant
Type=notifydans le fichier de conf) qui consiste a dire à systemd via une socket quand est-ce que le service est complètement initialisé.Pour les développeurs de daemon et les admin-sys, au contraire systemd simplifie drôlement les choses.
Je t'invite à lire les billets de Lennart pour plus d'infos, même si tu compte pas passer à systemd c'est intéressant de voir ce qu'il est possible de faire.
[^] # Re: Nope
Posté par Marotte ⛧ . Évalué à 2.
Merci pour tes explications, ainsi qu'à glumdk.
# systemd
Posté par jc51 . Évalué à 3. Dernière modification le 25 juillet 2012 à 15:20.
très bonne article Enjolras,je suis entièrement d'accord avec toi,moi je viens de passer mes 2 arch en full systemd ,et supprimé les rc.conf.
[^] # Re: systemd
Posté par Enjolras . Évalué à 4.
Je dis pas non plus qu'il faille installer systemd à tout prix. Et je trouve que rc.conf était une bonne chose.
Je préfère largement avoir rc.conf que 10 fichiers aux noms absurdes et à la syntaxe incohérente. Par contre, je dis que la décision de supprimer rc.conf n'est pas si irrationnelle que ce qu'on a tendance à l'affirmer.
[^] # Re: systemd
Posté par stopspam . Évalué à 3.
elle n'est pas irrationnelle sur d'autres distrib ou la complexité est masquée et ou l'utilisateur dispose de connaissances limitées.
Sur Arch la question se pose. Comme dit plus haut, il serait préférable de garder le choix du rc.conf par défaut et laisser ceux qui veulent de systemd. Par ailleurs, pourquoi ne pas avoir choisi un init systemV à l'origine ? Je pense qu'il y avait une ligne directrice sur la façon de faire et d'évoluer et qu'elle est maintenant en sursis.
Pour en revenir à ton journal :
Quelle rangaine. Chacun à le droit d'exprimer son opinion sur le choix qui est fait par les dev. Bénévole, communauté… n'a pas à rentrer en ligne de compte et il n'est même pas question de ça.
Je passe. Tu mélanges les genres et en vient à parler de "convivialité".
Trouves-moi une distrib sur laquelle on ne peut pas faire ce qu'on veut. Un peu de bon sens. Il s'agit encore une fois du choix par défaut que fait la distrib dont il est réellement question.
Le fait même qu'il y ait par-ci par-là des gens qui se posent des questions autour de mêmes sujets démontre un changement.
[^] # Re: systemd
Posté par Enjolras . Évalué à 1.
Tu poses beaucoup de questions et tu n'y réponds pas.
C'est évident qu'il serait préférable d'avoir les deux, personne ne l'a nié. Le fait est qu'on se place dans un cas ou les devs n'ont pas ENVIE d'avoir les deux. Dans ce cas on prend le plus simple à développer pour fournir le maximum d'outils, c'est tout à fait rationnel comme choix, si tu vois plus rationnel, je serais heureux de l'apprendre.
J'ai essayé de décrire la ligne directrice, si tu n'es pas d'accord propose une autre réponse, parler dans le vide ne sert à rien.
Tiens tu fais parti de ce genre de personne qui se comporte comme "tu as tort, mais c'est tellement débile que j'expliquerais même pas pourquoi je pense que tu as tort" Constructif comme commentaire…
Il y a différents niveaux de facilité à faire ça. Avec Arch, si tu veux KDE, tu dois pas désinstaller gnome avant.
Les gens se plaignent d'un changement d'implémentation. je ne vois pas en quoi ça dénote d'un changement de philosophie.
[^] # Re: systemd
Posté par stopspam . Évalué à 5. Dernière modification le 25 juillet 2012 à 19:57.
Je vais alors essayer de répondre.
A l'heure actuelle et jusqu'à preuve que systemd soit un élément indispensable de tout système Linux, le plus simple était de rester sur l'architecture en place, l'init BSD. Est-ce que la maintenance des scripts de démarrage ainsi que l'init était si compliqué et chronophage ? Le sera t'elle autant avec systemd ? Si qqun a un peu de recul la dessus, qu'il donne son point de vue.
Qu'apporte au final systemd et de façon pratique ? Un exemple concret et assez généraliste en dehors des 10 péquins qui ont une config très très exotique.
A propos du "KISS" : le mot simple n'étant déjà pas évident à définir, introduire le terme de convivialité n'aide pas plus. Il y a aussi souvent une confusion entre la simplicité et la rapidité qu'il faut dissiper.
On peut parler d'implémentation ou même de choix technologique. Chez moi, c'est intimement lié à la "philosophie". La façon de développer ou de choisir un logiciel reflète d'un certain état d'esprit. On peut comparer le développeur qui va ne pondre qu'une GUI (aussi belle soit-elle) et celui qui va utiliser un fichier texte universellement bidouillable.
Se tromper ça arrive, faire de mauvais choix répétitifs est le premier signe d'un changement de mentalité/philosophie.
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 4.
Ce qu'apport systemd ? Une vrai dépendance inter services ?
Parce que bon,
DAEMONS=(plop plip)
avec plip qui dépend de plop ne te garantie à aucun moment que plop sera opérationnel au lancement de plip… Avec systemd, tu peux gérer ce genre de problèmes…
[^] # Re: systemd
Posté par gnumdk (site web personnel) . Évalué à 2.
Faire un script qui lit un fichier rc.conf et qui génère la conf pour systemd, ca doit prendre moins d'une journée… Si tu veux garder ton rc.conf, tu peux, ca n'a juste aucun intérêt…
[^] # Re: systemd
Posté par stopspam . Évalué à 2.
Le problème n'est pas comment maintenir une synchro entre les 2 systèmes. C'est le choix de celui par défaut qui est discutable au détriment de l'autre solution qui ne sera plus du tout supportée.
# les développeurs de "ne pas respecter les utilisateurs", de "faire tout pour les embetter"
Posté par hitmanu . Évalué à -1.
les dev ont fais ce qu'ils pouvais pour maintenir grub1, rc.conf et autre, et ne pas utiliser systemd, mais ils aurais mieux fait de suivre ce que d'autre distrib on fait pour qu'il n y ai pas de grand râleur remonter contre leur distrib chérie et puis malgré tous ces changements radicaux elle reste facile a configurer, apres toute la casse que j'ai put faire il y a quelle que jour. ;)
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: les développeurs de "ne pas respecter les utilisateurs", de "faire tout pour les embetter"
Posté par JoeBar . Évalué à 2.
Tu sais il y a un mot qui s'appelle "quelque"…
[^] # Re: les développeurs de "ne pas respecter les utilisateurs", de "faire tout pour les embetter"
Posté par hitmanu . Évalué à -1.
j'aurai du me relire merci :(
Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.
[^] # Re: les développeurs de "ne pas respecter les utilisateurs", de "faire tout pour les embetter"
Posté par deasy . Évalué à 1.
aurais*
# Au sujet de KISS
Posté par jbbourgoin (site web personnel) . Évalué à 10.
Avec ces billets sur Arch j'entends parler de KISS à toute les sauces.
Le fait qu'une application fasse une seule chose et la fasse bien, est secondaire selon ce principe. Car KISS s'applique moins à l'usager qu'au développeur. C'est avant tout un principe de développement. D'ailleurs, les fondateurs d'Arch l'ont assez bien compris, et les premiers commentateurs de ce billet qui parlent d'une "distribution pour développeurs" sont clairement dans le vrai.
Il semble qu'il y ait une "récupération" du concept par les utilisateurs non-développeurs de Linux. C'est très intéressant d'ailleurs, car ce qui est simple pour un utilisateur n'est pas toujours simple côté développement ! On arrive donc à un concept qui aboutit à des jugements bien souvent opposés sur les mêmes logiciels.
Un exemple de KISS côté développement, afficher le contenu de dossiers et de sous-dossiers en arbre :
Cette méthode est la plus simple côté développement, car elle articule trois logiciels qui ne s'occupent de faire qu'un travail bien particulier. Le dev de ls n'a pas à se préoccuper de la mise en forme ni du tri qu'il laissera à grep et sed.
Côté utilisateur pur, il est clair que cette méthode est bien moins agréable qu'un simple :
Par contre, tree, côté développement est un peu moins KISS car s'il ne s'occupe que d'une chose (afficher le contenu de dossiers en arbre), il réalise tout seul des tâches bien différentes (lister, trier, mettre en forme…).
Dès lors le but d'Arch n'est pas de simplifier la vie de l'usager (rc.conf, AIF, grub2 etc.) mais celle des développeurs de la distrib (pas de patch, dernières versions des logiciels etc.).
[^] # Re: Au sujet de KISS
Posté par jbbourgoin (site web personnel) . Évalué à 6.
D'ailleurs, si nous comparons la "philosophie" Arch avec celle de Debian ("le système d'exploitation universel") on perçoit très vite les différences de conception.
Le but de Debian est de convenir autant que possible à tout le monde : dev, utilisateur "bureau", admin etc. D'où l'installation solide et simple, d'où la lenteur avant la distribution d'une versions stable, d'où les patchs aussi.
Il s'agit donc de choisir sa distrib en fonction de ce que l'on veut réellement, et de ce qu'elle propose réellement. Arch est tentante pour son côté rolling release, mais beaucoup d'utilisateurs qui recherche cela (où qui ne la perçoivenr que comme un linux habillé en BSD) ne perçoive pas clairement son orientation "développement" et finissent par ne pas comprendre certains de ses choix.
Idem pour Debian d'ailleurs. En ce qui concerne Ubuntu il y a moins de difficultés car ses objectifs sont globalement clairs pour tous : c'est le fameux bug n°1 !
[^] # Re: Au sujet de KISS
Posté par Marotte ⛧ . Évalué à 2.
Elle est aussi moins rapide je suppose.
[^] # Re: Au sujet de KISS
Posté par jbbourgoin (site web personnel) . Évalué à 2.
Certainement.
[^] # Re: Au sujet de KISS
Posté par Anonyme . Évalué à 2.
sur une debian :
…
|-cnam
|---activite1
|---activite2
|---activite3
|---activite4
|---cours5-filtre_data
|-----e00
|-------d00
|-------d01
|-------d02
|-------d03
…
et :
debian:~$ tree
bash: tree : commande introuvable
elle n'est pas partout non plus
[^] # Re: Au sujet de KISS
Posté par Marotte ⛧ . Évalué à 4.
Toi tu vas me faire le plaisir de te sortir les doigts du cul ! :)
Bon c'est Ubuntu là mais je suppose que le package existe aussi sous Debian.
[^] # tree
Posté par Arthur Accroc . Évalué à 3.
Sauf que le résultat de la vraie commande tree ressemblerait plutôt à :
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Et pourquoi systemd ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Dans ce cas pourquoi intégrer systemd et pas continuer comme ce qui se faisait avant ?
Et ne me dit pas pour que le démarrage soit plus rapide … Archlinux n'a pas besoin de systemd pour être véloce au démarrage.
Pour ne pas gérer les dépendances entre les services ?
Bof, ce que faisaient eux même les utilisateurs est déporté aux bénévoles de la distribution. A moins que ces derniers laissent les utilisateurs à se palucher la conf systemd pour chacun des services qu'ils veulent utiliser, auquel cas on passe d'un système simple d'utilisation à un système plus sioux (va te taper la doc sur systemd). Jusqu'alors, il suffisait d'indiquer dans le fichier rc.conf les daemons que l'on voulait démarrer et parmi ceux là ceux qui sont à lancer en arrière plan et franchement j'ai trouvé ça super sympa.
Franchement, j'ai du me palucher systemd sur une Fedora 17 pour tester la réalisation d'un paquet RPM et je reste assez dubitatif sur la chose : le compromis entre la complexité du bousin et le service qu'il est censé remplir vaut il vraiment le coup ?
[^] # Re: Et pourquoi systemd ?
Posté par cedric . Évalué à 6.
Tu as fait la comparaison ? J'ai un boute en 4s avec systemd au lieu de 40s avec l'init classique. Et oui, ca demarre le meme nombre de service et ca fait exactement la meme chose…
Meme pas, c'est deporte sur les developpeurs upstream qui fournissent une unit pour leur projet. Ca evite que les distribs ou les utilisateurs ne fassent trop n'importe quoi. Ca permet de faire le boulot une fois pour absolument tout le monde. Les unit systemd etant nettement plus portable que les scripts d'init…
Maintenant compare la complexite entre apprendre le shell script et le systeme de demarrage de ton systeme a la complexite d'un fichier unit qui sera terme fourni par la majorite des projets upstream. C'est sur faut changer ses habitudes et apprendre un truc nouveau pour ceux qui savaient deja de quoi on parlait.
C'est juste une periode de transition.
[^] # Re: Et pourquoi systemd ?
Posté par Anthony Jaguenaud . Évalué à 0.
Compare t’on la même chose ? À la fin de ton « boute », un ps contient t’il tous les services, ou c’est un fake comme windows qui démarre d’abord le graphique et ensuite les services rendant le PC inutilisable pendant de nombreuses secondes alors qu’on a l’impression qu’il a démarré.
[^] # Re: Et pourquoi systemd ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
La comparaison que j'ai n'est pas équitable : d'un côté une Fedora 17 sur un PC portable ultra-moderne et de l'autre un ArchLinux sur un vieux portable : je n'ai pas vu la différence notable au démarrage. A la décharge toutefois de la distrib Fedora, il me semble qu'elle démarre plus de services (faudra que je vérifie).
De plus, avec un SSD qui se démocratise de plus en plus, le démarrage même avec un vieux système d'init UNIX à la system-v est devenu convenable.
En attendant, ce n'est pas le cas. C'est donc AMHA encore tôt pour intégrer systemd.
De plus, ça risque d'être comme avec les scripts init : ce seront les packageurs qui devront le faire ou les adapter ; l'avenir nous le dira.
D'abord, je parlais de la complexité de l'implémentation (et donc du poids et de son obscurité) du bousin comparé au service rendu. Les questions auxquelles il tente de répondre sont pertinentes.
Ensuite, désolé, mais au vue du profil d'ArchLinux, ses utilisateurs, sans en être des experts, sont capables d'écrire des scripts shells. De plus, si un script shell est effectivement plus complexe que la syntaxe d'un fichier init à la windows, elle n'est pas si dramatique dans l'écriture d'un script de démarrage/d'arrêt de service et elle ne cache pas la complexité qu'il faudra tôt ou tard appréhender avec systemd pour pouvoir jouer avec les dépendances entre services et ressources systèmes.
[^] # Re: Et pourquoi systemd ?
Posté par gnumdk (site web personnel) . Évalué à 1.
Il faut quand même avouer que Arch sur un laptop SSD avec systemd, tu oublies la mise en veille, cela ne sert absolument à rien, j'ai un boot entre syslinux et kdm qui doit durer 2 secondes…
[^] # Re: Et pourquoi systemd ?
Posté par claudex . Évalué à 7.
Si je mets en veille (ou en hibernation), c'est pour garder les applications ouvertes dans leur état actuel, pas pour gagner du temps (je crois que j'en perd avec l'hibernation)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.