Le module LVM dans GRUB permet à Grub de retrouver ses fichiers de démarrage quand ton /boot est sur LVM. Mais en aucun cas il ne va initialiser ton LVM. Du coup, si tu veux accéder à tes autres fichiers sur LVM, il faut l'initialiser autrement.
Le module LVM de grub lui permet d'aller trouver ton noyau et donc forcément un fichier initramfs posés sur une partition elle-même sur du LVM. L'initramfs va permettre d'initialiser le LVM et les périphériques associés, qu'ensuite le noyau pourra accéder pour lancer l'init qui sera réellement utilisé par le système.
Donc effectivement, ce que tu veux faire n'est pas possible et le kernel panic correspondant n'est pas étonnant.
Linus accepte les patches qui ont pour objectifs de permettre la compilation avec un autre compilateur que gcc (clang en tête). Il n'accepte pas n'importe quel patch, mais il ne refuse pas une contribution sous-prétexte que la portabilité sur d'autres environnements l'ennui.
Quel est l’intérêt de cette remarque qui n’a rien à voir avec le sujet ?
Déjà, il me semble que le noyau Linux n'est porté que sur le noyau Linux !
Linus n’accepte pas les patches qui selon lui n’ont rien à faire dans le noyau (d’où les difficultés de kdbus par exemple), systemd n’accepte pas les patches qui n’ont rien à faire dans systemd : c’est pareil.
Et la preuve est que ces fonctionnalités (des API pour des appels système sous Linux) sont présentes dans la glibc (qui pourtant filtre ce qui est disponible sur un unique noyau), et qu’elles fonctionnent très bien et sont maintenues.
Pour information, ce n’est pas la première fois qu’un développeur demande à systemd d’implémenter des fonctions de la glibc parce que la libc qu’il utilise ne veut pas le faire.
Multiplier les implémentations d’API dans de multiples projets est très mauvais, c’est une très bonne raison de ne pas réimplémenter la roue dans systemd.
Bien sûr, ça va à l’encontre de l’histoire comme quoi systemd veut tout réimplémenter (glibc, GNU par exemple) au sein de son code, mais les incohérences n’arrêtent pas les trolls.
systemd est spécifique GNU/Linux, c’était clair dès le début.
Certains n’ont pas voulu l’entendre de cette oreille et ont décidé que c’était possible et pas un énorme boulot de gérer la compatibilité avec d’autres OS, pour décrédibiliser les développeurs systemd.
Seulement, arrivé dans la réalité, tous ces beaux parleurs jettent l’éponge les uns après les autres devant l’ampleur de la tâche, comme uselessd, prouvant par là même la compétence des dévs systemd et leur propre irresponsable incompétence.
1°/ Musl-libc n'a pas vocation à reproduire tout le bloat et extensions "propriétaires" de la glibc.
Systemd encore moins, c'est même la raison pour laquelle il utilise la Glibc au lieu de s'en recréer une.
2°/ Ton approche signifie que musl doit reproduire 100% des extensions propriétaires de la glibc, alors que peut-être 20% sont utilisées (et nécessiteraient d'être backportées) dans systemd
Non, mon approche signifie qu'il ne faut taper ni sur musl ni sur glibc, mais implémenter soi-même les fonctionnalités manquantes dans un fork de systemd. Ce qui revient au même puisque ceux-là même qui veulent mettre le patch upstream vont le maintenir. En fait, c'est même exactement de cette façon que c'est fait pour nombre de patchs du noyau Linux non acceptés upstream : ils sont maintenus dans une branche séparée, merci git.
Un systemd-musl n'est pas accepté upstream, mais rien n'empêche aux mainteneurs de proposer leur fork/branche.
3°/ Personne ne demande à Lennard de coder lui-même lesdites fonctionnalités, juste de ne pas bloquer les contributions de ceux qui souhaitent que ça marche ailleurs que sur Linux/Redhat/glibc/sa_machine. Si Linus avait eu le même comportement, je ne suis pas sûr que Linux marcherait sur ARM/MIPS/Alpha/…/Amiga/… (et pourtant, le support de ARM était un joyeux bazar avant l'avènement du DT)
Factuellement faux puisque le noyau et Linus fonctionnent exactement de la même façon.
Et il a parfaitement raison de refuser ces patchs.
Ce qui est demandé par ces distributions n'a aucun sens, et c'est évident à n'importe qui comprenant de quoi il s'agit.
Accepter des patches de ce genre, cela signifie tout simplement d'accepter de maintenir une sorte de fork de glibc dans systemd. Parce que ces patches consistent à maintenir des fonctionnalités manquantes de musl-libc (par exemple) par rapport à glibc, dans systemd.
systemd n'a pas la vocation d'être une libc, c'est à musl-libc qu'il faut envoyer ces patches évidemment. Et bien sûr cela a été fait, mais qu'ont répondu ces différents libc ? Elles ont refusé !
Et évidemment, on essaie de porter le blâme sur systemd.
Pour le système de logs de systemd dans BusyBox, cela n'avait de toutes façons aucun sens, systemd venant avec son système de logs. En fait cela ne change rien en pratique.
Et je pense vraiment qu'en ayant fait LFS, en ayant réfléchi pour se faire une gestion de paquets, on respecte et mesure à sa juste valeur le travail qui est fait dans les différentes distributions (enfin les vrais distributions…;o) ).
Ça, c’est bien vrai. Ça permet par exemple de comprendre aisément des choix comme ceux de passer à systemd. Pour avoir connu et appliqué LFS depuis plus de 15 ans, et avoir géré des Linux depuis, je comprends aisément les déboires des mainteneurs de distributions.
Je me rappelle à l’époque, quelqu’un m’avait demandé naïvement pourquoi je ne faisais pas une distribution avec tout ce que je savais. Si on ne l’a jamais fait, on ne peut pas s’en rendre compte. Gérer son propre OS dérivé de LFS c’est facile, et on a facilement mieux que n’importe quelle distribution. Mais gérer son OS sur les machines des autres avec leurs exigences et leurs configurations alors qu’ils ne maîtrisent rien, c’est une autre paire de manches et je trouve ce travail ingrat, donc jamais je ne ferai de distribution.
Certes LFS permet de comprendre l'assemblage, mais il permet aussi de comprendre ce qu'il faut faire pour faire une distribution. LFS permet aussi de voir les fonctions de chaque paquet, et comme il faut compiler chaque paquet, il y a souvent je pense chez les utilisateurs de LFS, la volonté de faire un système léger. Pourquoi ajouter le paquet trucmuche qui n'apporte rien…. ou pourquoi activer telle dépendance pour un paquet alors que la fonctionnalité apportée ne me sert à rien.
Au final, le résultat est léger et les performances en temps de démarrage, en capacité mémoire utilisée ou en espace disque n'ont rien à envier aux "vraies" distributions.
Il y a cela, le fait que ce que l’on obtient est toujours mieux que n’importe quelle distribution : par exemple, je suis en LVM sur RAID depuis le début, à une époque où l’option était soit inexistante sur les distributions, soit expérimentale.
Il y a aussi le fait que dès que l’on veut sortir des clous avec une distribution (application non supportée, nouvelle version majeure…) et installer des choses hors paquets officiels, le système devient vite instable, où alors il faut se lancer dans la création de paquets, ce qui est contraignant pour rien au mieux (paquet officiel qui sort plus tard) ou est contraignant pour rien (paquet à maintenir continuellement). J’avais testé avec toutes les distributions, jusqu’à Gentoo. Même avec Gentoo c’était ingérable, et recompiler des tonnes de trucs pour rien, j’en ai eu assez.
La comparaison avec gentoo est souvent faite à tord selon moi, car l’approche n'est pas du tout la même. Gentoo met à disposition des outils puissants pour maintenir sa distro à jour. Ça cache toute une partie du travail au yeux de l'utilisateur final. LFS permet de ne rien cacher et est ainsi un formidable outil pour apprendre. Par ailleurs, cela permet de créer facilement son propre gestionnaire de paquet. (ce qui est assez unique pour une distro)
Je suis d’accord, la comparaison avec Gentoo est vraiment faite à tort. Déjà tout simplement parce que LFS n’est pas vraiment une distribution.
Ce qui en découle, c’est qu’un gestionnaire de paquet est parfaitement inutile dès lors que l’on ne souhaite pas faire du pré mâché pour les autres, principe aussi connu sous le nom de distribution.
Puisqu’en fait on acquiert l’expertise pour faire les dépendances dans sa tête, ou dans des outils automatisés (scripts ou autres).
LFS est simple à maintenir avec les trois points que j’ai cités.
Évidemment, je ne parlais pas de BLFS et autres, où là c’est une autre paire de manches.
Et LFS ne fait pas tout ce qu’il faut pour amorcer un système, il ne gère pas le LVM, il ne gère pas les initramfs, ou la construction de LiveCD.
Cela s’est beaucoup amélioré au cours du temps (dracut est vraiment excellent maintenant), mais il faut encore gérer les adhérences entre le noyau Linux et des outils comme Syslinux dont la documentation est fausse et trompeuse car non maintenue, ou Busybox dont les outils minimalistes ne fonctionnent plus avec de nouvelles fonctions du noyau au fil du temps.
Il faut gérer aussi l’UEFI. Ce sont toutes ces nouveautés qui prennent du temps.
Une fois que l’on a compris comment cela fonctionne, si l’on veut tout automatiser avec ses propres options et préférences, il n’y a aucun outil disponible à part nALFS.
Mais LFS reste très instructif, et même s’il n’est plus mis à jour, il sera toujours aussi instructif.
Dommage, jhalfs c'est du Shell, donc totalement inapproprié et peu praticable par rapport à nALFS.
Tant pis, mon système fonctionne bien de toutes façons.
J'aurai voulu intégrer le cloisonnement kernel via systemd au lieu du chroot de nALFS, qui cause des problèmes, mais bon tant pis.
Une question que je me pose : est-ce que sortir de nouvelles versions de LFS est d'une complexité > constante ? Ou est-ce qu'il y a des obstacles de plus en plus difficiles à surmonter ?
Non, les difficultés sont toujours les mêmes :
— Changements d’ABI ou d’API à prendre en compte, surtout au niveau des éléments essentiels du système (la plomberie) par exemple la glibc ;
— Suivre les évolutions de la plomberie, mais pas trop vite, et créer les correctifs adéquats ou les récupérer ;
— Conserver la motivation, de bons outils aident beaucoup ;
à ce propos, j’utilise toujours nALFS que j’ai modifié pour supporter différentes choses (par exemple les tarballs xz ou activer la redirection pour cURL) et porg pour gérer mes systèmes et automatiser le tout.
Quelqu’un a-t-il des informations sur un groupe qui aurait repris nALFS ?
Sinon, ça fait 15 ans que je roule avec nALFS et tous mes systèmes fonctionnent parfaitement, sachant qu’il gère un équivalent de LFS systemd + BLFS + ALFS + CLFS (ARM + x86 + x86_64) + LiveCD. Le CLFS est abandonné, mais je gère toujours les 3 architectures avec le même nALFS.
Mais comme auparavant avec simpleinit-msb, si je peux m’abstenir de maintenir une application c’est toujours mieux.
Ha ! 99 % du temps pour du matos pas-si-vieux j'ai un matériel dont le pilote n'est pas disponible sous Windows (genre, le driver n'existe qu'en version pour Windows 32 bits uniquement, ce qui te bloque à Windows 7 32 bits pour pouvoir l'utiliser), mais qui fonctionne très bien sous Linux sans rien faire.
Tiens, c'est exactement mon cas, j'ai remonté un client Windows l'année dernière avec un vieux serveur dont je ne me servais plus depuis des années, qui comprenait une carte SCSI avec des disques SCSI. Ca a été une galère sans nom pour trouver un pilote qui fonctionne, et au final j'ai dû installer Windows 7 32 bits sur le disque IDE, puis basculer le système sur le disque SCSI.
J'ai eu d'autres misères mais rien que celle-là m'a coûté des jours de travail ingrat.
Ca m'a fait un choc de découvrir à quel point Windows était archaïque, plus encore que ce que j'imaginais : la version 32 bits ne supporte même pas 4 Go de RAM et trouve le moyen de ramer.
Le pilote graphique NVidia à jour plante régulièrement en regardant des vidéos Youtube ou autre !
Il existe deux grandes raisons objectives pour utiliser un logiciel proprio dans une distro libre: 1) il n'existe pas d'équivalent libre de qualité comparable (typiquement : drivers), ou 2) les équivalents libres ne sont pas compatibles avec le propriétaire, qui bénéficie d'un effet "réseau" (typiquement: Skype). Dans les deux cas, l'utilisation d'une brique proprio est le seul compromis raisonnable pour pouivoir encore utiliser un système à 99% libre.
Qu'est-ce qu'il ne faut pas lire, c'est le comportement gravissime dont parlait un posteur ci-dessus.
Le compromis dont tu parles n'a absolument rien de raisonnable, c'est juste le plus facile, certainement pas le plus raisonnable. Je ne vois pas ce qu'il y a de raisonnable à abandonner sa liberté à la moindre contrainte, surtout quand on sait que la liberté est qqch qui n'est pas facile à obtenir ou à maintenir, c'est un combat de chaque instant.
Et là, je lis qu'abandonner au premier coup reçu est raisonnable, c'est vraiment ridicule.
Le Logiciel Libre a été la réponse raisonnable à précisément ce genre de problématique, mais c'est long et difficile. Le chemin parcouru en 25 ans et plus me paraît juste incroyable.
Je n'ai rien contre lâchement accepter le compromis, je le fais aussi, en revanche je ne cautionne pas ceux qui, sachant qu'ils ont lâchement abandonné, se donnent bonne conscience en se disant que c'était ce qu'il y avait de mieux à faire, c'était le plus raisonnable, alors qu'ils sont sur un système qui prouve le contraire. Mais bon c'est humain…
Ou comment parler de théorie sans jamais avoir fait l'expérience de la réalité…
En fait ton post est un bon exemple de cette phrase, et tu parles manifestement d'un sujet que tu ne maîtrises pas du tout.
Allez, petit exemple pratique…
La société X sort le 8 aout 2015 un nouveau matériel, ou un soft, qui a besoin d'un module kernel (bref, un driver).
Elle fait comment pour que son matériel/soft tourne sur les Linux existants chez les utilisateurs qui sont du Ubuntu 12.04, 14.04, Redhat 6, OpenSuse 11, Debian x/y, etc… ? Ah oui tiens, c'est 3252 versions différentes de kernel, avec l'ABI qui casse quasiment à chaque update, qui sortent à des périodes différentes, à des fréquences différentes, avec des règles différentes pour l'inclusion de modules dans les dépots, etc…
Elle ne développe pas son module le jour de la sortie, et il lui suffit de fournir le module en question via le moyen qu'elle veut : Web, paquet de la distribution, … C'est justement ce que font tous les constructeurs qui supportent Linux. Et l'ABI du noyau Linux ne casse pas à chaque update. Il faut éviter d'asséner des choses lorsque l'on ne maîtrise pas du tout le sujet.
Ton exemple n'a rien de sorcier et est déjà géré.
Le seul moment où cela pose problème, c'est lorsque le constructeur n'a développé aucun pilote libre.
Tout ca pour supporter 1% du marché desktop.
La donne change quand ces 1% de desktop correspondent à 90+ % de desktop utilisés dans un domaine à forte valeur ajoutée auquel ce constructeur vend 99% de son matériel.
Sous Windows ? Ils peuvent dans la plupart des cas faire un driver qui tournera sur toutes les versions depuis Vista. Ca couvre 90% du marché desktop.
90 % du desktop, dont au mieux le marché du constructeur n'est qu'un sous-ensemble, au final pas forcément plus grand que le 1 % de desktop ci-dessus.
Ca, c'est la réalite.
Non, c'est un exemple qui contredit la réalité, associé à des chiffres sans aucun rapport, plus élevés du côté qui te plaît pour appuyer ton argument par un sophisme de juxtaposition.
Bref, ce que tu dis ne sert à rien, en plus d'être basé sur de l'ignorance.
L'inclure dans le kernel mainline ne résoud absolument rien du tout.
Et finir par une contre-vérité, ça résume bien le ridicule du post.
« The domain devuan.com may be for sale. Click here for details. ». C’est une blague, hein…
Non ce n'en est pas une, mais ça rentre exactement dans les prédictions de pas mal de "pro-systemd" comme moi. Il n'y a aucun argument technique valable derrière ce fork, à se demander si toute cette mascarade n'a pas été financée par des concurrents, ce serait de bonne guerre. Le contenu de la liste de diffusion est risible également.
En revanche, les personnes derrière tout cela ont quand même fait un peu de mal à Debian.
L'idée que j'ai en tête, c'est l'utilisation d'une distribution "généraliste" dans une carte style raspberry pi, pour lequel par exemple les versions les plus récentes du noyau ne seraient pas supporté (car nécessité de le patcher mais patch pas dispo pour le noyau courant de la distribution), ou sur laquelle on voudrait faire tourner un linux allégé d'un tas de choses dont systemd aurait besoin, mais inutile dans le cas de figure ou on veut utiliser la carte. Le support à 2 ans, comme dit plus haut ne devrait pas poser problème, par contre je crains que systemd ne pousse à intégrer un noyau et des libs inutiles. Mais je me trompe peut-être, et dans ce cas, merci de me le préciser (comme dit plus haut, je ne trolle pas, il s'agit d'un cas d'utilisation plus ou moins courant pour des personnes qui font un peu plus qu'utiliser une distrib serveur ou desktop).
Je tourne avec systemd sur Raspberry Pi depuis des mois, aucun problème de ce côté-là.
systemd est parfait pour cela, les options inutiles peuvent être omises à la compilation sans le moindre souci. Les options non disponibles pour cause de bibliothèques manquantes sont automatiquement écartées donc aucun souci non plus.
En revanche, il faut utiliser la glibc, de nombreuses fonctionnalités extrêmement utiles manquent aux libc minimalistes.
Trop de fonctionnalités tue les fonctionnalités, il y a des cas ou ces fonctionnalités peuvent être inutiles. L'avantage de sysvinit était justement de pouvoir adapter une distrib généraliste à un niveau minimaliste. Personnellement une de mes craintes à propos de systemd, c'est une perte de possibilités de personalisation.
C'est faux, trop de fonctionnalités n'a jamais tué les fonctionnalités dans un cas de figure comme celui de systemd. Ces fonctionnalités sont de l'ordre de la commodité, comme des options sur une voiture. Au pire elles ne sont pas utilisées, mais en général, si on les achète, c'est pour les utiliser. systemd c'est pareil, si on ajoute des fonctionnalités, c'est pour les utiliser à priori vu que ça peut (pas toujours) affecter l'empreinte mémoire de certains daemons de systemd.
Les seules bibliothèques requises par systemd sont quasi obligatoires sur tout système GNU/Linux un minimum sécurisé : glibc >= 2.14 (bientôt 2.16), libcap, libmount d'util-linux.
Même dbus est optionnel mais alors systemd devient très compliqué à utiliser, donc je rajouterai quand même dbus en composant supplémentaire perçu comme inutile ailleurs.
Pour un système embarqué, systemd est clairement meilleur que sysvinit auquel s'ajoute au moins un daemon par fonctionnalité de systemd et des tonnes de scripts, l'empreinte mémoire de systemd et ses "aides" est clairement plus faible, principalement parce que beaucoup de fonctionnalités sont partagées et pas dupliquées. J'ai pu dégager des trucs devenus inutiles et clairement inférieurs (moins fiables) comme xinetd, autofs (sauf si la conf est dans LDAP), dhcpcd, mes scripts d'initialisation réseau, l'initialisation du stockage, … Quand je vois le temps que j'ai passé à affiner dhcpcd avec mon firewall et bind afin qu'ils redémarrent correctement en cas de coupure réseau (ça m'a pris des jours avec des horreurs comme des timeout), et la simplicité avec laquelle j'ai fait la même chose avec systemd, c'est consternant.
TLDR; Il n'y a rien à recompiler, ni glibc, ni systemd.
Si tu veux mettre un noyau 4, sous-entendu non packagé et donc compilé par toi, sur une distribution, il faut que tu maîtrises ta distribution et la compilation du noyau, en particulier les options de compatibilité avec la glibc du noyau et les différences de patch entre le kernel upstream et celui de ta distribution.
Vu que tu utilises la version la plus récente du noyau Linux et que tu parles d'une distribution incluant systemd, il n'y aura aucun autre problème à prévoir.
Si tu veux faire une LFS avec systemd, je suppose que tu utiliseras les versions les plus récentes de la Glibc et de systemd, donc il n'y aura aucun problème non plus.
Excepté qu'il faut connaître les options minimum à placer dans le noyau pour que systemd fonctionne correctement. Je dis ça parce qu'un problème qui revient souvent sur la ML de dév de systemd, c'est que les gens n'ont pas mis l'option CONFIG_FHANDLE dans leur noyau.
Il est pourtant bien écrit là qu'un init qui monte rapidement un système est un bon init, et pas que c'est un objectif de systemd.
Il est ensuite indiqué ce qu'il faut selon l'auteur pour obtenir un bon init (en 2010+).
Il est précisé ensuite la pensée de l'auteur par ce qu'il entend par "fast", et c'est répété partout : tout est lancé en parallèle en fonction des événements, et surtout pas de manière sérialisée.
On ne parle pas de booter en quelques secondes de moins là, on parle de maximiser le CPU et les IO disponibles, comme précisé ensuite, et pas seulement au boot, mais pendant toute la durée où l'espace utilisateur et monté.
L'auteur parle également de la gestion de l'aspect dynamique du noyau, qui doit être géré par l'init. Il y a beaucoup de choses dans ce blog en fait.
Ceci afin de ne pas se retrouver avec des boucles d'attente sur des montages de disques ou carrément des boots crashés comme j'ai vu si souvent avec sysvinit.
Les arguments dans ce post décrivent la réflexion qui a conduit à systemd, pas les objectifs de systemd. Et la rapidité intrinsèque aux choix effectués montrent selon l'auteur que c'est un bon init s'il suit sa définition d'un bon init.
Il me semble qu'il y a un autre blog de l'auteur qui explique les objectifs de systemd (l'ensemble de logiciels, pas juste l'init).
systemd est un choix stratégique pour, à priori, amener les systèmes Linux vers une adoption plus importante dans le contexte du desktop.
C'est faux, va lire l'interview de Lennart de Linux Voice (http://www.linuxvoice.com/interview-lennart-poettering/), la deuxième question retrace l'historique, et systemd est entièrement un choix technique. Si tu peux suivre l'historique de systemd sur le blog de Lennart P., tu verras que depuis le départ les arguments techniques, ainsi que toutes les évolutions. Je suis le projet depuis le début puisque je cherchais à remplacer mon simpleinit-msb qui devenais impossible à maintenir, et j'avais galéré avec dbus + upstart sur mon OS.
Là ce que je vois c'est qu'en fonction de mes choix de système base, je vais devoir, ou pas, dire adieu à Gnome à moins d'y investir des heures de temps que je n'ai pas.
Et donc, on m'a imposé une perte de liberté.
On ne t'a enlevé aucune liberté ! Quelle est donc cette liberté que tu as soi-disant perdue ?
Et qui est ce "on" ? Ça ne peut être que ta distribution.
Oui c'est normal : tu as le socket ouvert par systemd et celui ouvert par ta session via XDG.
Tu as désactivé le socket dans systemd, donc il ne se réactivera pas. Mais tu as juste oublié d'arrêter celui qui est surement en cours avec "systemctl stop mpd.socket".
Bref, systemd n'est encore une fois pas en cause, c'est dû à une erreur de packaging et une méconnaissance de systemd de la part de l'administrateur.
Une chose est sûre en lisant les commentaires : linuxfr est totalement infiltré par les féministes les plus virulentes, notamment les partisans de la théorie du genre.
Déjà en lisant la nouvelle je n'en croyais pas mes yeux de voir une telle propagande. Pour quiconque connaît le mouvement, il est flagrant que c'est la théorie du genre qui est à l’œuvre.
Ensuite en lisant les commentaires, où tout débat est complètement occulté, j'ai failli me désabonner.
C'est simple :
- le matraquage en règle est clairement visible : tout partisan a une évaluation max à 10 ou proche, tout opposant identifié est évalué à -8 ou en-dessous; C'est assez rare pour être bien visible;
- toute personne qui réfléchit est systématiquement discrédité. La seule mention d’Égalité et Réconciliation ou de Soral donne droit à des jugements d'autorité ou le point Godwin est vite gagné pour empêcher tout débat sérieux;
- Quand j'en arrive à lire qu'il faut lutter contre les différences homme/femme, je sais que tout cela n'est qu'une saloperie de plus (c'est mon avis) : la théorie du genre dans toute sa splendeur. Dans mon monde, hommes et femmes sont très heureux de leurs différences, en usent et en abusent;
Les choses qui n'ont soi-disant pas été prouvées au niveau des différences homme/femme le sont en fait depuis des dizaines d'années, y compris les différences au niveau du cerveau, par exemple le cerveau féminin plus petit que le masculin, le corps calleux féminin bien plus gros que le masculin (ce qui explique pourquoi les femmes sont plus multitâches que les hommes), le fait que le cerveau féminin soit plus actif que celui des hommes (il n'est jamais en repos, les femmes ont du mal à comprendre quand un homme dit qu'il "ne pense à rien"), etc.
Heureusement, il y a des femmes courageuses (plus que beaucoup d'hommes) et vraiment dignes comme Farida Belghoul pour se mettre en danger et lutter contre cette saloperie de théorie du genre qui paraît-il n'existe pas.
Ça me fait de la peine de voir ce site infiltré par cette saloperie, mais c'était inévitable.
Pourtant, il me semble que la plupart des hommes en filière informatique meurent d'envie d'y voir plus de femmes, ce n'est pas moi qui m'en plaindrait en tout cas. Mais évidemment, il faut introduire qu'il y a une lutte homme/femme, sinon le combat de ces personnes n'a plus de sens.
Sans compter que des daemons comme rsyslog savent utiliser les API de systemd pour ceux qui veulent des logs texte.
Même les logs du noyau que l'on ne perd plus grâce à journald.
Et des logs encore plus précises grâce aux informations supplémentaires ajoutées dans le noyau Linux grâce à journald, et les infos supplémentaires que journalise journald.
Je ne comprends pas ces discussion qui ne servent à rien, vu que les gens qui en avaient besoin et qui utilisent réellement systemd ont déjà demandé tout ça et l'ont déjà obtenu.
Mais quelle saloperie le féminisme !
on a un ou plusieurs enfants brisés car leurs parents se séparent, et la préoccupation principale des féministes c'est forcer les pères à avoir plus souvent la garde des enfants !
Et "bizarrement", toutes les féministes viennent du même milieu : des bobos riches qui n'ont rien à foutre dans la vie, la majeure partie du temps sans enfant. Donc des femmes qui sont à cent lieues de la majorité des femmes, qui elles doivent bosser car le revenu de leur compagnon n'est pas suffisant ou bien elles ne sont pas rentières. Ces femmes bien souvent nous bassinent comme quoi elles ne veulent pas d'enfants (grand bien leur fasse), la plupart du temps elles ne peuvent plus en avoir d'ailleurs (ou sont lesbiennes).
Bizarrement, toutes ces féministes nous parlent toujours d'égalité pour des postes à haute responsabilité, ce qui est une toute petite partie des femmes. Parce que dans les autres métiers de moins de prestance, la parité est bien plus présente entre femmes et hommes.
Bref, je ne connais pas une féministe qui ne soit pas en fait en train de détourner la lutte des classes en lutte des sexes, ce qui est une belle saloperie de plus au final. Mais quand on discute avec une femme normale, une femme de tous les jours, elle n'a pas cette haine envers l'autre sexe qu'expriment les féministes, elles ne se considèrent pas spoliées. Les ouvrières à l'usine aimeraient bien bosser dans des métiers plus féminins par exemple.
Les seules avancées que je vois avec le féminisme en France, c'est qu'on veut maintenant taxer d'une manière ou d'une autre les femmes au foyer pour les forcer à aller bosser au lieu d'éduquer leurs enfants, même contre leur gré : "C'est pour votre bien madame, même si vous n'en avez pas conscience…"
Et toutes les soi-disant avancées sont du même acabit. Même les top models féminins ne veulent pas de ces chieuses qui les empêchent de bosser.
Et je n'entends pas trop le féminisme réagir contre la théorie du genre. Mais vu leurs origines que j'ai cité auparavant, cela ne m'étonne pas.
En revanche, les gens du quotidien, eux, quand ils entendent ce que c'est et que c'est déjà enseigner dans certaines de nos écoles, ça les fait réagir (et pas en bien en général).
Ces évaluations de lignes sont totalement fausses.
Il y a inclusion d'un autre script (qui lui-même en inclus d'autres) dans les scripts shell, spécifiquement de /etc/rc.subr, qu'il faut ajouter au nombre de lignes nécessaires pour que cela fonctionne. Ce qui rajoute plusieurs dizaines de lignes tout de suite (surement plus de 200 lignes).
Le script rc ne ressemble pas du tout à du systemd : par exemple, de la configuration est accédée par rc.subr, ce qui n'est pas le cas dans systemd où toute la configuration pour le service est soit dans l'initscript soit gérée par le service dans sa propre configuration.
Dans la suite des procédés malhonnêtes, indiquer qu'il n'y a pas de documentation dans le fichier systemd alors que cela dépend entièrement du mainteneur.
Il y a possibilité de mettre des commentaires de la même façon comme on peut le voir d'ailleurs dans l'exemple fourni, et même une directive "documentation" pouvant référencer man.
Et non, le script rc n'est pas du tout lisible au niveau syntaxe, la configuration est chargée et se trouve dans un autre fichier, enfin bref c'est un bordel sans nom, comme les initscripts SYSV d'ailleurs. Ce genre de trucs est très difficile à maintenir.
Avec systemd on ne code pas dans les initscripts, c'est censé être déclaratif, c'est un de ses points forts. L'initscripts est le dernier endroit où je veux du code.
Chez moi ça fait bientôt 7 ans que je tourne avec MythTV, cela marche parfaitement bien et j'ai toujours mes très vieux enregistrements.
J'ai 3+ To d'émissions enregistrées, donc je pense que ça fonctionne correctement.
Cependant, concernant Free, cela ne fonctionne plus depuis quelques années suite à une modification au niveau du multiposte de Free. Personne n'a repris le développement de cette fonctionnalité en France, qui effectivement ne fonctionne plus.
Après, concernant XBMC, cela ne me semble pas le même usage, ça semble plutôt orienté court terme.
# Pas étonnant
Posté par ookaze . En réponse au message grub2 gpt systemd lvm et uuid. Évalué à 1.
Le module LVM dans GRUB permet à Grub de retrouver ses fichiers de démarrage quand ton /boot est sur LVM. Mais en aucun cas il ne va initialiser ton LVM. Du coup, si tu veux accéder à tes autres fichiers sur LVM, il faut l'initialiser autrement.
Le module LVM de grub lui permet d'aller trouver ton noyau et donc forcément un fichier initramfs posés sur une partition elle-même sur du LVM. L'initramfs va permettre d'initialiser le LVM et les périphériques associés, qu'ensuite le noyau pourra accéder pour lancer l'init qui sera réellement utilisé par le système.
Donc effectivement, ce que tu veux faire n'est pas possible et le kernel panic correspondant n'est pas étonnant.
[^] # Re: Musl / uclibc
Posté par ookaze . En réponse au journal Busybox retire le support de systemd ?. Évalué à -1. Dernière modification le 16 novembre 2015 à 15:49.
Quel est l’intérêt de cette remarque qui n’a rien à voir avec le sujet ?
Déjà, il me semble que le noyau Linux n'est porté que sur le noyau Linux !
Linus n’accepte pas les patches qui selon lui n’ont rien à faire dans le noyau (d’où les difficultés de kdbus par exemple), systemd n’accepte pas les patches qui n’ont rien à faire dans systemd : c’est pareil.
Et la preuve est que ces fonctionnalités (des API pour des appels système sous Linux) sont présentes dans la glibc (qui pourtant filtre ce qui est disponible sur un unique noyau), et qu’elles fonctionnent très bien et sont maintenues.
Pour information, ce n’est pas la première fois qu’un développeur demande à systemd d’implémenter des fonctions de la glibc parce que la libc qu’il utilise ne veut pas le faire.
Multiplier les implémentations d’API dans de multiples projets est très mauvais, c’est une très bonne raison de ne pas réimplémenter la roue dans systemd.
Bien sûr, ça va à l’encontre de l’histoire comme quoi systemd veut tout réimplémenter (glibc, GNU par exemple) au sein de son code, mais les incohérences n’arrêtent pas les trolls.
systemd est spécifique GNU/Linux, c’était clair dès le début.
Certains n’ont pas voulu l’entendre de cette oreille et ont décidé que c’était possible et pas un énorme boulot de gérer la compatibilité avec d’autres OS, pour décrédibiliser les développeurs systemd.
Seulement, arrivé dans la réalité, tous ces beaux parleurs jettent l’éponge les uns après les autres devant l’ampleur de la tâche, comme uselessd, prouvant par là même la compétence des dévs systemd et leur propre irresponsable incompétence.
[^] # Re: Musl / uclibc
Posté par ookaze . En réponse au journal Busybox retire le support de systemd ?. Évalué à 0.
Systemd encore moins, c'est même la raison pour laquelle il utilise la Glibc au lieu de s'en recréer une.
Non, mon approche signifie qu'il ne faut taper ni sur musl ni sur glibc, mais implémenter soi-même les fonctionnalités manquantes dans un fork de systemd. Ce qui revient au même puisque ceux-là même qui veulent mettre le patch upstream vont le maintenir. En fait, c'est même exactement de cette façon que c'est fait pour nombre de patchs du noyau Linux non acceptés upstream : ils sont maintenus dans une branche séparée, merci git.
Un systemd-musl n'est pas accepté upstream, mais rien n'empêche aux mainteneurs de proposer leur fork/branche.
Factuellement faux puisque le noyau et Linus fonctionnent exactement de la même façon.
[^] # Re: Musl / uclibc
Posté par ookaze . En réponse au journal Busybox retire le support de systemd ?. Évalué à 9.
Et il a parfaitement raison de refuser ces patchs.
Ce qui est demandé par ces distributions n'a aucun sens, et c'est évident à n'importe qui comprenant de quoi il s'agit.
Accepter des patches de ce genre, cela signifie tout simplement d'accepter de maintenir une sorte de fork de glibc dans systemd. Parce que ces patches consistent à maintenir des fonctionnalités manquantes de musl-libc (par exemple) par rapport à glibc, dans systemd.
systemd n'a pas la vocation d'être une libc, c'est à musl-libc qu'il faut envoyer ces patches évidemment. Et bien sûr cela a été fait, mais qu'ont répondu ces différents libc ? Elles ont refusé !
Et évidemment, on essaie de porter le blâme sur systemd.
Pour le système de logs de systemd dans BusyBox, cela n'avait de toutes façons aucun sens, systemd venant avec son système de logs. En fait cela ne change rien en pratique.
[^] # Re: Maintenabilité ?
Posté par ookaze . En réponse à la dépêche Linux From Scratch 7.8 : nouvelle version de la distro dont vous êtes le dictateur !. Évalué à 0.
Ça, c’est bien vrai. Ça permet par exemple de comprendre aisément des choix comme ceux de passer à systemd. Pour avoir connu et appliqué LFS depuis plus de 15 ans, et avoir géré des Linux depuis, je comprends aisément les déboires des mainteneurs de distributions.
Je me rappelle à l’époque, quelqu’un m’avait demandé naïvement pourquoi je ne faisais pas une distribution avec tout ce que je savais. Si on ne l’a jamais fait, on ne peut pas s’en rendre compte. Gérer son propre OS dérivé de LFS c’est facile, et on a facilement mieux que n’importe quelle distribution. Mais gérer son OS sur les machines des autres avec leurs exigences et leurs configurations alors qu’ils ne maîtrisent rien, c’est une autre paire de manches et je trouve ce travail ingrat, donc jamais je ne ferai de distribution.
Il y a cela, le fait que ce que l’on obtient est toujours mieux que n’importe quelle distribution : par exemple, je suis en LVM sur RAID depuis le début, à une époque où l’option était soit inexistante sur les distributions, soit expérimentale.
Il y a aussi le fait que dès que l’on veut sortir des clous avec une distribution (application non supportée, nouvelle version majeure…) et installer des choses hors paquets officiels, le système devient vite instable, où alors il faut se lancer dans la création de paquets, ce qui est contraignant pour rien au mieux (paquet officiel qui sort plus tard) ou est contraignant pour rien (paquet à maintenir continuellement). J’avais testé avec toutes les distributions, jusqu’à Gentoo. Même avec Gentoo c’était ingérable, et recompiler des tonnes de trucs pour rien, j’en ai eu assez.
[^] # Re: Maintenabilité ?
Posté par ookaze . En réponse à la dépêche Linux From Scratch 7.8 : nouvelle version de la distro dont vous êtes le dictateur !. Évalué à 0.
Je suis d’accord, la comparaison avec Gentoo est vraiment faite à tort. Déjà tout simplement parce que LFS n’est pas vraiment une distribution.
Ce qui en découle, c’est qu’un gestionnaire de paquet est parfaitement inutile dès lors que l’on ne souhaite pas faire du pré mâché pour les autres, principe aussi connu sous le nom de distribution.
Puisqu’en fait on acquiert l’expertise pour faire les dépendances dans sa tête, ou dans des outils automatisés (scripts ou autres).
[^] # Re: Maintenabilité ?
Posté par ookaze . En réponse à la dépêche Linux From Scratch 7.8 : nouvelle version de la distro dont vous êtes le dictateur !. Évalué à 1.
LFS est simple à maintenir avec les trois points que j’ai cités.
Évidemment, je ne parlais pas de BLFS et autres, où là c’est une autre paire de manches.
Et LFS ne fait pas tout ce qu’il faut pour amorcer un système, il ne gère pas le LVM, il ne gère pas les initramfs, ou la construction de LiveCD.
Cela s’est beaucoup amélioré au cours du temps (dracut est vraiment excellent maintenant), mais il faut encore gérer les adhérences entre le noyau Linux et des outils comme Syslinux dont la documentation est fausse et trompeuse car non maintenue, ou Busybox dont les outils minimalistes ne fonctionnent plus avec de nouvelles fonctions du noyau au fil du temps.
Il faut gérer aussi l’UEFI. Ce sont toutes ces nouveautés qui prennent du temps.
Une fois que l’on a compris comment cela fonctionne, si l’on veut tout automatiser avec ses propres options et préférences, il n’y a aucun outil disponible à part nALFS.
Mais LFS reste très instructif, et même s’il n’est plus mis à jour, il sera toujours aussi instructif.
[^] # Re: Maintenabilité ?
Posté par ookaze . En réponse à la dépêche Linux From Scratch 7.8 : nouvelle version de la distro dont vous êtes le dictateur !. Évalué à 0.
Dommage, jhalfs c'est du Shell, donc totalement inapproprié et peu praticable par rapport à nALFS.
Tant pis, mon système fonctionne bien de toutes façons.
J'aurai voulu intégrer le cloisonnement kernel via systemd au lieu du chroot de nALFS, qui cause des problèmes, mais bon tant pis.
[^] # Re: Maintenabilité ?
Posté par ookaze . En réponse à la dépêche Linux From Scratch 7.8 : nouvelle version de la distro dont vous êtes le dictateur !. Évalué à 2.
Non, les difficultés sont toujours les mêmes :
— Changements d’ABI ou d’API à prendre en compte, surtout au niveau des éléments essentiels du système (la plomberie) par exemple la glibc ;
— Suivre les évolutions de la plomberie, mais pas trop vite, et créer les correctifs adéquats ou les récupérer ;
— Conserver la motivation, de bons outils aident beaucoup ;
à ce propos, j’utilise toujours nALFS que j’ai modifié pour supporter différentes choses (par exemple les tarballs xz ou activer la redirection pour cURL) et porg pour gérer mes systèmes et automatiser le tout.
Quelqu’un a-t-il des informations sur un groupe qui aurait repris nALFS ?
Sinon, ça fait 15 ans que je roule avec nALFS et tous mes systèmes fonctionnent parfaitement, sachant qu’il gère un équivalent de LFS systemd + BLFS + ALFS + CLFS (ARM + x86 + x86_64) + LiveCD. Le CLFS est abandonné, mais je gère toujours les 3 architectures avec le même nALFS.
Mais comme auparavant avec simpleinit-msb, si je peux m’abstenir de maintenir une application c’est toujours mieux.
[^] # Re: Tu peu même élargir ...
Posté par ookaze . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 2.
Tiens, c'est exactement mon cas, j'ai remonté un client Windows l'année dernière avec un vieux serveur dont je ne me servais plus depuis des années, qui comprenait une carte SCSI avec des disques SCSI. Ca a été une galère sans nom pour trouver un pilote qui fonctionne, et au final j'ai dû installer Windows 7 32 bits sur le disque IDE, puis basculer le système sur le disque SCSI.
J'ai eu d'autres misères mais rien que celle-là m'a coûté des jours de travail ingrat.
Ca m'a fait un choc de découvrir à quel point Windows était archaïque, plus encore que ce que j'imaginais : la version 32 bits ne supporte même pas 4 Go de RAM et trouve le moyen de ramer.
Le pilote graphique NVidia à jour plante régulièrement en regardant des vidéos Youtube ou autre !
[^] # Re: Tu peu même élargir ...
Posté par ookaze . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 0.
Qu'est-ce qu'il ne faut pas lire, c'est le comportement gravissime dont parlait un posteur ci-dessus.
Le compromis dont tu parles n'a absolument rien de raisonnable, c'est juste le plus facile, certainement pas le plus raisonnable. Je ne vois pas ce qu'il y a de raisonnable à abandonner sa liberté à la moindre contrainte, surtout quand on sait que la liberté est qqch qui n'est pas facile à obtenir ou à maintenir, c'est un combat de chaque instant.
Et là, je lis qu'abandonner au premier coup reçu est raisonnable, c'est vraiment ridicule.
Le Logiciel Libre a été la réponse raisonnable à précisément ce genre de problématique, mais c'est long et difficile. Le chemin parcouru en 25 ans et plus me paraît juste incroyable.
Je n'ai rien contre lâchement accepter le compromis, je le fais aussi, en revanche je ne cautionne pas ceux qui, sachant qu'ils ont lâchement abandonné, se donnent bonne conscience en se disant que c'était ce qu'il y avait de mieux à faire, c'était le plus raisonnable, alors qu'ils sont sur un système qui prouve le contraire. Mais bon c'est humain…
[^] # Re: Tu peu même élargir ...
Posté par ookaze . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 5.
En fait ton post est un bon exemple de cette phrase, et tu parles manifestement d'un sujet que tu ne maîtrises pas du tout.
Elle ne développe pas son module le jour de la sortie, et il lui suffit de fournir le module en question via le moyen qu'elle veut : Web, paquet de la distribution, … C'est justement ce que font tous les constructeurs qui supportent Linux. Et l'ABI du noyau Linux ne casse pas à chaque update. Il faut éviter d'asséner des choses lorsque l'on ne maîtrise pas du tout le sujet.
Ton exemple n'a rien de sorcier et est déjà géré.
Le seul moment où cela pose problème, c'est lorsque le constructeur n'a développé aucun pilote libre.
La donne change quand ces 1% de desktop correspondent à 90+ % de desktop utilisés dans un domaine à forte valeur ajoutée auquel ce constructeur vend 99% de son matériel.
90 % du desktop, dont au mieux le marché du constructeur n'est qu'un sous-ensemble, au final pas forcément plus grand que le 1 % de desktop ci-dessus.
Non, c'est un exemple qui contredit la réalité, associé à des chiffres sans aucun rapport, plus élevés du côté qui te plaît pour appuyer ton argument par un sophisme de juxtaposition.
Bref, ce que tu dis ne sert à rien, en plus d'être basé sur de l'ignorance.
Et finir par une contre-vérité, ça résume bien le ridicule du post.
[^] # Re: Et devuan ?
Posté par ookaze . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à -2.
Non ce n'en est pas une, mais ça rentre exactement dans les prédictions de pas mal de "pro-systemd" comme moi. Il n'y a aucun argument technique valable derrière ce fork, à se demander si toute cette mascarade n'a pas été financée par des concurrents, ce serait de bonne guerre. Le contenu de la liste de diffusion est risible également.
En revanche, les personnes derrière tout cela ont quand même fait un peu de mal à Debian.
[^] # Re: glibc non, systemd peut-être
Posté par ookaze . En réponse au message Kernel 4.0 et lfs. Évalué à 3.
Je tourne avec systemd sur Raspberry Pi depuis des mois, aucun problème de ce côté-là.
systemd est parfait pour cela, les options inutiles peuvent être omises à la compilation sans le moindre souci. Les options non disponibles pour cause de bibliothèques manquantes sont automatiquement écartées donc aucun souci non plus.
En revanche, il faut utiliser la glibc, de nombreuses fonctionnalités extrêmement utiles manquent aux libc minimalistes.
C'est faux, trop de fonctionnalités n'a jamais tué les fonctionnalités dans un cas de figure comme celui de systemd. Ces fonctionnalités sont de l'ordre de la commodité, comme des options sur une voiture. Au pire elles ne sont pas utilisées, mais en général, si on les achète, c'est pour les utiliser. systemd c'est pareil, si on ajoute des fonctionnalités, c'est pour les utiliser à priori vu que ça peut (pas toujours) affecter l'empreinte mémoire de certains daemons de systemd.
Les seules bibliothèques requises par systemd sont quasi obligatoires sur tout système GNU/Linux un minimum sécurisé : glibc >= 2.14 (bientôt 2.16), libcap, libmount d'util-linux.
Même dbus est optionnel mais alors systemd devient très compliqué à utiliser, donc je rajouterai quand même dbus en composant supplémentaire perçu comme inutile ailleurs.
Pour un système embarqué, systemd est clairement meilleur que sysvinit auquel s'ajoute au moins un daemon par fonctionnalité de systemd et des tonnes de scripts, l'empreinte mémoire de systemd et ses "aides" est clairement plus faible, principalement parce que beaucoup de fonctionnalités sont partagées et pas dupliquées. J'ai pu dégager des trucs devenus inutiles et clairement inférieurs (moins fiables) comme xinetd, autofs (sauf si la conf est dans LDAP), dhcpcd, mes scripts d'initialisation réseau, l'initialisation du stockage, … Quand je vois le temps que j'ai passé à affiner dhcpcd avec mon firewall et bind afin qu'ils redémarrent correctement en cas de coupure réseau (ça m'a pris des jours avec des horreurs comme des timeout), et la simplicité avec laquelle j'ai fait la même chose avec systemd, c'est consternant.
# Rien à faire à part savoir compiler un noyau
Posté par ookaze . En réponse au message Kernel 4.0 et lfs. Évalué à 2.
TLDR; Il n'y a rien à recompiler, ni glibc, ni systemd.
Si tu veux mettre un noyau 4, sous-entendu non packagé et donc compilé par toi, sur une distribution, il faut que tu maîtrises ta distribution et la compilation du noyau, en particulier les options de compatibilité avec la glibc du noyau et les différences de patch entre le kernel upstream et celui de ta distribution.
Vu que tu utilises la version la plus récente du noyau Linux et que tu parles d'une distribution incluant systemd, il n'y aura aucun autre problème à prévoir.
Si tu veux faire une LFS avec systemd, je suppose que tu utiliseras les versions les plus récentes de la Glibc et de systemd, donc il n'y aura aucun problème non plus.
Excepté qu'il faut connaître les options minimum à placer dans le noyau pour que systemd fonctionne correctement. Je dis ça parce qu'un problème qui revient souvent sur la ML de dév de systemd, c'est que les gens n'ont pas mis l'option CONFIG_FHANDLE dans leur noyau.
[^] # Re: Merci
Posté par ookaze . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à -4.
Il est pourtant bien écrit là qu'un init qui monte rapidement un système est un bon init, et pas que c'est un objectif de systemd.
Il est ensuite indiqué ce qu'il faut selon l'auteur pour obtenir un bon init (en 2010+).
Il est précisé ensuite la pensée de l'auteur par ce qu'il entend par "fast", et c'est répété partout : tout est lancé en parallèle en fonction des événements, et surtout pas de manière sérialisée.
On ne parle pas de booter en quelques secondes de moins là, on parle de maximiser le CPU et les IO disponibles, comme précisé ensuite, et pas seulement au boot, mais pendant toute la durée où l'espace utilisateur et monté.
L'auteur parle également de la gestion de l'aspect dynamique du noyau, qui doit être géré par l'init. Il y a beaucoup de choses dans ce blog en fait.
Ceci afin de ne pas se retrouver avec des boucles d'attente sur des montages de disques ou carrément des boots crashés comme j'ai vu si souvent avec sysvinit.
Les arguments dans ce post décrivent la réflexion qui a conduit à systemd, pas les objectifs de systemd. Et la rapidité intrinsèque aux choix effectués montrent selon l'auteur que c'est un bon init s'il suit sa définition d'un bon init.
Il me semble qu'il y a un autre blog de l'auteur qui explique les objectifs de systemd (l'ensemble de logiciels, pas juste l'init).
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par ookaze . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 1.
C'est faux, va lire l'interview de Lennart de Linux Voice (http://www.linuxvoice.com/interview-lennart-poettering/), la deuxième question retrace l'historique, et systemd est entièrement un choix technique. Si tu peux suivre l'historique de systemd sur le blog de Lennart P., tu verras que depuis le départ les arguments techniques, ainsi que toutes les évolutions. Je suis le projet depuis le début puisque je cherchais à remplacer mon simpleinit-msb qui devenais impossible à maintenir, et j'avais galéré avec dbus + upstart sur mon OS.
On ne t'a enlevé aucune liberté ! Quelle est donc cette liberté que tu as soi-disant perdue ?
Et qui est ce "on" ? Ça ne peut être que ta distribution.
[^] # Re: pour l'histoire du port
Posté par ookaze . En réponse au message mpd démarre tout seul. Évalué à 0.
Oui c'est normal : tu as le socket ouvert par systemd et celui ouvert par ta session via XDG.
Tu as désactivé le socket dans systemd, donc il ne se réactivera pas. Mais tu as juste oublié d'arrêter celui qui est surement en cours avec "systemctl stop mpd.socket".
Bref, systemd n'est encore une fois pas en cause, c'est dû à une erreur de packaging et une méconnaissance de systemd de la part de l'administrateur.
[^] # Re: Pour voir si c'est cassé chez vous
Posté par ookaze . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 2.
Pas sûr, il y a des problèmes de charge qui peuvent remonter des faux négatifs.
C'est indiqué sur le site.
[^] # Re: Encore la théorie du genre...
Posté par ookaze . En réponse à la dépêche Les femmes dans l'informatique. Évalué à -10.
Une chose est sûre en lisant les commentaires : linuxfr est totalement infiltré par les féministes les plus virulentes, notamment les partisans de la théorie du genre.
Déjà en lisant la nouvelle je n'en croyais pas mes yeux de voir une telle propagande. Pour quiconque connaît le mouvement, il est flagrant que c'est la théorie du genre qui est à l’œuvre.
Ensuite en lisant les commentaires, où tout débat est complètement occulté, j'ai failli me désabonner.
C'est simple :
- le matraquage en règle est clairement visible : tout partisan a une évaluation max à 10 ou proche, tout opposant identifié est évalué à -8 ou en-dessous; C'est assez rare pour être bien visible;
- toute personne qui réfléchit est systématiquement discrédité. La seule mention d’Égalité et Réconciliation ou de Soral donne droit à des jugements d'autorité ou le point Godwin est vite gagné pour empêcher tout débat sérieux;
- Quand j'en arrive à lire qu'il faut lutter contre les différences homme/femme, je sais que tout cela n'est qu'une saloperie de plus (c'est mon avis) : la théorie du genre dans toute sa splendeur. Dans mon monde, hommes et femmes sont très heureux de leurs différences, en usent et en abusent;
Les choses qui n'ont soi-disant pas été prouvées au niveau des différences homme/femme le sont en fait depuis des dizaines d'années, y compris les différences au niveau du cerveau, par exemple le cerveau féminin plus petit que le masculin, le corps calleux féminin bien plus gros que le masculin (ce qui explique pourquoi les femmes sont plus multitâches que les hommes), le fait que le cerveau féminin soit plus actif que celui des hommes (il n'est jamais en repos, les femmes ont du mal à comprendre quand un homme dit qu'il "ne pense à rien"), etc.
Heureusement, il y a des femmes courageuses (plus que beaucoup d'hommes) et vraiment dignes comme Farida Belghoul pour se mettre en danger et lutter contre cette saloperie de théorie du genre qui paraît-il n'existe pas.
Ça me fait de la peine de voir ce site infiltré par cette saloperie, mais c'était inévitable.
Pourtant, il me semble que la plupart des hommes en filière informatique meurent d'envie d'y voir plus de femmes, ce n'est pas moi qui m'en plaindrait en tout cas. Mais évidemment, il faut introduire qu'il y a une lutte homme/femme, sinon le combat de ces personnes n'a plus de sens.
[^] # Re: Mon avis personnel
Posté par ookaze . En réponse au journal Debian adopte systemd comme init par défaut. Évalué à 5.
Sans compter que des daemons comme rsyslog savent utiliser les API de systemd pour ceux qui veulent des logs texte.
Même les logs du noyau que l'on ne perd plus grâce à journald.
Et des logs encore plus précises grâce aux informations supplémentaires ajoutées dans le noyau Linux grâce à journald, et les infos supplémentaires que journalise journald.
Je ne comprends pas ces discussion qui ne servent à rien, vu que les gens qui en avaient besoin et qui utilisent réellement systemd ont déjà demandé tout ça et l'ont déjà obtenu.
[^] # Re: Que dire de plus ?
Posté par ookaze . En réponse au journal Le féminisme me gonfle. Évalué à -9.
Mais quelle saloperie le féminisme !
on a un ou plusieurs enfants brisés car leurs parents se séparent, et la préoccupation principale des féministes c'est forcer les pères à avoir plus souvent la garde des enfants !
[^] # Re: Que dire de plus ?
Posté par ookaze . En réponse au journal Le féminisme me gonfle. Évalué à -10.
Et "bizarrement", toutes les féministes viennent du même milieu : des bobos riches qui n'ont rien à foutre dans la vie, la majeure partie du temps sans enfant. Donc des femmes qui sont à cent lieues de la majorité des femmes, qui elles doivent bosser car le revenu de leur compagnon n'est pas suffisant ou bien elles ne sont pas rentières. Ces femmes bien souvent nous bassinent comme quoi elles ne veulent pas d'enfants (grand bien leur fasse), la plupart du temps elles ne peuvent plus en avoir d'ailleurs (ou sont lesbiennes).
Bizarrement, toutes ces féministes nous parlent toujours d'égalité pour des postes à haute responsabilité, ce qui est une toute petite partie des femmes. Parce que dans les autres métiers de moins de prestance, la parité est bien plus présente entre femmes et hommes.
Bref, je ne connais pas une féministe qui ne soit pas en fait en train de détourner la lutte des classes en lutte des sexes, ce qui est une belle saloperie de plus au final. Mais quand on discute avec une femme normale, une femme de tous les jours, elle n'a pas cette haine envers l'autre sexe qu'expriment les féministes, elles ne se considèrent pas spoliées. Les ouvrières à l'usine aimeraient bien bosser dans des métiers plus féminins par exemple.
Les seules avancées que je vois avec le féminisme en France, c'est qu'on veut maintenant taxer d'une manière ou d'une autre les femmes au foyer pour les forcer à aller bosser au lieu d'éduquer leurs enfants, même contre leur gré : "C'est pour votre bien madame, même si vous n'en avez pas conscience…"
Et toutes les soi-disant avancées sont du même acabit. Même les top models féminins ne veulent pas de ces chieuses qui les empêchent de bosser.
Et je n'entends pas trop le féminisme réagir contre la théorie du genre. Mais vu leurs origines que j'ai cité auparavant, cela ne m'étonne pas.
En revanche, les gens du quotidien, eux, quand ils entendent ce que c'est et que c'est déjà enseigner dans certaines de nos écoles, ça les fait réagir (et pas en bien en général).
[^] # Re: systemd
Posté par ookaze . En réponse à la dépêche Petit état de l'art des systèmes d'initialisation (1). Évalué à 1.
Ces évaluations de lignes sont totalement fausses.
Il y a inclusion d'un autre script (qui lui-même en inclus d'autres) dans les scripts shell, spécifiquement de /etc/rc.subr, qu'il faut ajouter au nombre de lignes nécessaires pour que cela fonctionne. Ce qui rajoute plusieurs dizaines de lignes tout de suite (surement plus de 200 lignes).
Le script rc ne ressemble pas du tout à du systemd : par exemple, de la configuration est accédée par rc.subr, ce qui n'est pas le cas dans systemd où toute la configuration pour le service est soit dans l'initscript soit gérée par le service dans sa propre configuration.
Dans la suite des procédés malhonnêtes, indiquer qu'il n'y a pas de documentation dans le fichier systemd alors que cela dépend entièrement du mainteneur.
Il y a possibilité de mettre des commentaires de la même façon comme on peut le voir d'ailleurs dans l'exemple fourni, et même une directive "documentation" pouvant référencer man.
Et non, le script rc n'est pas du tout lisible au niveau syntaxe, la configuration est chargée et se trouve dans un autre fichier, enfin bref c'est un bordel sans nom, comme les initscripts SYSV d'ailleurs. Ce genre de trucs est très difficile à maintenir.
Avec systemd on ne code pas dans les initscripts, c'est censé être déclaratif, c'est un de ses points forts. L'initscripts est le dernier endroit où je veux du code.
[^] # Re: PVR et Freeboite
Posté par ookaze . En réponse à la dépêche XBMC 12 "Frodo" est de sortie. Évalué à 2.
Chez moi ça fait bientôt 7 ans que je tourne avec MythTV, cela marche parfaitement bien et j'ai toujours mes très vieux enregistrements.
J'ai 3+ To d'émissions enregistrées, donc je pense que ça fonctionne correctement.
Cependant, concernant Free, cela ne fonctionne plus depuis quelques années suite à une modification au niveau du multiposte de Free. Personne n'a repris le développement de cette fonctionnalité en France, qui effectivement ne fonctionne plus.
Après, concernant XBMC, cela ne me semble pas le même usage, ça semble plutôt orienté court terme.