Crux est disponible dans sa version 3.1 depuis le 16 juillet dernier. Cette distribution, qui a été la principale source d'inspiration à la création d'Arch Linux, suit le principe KISS (keep it simple), dispose d'un système d'init à la BSD ainsi que d'un système de [ports]. C'est une distribution légère ciblant l'architecture x86-64 et des utilisateurs Linux avancés.
Crux, dont la première version date de décembre 2002, n'est basée sur aucune autre distribution et possède ses propres outils pour, par exemple, la gestion des paquets et ports.
Plus d'informations se trouvent dans la suite de la dépêche.
Sommaire
- Scripts d'initialisation
- Ports et paquets
- Description: Compression utility using the lzma algorithm, successor of lzma-utils
- URL: http://tukaani.org/xz/
- Maintainer: CRUX System Team, core-ports at crux dot nu
- Installation
- Changements dans la version 3.1
Scripts d'initialisation
Les utilisateurs de systèmes *BSD ne devraient pas être trop dépaysés par Crux. En effet, point de systemd ici mais un système d'init à la BSD.
Le système comporte plusieurs runlevels, tels que définis dans /etc/inittab:
- 0: halt
- 1: mode utilisateur unique
- 2: mode multi-utilisateur
- 3-5: non utilisés
- 6: reboot
Le script de démarrage système est défini dans /etc/rc alors que celui pour l'extinction se trouve dans /etc/rc.shutdown et l'initialisation des modules passe par /etc/rc.modules. Le script pour le mode utilisateur unique dans /etc/rc.single, pour le mode multi-utilisateur dans /etc/rc.multi.
La configuration de base du système se fait via /etc/rc.conf et les scripts des services, par exemple sshd, se trouve dans /etc/rc.d.
Ports et paquets
Le système de paquets utilise des simples tarballs tar.gz, sans métadonnées. Cependant, l'extension .pkg.tar.gz est utilisée afin de permettre de différencier un paquet d'un simple tarball. Les paquets peuvent également être compressés avec bzip2 ou encore xz et dans ce cas là, l'extension est changée en accord (.pkg.tar.bz2 et .pkg.tar.xz).
Les paquets s'installent et se mettent à jour via pkgadd(8), se désinstallent via pkgrm(8) et peuvent se créer via pkgmk(8) tandis que pkginfo(8) permet l'obtention d'informations sur les paquets.
Ce système de paquets simple ne supporte pas, par exemple, la résolution des dépendances. En revanche, un front-end, prt-get(8), est fourni avec le système et permet notamment la résolution des dépendances.
Crux comprend également un système de ports que l'on peut trouver dans /usr/ports. Un port comprend les fichiers Pkgfile, .md5sum et .footprint. Le Pkgfile est en réalité un script shell spécial qui permet la création d'un paquet, un peu à la manière d'un PKGBUILD chez Arch Linux. Un exemple valant mieux que mille mots:
```
Description: Compression utility using the lzma algorithm, successor of lzma-utils
URL: http://tukaani.org/xz/
Maintainer: CRUX System Team, core-ports at crux dot nu
name=xz
version=5.0.5
release=1
source=(http://tukaani.org/xz/$name-$version.tar.bz2)
build() {
cd $name-$version
./configure --prefix=/usr \
--mandir=/usr/man \
--disable-nls
make
make DESTDIR=$PKG install
ln -s liblzma.so.$version $PKG/usr/lib/liblzma.so.0
rm -r $PKG/usr/share
}
``Le fichier.md5sumsert donc à stocker la somme md5 du (des) tarball(s) nécessaire(s) à la création du paquet tandis que le fichier.footprint` contient la liste des fichiers et dossiers créés par le port. Évidemment, si des patches ou fichiers de configuration sont nécessaires, ils prendront également leur place dans le dossier du port en question.
Il faut noter que les paquets sont réduits au strict minimum. Ainsi, les fichiers de traduction ne sont pas installés, de même que les fichiers de documentation tels des README, fichiers *.info ou *.html, etc. Seules les pages de manuels sont conservées comme documentation.
L'arbre des ports se synchronise via l'utilitaire ports(8). Ainsi, une mise à jour de son système peut être réalisée simplement via un ports -u && prt-get sysup.
Le noyau Linux est une exception. En effet, il n'existe pas de port pour le noyau Linux. Les sources du noyau se trouvent par défaut dans /usr/src. Par exemple, la version 3.1 de Crux fournit les sources du noyau Linux 3.12 dans /usr/src/linux-3.12.24. L'installation du noyau passe donc par un procédé standard:
$ cd /usr/src/linux-3.12.24
$ make menuconfig
$ make all
$ make modules_install
$ cp arch/x86/boot/bzImage /boot/vmlinuz
$ cp System.map /boot
Pour une mise à jour du noyau, il suffit donc de télécharger les sources depuis kernel.org, de copier le fichier de configuration du noyau et de lancer un make oldconfig suivi d'un make all && make modules_install && make install.
Étant donné que le noyau n'est pas géré par pkgadd(8), il est tout à fait possible de télécharger et installer le noyau de son choix sans rendre la base de données des paquets inconsistante. Par ailleurs, cela n'affecte pas non plus les headers kernel qui se trouvent dans /usr/include/linux et /usr/include/asm étant donné que ceux-ci ne sont pas des liens symboliques vers les sources du kernel mais contiennent une copie des headers.
Installation
Concernant l'installation, point de GUI ou de superflu. Le média d'installation est une image ISO hybride pouvant autant être gravée sur un CD-ROM qu'utilisée pour créer une clé USB amorçable. Une fois démarré sur le média d'installation, l'utilisateur se trouve connecté en tant que root et peut donc procéder à l'installation du système.
Le partitionnement se fait généralement via fdisk(8) suivit d'un mkfs(8). Une fois cela fait, il faut monter la (ou les) partition(s) nouvellement créée(s), par exemple dans /mnt et lancer la commande setup. Cette dernière permet d'installer les paquets nécessaires au système, notamment les paquets de core. Une fois cela effectué, il faut créer un chroot pour finir la configuration de son système. Cela peut se faire de manière traditionnelle mais la commande setup-chroot permet d'automatiser le processus. Une fois dans le chroot, l'utilisateur doit donc définir un mot de passe pour le super-utilisateur, éditer /etc/fstab afin de configurer les systèmes de fichiers, éditer /etc/rc.conf pour configurer le système de base tel que la timezone, le layout du clavier ou encore le hostname et les services à lancer au démarrage. La configuration du réseau passe par l'édition des fichiers /etc/rc.d/net, /etc/hosts et /etc/resolv.conf.
Une fois ceci fait, il est nécessaire de configurer et installer son kernel, tels que décrit dans la section précédente. À noter qu'un fichier .config générique est fourni de base pour simplifier le processus.
Le gestionnaire de démarrage de base par défaut est lilo. Pour autant que l'utilisateur le choisisse, il doit passer par l'édition de /etc/lilo.conf afin de rendre son système démarrable.
Changements dans la version 3.1
La toolchain utilise glibc 2.19.0, gcc 4.8.3 et binutils 2.24.
Le kernel par défaut est le kernel à support à long terme 3.12.24. À noter que depuis la disponibilité de Crux 3.1, la version 3.12.25 est disponible et une mise-à-jour du noyau est donc conseillée.
À noter également que udev a disparu au profit de eudev.
Les détails peuvent se trouver dans les notes de mise à jour ainsi que dans le changelog.
Aller plus loin
- Homepage (692 clics)
- Handbook de la version 3.1 (66 clics)
- Notes de version (25 clics)
# Compilation du noyau sous root ?
Posté par gouttegd . Évalué à 5. Dernière modification le 25 juillet 2014 à 13:49.
Tout ceci est supposé être fait en tant que root ? Alors ce n’est pas le procédé standard. Il n’y a aucune raison de configurer et compiler le noyau sous l’identité du superutilisateur, et les développeurs du noyau le déconseillent formellement.
Extrait du README à la racine des sources du noyau :
Greg Kroah-Hartman en particulier insiste lourdement là-dessus, dans une page de « Linux Kernel in a Nutshell » que je me permets de citer largement (vu que la page en question est dans un PDF et que je ne peux donc pas y faire de lien direct) :
[^] # Re: Compilation du noyau sous root ?
Posté par Raoul Volfoni (site web personnel) . Évalué à -1.
Parce que le signe dollar apparait comme prompt ne signifie pas forcément que le compte est root même si c'est une vieille habitude.
Tu as tout à fait raison là-dessus.
Je suis taquin aujourd'hui, j'en fais un.
Tiens c'est drôle il y a le signe dollar partout. ;)
[^] # Re: Compilation du noyau sous root ?
Posté par Reihar . Évalué à 9.
Le dollar n'est pas censé signifier au contraire, que c'est un compte utilisateur et non un compte root?
[^] # Re: Compilation du noyau sous root ?
Posté par gouttegd . Évalué à 10.
D’une part, non justement, le signe $ signifie habituellement que c’est un compte utilisateur normal, c’est # qui dénote typiquement le superutilisateur. Mais ce n’est qu’une habitude.
D’autre part, le fait de procéder à la compilation directement dans le répertoire /usr/src/linux-3.12.24 suppose que l’utilisateur a le droit d’écrire dans cette arborescence, privilège normalement réservé au superutilisateur. Et comme il n’y a de plus aucun changement d’identité entre les commandes de configuration/compilation et les commandes d’installation, il est logique de conclure que c’est bien toute l’opération que l’on est supposé faire sous l’identité du superutilisateur, peu importe quel est le symbole du prompt.
Oui, le signe $ qui dénote typiquement un utilisateur non-privilégié.
[^] # Re: Compilation du noyau sous root ?
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
Houlala oui. Faut que j'aille me reposer moi !
[^] # Re: Compilation du noyau sous root ?
Posté par Rolinh (site web personnel) . Évalué à 3.
Un utilisateur responsable n'a pas de problème à faire un
chown -R george:users linux-3.12.24ou a télécharger les sources du noyau dans un endroit de son home et à ne passer en mode super utilisateur que pour la phase d'installation. Ce qui est "standard" ici c'est la procédure de configuration et compilation du noyau.[^] # Re: Compilation du noyau sous root ?
Posté par barmic . Évalué à 3.
Un utilisateur responsable ferra aussi un
chown -R george:users /boot?Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Quelques questions
Posté par jseb . Évalué à 5.
Ah très bien, je me posais justement quelques questions sur cette distrib !
Tout d'abord, a-t-elle une bonne base utilisateurs et possède t-elle les mainteneurs capables de la développer en autarcie, hors de l'écosystème-d ?
Je sais qu'elle existe depuis longtemps, mais ne va t-elle pas rencontrer de sérieuses difficultés quand udev sera devenu tellement indissociable de systemd que les alternatives comme mdev seront trop compliquées à maintenir ? Ce n'est pas un appel au troll, mais quand je vois les difficultés récentes de Gentoo avec eudev (http://lists.freedesktop.org/archives/systemd-devel/2014-May/019587.html), on peut se poser de sérieuses questions.
Le système de port: ça me fait penser à Gentoo (et à FreeBSD bien sûr, mais je n'ai utilisé réellement que Gentoo) que j'ai abandonné suite à deux changements dans le même mois de la libjpeg. À peine fini la recompilation de tous les paquets dépendants de la libjpeg, j'avais dû tout reprendre. Existe t-il un moyen documenté (ou mieux, un utilitaire) pour préparer ses paquets depuis une autre plateforme, avec la bonne libc, les bonnes options de compilo et les libs dynamiques correspondant à la plate-forme cible ? En gros, cross-compiler pour la crux sur mon netbook depuis mon serveur octo-core. J'aimerais éviter de me palucher la config de distcc et ccache, et je rêve d'un truc tout prêt. Je sais bien que ce n'est pas vraiment une question spécifique à Crux, mais vu que la distrib est très concernée par les compilations, il doit bien y avoir un truc tout prêt, non ?
La disponibilité des ports: j'ai vu qu'il n'y avait pas Blender, en allant voir ici: http://crux.nu/portdb/
Existe t-il d'autres emplacements bien achalandés en ports ? Sinon, peut-on adapter facilement un PKGBUILD de Arch (piqué dans l'AUR) ? À première vue, je dirais bien que oui, mais il peut y avoir des pièges.
La version 3.1 nécessite un passage par les binaires fournis. Autrement, «un cassage temporaire du système» (sic la doc) est à redouter avec des ports linkés sur des libs pas compatibles. Est-ce comme celà à chaque release de Crux ? Cela ne réduit-il pas quelque peu l'intéret du système de port ?
En me relisant, mes questions peuvent apparaitre critiques. J'ai essayé de nuancer, car cette distrib m'intéresse réellement, mais les interrogations demeurent :)
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Quelques questions
Posté par keyser.dyson . Évalué à -1.
Au niveau de Gentoo, si l'on compile sur une autre machine, on perd les quelques pourcentages d'optimisation lié à la compilation en local.
Est ce que je me trompe?
[^] # Re: Quelques questions
Posté par claudex . Évalué à 3.
Oui, on peut tout à fait compiler pour un autre processeur en mettant autre chose que
nativeà march« 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: Quelques questions
Posté par Rolinh (site web personnel) . Évalué à 4.
Cela, j'en doute. La communauté semble plutôt restreinte bien que pas non plus microscopique. Ceci dit, je pense que ce n'est pas la seule communauté qui a un intérêt hors de l'écosystème-d (je pense à Gentoo, Slackware, les distributions à destination de l'embarqué, etc.).
C'est une vrai question. L'avenir le dira. Pour l'instant, avec cette version, c'est eudev qui est utilisé.
Je ne crois pas qu'il y ait un truc "tout prêt". Après, il y a toujours moyen.
C'est un peu le point faible selon moi. Les ports sont très peu nombreux. D'un autre côté, il est extrêmement aisé de créer un port (c'est même encore plus simple qu'un PKGBUILD arch linux).
En dehors des ports officiels (core, opt, xorg et compat-32), il y a les ports semi-officiels de contrib (ports communautaires) ainsi que tous les ports mis à disposition par les utilisateurs.
Tout à fait. En général, passer d'un PKGBUILD à un Pkgfile consiste surtout à enlever le superflu du PKGBUILD. Ensuite, il y a aussi les principes de packaging propres à Crux qui veulent les "junks files" (selon la doc) ne doivent pas être inclus, etc.
Il faut en général passer par la case recompilation je pense en cas de certains changements.
Pardonne-moi de ne pas donner plus de détails mais j'ai écrit cette dépêche sur un coup de tête et n'ai en fait testé Crux que récemment. Je cherchais une distribution sans systemd à la philosophie assez proche des BSD et, étant utilisateur de longue date d'arch linux, cela m'a paru naturel de jeter un œil sur Crux.
[^] # Re: Quelques questions
Posté par xcomcmdr . Évalué à 0.
C'était quoi le problème avec système sous arch ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quelques questions
Posté par xcomcmdr . Évalué à 1.
s/système/systemd
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quelques questions
Posté par Rolinh (site web personnel) . Évalué à 3.
Je ne vais pas nourrir le troll :)
Je cherche simplement une distribution à la philosophie plus proche des BSD.
[^] # Re: Quelques questions
Posté par xcomcmdr . Évalué à -2.
Bah euh c'était une vraie question. :(
J'avais compris que c'était systemd qui t'avait poussé à changé de distrib', et j'étais curieux de savoir pourquoi.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quelques questions
Posté par Rolinh (site web personnel) . Évalué à 9.
Bon, alors je vais répondre franchement mais je vais tâcher de faire court ;)
Je trouve dommage que tout le paysage des distributions Linux se tourne vers systemd. Il reste peu, aujourd'hui, de distributions qui ne l'utilise pas (ou pour lesquels ce n'est pas prévu). On perd de la diversité et du choix. Dans les faits, cela devient pénible pour une distribution de faire sans systemd de nos jours. Et je ne vais pas revenir sur les problèmes que cela pose avec udev, etc.
Sinon, j'ai techniquement pas mal de reproches envers systemd. D'une part, il en fait beaucoup trop en tant que PID 1 (oui, je suis au courant pas tout n'est dans le PID 1, et heureusement d'ailleurs). Cela a plusieurs conséquences: une étant que, en étant complexe il y a plus de risques de plantages et en tant que PID 1 ça ne pardonne pas puisqu'il n'y a personne pour récupérer l'orphelin; une autre, le fait que certaines mises-à-jour de systemd demandent du coup un redémarrage.
Les logs binaires, je trouve ça vraiment stupide. Oui, je sais qu'aujourd'hui on peut encore envoyer vers syslog mais… pour combien de temps encore?
Sinon, il y a aussi tout le bloat: systemd incluant notamment, un serveur http, de quoi servir des codes QR, etc.
Je pense que systemd fait trop de choses. Niveau sécurité, je pense que systemd est également un problème. On a déjà vu passer quelques CVE concernant systemd mais à mon avis, cette tendance ne va aller qu'à la hausse puisque, vu son importance, il est une cible de choix.
Ceci dit, je ne pense pas que du mal de systemd. J'ai juste relevé les points que je trouve négatifs, puisque tu le demandais.
[^] # Re: Quelques questions
Posté par xcomcmdr . Évalué à -6. Dernière modification le 16 septembre 2024 à 20:28.
T'as eu la même réaction quand SysV s'est imposé ?
Peut-être que systemd s'impose car il est bien meilleur que SysV. Par exemple, plus besoin de maintenir des scripts : on prend l'unit file upstream et c'est plié.
De la diversité pour un système d'init. Comment dire… Tout ce que je demande à un système d'init (en gros), c'est que la machine boot sans problème. Au delà, qu'il soit SysV ou systemd importe peu.
Et puis là c'est pas de la diversité : c'est revenir sur SysV. Si au moins c'était un init nouveau, là il y aurait une vraie diversité.
Et que penses-tu de Mir alors ? Tu crois que c'est une chance d'avoir autre chose que Wayland pour le futur des serveurs d'affichage ? Deux APIs, deux serveurs d'affichages concurrents, deux fois plus de bugs potentiels : youpi… ;-)
Je pense qu'au contraire qu'avoir systemd partout permet :
- d'avoir une seule API pour l'init
- de même pour l'usage des cgroups par l'user-space
- d'éviter d'écrire 1000 fois a peu près le même script d'init pour le service X (1 fois par distribution. Et encore, 1000, c'est loin du compte du nombre de distribs).
Faut croire que c'est pas tellement le cas vu que Crux, Gentoo, Slackware, Ubuntu (jusqu'à la 14.04 au moins, qui a 5 ans de support), la dernière Debian stable (d'ailleurs systemd a été choisi pour d'autres raisons que sa "pénibilité" supposée : après tout les arguments autres que techniques n'avaient pas leur place dans la discussion) et d'autres font bien sans.
Bah systemd est très dépendant d'udev, et puis bon le seul "problème" c'est de pouvoir compiler udev sans systemd.
Les forks c'est bien, sauf quand on s'appelle eudev et qu'on a pas parlé à l'upstream avant de forker udev en "eudev". C'est sûr que si on coopère pas, rien ne changera.
systemd, ses outils (dont udev) sont développés ensemble, et sont sur un VCS commun à la BSD. Mais ça ne plaît pas à BSDiste. Et ça ne plaît pas aux linuxiens. Faut croire que le problème, c'est peut-être pas systemd…
Pour l'etc, je ne vois pas… (je suis pas devin ;-) )
Dommage que ce soit toujours les même arguments répétés 1000 fois et réfutés 1000 fois. :/
Honnêtement, pour la plupart de tes griefs, je me suis renseigné 30 secondes pour savoir que c'était faux…
"Mon" /sbin/init (systemd) ne fait guère de plus que SysV, il me semble (non seulement d'après la page de man, mais en lançant /sbin/init --help on voit qu'on a pas grand chose de compliqué :
Ou du moins, il n'y a rien de surprenant.
D'ailleurs, quand j'interagis (rarement, d'ailleurs) avec systemd, j'utilise en fait /usr/bin/systemctl
Euh, ce n'est pas mon impression. Extrait du man :
Et puis tant qu'on parle de fiabilité : quand je m'étais planté dans mon inittab, SysV empêchait le système de démarrer. C'était tellement mieux, SysV à ce niveau ?
J'ai jamais eu cette impression.
Quant à la sécurité de SysV : euh, quelle sécurité ? La sécurité d'avoir des scripts shells exécutés par root, sans usage des control groups qui plus est ?
Et puis bon, face à la complexité du kernel, de Firefox, ou de Xorg, systemd (le PID 1 pas si compliqué que ça en fait…) c'est rien du tout du tout du tout. Mais le kernel et Xorg ne sont pas des cibles de choix : après tout, ce n'est pas systemd. ;-)
Euh… lesquelles ?
J'ai jamais été obligé de redémarrer. Et pour profiter de la nouvelle version les mises à jours du kernel ou de Xorg nécessitent elles aussi un redémarrage : rien d'anormal là dedans (oui pour Xorg on peut "juste" redémarrer Xorg : mais c'est plus rapide pour moi de redémarrer tout court…).
Bah d'un point de vue sécurité, c'est les logs textuels le plus "stupide" :
- N'importe qui ayant accès aux logs peut les modifier et effacer ses traces (ce qui n'est pas le cas avec journald)
- on ne peut pas mettre un core dump ou un dump de firmware avec les logs. Oh, on peut mettre ça à côté, mais ce n'est pas dans le journal binaire, le même journal qu'on veut pouvoir être lisible avec journalctl sur un autre système et authentifier facilement.
- on a pas un standard de notation des dates/heures, ce qui est particulièrement énèrvant quand on a des tonnes de logs
- Perso, je trouve bien plus vite les erreurs avec journald qu'avec des fichiers textes (pas besoin de me souvenir comment fonctionne awk, sed, & co.). Au bout d'un moment, avoir une abstraction qui m'évite cette peine a du sens.
Je veux les logs produits par Firefox ? Aucun problème :
Je veux les logs du boot précédent ? OK :
Les exemples du manuel sont pas mal aussi.
Aux pros de awk/sed & co. : Bravo, mais il y a des gens qui sont de simples mortels. Désolé de vous décevoir.
Euh, tu nous fais du FUD maintenant ?
Personne ne peut répondre à ce genre de questions, à part les auteurs de systemd ! D'ailleurs, tu leur a posé la question ?
Et à part ça, t'es au courant que c'est un logiciel libre, tout de même ?
Surtout qu'il te donne plus d'informations dans ton syslog que ne le fait SysV (parce que journald démarre plus tôt que ne peut le faire syslog, et que journald enregistre la sortie standard et la sortie d'erreurs de tout service système) : rien n'est caché à syslog. En rien, on ne te force d'utiliser journald.
C'est optionnel à la compilation, et d'ailleurs sur Archlinux ce n'est même pas compilé.
Le support de la génération de codes QR par journald (et non systemd) c'est environ 116 lignes.
Y'a pas de quoi fouetter un chat, surtout quand on sait à quoi ça sert.
(en gros, c'est une option pour ne pas avoir à copier des clés de vérification que l'utilisateur pourrait trouver trop longues).
Quant au serveur http (cela semble être systemd-journald-gatewayd) embarqué :
- il est embarqué (ou pas, si on le compile pas) pour éviter une dépendance
- sa compilation n'est pas activé par défaut
- son code est réduit au minimum
- il permet d'envoyer le journal de journald à travers le réseau. Rien de révoltant là non plus (on faisait pareil avec SysV)
- même s'il est compilé, il faut l'activer pour l'utiliser ou le désactiver si on en veut pas, comme n'importe quel autre service.
Euh ouais… Tout comme le kernel monolithique linux, Xorg le très mauvais middle-man (c'est les devs Xorg qui le disent eux-mêmes !), ou Firefox si on en croit certains (c'est vrai que je largement mets moins de temps à compiler linux qu'à compiler Firefox), si on va par là…
Et c'est vrai que quand j'ai découvert (par exemple) que systemd s'occupait de l'ACPI, je me suis dit qu'il faisait trop de choses. Mais ça a du sens sur un système embarqué (c'est un marché ou systemd semble être utilisé)
Ou si on veut pas utiliser de bureau : j'imaginerais bien un système utilisateur léger avec un WM de son choix, et systemd pour l'ACPI (pas xfce4-power-manager ni rien de tout ça !). :)
Ce qui compte, c'est pas la tellement taille du code, c'est sa qualité. Sinon, on utiliserait tous nginx au lieu d'Apache (ben oui moins de code = plus de sécurité. Autant éteindre l'ordi et le débrancher : il y aura zéro code, donc un maximum de sécurité ;-) ).
En parlant de qualité, avec des suites de tests et une convention de style de code assez détaillée, c'est bien plus que pas mal de projets…
Et j'ai du mal à imaginer qu'il n'y ait jamais eu de CVE avec SysV. Ou Xorg. Ou Linux. Ou Firefox. Ou Apache… Ou nginx.
Et je t'en remercie.
Pour en rire : voici les six étapes de systemd (linux conf.au 2014). ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quelques questions
Posté par Moonz . Évalué à 6.
SysV a longtemps été certes dominant mais jamais en situation de monopole. Cf init-ng et mudur par exemple (pour ceux que j’utilisais avant la systemd-mania).
C’est très très réducteur comme vue. Et tu n’y crois pas d’ailleurs toi-même :
De fait si tout ce qu’on demandait à un système d’init « c’est que la machine boot sans problèmes » pourquoi s’embêter à remplacer sysvinit ? Aux dernières nouvelles les machines bootaient sans problèmes avec sysvinint hein…
systemd changera rien à l’affaire tant que la moitié des distribs nommeront apache apache2, l’autre moitié httpd, et quelques autres apache ou httpd2
Et dans l’hypothèse où les distribs arrivent à se mettre d’accord pour ce genre de choses les scripts sysv sont tout aussi portables
Ça c’est pas des arguments logs textuels vs logs binaires mais format standardisé vs sans format
# Mise en page
Posté par Rolinh (site web personnel) . Évalué à 6.
Lors de la modération, la mise en page a été cassée. Il manque un backtick et un saut de ligne à la fin de l'exemple de Pkgfile.
# Kis vs Kiss
Posté par Denis Dordoigne . Évalué à 2.
Il s'agit d'une distribution simple pour les geeks qui connaissent déjà bien linux ou ont eu la bonne idée de monter une LFS. Mais je ne vois nulle part une volonté KISS de ne pas rendre les choses plus compliquées que nécessaire, le dernier S de KISS signifie Stupid, pas Superuser.
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: Kis vs Kiss
Posté par Rolinh (site web personnel) . Évalué à 9.
Le dernier S signifie bien stupide mais c'est du système qu'il s'agit, pas de l'utilisateur. Par conséquence, un système stupide a besoin d'un utilisateur moins stupide afin de marcher correctement.
# Chtite question aux spécialistes de Crux
Posté par microlinux (site web personnel) . Évalué à 1.
Est-ce que Crux utilise Linux-PAM ? C'est malheureusement le seul truc qui manque vraiment à Slackware, et qui fait qu'on est obligé de sauter à travers des cerceaux en feu pour configurer une authentification centralisée avec LDAP.
Dyslexics have more fnu.
[^] # Re: Chtite question aux spécialistes de Crux
Posté par Rolinh (site web personnel) . Évalué à 3.
Pas par défaut en tout cas. En revanche, il y a un port
linux-pamainsi quepam_ldapdans contrib ainsi queopenldapdans opt. J'imagine que c'est donc possible de mettre ça en place. Le mieux reste encore de demander sur leur channel irc (#crux sur Freenode).Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.