Sondage La dernière fois que j’ai compilé un noyau Linux, c'était parce que…

Posté par . Licence CC by-sa.
Tags : aucun
10
9
sept.
2019
  • je voulais tester ou appliquer un patch :
    338
    (16.9 %)
  • le noyau précompilé de ma distribution ne répondait pas à mes besoins :
    415
    (20.7 %)
  • je voulais minimiser ce qui était inclus, pour des raisons de sécurité :
    121
    (6.0 %)
  • je voulais réduire la durée de démarrage du système :
    120
    (6.0 %)
  • je voulais limiter la consommation de ressources (embarqué par exemple) :
    127
    (6.3 %)
  • ma distribution me l’imposait :
    211
    (10.5 %)
  • rien, je n’ai jamais fait ça :
    672
    (33.5 %)

Total : 2004 votes

La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # [X] le noyau pré-compilé de ma distribution ne répondait pas à mes besoins

    Posté par (page perso) . Évalué à 10 (+11/-0).

    … et ça remonte à plus de quinze ans, je crois.

  • # Android

    Posté par . Évalué à 6 (+4/-0). Dernière modification le 09/09/19 à 17:54.

    C'était cet été, en compilant Android (pour architecture x86 - des isos sont fournies sur android-x86.org mais avec les Google Apps…)

    J'ai donc coché "ma distribution me l'imposait" sans trop savoir si c'était la bonne option :-)

  • # Houla !

    Posté par . Évalué à 5 (+5/-0).

    Simplement par geekerie et optimisation. :)
    Ca remonte à du Debian Potato ou Woody

  • # C'était juste pour voir

    Posté par . Évalué à 3 (+2/-0). Dernière modification le 09/09/19 à 18:48.

    je l'ai fait une fois, il y a plus de 20 ans*. C'était à titre purement expérimental.
    *) ma distro s'appelait encore Mandrake ;-)

  • # Il manque un choix...

    Posté par . Évalué à 10 (+10/-0).

    Je penses qu'il manque un choix important : "à titre éducatif ou par curiosité"

    La première et dernière fois que je l'ai fait c'était encore pour un noyau 2.6. Par curiosité j'ai essayé de compiler mon noyau "pour voir comment ça fait".

    Ca a marché mais ce fut long et ça a bien fait chauffer mon ordinateur portable. L'expérience fut intéressante, notamment pour le choix des "options" et les paramètres de compilation.

    • [^] # Re: Il manque un choix...

      Posté par . Évalué à 6 (+4/-0).

      Il manque aussi "Je ne m'en souviens pas".

      La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

  • # La mémoire...

    Posté par . Évalué à 2 (+2/-0).

    J'ai voté rien, mais je me souviens l'avoir fait dans le cadre de mes cours et une fois pour moi mais c'était il y a tellement longtemps que je ne me souviens plus de la raison.

  • # autres cas

    Posté par . Évalué à 2 (+3/-1).

    Concernant linux, celà remonte à moins de 10 ans, lorsque j'utilisais un thecus n2100 sous debian pour avoir une passerelle/FW qui fait aussi nas avec du raid à la maison (un peu bruyant, mais très pratique, sachant que l'on pouvait facilement augmenter la RAM).

    La dernière compilation de noyau non-linux remonte à juillet pour passer en version 12 de FreeBSD.

  • # Pour un patch linux temps réel

    Posté par (page perso) . Évalué à 2 (+2/-0).

    La dernière fois il y a quelques années, pour intégrer le patch Xenomai (patch pour faire du temps réel sous Linux) dans le cadre d'un projet de stage ;-) .

  • # Arch

    Posté par (page perso) . Évalué à 0 (+2/-4).

    Imposée sur Arch mais la compilation est pré-configurée et s'exécute d'elle-même à chaque nouveau noyal.

    La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

    • [^] # Re: Arch

      Posté par (page perso) . Évalué à 8 (+7/-0). Dernière modification le 10/09/19 à 11:35.

      Hein ?! Je suis sous Arch et je récupère un binaire à chaque nouveau noyal (paquet linux).

      • [^] # Re: Arch

        Posté par (page perso) . Évalué à 5 (+3/-0). Dernière modification le 10/09/19 à 18:28.

        Pardon, je n'utilise pas le kernel généric mais un kernel zen sur repo git.

        C'est pas Arch qui l'impose contrairement à ce que mon message laissait croire, c'est ma configuration perso qui l'impose ;).

        Mais c'est transparent pour moi, c'est pacman qui s'occupe de tout.

        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

    • [^] # Re: Arch

      Posté par . Évalué à 1 (+1/-0).

      Est-ce que tu ne confonds pas avec la génération de l'initramfs ? Via la commande mkinitcpio ?

  • # C’était pour alléger…

    Posté par (page perso) . Évalué à 5 (+4/-0).

    C’était pour alléger TinyCore Linux, pour tenter de l’utiliser à la place du vieillissant DamnSmallLinux sur mon PC portable Toshiba 300CDS avec 24MB RAM. Je n’ai pas réussi : le kernel moderne était toujours trop gros :-(

    Sinon, avant ça, c’était il y a des années, pour mon PC de salon à base d’EPIA M10000N, un truc sans driver open-source (à l’époque). L’enfer.
    Ça marchait, mais les mises à jour étaient compliquées. Je me suis juré de ne plus jamais acheter un périphérique non utilisable avec un driver open-source.

  • # C'était...

    Posté par . Évalué à 1 (+0/-0).

    Pour un petit netbook sous cherry trail, le asus x205ta qui était inutilisable sans noyau personnalisé.

  • # Compilation noyau Linux : curiosité !

    Posté par . Évalué à 2 (+2/-0).

    Bonjour,
    C'était en 2000 pour pouvoir créer un mini OS linux (dont je ne me rappelle plus le nom ) qui tenait sur une disquette !
    Pour avoir la prise en charge réseau sur la disquette, il fallait compiler un module particulier, si je me souviens bien.
    J'avais adoré, avec les liens symboliques du noyau, le boot, etc.

  • # Pour le boulot

    Posté par (page perso) . Évalué à 7 (+5/-0).

    La dernière fois, c'était pour le boulot, on travaillait sur la dernière version du noyau pour l'étudier et l'étendre si besoin. C'était pour device-mapper essentiellement.

  • # je voulais limiter la consommation de ressources

    Posté par . Évalué à 4 (+4/-0).

    Au boulot, on vendait des machines qui tournaient avec des cartes mémoire Compact Flash de 128Mo, alors fallait bien que ça rentre dedans, même si le proc n'était pas aussi poussif que ça (Celeron ou Atom selon).
    Distribution aujourd'hui disparue Trustix.

  • # BSD

    Posté par . Évalué à 3 (+1/-0). Dernière modification le 10/09/19 à 16:13.

    La dernière fois que j'ai compilé un noyau c'était un noyau openbsd car le projer fourni toujours ses erratas sous forme de patches et que ça compile assez rapidement.

    La dernière fois que j'ai compilé un noyau linux ça fait fort longtemps, une vingtaine d'années peut-être.

    • [^] # Re: BSD

      Posté par (page perso) . Évalué à 3 (+1/-0).

      Depuis peu avec openbsd on a des binaires pour les erratas aussi, c'est bien pratique, commande syspatch et puis voilà !

  • # La semaine dernière...

    Posté par . Évalué à 4 (+4/-0).

    … pour la mise à jour de ma Gentoo,
    J'utilise une distrib en mode sources, Gentoo : "tu compiles too" ;o), aussi l'outil genkernel est mon ami.
    Au passage, j'ai allégé les logs, il traînait un ou deux paramètres en mode "debug" qui polluaient mes logs depuis quelques temps.

    • [^] # Re: La semaine dernière...

      Posté par . Évalué à 5 (+3/-0).

      Je me souviens encore de la première fois que je l'ai vue. En TP en licence, on était censés installer chéplukel soft, tout le monde était sous Ubuntu, j'étais sous Debian, et il y avait cet étudiant qui prenait toujours 2 fois plus de temps que les autres pour installer ses paquets. Je suis donc allé voir pourquoi et il m'a expliqué qu'il était sous Gentoo et qu'il devait tout compiler et que c'était plus optimisé etc… Forcément ça m'a plu donc je l'ai adoptée aussi !
      J'ai quitté Gentoo il y a 11 ans (j'ai une tour qqpart qui l'a encore), mais les 2 ans que j'ai passés dessus m'ont beaucoup appris. En plus de la compilation du noyau et pilotes (carte wifi) j'y ai découvert la possibilité de choisir finement les paquets et options qu'on installe. Comment avoir un joli desktop sans télécharger les gigas de KDE/Gnome. Le plaisir d'une rolling-release qui "juste marche". Mais à l'époque j'avais le temps de rester assis à regarder les compilations se faire pour chaque logiciel… Maintenant ça n'est carrément plus possible.
      Du coup pour avoir tout ça mais sans le temps de compilation j'ai testé Arch et je suis resté. Mais j'aurai toujours un faible pour Gentoo. Pas ma première distro, mais la première qui m'a fait mettre les mains sous le capot.

    • [^] # Re: La semaine dernière...

      Posté par . Évalué à 2 (+2/-0).

      Pareil, tout les 15jours environ et du coup il manque une option dans le vote : "parce que j'aime ça"

      Sous Gentoo depuis presque 15ans et j'ai toujours compilé mes noyaux, je n'inclus que ce qui est nécessaire pour la machine.

      Il faudra que je teste genkernel un jour ou l'autre :-) mais choisir sa config noyau à la main avec menuconfig ça donne un bon aperçu des différentes briques du noyau et de son fonctionnement.

      Mais le premier kernel que j'ai compilé (probablement une version 2.0) c'était sur une Mandrake sur un K6II 450… c'était un peu long à l'époque --'

  • # VRF-Lite

    Posté par . Évalué à 2 (+1/-0).

    En ce qui me concerne, le noyau de Debian n'était pas compilé avec l'option CONFIG_CGROUP_BPF, qui est nécessaire pour utiliser la commande "ip vrf exec", le but étant de pouvoir lancer une commande directement dans un VRF-lite.

    Entre temps, y'a eu un bug report sur le sujet, et l'option est activée par défaut.

    Voilà.

    (c'était vraiment très intéressant, dis-donc)

  • # à défaut du bon choix..

    Posté par (page perso) . Évalué à 5 (+2/-0).

    J'ai coché « le noyau précompilé de ma distribution ne répondait pas à mes besoins » car j'avais besoin d'ajouter le support d'un matériel qui n'était pas pris en charge nativement. C'est un vieux Intel Pentium 90 de mémoire.

  • # Philosophie Gentoo...

    Posté par (page perso) . Évalué à 2 (+2/-1).

    Linux octopus 5.2.3-ck-fw-llk #1 SMP PREEMPT Sun Aug 11 15:55:33 CEST 2019 x86_64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz GenuineIntel GNU/Linux

    ^
    Manifestement, sur cette station, c'était il y a un mois, mais chez moi je suis plus à jour.
    Les processeurs actuels compilent si vite, que diminuer la superficie et la dépense de ressources est devenu assez simple.
    Pour info, j'ai eu un BiCéléron 500 comme raillé plus haut, et mon desktop maison est un Ryzen R9 3900X, ce qui rend l'exercice rapide.

    J'ai encore le cluster de prod en fin de validation, sous mon bureau. Ça fait un barouf d'enfer, mais les Threadripper 2950X compilent assez vite aussi ;-)

    Bref, compiler son noyau, pourquoi en perdre l'habitude ?

    • [^] # Re: Philosophie Gentoo...

      Posté par (page perso) . Évalué à 5 (+4/-0). Dernière modification le 10/09/19 à 21:41.

      J'utilise Gentoo aussi, par contre je ne suis pas vraiment convaincu que le temps passé à compiler soit compensé par le temps gagné par la suite en temps d'exécution. Je pense même que globalement la consommation d'énergie est largement supérieure dans le cas d'utilisation de Gentoo à en juger par la température de la pièce à la fin de la journée.

      • [^] # Re: Philosophie Gentoo...

        Posté par (page perso) . Évalué à 3 (+3/-1).

        L'essentiel ne me semble pas tant être un gain de temps d’exécution, qu'une bien meilleure maîtrise de chaque morceau de code qui tourne sur le système.
        La lisibilité de OpenRC, la possibilité de vérifier si un binaire est issu de portage ou pas, la possibilité de recompiler tout le système si besoin, garder le même système en évolution sur plusieurs années, voilà les vraies bonnes raisons.

        • [^] # Re: Philosophie Gentoo...

          Posté par . Évalué à 5 (+3/-0).

          Le tunning de chaque paquet, avec ou sans support de tel truc, avec python 2 ou python3, etc.

          C'est surtout ça que j'adorais.

        • [^] # Re: Philosophie Gentoo...

          Posté par (page perso) . Évalué à 3 (+2/-0).

          Tout à fait je rebondissais seulement sur:

          Les processeurs actuels compilent si vite, que diminuer la superficie et la dépense de ressources est devenu assez simple.

          L'intérêt de Gentoo est ailleurs, comme tu l'as dit. Le principal à mon avis étant la customisation du système à l'aide des use flags.

      • [^] # Re: Philosophie Gentoo...

        Posté par (page perso) . Évalué à 5 (+3/-0). Dernière modification le 11/09/19 à 17:56.

        Je pense même que globalement la consommation d'énergie est largement supérieure dans le cas d'utilisation de Gentoo à en juger par la température de la pièce à la fin de la journée.

        Je me suis fait cette réflexion il y a peu. Un système type Gentoo qui compile en local c'est pas très green IT, non ? Ou alors il faut faire ça l'hiver ;)

        « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

  • # je voulais minimiser ce qui était inclus, réduire la durée de démarrage du système et la conso

    Posté par . Évalué à 2 (+1/-0).

    Les 3 à la fois. Des tests sur Raspberry Pi avec Gentoo.

  • # … C'était mon boulot

    Posté par (page perso) . Évalué à 5 (+3/-0). Dernière modification le 10/09/19 à 21:22.

    Sinon, je (re)compile du FreeBSD dans les trois à quatre fois par semaine.

    De fait, je, c'est beaucoup dire: je confie cette tâche à des scripts Makefile qui, in fine, demandent à clang d'effectuer le gros du boulot.

  • # ... ma distribution est en fait mon OS

    Posté par . Évalué à 1 (+2/-1).

    Cela fait plus de 18 ans que je compile mon propre OS, à la base basé sur LFS, puis modifié à ma sauce en fonction des machines sur lesquelles je le place (6 types différents aujourd'hui).
    La dernière fois que j'ai compilé des noyaux (un par machine) correspond à la dernière version de la 5.1.
    La règle que j'applique aujourd'hui est que je place la dernière version EOL du noyau qui précède la stable actuelle. Cela m'évite de compiler plusieurs versions mineures.
    Surtout que je ne reboote pas les machines de toutes façons, excepté les plus sensibles comme les frontaux de sécurité, ou s'il y a un problème de sécurité nécessitant un reboot.
    C'est d'ailleurs le seul cas où je compile tout de suite la dernière version stable : quand il y a un problème de sécurité. J'ai dû compiler une 5.1 ou une 5.0 en catastrophe suite à la dernière faille liée aux pipelines prédictifs des processeurs Intel.
    Mais bon, je suis une exception.

    • [^] # Re: ... ma distribution est en fait mon OS

      Posté par (page perso) . Évalué à 4 (+2/-0). Dernière modification le 11/09/19 à 15:39.

      La règle que j'applique aujourd'hui est que je place la dernière version EOL du noyau qui précède la stable actuelle. Cela m'évite de compiler plusieurs versions mineures.

      Euh, pourquoi ?
      Il pourrait y avoir des apports intéressants dans une version mineure, voire des corrections de failles.

      La vrai difficulté est de suivre ces modifications et de savoir lesquelles pourraient vous être utiles (selon les architectures, vo applications, les drivers …).

      Et c'est valable pour d'autre OS.

      Par exemple, j'ai des machines sous FreeBSD.12-Stable et je dois suivre les commits sur cette branche pour savoir si oui ou non, ça vaut le peine de prendre le risque de rebooter sur une nouvelle révision.


      En fait, je prend souvent ce risque. parce que même pas peur.
      ( et que zfs send/zfs recv incrémental tous les jours vers une autre machine, aussi.)

      • [^] # Re: ... ma distribution est en fait mon OS

        Posté par . Évalué à 0 (+0/-0).

        C'est uniquement que ça me demande moins de travail inutile.
        J'ai recompilé chaque version sortie pendant des années, mais cela ne servait à rien. La plupart du temps, ces compilations étaient faites pour rien puisque je ne reboote pas derrière. Les serveurs principaux peuvent tourner des mois sans rebooter. Seuls les apports en sécurité me font rebooter essentiellement les frontaux.

  • # Pour contourner un bug matériel

    Posté par (page perso) . Évalué à 4 (+2/-0). Dernière modification le 11/09/19 à 20:52.

    J'ai eu à désactiver une option dans le noyau fourni par ma Mageia, car elle bloquait le boot dans un ordi de 2008 d'un copain. Comme il n'a plus le mot de passe du Bios, je ne peux pas désactiver le périphérique, mais la recompilation du noyau sauve tout!

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # [x] Je voulais backporter/vérifier un patch pour étendre la gestion matérielle dans Debian Buster

    Posté par (page perso) . Évalué à 7 (+6/-0).

    Depuis ce week-end il est possible d'utiliser un Raspberry Pi CM3 (et même CM3+) avec Debian Buster sans avoir à craindre de problème de DTB manquante. Rigolo, le timing du sondage, j'ai publié quelques détails sur la démarche, en anglais et en début de semaine : Adding Raspberry Pi CM3 support to Debian Buster.

    Debian Consultant @ DEBAMAX

  • # Rares limites en dur

    Posté par . Évalué à 1 (+0/-0).

    La dernière fois, c'était pour une des très rares limites en dur à modifier avant la compilation où je risquait la saturation dans mon utilisation, et qu'on ne peut donc pas modifier via /proc ou (/sys|sysctl).

    Sinon de temps en temps pour tuner dans des cas très spéciaux ou encore de temps en temps avoir un gros-binaire sans modules, pour embarquer ou netbooter plus facilement. Mais ça doit être une ou deux fois par an max je pense.

  • # Par flemme ...

    Posté par . Évalué à 1 (+1/-0). Dernière modification le 12/09/19 à 21:24.

    Il y a même pas une semaine, Gentoo oblige.

    • Au début, c'était pour l'optimisation en mode kéké-tuning : "hey regarde je consomme que 100Mo de RAM au boot !"
    • Ensuite je me suis rendu compte que c'est génial d'un point de vue pédagogique : "je sais comment fonctionne mon ordinateur"
    • Puis en esthète minimaliste j'ai essayé d'éliminer le superflu : "les lignes de mon OS sont épurées, c'est beau et facile à nettoyer"
    • Maintenant j'ai juste la flemme. emerge -avDNut world; emerge --depclean -> mettre à jour les paquets et nettoyer cd /usr/src/linux; eselect kernel set 1; cp .config /usr/src/linux; cd /usr/src/linux -> changer la version du noyau mais reprendre l'ancienne conf parce que flemme make -j9; make install; make modules_install -> compiler et installer le nouveau noyau grub-mkconfig -o /boot/grub/grub.cfg -> booter par défaut sur ce noyau Emballé c'est pesé, je n'ai plus le temps d'entretenir ma machine. J'ai passé des mois à la tuner pour optimiser et comprendre, et tout ce temps je l'ai largement regagné à ne pas me poser la question de la MCO. Si, il y a un truc que j'ai dû faire une fois : choisir d'autres drivers lorsque j'ai changé de machine, puis tout recompiler sans réfléchir après un vulgaire copier-coller de la conf du système. C'est tout.

    Et lorsque je retombe ailleurs sur d'autres distros plus classiques, ma p'tite Gentoo me manque très vite, c'est tellement plus simple avec elle. Et le concept de compilation du noyau y est si bien intégré que finalement ce n'est même pas un exploit ou de la magie noire, c'est juste cocher empiriquement des cases après un make menuconfig puis faire un make ; rien de bien sorcier.

    Ou alors c'est juste une question d'habitude.

  • # [X] Pour le boulot.

    Posté par (page perso) . Évalué à 3 (+1/-0).

    Je bosse sur des firmwares pour de l'embarqué.
    Compiler des noyaux fait partie des tâches récurrentes, que ce soit pour tester des optimisations ou pour "releaser" une version de firmware.

  • # 🗹 parce que j’avais écrit un patch

    Posté par (page perso) . Évalué à 5 (+3/-0).

    🗹 j’ai ajouté les identifiants USB d’une manette de jeu pour activer sa prise en charge
    🗹 j’ai changé le profil d’alimentation par défaut d’une carte graphique radeon pour contourner un bug qui semble lié au firmware

    ce commentaire est sous licence cc by 4 et précédentes

  • # [*] Pour le plaisir

    Posté par (page perso) . Évalué à 2 (+1/-0).

    Parce qu'on n'est pas un vrai Geek si t'as jamais compilé ton noyau.

  • # Plusieurs raisons, plusieurs OS :-)

    Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 17/09/19 à 22:15.

    Ma dernière compilation de noyau Linux date de cette année, je crois, au pire de l'année dernière : il s'agit de remplacer le noyau de la distribution utilisée à ${DAYJOB} par un noyau comportant entre autres le patch grsecurity.

    Concernant NetBSD, aussi depuis moins d'un an :
    - en x86_64, recompilation du noyau PV Xen pour inclure NPF directement (brique de filtrage de paquets) ;
    - en armv6 (Raspberry Pi B+), il s'agit d'ajouter la prise en charge de CARP.

    J'avais auparavant recompilé le noyau NetBSD pour armv6 et armv7 (Raspberry Pi 2B) car l'option tun n'était pas activée, ce qui était peu pratique pour OpenVPN. Mais depuis, l'option est activée par défaut je crois.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.