-
je voulais tester ou appliquer un patch :
481(17.5 %)
-
le noyau précompilé de ma distribution ne répondait pas à mes besoins :
538(19.6 %)
-
je voulais minimiser ce qui était inclus, pour des raisons de sécurité :
158(5.7 %)
-
je voulais réduire la durée de démarrage du système :
166(6.0 %)
-
je voulais limiter la consommation de ressources (embarqué par exemple) :
160(5.8 %)
-
ma distribution me l’imposait :
280(10.2 %)
-
rien, je n’ai jamais fait ça :
966(35.1 %)
Total : 2749 votes
# [X] le noyau pré-compilé de ma distribution ne répondait pas à mes besoins
Posté par Sten Spårvagnhög (site web personnel) . Évalué à 10.
… et ça remonte à plus de quinze ans, je crois.
[^] # Re: [X] le noyau pré-compilé de ma distribution ne répondait pas à mes besoins
Posté par bosskev . Évalué à 4.
Exactement pareil, c'était sur Slackware 8.0 !
[^] # Re: [X] le noyau pré-compilé de ma distribution ne répondait pas à mes besoins
Posté par dinomasque . Évalué à 3.
Presque 20 ans de mon coté. A l'époque je n'avais pas encore BeOS et il "fallait" recompiler son noyal pour avoir les bons pilotes de périphériques.
Je met des guillemets parceque hors quelques cas particuliers, le système de modules (dé)chaegeables à chaud marchait déjà plutôt bien et du coup recompiler son noyal servait pas mal de benchmark/concours de bite (surtout pour ceux qui frimaient avec leur bi-céléron).
BeOS le faisait il y a 20 ans !
[^] # Re: [X] le noyau pré-compilé de ma distribution ne répondait pas à mes besoins
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Je crois même que c'est encore plus vieux pour moi, c'était avant Mandrake 5.1
De 1995 à 1997, il fallait recompiler le noyau quand on ajoutait un périphérique. C'était le moyen-âge informatique…
[^] # Re: [X] le noyau pré-compilé de ma distribution ne répondait pas à mes besoins
Posté par Gauthier Monserand (site web personnel) . Évalué à 2.
idem ça date maintenant, pour lfs puis gentoo. à l'époque surtout pour découvrir les options avancées du réseau.
[^] # Re: [X] le noyau pré-compilé de ma distribution ne répondait pas à mes besoins
Posté par Graveen . Évalué à 3.
Idem, il y a 20 ans. Il y a 2 ans j'étais chaud pour le faire sur une RPi mais un stackoverflow m'a rensigné sur le fait que c'était inutile :D
[^] # Re: [X] le noyau pré-compilé de ma distribution ne répondait pas à mes besoins
Posté par freejeff . Évalué à 2.
Moi ça date aussi, ça remonte à quand le RT_PREMPT n'était pas encore fonctionnel et qu'il faillait se panner la compilation du Linux et RTAI, j'en ai encore des sueurs froides …
[^] # Re: [X] le noyau pré-compilé de ma distribution ne répondait pas à mes besoins
Posté par Olivier LAHAYE (site web personnel) . Évalué à 1.
C'étais sur Amiga 3000; recompilation du noyau NetBSD pour écriture du driver retina3
Puis linux pour ajouter le support de je sais plus quoi sur un pentium90 (driver modem 14400K??? ou carte réseau 10Mb/s BNC???)…
Depuis….je n'ai jamais eu besoin de recompiler le noyau. J'ai just créer un ou deux dkms il y a plus de 10ans pour le flasheur de cartouche gameboy advance (EZ Flash) et reconstruit quelques dkms nvidia, mais rien de plus.
# Android
Posté par raphj . Évalué à 7. Dernière modification le 09 septembre 2019 à 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 Clockover . Évalué à 6.
Simplement par geekerie et optimisation. :)
Ca remonte à du Debian Potato ou Woody
# C'était juste pour voir
Posté par xavier philippon . Évalué à 3. Dernière modification le 09 septembre 2019 à 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 ;-)
[^] # Re: C'était juste pour voir
Posté par Yves Bourguignon . Évalué à 3.
Pareil (et même distro). Pour voir et pour savoir le faire. Et donc j'aurai voté pour cet intitulé « c'était juste pour voir »…
# Il manque un choix...
Posté par Megagolgoth . Évalué à 10.
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 fasthm . Évalué à 6.
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 benoitb85 . Évalué à 2.
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 orgon . Évalué à 2.
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 verdesroches (site web personnel) . Évalué à 2.
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 Nibel . Évalué à -1.
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 Pierre Tramal (site web personnel) . Évalué à 8. Dernière modification le 10 septembre 2019 à 11:35.
Hein ?! Je suis sous Arch et je récupère un binaire à chaque nouveau noyal (paquet linux).
[^] # Re: Arch
Posté par Nibel . Évalué à 5. Dernière modification le 10 septembre 2019 à 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 Anonyme . Évalué à 3.
après sous Arch, on n'est à l'abri de rien !
[^] # Re: Arch
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 1.
Est-ce que tu ne confonds pas avec la génération de l'initramfs ? Via la commande mkinitcpio ?
[^] # Re: Arch
Posté par damaki . Évalué à 2.
Ou la compilation des modules tiers ?
# C’était pour alléger…
Posté par Yves (site web personnel) . Évalué à 5.
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 ekyo . Évalué à 1.
Pour un petit netbook sous cherry trail, le asus x205ta qui était inutilisable sans noyau personnalisé.
# Compilation noyau Linux : curiosité !
Posté par Marius . Évalué à 2.
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.
# Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
# je voulais limiter la consommation de ressources
Posté par ll0zz (Mastodon) . Évalué à 4.
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 Psychofox (Mastodon) . Évalué à 3. Dernière modification le 10 septembre 2019 à 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 anaseto . Évalué à 4.
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 j-landru . Évalué à 4.
… 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 Faya . Évalué à 5.
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 titinux . Évalué à 3.
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 N-Mi . Évalué à 3.
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 Florent Zara (site web personnel, Mastodon) . Évalué à 5.
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 Rafael (site web personnel) . Évalué à 2.
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 paulez (site web personnel) . Évalué à 5. Dernière modification le 10 septembre 2019 à 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 Rafael (site web personnel) . Évalué à 3.
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 Anthony Jaguenaud . Évalué à 5.
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 paulez (site web personnel) . Évalué à 3.
Tout à fait je rebondissais seulement sur:
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 deuzene (site web personnel) . Évalué à 5. Dernière modification le 11 septembre 2019 à 17:56.
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 AlexTérieur . Évalué à 3.
Les 3 à la fois. Des tests sur Raspberry Pi avec Gentoo.
# … C'était mon boulot
Posté par David Marec . Évalué à 5. Dernière modification le 10 septembre 2019 à 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 ookaze . Évalué à 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 David Marec . Évalué à 4. Dernière modification le 11 septembre 2019 à 15:39.
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 ookaze . Évalué à 1.
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 ʭ ☯ . Évalué à 4. Dernière modification le 11 septembre 2019 à 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 Cyril Brulebois (site web personnel) . Évalué à 7.
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
[^] # Re: [x] Je voulais backporter/vérifier un patch...
Posté par Jean Parpaillon (site web personnel) . Évalué à 0.
…parce qu'il n'y pas de noyau Kerrighed dans Debian :)
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
# Rares limites en dur
Posté par tao popus . Évalué à 1.
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 inky-full-bash . Évalué à 2. Dernière modification le 12 septembre 2019 à 21:24.
Il y a même pas une semaine, Gentoo oblige.
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.
[^] # Re: Par flemme ...
Posté par Gauthier (Mastodon) . Évalué à 2.
Ça donnerai presque envie de s'y remettre.
J'étais fan de Gentoo pendant de nombreuses années. Mais j'ai arrêté par manque de temps.
[^] # Re: Par flemme ...
Posté par Sufflope (site web personnel) . Évalué à 5.
Oui on voit ça. Moi je fais
dnf upgrade
.# [X] Pour le boulot.
Posté par LaBienPensanceMaTuer . Évalué à 3.
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 Thomas Debesse (site web personnel) . Évalué à 6.
🗹 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 Snarky . Évalué à 2.
Parce qu'on n'est pas un vrai Geek si t'as jamais compilé ton noyau.
# Plusieurs raisons, plusieurs OS :-)
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 17 septembre 2019 à 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.
# La dernière fois
Posté par 41px . Évalué à 1.
C'était quand j'installais PengAOL chez mes parents. Puis la raie Wanadoo … pendant que mes potes d'irc étaient chez Nerim …
# Tout (macchiatobin + Gentoo)
Posté par alpha_one_x86 (site web personnel) . Évalué à 3. Dernière modification le 19 septembre 2019 à 15:26.
Tout en fait:
- je voulais tester ou appliquer un patch
- le noyau précompilé de ma distribution ne répondait pas à mes besoins : j'avais besoin de certain module noyau (réseau pas actif par défaut)
- je voulais minimiser ce qui était inclus, pour des raisons de sécurité : moins de code, moins de 0day
- je voulais réduire la durée de démarrage du système : noyau + léger à charger de la uSD
- je voulais limiter la consommation de ressources (embarqué par exemple) : - de drivers, voir des parties entière du noyau en moins (comme la partie graphique), ca aide
- ma distribution me l’imposait: + 10 ans sous Gentoo, à peu prêt sur tout les matos (x86, ARM, MIPS, RISC-V) inclut un Fit PC1 (AMD Geode à 500Mhz 256MB mémoire) et RPI1 (700 MHz ARM1176JZF-S + 256MB mémoire)
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
# La dernière fois, je ne sais plus. Mais la première, si !
Posté par Vincent Danjean . Évalué à 4.
La première fois que j'ai compilé un noyau linux, je m'en souviens encore.
J'avais découvert Linux en classe prépa : une salle entière, en libre service, avec du réseau (local + lien vers le rectorat/monde en modem), des droits sur les répertoires/fichiers, du NFS, … et ça ne plantait pas. On y faisait les TPs (Maple puis Camllight avec emacs) et on pouvait utiliser un navigateur graphique pour aller sur le WEB (Mosaic).
Chez moi, j'avais déjà eu des ordis. Mon premier avait été un Atari STE 1040 (conseillé par un vendeur Mac/Atari avec Notator — concurrent de cubase — car je voulais faire de la musique MIDI) puis j'étais passé au Falcon 030 (et Notator Logic pour la musique).
Le Falcon 030 pouvait recevoir une carte d'extension le transformant en 80286 (ce qui m'avait permis de faire tourner Pascal en terminal pour faire mes TP de mon option informatique). Mais en découvrant Linux en prépa, je voulais tester chez moi. Et Linux nécessitait au minimum un 80386…
Mais bon, le Falcon avait, de base, un 68030 qui était censé être supporté par Linux. Sauf qu'il avait besoin du coprocesseur d'arithmétique flottante, qui n'était pas dans le Falcon 030. Cela dit, on trouvait des patches (non libres de mémoire) permettant au noyau d'intercepter les traps et d'émuler le coprocesseur. Cool. Sauf que ce patch n'était pas présent dans les binaires disponibles.
Ma première compilation du noyau Linux a donc consisté en une cross-compilation sur les ordis du lycée (x86) d'un noyau 68030 avec un patch appliqué. Le truc le plus simple du monde… Il m'a fallu plusieurs semaines, voire mois (je compilais en semaine au lycée et testait le WE chez moi…) mais ça a fini par marcher.
Je me souviens aussi que je voulais utiliser Debian qui devait sortir incessamment sous peu pour 68030. C'est là que j'ai découvert le "on release quand c'est prêt" : quand Hamm est finalement sorti, ça faisait plusieurs mois que tournait sous Slackware…
[^] # Re: La dernière fois, je ne sais plus. Mais la première, si !
Posté par Maclag . Évalué à 10.
Ma première compilation de noyau, c'était aussi en prépa (intégrée à l'école d'ingé), mais c'était bien plus ridicule que ça.
J'ignorais totalement jusqu'à l'existence de Linux
À l'époque, j'avais eu un Thomson TO8 à la maison puis un Amstrad 1512 (double lecteur de disquette 5"25 s'il vous plait!), et j'avais un PC monté maison avec un Pentium60 (sans le bug, j'y tenais, mais sans trop savoir ce que ça voulait dire non plus).
Le club informatique de l'école d'ingé organisait un achat groupé de RedHat pour les passionnés. Je me suis laissé tenté (c'était pas cher et ils en faisaient tellement d'éloges avec pleins de mots que je ne comprenais pas, ça avait l'air trop cool…).
Bref, j'ai suivi méticuleusement tous le manuel qui venait avec, toujours sans trop comprendre ce que je faisais. Et juste après l'installation, il y avait un guide de recompilation du noyau.
J'ai donc recompilé le noyau.
Pas parce que j'avais besoin d'enlever des trucs.
Pas parce que j'avais besoin de rajouter des trucs.
Pas parce que j'avais besoin de modifier des trucs.
Juste parce que c'était juste après le guide d'installation et je pensais que ça faisait partie de la procédure normale post-installation…
Aujourd'hui encore, j'espère avoir fait la première compilation de noyau en mode Forrest Gump de l'histoire. \o/
N'empêche que ça m'aura évité ensuite l'appréhension face au "truc d'expert super compliqué et pas à ta portée":
"ah ben non, moi je l'ai recompilé presque sans faire exprès! ç'pas dur!".
# Ma boîte me l'imposait
Posté par elf32 . Évalué à 1.
Parce que ma boîte faisait bosser leurs devs avec Gentoo, donc il fallait compiler le noyau (ou voler la config d'une autre distro déjà existante, ce que je n'ai pas fait) au moment d'installer sa machine de travail.
Mais c'était cool, j'ai appris des trucs.
# Arch LTS maintenant
Posté par Maderios . Évalué à 1. Dernière modification le 15 octobre 2019 à 17:10.
Sur Arch, Un noyau "ancien" Aur LTS peut servir lors des changements de version LTS, par exemple lors de la future transition linux-lts 4.19.xx à linux-lts 5.4.xx
Explication: sur Arch, les premières versions LTS sont trop jeunes pour moi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.