Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Mon expérience ArchLinux, Faites partager la votre :)

Pylades

N’empêche que c’est insupportable alors qu’un simple fichier suffirait. Ça rend impossible d’emporter une conf. Et puis aussi, ça me pourrit ma console.

The Uploader

Bof.

Pylade a écrit Et puis aussi, ça me pourrit ma console.

Mais de quoi tu parles ?

shoot76

De retour après une longue absence, content de voir que ce topic est toujours viable et que les retours se multiplient !

Depuis le temps, je suis passé sous Openbox, une fois maitrisé, ça devient plus que jouissif. Je recommande l'utilisation de "terminator" la multiplication des consoles en écran scindé est un pur régal !

En tout cas continuez, j'essaierai bientôt si possible de faire d'autres retours !

See you soon guys

Pylades

Notamment que ça n’accepte de m’afficher ma belle fonte Terminus à la place du défaut moche que si j’active l’early KMS, ce dont je n’ai aucune envie.

Sinon, la dernière mise à jour m’a installé plein de merdes : js pour polkit, harfbuzz pour pango, at-spi2-atk, at-spi2-core et dconf pour gtk3, iptables pour iproute2 et gstreamer et gst-plugins-base-libs pour webkitgtk2.
Mais pourquoi tous ces trucs inutiles, d’un coup (surtout cette merde de dconf) ? :mad:

[supprimé]

Si ça ne te convient pas, tu peux récupèrer les PKGBUILDs correspondants et les modifier à ta guise, hein.
Sinon pour terminator, je ne suis pas fan (rien ne vaut tiling + urvxt, dwtm ou encore tmux).
EDIT: Pour iptables, c'est normal: http://www.spinics.net/lists/netdev/msg212312.html

Rolinh

Bah moi je rejoins Pylade. Sans vouloir troller, depuis que je suis passé full systemd j'ai gagné:
- 5 secondes au démarrage (10 au lieu de 15...)
- un systemctl qui n'a de loin pas l'élégance du feu rc.d pour ce qui est de start/restart/stop les daemon (oh, pardon, les services)
- ?

Et j'ai surtout perdu:
- une config centralisée dans le rc.conf
- des logs sous forme de simple fichier texte
- la ligne des daemons dans le rc.conf
- ...

Il faut certainement que j'y mette un peu du mien mais franchement... je ne peux pas dire que ça soit positif hein.

[supprimé]

Pour les logs texte, tu peux installer syslog 🙂

Rolinh

Ouep, ça sera déjà ça. Merci. 🙂

The Uploader

- journald se connecte de manière bidirectionnelle à syslog-ng. D'ailleurs chez moi il se plaint au démarrage s'il n'est pas présent (c'est peut-être ma config mais j'ai rien fait de spécial pour ça).

Rolinh a écrit- un systemctl qui n'a de loin pas l'élégance du feu rc.d pour ce qui est de start/restart/stop les daemon (oh, pardon, les services)

Bof, quand t'as vu l' "élégance" du code des scripts qui étaient dans rc.d, pas étonnant que les mainteneurs d'Arch sont contents de s'en débarrasser.
Et puis c'est tout aussi facile avec systemctl.

Rolinh a écritEt j'ai surtout perdu:
- une config centralisée dans le rc.conf

C'était propre à Arch, un bidule à maintenir qui n'était pas upstream (donc pas KISS). Les fichiers de configuration qui le remplacent se retrouvent sur les autres distribs. (<- plus toutes les autres raisons pour lesquels Arch est passée à systemd)

Rolinh a écrit- la ligne des daemons dans le rc.conf

'systemctl' : regarde ceux qui sont 'enabled'. (on peut aussi lister uniquement ceux-là)

Pylades

The Uploader a écrit
Rolinh a écrit- la ligne des daemons dans le rc.conf
'systemctl' : regarde ceux qui sont 'enabled'. (on peut aussi lister uniquement ceux-là)

Ça, on s’en fout. On veut un fichier de configuration, pas des liens symboliques. Ce n’aurait pas été compliqué à faire :

[multiuser]
network=enabled
cronie=enabled
crap=disabled
atd=enabled
ntp=enabled
gpm=enabled

[graphical]
slim=enabled

Et voilà, on a un truc simple, propre, KISS ; et en plus on se débarrasse du /etc/inittab tout moche. Mais non, il a fallu suivre l’affreux style des liens symboliques à la Debian. C’est très dommage.

Sinon, le coup de iptables, je veux bien comprendre, mais dconf, ça me fait mal, quand même…

grim7reaper

Si les choix d’Arch’ vous rebutent tant, vous pouvez toujours passez à autre choses hein (genre Slackwae, Gentoo, que-sais-je).
Y’a pas que Arch’ dans la vie 😉

Keiser

Πυλάδης a écrit
The Uploader a écrit
Rolinh a écrit- la ligne des daemons dans le rc.conf
'systemctl' : regarde ceux qui sont 'enabled'. (on peut aussi lister uniquement ceux-là)
Ça, on s’en fout. On veut un fichier de configuration, pas des liens symboliques. Ce n’aurait pas été compliqué à faire :
[multiuser]
network=enabled
cronie=enabled
crap=disabled
atd=enabled
ntp=enabled
gpm=enabled

[graphical]
slim=enabled
Et voilà, on a un truc simple, propre, KISS ; et en plus on se débarrasse du /etc/inittab tout moche. Mais non, il a fallu suivre l’affreux style des liens symboliques à la Debian. C’est très dommage.

Sinon, le coup de iptables, je veux bien comprendre, mais dconf, ça me fait mal, quand même…

C'est qui ce "on" qui veut ce fichier de configuration ?

Pylades

@ grim7reaper : mais, le truc c’est que ce ne sont pas les choix d’Arch, qui me rebutent. 😛

@ Keiser : des gens, dont au moins moi.

The Uploader

Πυλάδης a écrit Ça, on s’en fout. On veut un fichier de configuration, pas des liens symboliques.

Écoute, j'propose une solution qui fonctionne très bien. Un "ça on s'en fout, on veut comme c'était avant", on dirait un gamin qui fait un caprice. :rolleyes:

Ce genre de réponse, ça donne vraiment envie d'aider...

Pylade a écrit Ce n’aurait pas été compliqué à faire :

[multiuser]
network=enabled
cronie=enabled
crap=disabled
atd=enabled
ntp=enabled
gpm=enabled

[graphical]
slim=enabled

Prouve-le alors. Code-le dans systemd. Propose des patchs...

Pylade a écritEt voilà, on a un truc simple, propre, KISS ; et en plus on se débarrasse du /etc/inittab tout moche. Mais non, il a fallu suivre l’affreux style des liens symboliques à la Debian. C’est très dommage.

Je ne vois pas en quoi les liens symboliques sont forcément affreux. C'est purement subjectif.

rc.conf ; truc propre à Arch, interface à maintenir entre rc.conf et les fichiers qui vont bien upstream.
systemd : il est comme il est upstream.

Donc tu as gagné au KISS, mais tu as perdu de la "facilité d'utilisation" à la Ubuntu.

Deal with it.

Pylades

The Uploader a écritProuve-le alors. Code-le dans systemd. Propose des patchs...

Oo’

En quoi c’est plus compliqué de faire un simple fichier de conf plutôt que des liens symboliques ? J’vais pas me palucher le code de systemd juste pour faire un patch qui ne sera jamais accepté, mais quand même…

Et non, ce n’est pas KISS. Mettre des liens symboliques, c’est au contraire une logique à la Debian/Ubuntu, plus facile d’utilisation mais pas KISS.

The Uploader

Si, le KISS, c'est ne pas rajouter de couches par rapport à l'upstream. Le rc.conf en était une. C'est plus propre, plus proche de l'upstream, ça enlève du code boilerplate, ça rend Arch plus KISS.

Tu confonds le KISS du design de la distrib', avec la facilité d'utilisation.

Pylades

Mais je ne parle pas d’Arch, là, mais de systemd.

The Uploader

Ce n'est même pas toi qui gère directement les liens symboliques ou leur suppression... C'est vraiment se plaindre parce que c'était mieux avant.

Ce n'est ni plus ni moins compliqué qu'avant. C'est même plus rapide (un coup de systemctl plutôt que d'aller éditer un fichier...)

Rolinh

The Uploader a écrit(...) C'était propre à Arch, un bidule à maintenir qui n'était pas upstream (donc pas KISS)

Gné?
Ça rendait Arch plus proche d'un BSD et le système d'init d'Arch était une de ses grandes force à mon sens (à côté de l'Arch Build System).

@Grim: j'ai songé à passer sous Gentoo (et j'ai considéré Slack aussi) mais bon, la flemme/pas le temps/pas maintenant. 😛 Et puis j'aime bien me faire mon propre avis sur les choses donc tester un peu systemd sous Arch est intéressant aussi.

The Uploader

Rolinh a écrit
The Uploader a écrit(...) C'était propre à Arch, un bidule à maintenir qui n'était pas upstream (donc pas KISS)
Gné?
Ça rendait Arch plus proche d'un BSD et le système d'init d'Arch était une de ses grandes force à mon sens (à côté de l'Arch Build System).

Allan McRae a écritControversy #2 – The demise of /etc/rc.conf
While the single rc.conf is highlighted as major feature of Arch Linux, reading the reviews makes you notice that configuration of an Arch install was never down to a single file. Other files mentioned included…

/etc/conf.d/wireless
/etc/fstab
/etc/group
/etc/grub.conf
/etc/hosts
/etc/inittab
/etc/lilo.conf
/etc/locale.gen
/etc/mkinitrd.conf
/etc/modules.conf
/etc/modprobe.conf
/etc/rc.local
/etc/resolv.conf
/etc/pacman.conf
/etc/X11/XF86config
~/.xinitrc

And that is just the configuration files mentioned in what were quite superficial reviews of Arch Linux. So a single configuration file was really just a myth.

But lets take a step back here… How about some quotes from Judd, the founder of Arch Linux:

“In Arch “simple” is different what other distros are considering. The learning is more important than getting something easily done.”

“Relying on GUIs to build/use your system is just going to hurt a user in the end. At some point in time a user will need to know all that some GUIs hide.”

What does a single configuration file get us? Is it “simple” in terms of the definition above? Not really… It requires that we write our own tools to deal with it and convert these into the appropriate commands during boot-up. For example, instead of configuring modules in /etc/rc.conf, we should directly use the configuration files that the module loading software reads. How is putting the settings in rc.conf and having software interpret them any different than using a GUI to do the same thing? It does not give us any actual understanding of the system. Also using the same configuration files as other distributions do (and this is becoming more standardized) means the learning done in Arch Linux will apply to many other distributions.

Article complet : Are We Removing What Defines Arch Linux?

« Page précédente Page suivante »