Articles précédents : Code
- [11] Busybox 1.0
- [101] John Carmack victime des brevets logiciels
- [154] Le code de Java3D est disponible
- [26] GFS à nouveau en GPL et résultats financiers de Red Hat
- [79] Linux VServer, pour ceux qui ne connaissent pas...
- [34] XFS inclus dans le noyau 2.4
- [48] Alsa-Project : Tout va très vite....
- [146] Tentative d'insertion d'une porte dérobée dans le noyau Linux
- [83] SCO enfonce le clou.
- [40] Relic Entertainment ouvre le code source de Homeworld
Liens connexes
- Présentation (1938 hits)
- CD de démo (à tester avec Qemu par exemple) (621 hits)
- Autres Bellarderies (1591 hits)
Dépêche modérée par
Dépêche éditée par
Code : « Autocompiler » son noyau au démarrage avec TCCBoot
Posté par David Decotigny (page perso, ). Modéré le 27 octobre 2004.Ça ne sert à rien mais c'est beau !
Présentation (1938 hits)
CD de démo (à tester avec Qemu par exemple) (621 hits)
Autres Bellarderies (1591 hits)
> Lire la dépêche (60 commentaires, moyenne: 3,1).
plop
-
[^]Re: plop
Posté par Benjamin G. ( Prae ) (page perso, ) le 27/10/2004 à 12:05. (lien). Évalué à 10.« Rigoureusement inutiles donc absolument indispensables »
-- Jérome Bonaldi, NPA 1999
Ce grand philosophe des catastrophes live'ienne :)-
[^]Re: plop
Posté par Seazor (Jabber id, ) le 27/10/2004 à 13:41. (lien). Évalué à 5.Si mes souvenirs sont bons...
- il était dans les premiers arrivés dans NPA, il devait avoir sa propre émission le midi vers 1999 => Ca doit dater de vachement plus tot !!
- C'est : "Totallement inutile donc rigoureusement indispensable"
Note : Il a surement du en faire qq variantes ;-)
Respect pour le plus grand disciple de Murphy :)
De plus, il continue de se meler de tout à notre plus grand plaisir : https://linuxfr.org/2004/10/21/17476.html(...)--
"We all freezed on a bugged subroutine, bugged subroutine, bugged subroutine..." (nearly Beatles)
-
[^]Re: plop
Posté par tgl () le 27/10/2004 à 14:01. (lien). Évalué à 8.Si la compile du noyau au boot semble effectivement assez futile, tcc lui même ne l'est pas :
Ça ça peut clairement avoir des vraies applications. À noter aussi que tcc inclue un memory & bounds checker (un machin pour vérifier qu'on se gauffre pas dans l'utilisation des tableaux et pointeurs), ce qui fait défaut à gcc (enfin pas vraiment, le patch est là : http://web.inter.nl.net/hcc/Haj.Ten.Brugge/(...) ). Et ça, c'est Bien™.- C script supported : just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line.
- With libtcc, you can use TCC as a backend for dynamic code generation.
-
[^]Re: plop
Posté par nicolassanchez () le 27/10/2004 à 16:30. (lien). Évalué à 5.C script supported : just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line.
Ça ne doit pas être bien compliquer à faire avec gcc ça...
Avec un bon petit script qui supprime la première ligne du fichier et qui compile puis exécute dans un répertoire temporaire, y'a rien d'exceptionnel...
With libtcc, you can use TCC as a backend for dynamic code generation.
Ça parcontre, ça semble plus intéressant, bien que, avec un script du même style, tu recompiles tes sources et tu charges le merdier avec un dlopen...-
[^]Re: plop
Posté par Damien Metzler () le 27/10/2004 à 17:00. (lien). Évalué à 6.Y'a un journal y'a longtemps où on avait donné plusieurs méthodes avec une ligne de shell :
http://linuxfr.org/~Salagnac/4500.html(...)-
[^]Re: plop
Posté par nicolassanchez () le 27/10/2004 à 17:31. (lien). Évalué à 0.Et dire que je me cassais le cul pour le refaire...
-
-
-
Débugage
Limite, ça peut être pratique pour le débuguage. Un fichier pose problème? On monte l'image, on édite, on démonte puis reboot. Encore un pb, idem...
Mon JID est yannbng@jabber.fr
-
[^]Re: Débugage
-
[^]Re: Débugage
Posté par Pooly (page perso, ) le 27/10/2004 à 22:14. (lien). Évalué à 5.mais on peut pas encore avoir un noyau totalement en userland ou le boot est inutile ? (hurd ? :)
-
[^]Re: Débugage
Posté par Christophe Lucas (page perso, ) le 28/10/2004 à 07:35. (lien). Évalué à 4.usermode-linux (UML)
ou encore des trucs comme bochs ou qemu.--
- Christophe -
-
CD live ?
À quand un CD live avec OOo, KDE, y tout, qui se compile au boot ?
-
[^]Re: CD live ?
Posté par Laurent Mouillart (page perso, ) le 27/10/2004 à 12:16. (lien). Évalué à 10.Ah il marche pas comme ça le live CD de gentoo ? je suis deçu ...
-
[^]Re: CD live ?
Posté par Nap (page perso, ) le 27/10/2004 à 13:06. (lien). Évalué à 3.c'est malin, j'ai éclaté de rire comme un con devant mon écran
-
[+] [^]Re: CD live ?
Posté par Tuxmym () le 27/10/2004 à 13:21. (lien). Évalué à -5.Certes c'est très drôle, mais doit-on plusser le caractère comique d'un commentaire ou son coté pertinent relativement à l'article ?
-
[^]Re: CD live ?
Posté par Raphaël Maurel-Segala () le 27/10/2004 à 13:34. (lien). Évalué à 8.doit-on plusser le caractère comique d'un commentaire ou son coté pertinent relativement à l'article
... Ou, pourquoi pas, le plusser pour son caractère comique relativement à l'article ?
Ce qui pose la grande question : le comique contextuel existe-t-il? "Oui !", répondront en masse les Desprogiens. ("42", s'exclameront les lecteurs peu attentifs)
Bref, dans la veine comique, c'est tout de même F. Bellard qui a commencé, non ?-
[^]Re: CD live ?
Posté par Clément Canonne (page perso, ) le 27/10/2004 à 14:42. (lien). Évalué à 2.Ce qui pose la grande question : le comique contextuel existe-t-il? "Oui !", répondront en masse les Desprogiens. ("42", s'exclameront les lecteurs peu attentifs)
Ook.
N'empêche, ça peut être relativement utile pour frimer devant ses copains, ça : "je recompile mon noyau toutes les semaines, ça m'évite de rouiller" :P--
"La route est droite, mais la panthère rose."-
[^]Re: CD live ?
Posté par Vincent Pelletier () le 27/10/2004 à 19:03. (lien). Évalué à 3.De toute façon, n'est-on pas sensé ne rebooter que pour changer de noyau ? :)
De ce point de vue là, ça économise des lignes de shell, ce genre de programme/concept.
Il pourrait même être bon d'intégrer ce genre de truc dans les bécanes pour parfaire la portabilité : le bios ou équivalent compile un bootloader qui se charge de charger et/ou compiler la suite, etc.-
[^]Re: CD live ?
Posté par Clément Canonne (page perso, ) le 27/10/2004 à 19:14. (lien). Évalué à 1.Oui, enfin, bon, je suis quand même pas un pur, un dur, un tatoué : ça m'embêterait que mon noyau se recompile chaque fois qu'il y a une coupure de courant !
Comment ça, "petit joueur" o_O ?:-D--
"La route est droite, mais la panthère rose."
-
-
-
[^]Re: CD live ?
Posté par Ramso (page perso, ) le 27/10/2004 à 16:06. (lien). Évalué à 4.> Ce qui pose la grande question : le comique contextuel existe-t-il?
Ben oui, c'est le comique de situation.--
Groar !
-
-
[^]Re: CD live ?
Posté par Tuxmym () le 28/10/2004 à 07:44. (lien). Évalué à 1.Je vois que certains utilisateurs de linuxfr ont du mal à s'exprimer avec des mots pour répondre à une question pas très compliquée et préfèrent moinser, ça doit faire partie du coté comique... "Moi moinser ! é Rigolo !"
Merci Mercurial de t'être réellement posé la question.
-
-
-
[^]Re: CD live ?
Posté par Jimmy (page perso, ) le 27/10/2004 à 17:42. (lien). Évalué à 7.Il y a déjà un live CD qui contient TCC (mais qui ne s'autocompile pas). Il s'agit de Damn Small Linux (http://damnsmalllinux.org(...)), le live-CD de moins de 50Mo. Et quand on le copie en RAM, ca booooste !
Pour ceux qui auraient raté les épisodes précédents, je précise que le Sieur Bellard code comme un malpropre : il avait en effet remporté l'IOCCC (pour la seconde fois) avec la première version de TCC ;-)
Et en plus, dans la catégorie "best abuse of the rules" ! Respect.
http://ioccc.org(...)
http://www.de.ioccc.org/years.html#2001_bellard(...)
Vive le C !!
Ca sert a prouver que le C c'est cool.
c'est tellement hasbeen de ne pas utiliser de templates de nos jours .. Moi je m'en vais customiser le noyau avec la STL, histoire de rajouer un peu de temps au temps au boot.
-
[^]Re: Vive le C !!
Posté par 007 () le 27/10/2004 à 12:15. (lien). Évalué à 0.Juste pour info, ton noyau tourne sur une VM ?
-
[^]Re: Vive le C !!
Posté par zeSixty4Douille () le 27/10/2004 à 12:28. (lien). Évalué à 3.yes ofcourse, il depend de .NET, mais il est portable, dans un disque dur .. (VM = Machine virtuelle ??)
-
-
[^]Re: Vive le C !!
Posté par zeSixty4Douille () le 27/10/2004 à 15:37. (lien). Évalué à 0."-4" pour dire que le C c'est cool, ca laisse reveur.
J'ai pas dit que la STL puait, la j'aurais certainement tord. Je sous entends simplement que c'est parfois long a compiler. Vous pouvez toujours moinsser, mais c'est un fait. Une forward declaration avec les Standard iostreams, c'est 3000 ligne de header quand meme ...
Fabrice Bellard
Quand je vois le travail de Fabrice Bellard, je suis à la fois admiratif et jaloux... Qemu, TCC, Qemacs, FFMPEG et maintenant TCC Boot ...
Incroyable.
-
[^]Re: Fabrice Bellard
Posté par Ph Husson (page perso, ) le 27/10/2004 à 12:45. (lien). Évalué à 2.Ué une fois j'etais passé sur sa page d'accueil
Deja qemu tt seul j'etais impressionné
page d'accueil:
qemu & ffmpeg & plein de "petits" trucs a cote
et maintenant ca
pour moi c'est un dieu lui!
J'exagere ptet un tantinet mais quand meme-
[^]Re: Fabrice Bellard
Posté par Frédéric Lopez () le 27/10/2004 à 14:32. (lien). Évalué à 3.Et je crois que ça date pas d'hier, il me semble avoir utilisé il y a longtemps un éditeur télétexte écrit par lui pour faire des pages pour un serveur RTC. Je sais plus comment s'appellait l'appli par contre.
-
-
[^]Re: Fabrice Bellard
Posté par Olivier Jeannet () le 27/10/2004 à 18:36. (lien). Évalué à 5.Quand je vois le travail de Fabrice Bellard, je suis à la fois admiratif et jaloux... Qemu, TCC, Qemacs, FFMPEG et maintenant TCC Boot ...
J'ai connu par hasard ce type qui était un camarade de mon frère. En 1995 on était allé dans sa chambre d'étudiant, où j'avais vu mon premier Linux, il tournait sous X11 et j'avais été impressionné par quelques démos, voire des jeux (à l'époque j'étais sur Amiga, et là sur Linux on pouvait bouger une fenêtre et le contenu continuait à se rafraîchir).
Quand j'avais lu dans une revue scientifique qu'un record concernant les décimales de Pi était tombé (avec un développement en série original, en binaire), j'ai vu son nom et je m'étais demandé si c'était le même; eh bien oui ! Cf http://fabrice.bellard.free.fr/pi/(...) et "A world record ! The 1000 billionth binary digit of Pi is '1'".
Ce type est impressionnant de productivité, ffmpeg est déjà un beau morceau.
Impressionnant !
Ce qui est beau surtout, c'est que le compilateur TCC peut compiler un noyau Linux classique en moins de 15 secondes sur un Pentium 2.4Ghz [1]. Personnellement, un noyau Linux configuré par défaut sous Slackware sur mon Duron 800, ça se compte en dizaine minutes, forcément j'ai du mal à imaginer qu'en 15 secondes on puisse compiler un noyau :)
Par contre, il n'est pas mentionné dans la nouvelle que TCC ne compile pas le noyau tel quel : il faut auparavant lui appliquer quelques correctifs pour le rendre compilable par TCC.
[1] http://fabrice.bellard.free.fr/tcc/tccboot.html(...) : « TCCBOOT is only 138 KB big (uncompressed code) and it can compile and run a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4. »
-
[^]Re: Impressionnant !
Posté par liberforce (Jabber id, page perso, ) le 27/10/2004 à 12:54. (lien). Évalué à 2.M'enfin, quels sont les inconvénients de TCC pour qu'il n'ait pas remplacé GCC ? Il y en a forcément, non, ce serait trop simple...
Quelqu'un a une idée ?-
[^]Re: Impressionnant !
Posté par Larry Cow () le 27/10/2004 à 13:06. (lien). Évalué à 7.GCC n'est pas qu'un compilateur C, mais une suite de compilation "générique" qui sait également bouffer du C++, du Java, du Fortran, ...
Et puis aussi, des choses comme ça:
TCC implements many features of the new C standard: ISO C99. Currently missing items are: complex and imaginary numbers and variable length arrays.
Et enfin le fait que, si TCC est léger et compile vite, il n'est pas garanti du tout que le code produit soit plus efficace que celui écrit par GCC.
TCC est une très jolie démonstration du savoir-faire du monsieur (même si QEmu et FFMpeg sont plutôt plus significatifs, à mon avis), ainsi qu'un outil de plus dans la malette de l'utilisateur de logiciel libre. Un outil qui peut s'avérer utile dans certains cas, peu fréquents certes, mais qui mérite tout de même d'exister.
-
[^]Re: Impressionnant !
Posté par Ramso (page perso, ) le 27/10/2004 à 16:07. (lien). Évalué à 3.Au hasard, que GCC fonctionne sur un cinquantaine d'architectures ?
(Je dis ça au pif.)
Tiens ça me rappelle des discu^Wtrolls sur Debian...--
Groar !
-
-
[+] [^]Re: Impressionnant !
Posté par 007 () le 27/10/2004 à 12:58. (lien). Évalué à -5.> TCC peut compiler un noyau Linux classique en moins de 15 secondes
Un noyau classique... C'est celà oouuiii...
> TCCBOOT is only 138 KB big (uncompressed code)
Ben ici le tar décompressé de Linux 2.6.9 fait 196 Mo ! Plus de mille fois plus.
Rien que pour lire l'archive (un gros fichier et pas des milliers de fichier) en 15 seconde il faut la "bouffer" à plus de 10 Mo/s.-
[^]Re: Impressionnant !
Posté par Ph Husson (page perso, ) le 27/10/2004 à 13:03. (lien). Évalué à 0.quand tu compile le noyau tu compile *TOUT*?
Et pis bon faut voir ce qu'il compile
S'il compile à partir des sources deja compilé
et rajoute une option
Prendre 15s c'est plus que possible-
[+] [^]Re: Impressionnant !
Posté par 007 () le 27/10/2004 à 13:27. (lien). Évalué à -4.> Prendre 15s c'est plus que possible
Pour un noyau "classique" comme c'est indiqué ?
Mon vmlinuz (compressé) "classique" (de la distribution) fait 1.4 Mo et j'ai 31 Mo de modules.
Mon vmlinuz au petit oignons fait 930 Ko et j'ai 2.5 Mo de modules. 15 secondes pour mon noyau customiser, je n'y crois pas 0,0002 quart de seconde.
Arrêter les cigarettes qui font rire.
-
-
[^]Re: Impressionnant !
Posté par zeSixty4Douille () le 27/10/2004 à 13:07. (lien). Évalué à 1.ce doit etre sans les modules. Chez moi, avec uCLinux, le noyau n'est que de 800ko, les sources conscernees ne doivent pas representer tellement plus.
-
[^]Re: Impressionnant !
Posté par Laurent Mouillart (page perso, ) le 27/10/2004 à 13:08. (lien). Évalué à 1.Marrant moi mon noyau fait ~3.5Mo non compresser (et pas 196), a mon avis tu as confondu avec le code source du noyau.
-
[^]Re: Impressionnant !
Posté par Chl (page perso, ) le 27/10/2004 à 13:10. (lien). Évalué à 6.Rien que pour lire l'archive (un gros fichier et pas des milliers de fichier) en 15 seconde il faut la "bouffer" à plus de 10 Mo/s.
Oui, sauf qu'un compilateur ne lit pas des archives, mais des fichiers .c par exemple. De plus, pour compiler un noyeau pour une archi, certains fichiers ne vont pas etre lu par le compilateur, par exemple les fichiers des autres architectures.
Enfin, voici les resultats de TCC pris de http://fabrice.bellard.free.fr/tcc/(...) :
Compiler Time(s) lines/second MBytes/second
TinyCC 0.9.14 12.1 134000 4.8
GCC 2.95.2 -O0 103.0 16000 0.56
GCC 3.2 -O0 111.4 15000 0.52
Measures were done on a 500 MHz K6. Real time is measured. Compilation time includes compilation, assembly and linking.
Donc avec une machine plus recente, il doit surement etre possible d'aller au dela des 4.8MB/s.-
[+] [^]Re: Impressionnant !
Posté par 007 () le 27/10/2004 à 13:39. (lien). Évalué à -2.Pour :
- Compilation speed for the Links Browser project. There are 76936 lines (including headers). 1632659 lines (57.9 MBytes) are compiled because the same headers are included in many files.
Notes que _tout_ tient dans le cache.
Ça doit beaucoup jouer sur le temps de chargement de gcc.
Le 4.8 Mo/s est en tenant compte de la _relecture_ des entêtes.
Soit (sans compter la relecture des headers) : 0.226 Mo/s (beau score) !
Pour Linux (en imaginant qu'on peut extrapoler car Linux est beaucoup plus complexe que links) à ce rythme, il faut 867 secondes (14 minutes et 27 secondes).
Je ne critique pas TCC, c'est peut-être un truc super. Mais il ne faut pas "n'importe quoi".
-
-
[^]Re: Impressionnant !
Posté par tgl () le 27/10/2004 à 13:39. (lien). Évalué à 3.> Rien que pour lire l'archive (un gros fichier et pas des milliers de
> fichier) en 15 seconde il faut la "bouffer" à plus de 10 Mo/s.
Nan mais je suppose qu'on parle là de temps CPU, sans les IO. Après tout, c'est ça qui compte pour comparer les perfs d'un compilo ; tu comptes juste le parsing et la génération du code binaire.
(Enfin en simplifiant, parceque en fait des compilateurs peuvent aussi se différencier avec des astuces limitant entre autres les IO redondantes, comme les multiples relecture d'un même header.)
-
[^]Re: Impressionnant !
Posté par L (page perso, ) le 27/10/2004 à 14:09. (lien). Évalué à 5.> Ben ici le tar décompressé de Linux 2.6.9 fait 196 Mo ! Plus de mille fois plus. Rien que pour lire l'archive (un gros fichier et pas des milliers de fichier) en 15 seconde il faut la "bouffer" à plus de 10 Mo/s.
J'ai téléchargé les sources qui sont fournies avec un .config et un correctif pour le noyau 2.4.26. Donc déjà il ne s'agit pas d'un noyau 2.6.x mai d'un noyau 2.4. D'autre part, je pense personnellement, vu les travaux de Mr Bellard, qu'il n'a rien à prouver à qui que ce soit et que ça le desservirait grandement de tricher sur un résultat vérifiable par quiconque s'en donne les moyens (et possède un Pentium 4 tournant au moins à 2.4 Ghz). En définitive, à moins que tu puisses prouver qu'il ait menti, abstient toi de dénigrer gratuitement son travail.-
[^]Re: Impressionnant !
Posté par 007 () le 27/10/2004 à 15:00. (lien). Évalué à 4.> abstient toi de dénigrer gratuitement son travail.
Où tu vois ça ?
Je dis qu'il ne faut pas 15 secondes pour compiler un noyau linux classique.
Je suis sûr que TCC ne fait pas ça.
L'image initrd décompressée avec les sources linux à compiler fait 18Mo (compilateur compris) ! Linux en fait 10 fois plus.
Les sources dans l'image font : 399 742 (251 fichiers ".c")
Linux 2.6.9 (non, je ne vais pas downloader le 2.4.18 pour ça) : 6 463 002 (6841 fichiers ".c")
Le README :
http://fabrice.bellard.free.fr/tcc/tccboot_readme.html(...)
- For your information, the patch 'linux-2.4.26-tcc.patch' gives the
necessary modifications to build a Linux kernel with TCCBOOT (NOTE: it
is not suffisant to build the kernel with its own Makefiles - I never
tried)
Voilà comment est compilé le noyau :
- # This file contains the TinyCC command line arguments needed to
# produce the kernel.
# the output binary (DO NOT CHANGE IT)
-o kernel
# LDFLAGS
-nostdlib -static -Wl,-Ttext,c0100000 -Wl,--oformat,binary
# CFLAGS
-D__KERNEL__ -nostdinc -Iusr/local/lib/tcc/include -Iusr/src/linux/include
-D__GNUC__=2 -D__GNUC_MINOR__=95 -D__OPTIMIZE__ -fno-common
# sources files
usr/src/linux/tcc/kstart.S
usr/src/linux/arch/i386/kernel/head.S
usr/src/linux/arch/i386/kernel/init_task.c
...
Pas de dépendances, etc...
Je ne critique pas son boulot _ni_ ne remets en cause ses chiffres, _ni_ sont exploit !
Par contre l'interprétation de certains "Super, je vais pouvoir compiler mon noyau en 15 seconde avec TinyCC" m'énerve.
C'est chiant de devoir toujours se justifier pour des trucs aussi évidents.-
[^]Re: Impressionnant !
Posté par Chl (page perso, ) le 27/10/2004 à 15:07. (lien). Évalué à 5.C'est chiant de devoir toujours se justifier pour des trucs aussi évidents.
Si tu t'exprimais correctement aussi ... les gens te comprendraient.
Tu es un incompris.-
[^]Re: Impressionnant !
Posté par 007 () le 27/10/2004 à 15:12. (lien). Évalué à 2.> Si tu t'exprimais correctement aussi ... les gens te comprendraient.
J'ai été claire (il me semble).
La différence c'est que les autres disent qu'il est normal de compiler un noyau "classique" en 15 secondes et n'ont pas à le prouver.
Moi je dois prouver noir sur blanc que ce n'est pas possible alors que c'est évident.
Cherchez l'erreur.-
[^]Re: Impressionnant !
Posté par 桃白白 (page perso, ) le 27/10/2004 à 15:31. (lien). Évalué à 4.J'ai été claire (il me semble).
Je croyais que tu etais 007.
-
[^]Re: Impressionnant !
Posté par Guillaume Knispel () le 27/10/2004 à 18:19. (lien). Évalué à 2.Bah ca a rien d'impressionnant de compiler aussi rapidement, maintenant c'est sur que le code généré est surrement tres tres peu optimisé. Je me souviens que Turbo C etait ultra rapide sur un 486 avec un cache disque quand je codais sous DOS.
Quand a savoir ce qu'il faut à un noyau pour etre classique...
-
-
-
[^]Re: Impressionnant !
-
-
-
Pas moi!
Je sais que c'est une blague mais "À ceux qui trouvent que le noyau Linux démarre bien trop vite", je n'en fais pas parti: apres avoir testé BeOS qui mettait ~20s pour arriver en mode graphique contre 1+min pour Linux (avec KDE, j'ignore si Gnome démarre plus vite)..
C'était sur un Céléron 333 à l'époque, mais bref, je ne trouve pas que Linux demarre trop vite!
Et BeOS ne trichait pas comme WindowsXP: il était immédiatement utilisable dès que l'interface graphique donnait la main..
-
[^]Re: Pas moi!
Posté par Romuald Delavergne () le 27/10/2004 à 13:29. (lien). Évalué à 3.Ici on parle du noyau Linux. C'est à dire juste avant le démarrage du premier process ('init' ou 'linuxrc' pour une ramdisk).
-
[^]Re: Pas moi!
Posté par Pooly (page perso, ) le 27/10/2004 à 22:22. (lien). Évalué à 2.Si tu vire tout les trucs absolument inutile, tu peux réduire le temps de boot, 30s pour une LFS brute de décoffrage (bon sans KDE, juste X et oroborus) sur un Duron 600
-
[^]Re: Pas moi!
Posté par reno () le 28/10/2004 à 05:35. (lien). Évalué à 2.Bin oui, mais être "juste", il faut comparer des choses comparables..
Je trouve que le desktop de BeOS et KDE sont a peu pres équivalent, j'avoue ne pas connaitre oroborus..
Et puis pour BeOS je n'avais rien eu à faire, pas de recompilation rien, pas de daemon à virer, ce qui est quand même différent d'une LFS.
-
[^]Re: Pas moi!
Posté par Frédéric (page perso, ) le 29/10/2004 à 20:34. (lien). Évalué à 1.Concernant le temps de boot, pour mon juke-box de voiture il y a +/- 35 secondes entre le moment où le PC s'allume et le moment où il joue le premier morceau.
Là où il perd le plus de temps, c'est dans le BIOS et dans syslinux lors du chargement du kernel et du ramdisk à partir de la CompactFlash.
Faut dire que j'ai aussi triché un peu:
- busybox dans le ramdisk
- le /usr n'est pas sur le ramdisk: il est dans un autre fichier sur la flash qui est monté par après (Goret powah !!)
- J'ai un serveur X avec XMMS sans WM, arraché de ma Woody avec un script maison.
J'estime pouvoir gagner environ 5 secondes si je vire l'image de la bootrom PXE du bios à coups de CBROM et 5 à 10 autres secondes si je fous le /lib dans le fichier du /usr (Encore plus goret... :-P)
-
"Ça ne sert à rien mais c'est beau !"
Quand bien même sa ne servirait a "rien", le seul fait que ca soit beau permet de prouver (encore une fois) la puissance des solutions libres et de Linux et ca c'est toujours utile.
Après, vu l'augmentation des débits de connexion et des processeurs, on pourrait imaginé un micro noyau qui va chercher les sources du noyau, les compiles, le boot, puis va chercher quelques soft. A tout casser, ca doit tenir dans 300Ko au début !!
(Bon c'est juste une idée comme ca, je n'ai pas le temps de bosser dessus en ce moment)
Bravo quand même.
-
[^]Re: "Ça ne sert à rien mais c'est beau !"
Posté par Landry MINOZA (page perso, ) le 27/10/2004 à 13:32. (lien). Évalué à 1.Il n'y a plus qu'a donner l'url des CVS pour être sur d'avoir toujours le noyau le plus à jour !
Et hop, plus de MAJ à faire...-
[^]Re: "Ça ne sert à rien mais c'est beau !"
-
Plus besoin d'un noyau modulaire ?
A quoi servent les modules alors maintenant ?
Il ne reste qu'à faire un programme qui détecte le matériel et produit le fichier .config pour compiler le kernel, le tout au boot : ce qui fait qu'on a toujours un noyau monolithique mais avec les modules utiles uniquement . Si on rajoute du matériel, on reboote et un nouveau noyau est généré en fonction de sa config qui a changée.
Pour faire ce programme, il y a un bon nombre de routines de détection de matériel qu'on peut reprendre directement... du noyau.
Avis aux amateurs !
-
[^]Re: Plus besoin d'un noyau modulaire ?
Posté par beny (page perso, ) le 27/10/2004 à 15:14. (lien). Évalué à 3.Donc on a du réseau, on met tout le code dépendant de Networking options ? (ipv4/v6, bootp, netfilter, virtual server, etc ..)
-
[^]Re: Plus besoin d'un noyau modulaire ?
Posté par Guillaume Knispel () le 27/10/2004 à 18:25. (lien). Évalué à 4.euh tcc ne doit surrement pas optimiser aussi bien (moyenement ? ;) que gcc ...



Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.