Archlinux.fr [Forums]

[edit modo]split depuis http://forums.archlinux.fr/topic11488.html[/edit]

jc51 a écrit :@Ypnose j'ai testé systemd c'est vraiment rapide le démarrage,on voit la différence

franchement, vous redémarrez souvent votre ordinateur ?
Je dois le redémarrer tous les 15-30 jours, sinon je le mets en hibernation.

Foutre en l'air toute la philosophie Unix, supprimer l'init BSD si pratique, et injecter une technologie merdique (oups un gros mot, bah ça fait vendre, cf. Theo de Raadt, Linus et compagnie qui ne mâchent pas leurs mots), uniquement compatible Linux en plus, merci pour les autres OS, juste pour gagner 15 secondes aux démarrages, quel gâchi.

L'avantage de l'init BSD, en plus, c'est qu'il est très facile de rajouter des scripts à lancer lors de l'init, pour démarrer certains programmes, services tiers etc.

Sans compter la facilité d'utilisation de rc.conf

Si archlinux abandonne ça, peut-être que je vais passer sous Slackware, voire sous BSD...

farvardin a écrit :Si archlinux abandonne ça, peut-être que je vais passer sous Slackware, voire sous BSD...

Il n'est pas question de l'abandonner (tout de suite... ), mais merci de ne pas dévier ce sujet vers systemd non plus. Si ça vous intéresse, lancez-en un autre. (ou par là, vu que ça parle du rc.conf new look: http://forums.archlinux.fr/topic11496.html )

farvardin a écrit : franchement, vous redémarrez souvent votre ordinateur ?
Je dois le redémarrer tous les 15-30 jours, sinon je le mets en hibernation.

Argument très pertinent
Je vais essayer de l'appliquer, perso (parce qu'il faut commencer par ses besoins), si je supprime ce qui est par défaut dans le rc.conf, il me reste ça: Et si je supprime ce que je ne renseigne qu'à l'installation: Donc, en suivant ton raisonnement, on enlève tout, on laisse DAEMONS, c'est largement suffisant.

farvardin a écrit : uniquement compatible Linux en plus, merci pour les autres OS

Pourquoi voudrais tu avoir le même init partout ? Rien n'empêche de le porter sur BSD, jusqu'à preuve du contraire, c'est libre ! Après, ça s'arrête où ? il faut gérer Haiku ? Sinon, je ne vois pas en quoi les initscripts sont compatibles bsd !

farvardin a écrit : L'avantage de l'init BSD, en plus, c'est qu'il est très facile de rajouter des scripts à lancer lors de l'init, pour démarrer certains programmes, services tiers etc.

Pourquoi tu n'irais pas d'abord voir de quoi ont l'air les fichiers de démarrage avant ?
Compare ceux de slim par exemple (ils sont tous deux dans le paquet slim)
De plus, si les choses s'unifient un minimum, on aura plus à bricoler pour démarrer tel service dont le fichier de démarrage n'est compatible qu'avec ubuntu ou qu'avec redhat etc.

farvardin a écrit : Sans compter la facilité d'utilisation de rc.conf

Enfin un argument valable, qui reste d'actualité avec systemd sous Arch de la même façon que SysV était modifié pour utiliser un rc.conf.

farvardin a écrit : Si archlinux abandonne ça, peut-être que je vais passer sous Slackware, voire sous BSD...

Ca va te faire bizarre pour les versions de soft (sans parler des deps etc. sous slackware)

tuxce a écrit :

farvardin a écrit :L'avantage de l'init BSD, en plus, c'est qu'il est très facile de rajouter des scripts à lancer lors de l'init, pour démarrer certains programmes, services tiers etc.

Pourquoi tu n'irais pas d'abord voir de quoi ont l'air les fichiers de démarrage avant ?
Compare ceux de slim par exemple (ils sont tous deux dans le paquet slim)

+1.
Je ne scripte pas mais les fichiers de service sont clairs.

Pour ma part et pour ce que ça vaut, je teste Arch avec systemd sur mon eeepc... et depuis hier soir, j'ai même dégagé initscripts. Plus de rc.conf donc.

Je peux comprendre qu'on pleure à la perte du rc.conf, qui regroupe toute la configuration, mais d'avoir des petits fichiers ne complexifie pas la chose (vu le contenu et l'usage: une fois fait on y touche plus de toutes manières).

Pour ce qui est de la gestion des services, je découvre, mais je trouve très sympa de ne plus avoir à passer par le rc.conf pour les rendre pérennes justement. Tu lances tes services, tu les établis éventuellement au démarrage (systemctl enable / l'équivalent de placer un service dans les DAEMONS donc), fini et ça roule au démarrage suivant. Ensuite tu as de quoi les suivre, les lister (faut que je vois pour les logs et l'archivage par contre si syslog et logrotate font toujours bien le boulot).
Seul bémol pour le moment: en full systemd, l'extinction a parfois des ratés (un truc avec slim apparemment ou avec xfce).

Pour l'utilisateur final, ça ne changera pas grand-chose. Pour l'administrateur, je comprend qu'il apprécie. Pour le côté KISS et le côté "rc.conf c'est Arch donc pas touche", à mon sens, c'est toujours KISS (pour moi Arch c'est pacman ^^). Et comme dit et redit, initscripts et systemd peuvent ou non cohabiter: on a toujours le choix (dans le temps, peut-être moins, ou ça obligera à trouver des solutions plus pertinentes, mais Arch veut un maximum de compatibilité avec les autres distributions aussi).

@FoolEcho mois aussi je viens de passer mon pc a systemd,j'utilise aussi xfce+slim et pour l'instant aucun problème à l'extinction.
je voulais savoir si je peux supprimer le rc.conf? comme je m'en sers pu,je l'ai renommé en .old et j'ai supprimé initscripts,et je pense que on peut supprimer l'inittab aussi?

@jc51: oui. Sans initscripts/initscripts-systemd, le rc.conf n'est plus lu (inittab est quant à lui ignoré de toutes manières). Ne pas oublier d'installer systemd-sysvcompat par contre (moi avoir lu trop vite et moi y en du forcer le démarrage sur ramfs parce que sans init dans le système, ça y en a marché nettement moins bien ).

oui j'ai installé systemd-sysvcompat j'ai déjà redémarré sans rc.conf et sans iniscripts tous fonctionne nickel,il y a rien de bien compliqué.

bonjour,

c'est pas l'arrivée de systemd en tant que remplacant de sysV qui me gene car il apporte des choses interessantes pour certains usages rapidité de demarrage, CGROUPS.
Ce qui me gene c'est que on regarde seulement le lancement de l'OS, mais au vu de ce que je comprends c'est qu'il va bien plus loin que cela.

Cet outil à tout faire, semble faire un pied de nez à la philosophie d’UNIX en combinant plusieurs fonctions en un seul programme.

source : http://linuxfr.org/news/%C3%A9volutions ... de-systemd

Le but avoué est de gérer tout ce qui se rapporte au démarrage, après, toute la problématique est ce qu'on entend par démarrage ...

Gérer les sockets peut paraître inutile, mais quand ça permet de mieux gérer les services sans avoir à reprendre les dépendances pour un redémarrage... De même pour le système de fichier, des cas comme attendre que la partition x dont on a pas besoin finisse d'être vérifiée avant de poursuivre le démarrage sont contournés par systemd...

Par contre, il y a certaines fonctionnalités liées à systemd mais qui ne font pas partie du PID 1. Par exemple, la gestion des seats / sessions utilisateurs (ça a pour but de pouvoir avoir plusieurs postes sur un ordi, par exemple, sur Fedora, on plug un dock Plugable, on a un gdm qui s'ouvre et la session démarrée depuis aura ses propres périphériques d'e/s).

nlu_ a écrit :source : http://linuxfr.org/news/%C3%A9volutions ... de-systemd

L'article est pas mal... Par contre, aucune contre-analyse.

et ça continue :
https://linuxfr.org/users/sygne/journau ... e-tournant

Que de mécontents face à ces merveilleuses évolutions technologiques !

Dans ces conditions, j'espère qu'il y aura un jour un fork d'Arch.

En test : http://www.salixos.org/wiki/index.php/Home

et c'est plutôt bien

farvardin a écrit :et ça continue :
https://linuxfr.org/users/sygne/journau ... e-tournant

Que de mécontents face à ces merveilleuses évolutions technologiques !

Dans ces conditions, j'espère qu'il y aura un jour un fork d'Arch.

beaucoup de bruit pour pas grand chose ,discourt habituel dans la communauté linux le changement c'est le mal.je comprend pas le problème avec ces quelque fichier en plus sur tous que c'est pas des fichiers que tu vas configurer tous les 4 matins.

farvardin a écrit :Que de mécontents face à ces merveilleuses évolutions technologiques !

De gens qui râlent sans tester pour la plupart.

farvardin a écrit :Dans ces conditions, j'espère qu'il y aura un jour un fork d'Arch.

C'est possible mais pour en faire quoi ? Un refuge pour grub legacy, rc.conf... kernel26 (et antérieur) ? hal ? Xorg < 1.8 ? (y faisaient moins de barouf les gens quand udev a pris le relai de hal, permettant à X de faire un meilleur boulot et à nous de n'avoir qu'à personnaliser la configuration au besoin, non ?)

Je tiens à rappeler que je suis toujours réservé vis-à-vis du changement: je ne suis pas un geek, je ne me rue pas sur le dernier truc qui brille, j'veux des trucs pas trop prises de tête à utiliser et configurer. J'aime bien grub legacy, et parce que je l'aime bien je pouvais très bien le conserver, mais je suis passé à syslinux (je voulais le tester depuis longtemps). Ce qui n'empêche que celui qui veut utiliser grub2 en semi-automatique ou en manuel le peut (je sais que j'ai souvent ralé après les fans de grub2... c'est juste que j'aime voir jusqu'où peut aller l'argumentation des gens )...

jc51 a écrit :je comprend pas le problème avec c'est quelque fichier en plus sur tous que c'est pas des fichiers que tu vas configurer tous les 4 matins.

+1.
Et puisqu'on vous dit que le rc.conf n'est pas mort. Et quand bien même, en quoi le garder ou utiliser des fichiers séparés changerait quelque chose: vous changez la locale du système tout le temps ou le nom de votre machine ? Quand bien même, si tu les utilises tout le temps, tu n'auras aucun mal à les retrouver (en plus, directement dans /etc... c'est pas comme s'ils se trouvaient tous à perpète-les-oies).

Vis-à-vis de systemd: en quoi ça tuerait une quelconque philosophie, unix, linux ou kiss ? Comme l'a dit tuxce, tout dépend de ce qu'on appelle démarrage. Un logiciel qui fait tout peut aussi bien être aussi simple que plusieurs avec des tâches séparées, ça n'est pas la question. Que tu lances via iniscripts un service ou que tu le lances par systemd, où est la différence pour toi qui gères ta machine ? C'est toujours toi qui a la main.
Perso, j'ai même flingué le rc.conf sur ma machine de test en full systemd (j'ai commencé à regarder ces histoires lorsque que kmod est arrivé et que udev s'est fondu dans systemd) et bien ça me botte d'avoir quelques fichiers statiques (hostname, locale, timezone, consoleconf...) auquel je ne toucherai plus de toutes manières et d'avoir les services lancés au démarrage parce que tu l'as gentiment demandé.
Et encore une fois, aucun problème à avoir initscripts *et* systemd, ou initscripts seul.
Quant à parler du truc le plus visible avec systemd, je rigole quand dans quelques mois, plein d'utilisateurs trouveront formidable la vitesse à laquelle le système démarre (perso, c'est la question des logs qui m'intéresse avec ou sans syslog + archivage).
Maintenant, je ne suis pas naïf, dans quelques temps sysv/init seront supplantés par systemd... et alors ?

C'est quand même un comble d'utiliser une rolling-release et de ne pas vouloir qu'elle s'adapte à l'évolution des logiciels et des machines.
Et en reprenant les principes d'Arch, tout ça reste simple et c'est toujours l'utilisateur qui a la main.

Maintenant on (en tous cas c'est mon cas, je le déplore) peut effectivement déplorer que certaines récentes orientations soient prises sans réel intérêt (en plus tout arrive en même temps: se rajoute la nouvelle iso qui change également l'installation, faute de bras):
-pourquoi inciter à passer de grub legacy à grub, il y a d'autres chargeurs d'amorce, donc certains dans [core] (au passage, très marrant d'ailleurs que lilo y soit sans mise à jour depuis 2011 ) ... quand bien même on voudrait changer (ceci étant, c'est vrai que grub2 supporte plus de choses, dans des cas particuliers c'est donc lui qu'il faut utiliser donc solution de facilité, c'est un peu dommage).
-pourquoi ce passage de /lib à /usr/lib ? En soi, ça ne change rien et n'apporte pas grand-chose... sauf pour ceux qui ne lisent pas ou mal les annonces.

Mais je comprends le sentiment des mécontents, on se croirait à l'Assemblée Nationale: c'est l'été, tout le monde est en vacances, faisons passer les trucs les moins populaires...

+1@FoolEcho c'est bizarres que ces histoires arrivent maintenant alors que tous ça est la suite logique de cette annonce qui date de 2 mois systemd-tools remplace udev.

Et même quelques mois avant encore, insidieusement, avec l'arrivée du locale.conf pouvant supplanter les réglages du rc.conf dans initscripts.

farvardin a écrit : Que de mécontents face à ces merveilleuses évolutions technologiques !

Comme d'habitude et avec énormément d'arguments !

farvardin a écrit :Dans ces conditions, j'espère qu'il y aura un jour un fork d'Arch.

Surement, tu y trouveras mate, hal, tde etc.
(Et pourtant il suffit juste d'arrêter de mettre à jour, ça serait bien plus simple )

@FoolEcho, j'essaie de comprendre ton sentiment sur grub, mais franchement, dis moi quelle est la différence entre ce grub.cfg et ce menu.lst
On peut discuter du choix de la majorité des tutos (dont le nôtre ) à mettre en avant l'utilisation de grub-mkconfig, mais grub n'a rien à voir là dedans.

Finalement, j'ai pas mal râlé et je me suis aussi inquiété quand j'ai appris la prochaine arrivée de SystemD. Mais d'après les retours favorables sur ce forum, je m'inquiète moins.
Et puis avec le paquet d'explications de Tuxce et FoolEcho, j'attends de voir comment cela va se mettre en place, avant de critiquer.
Et puis, je fais aussi confiance aux devs. Ils savent ce qu'ils font, et ils garderont certainement l'esprit KISS.

Voyant systemd arriver petit à petit, je n'étais pas particulièrement chaud non plus. Mais consulte les wikis, voire même teste en gardant initscripts à côté et tu verras que ça n'est pas la mort annoncée d'Arch (car oui, mesdames, messieurs qui utilisaient Arch, soyez rassurés vous êtes toujours sous Arch: systemd ne se lancera pas si vous n'en voulez pas et une fois lancée vous pouvez très bien revenir sur initscripts ou l'utiliser avec). Je ne vois pas ça incompatible du tout. En plus ça intègre des choses déjà présentes et utilisées: udev... et qui n'utilise pas dbus ?

L'article rapporté par nlu_ montre aussi comment ça marche. Maintenant, si les gens veulent vraiment critiquer, ils doivent tester le machin et indiquer les points qui ne vont pas (au-delà des questions de philosophie ou alors si c'est vraiment énorme, mais ça n'est pas aussi rigide que les gens le croient, heureusement ... la preuve: /lib ou /usr/lib ? ).