Forgot your password?
typodupeerror
Announcements Software Linux

TCCBOOT Compiles And Boots Linux In 15 Seconds 342

Posted by timothy
from the count-to-ten-very-slowly dept.
An anonymous reader writes "TCCBOOT is the first boot loader able to compile and boot a Linux kernel directly from its source code. It can compile and start booting a typical Linux kernel in less than 15 seconds on a 2.4 GHz Pentium 4. TCCBOOT uses the latest version of the TinyCC C compiler."
This discussion has been archived. No new comments can be posted.

TCCBOOT Compiles And Boots Linux In 15 Seconds

Comments Filter:
  • Too fast... (Score:5, Funny)

    by smudge8 (812705) <smudge8@gmai[ ]om ['l.c' in gap]> on Wednesday October 27, 2004 @09:25AM (#10641438) Journal
    To be honest, I LIKE the delay when I have to reboot. It gives me time to have a pee, stretch my legs, have a drink...

    Eventually we're going to spend 24 hours a day staring at the screens because there'll be no excuse at all for leaving the screen.
    • Re:Too fast... (Score:2, Redundant)

      by OverlordQ (264228) *
      Erm, no offense, but if I have to piss or get a drink I go do that, just because the computer is on (Oh noes!) doesn't mean I'm forced to sit at it 24/7.
      • by Anonymous Coward
        if I have to piss ... I go do that

        +2 Insightful. ... When did /. become a Zen monastery? "If you are hungry, then eat. If you are tired, then sleep."
    • by Dasein (6110) <tedc&codebig,com> on Wednesday October 27, 2004 @09:29AM (#10641480) Homepage Journal
      there'll be no excuse at all for leaving the screen

      Um. Social life, family, sex, ....

      Yes, I do realize that I'm posting to slashdot.
      • All of which are possible from in front of the screen:

        1. Social Life: On-line chat. MMORPG.
        2. Family: See the next one:
        3. Sex: Through on-line chat, tell someone that you think is a chick to get their ass over to your house, so they can sit on your lap. Existance of a family then ensues... unless you find out that your "chick" was a dude.
    • by wrook (134116) on Wednesday October 27, 2004 @09:38AM (#10641567) Homepage
      That might be OK for Windows. For Linux, you might not want to wait for a reboot to take a pee. Just a word of warning...
    • by D-Cypell (446534) on Wednesday October 27, 2004 @09:49AM (#10641659)
      I LIKE the delay when I have to reboot. It gives me time to have a pee, stretch my legs, have a drink...

      Then I suggest you stay away from windows, you will end up as a dehydrated, 12 foot alcholic!
    • by rattler14 (459782) on Wednesday October 27, 2004 @09:55AM (#10641701)
      well said!

      plus, my boss really thinks i'm working hard when he sees 4 terminals open with stuff flying past them. hence, i always compile from source
      • Re:Too fast... (Score:3, Interesting)

        by Zardus (464755)
        I used to have a tech support job for which we could spend part of our time administering the help desk's servers if we wanted to. While we were doing that, usually no one would bother us with tech-support questions. At one point, I just launched up

        # while [ true ]; do make; make clean; done

        and sat back and had a nice relaxing day. Whenever anyone would ask me anything, I'd point to the scrolling compile messages on the screen and tell them that I was busy.

        Now that I think back on it, I could have just i
  • script? (Score:4, Insightful)

    by sporty (27564) on Wednesday October 27, 2004 @09:26AM (#10641440) Homepage
    So they effectively make the kernel a script instead of a compiled unit, where it needs to be loaded, compiled into memory, and then used.


    Perl5 does the same thing. read, compile, run..


    So what are the uses for this?

    • Re:script? (Score:5, Insightful)

      by vidarh (309115) <vidar@hokstad.com> on Wednesday October 27, 2004 @09:30AM (#10641487) Homepage Journal
      Comparing it to Perl is a bit unfair considering we don't exactly have a full fledged Unix like kernel written in Perl to boot...

      I prefer to see this as a great proof of concept that kernel compilation can be made fast enough to do "on the fly". Considering that driver installation for Linux still often requires a kernel recompile, if this system can be made solid enough it could make things like that a lot easier for end users, though I think I'd prefer to have it done at package installation time rather than boot time :-)

      • Re:script? (Score:3, Funny)

        by Ford Prefect (8777)
        Comparing it to Perl is a bit unfair considering we don't exactly have a full fledged Unix like kernel written in Perl to boot...

        How about using it to bootstrap Emacs? That's virtually an operating system already... ;-)
      • Re:script? (Score:3, Informative)

        by Alioth (221270)
        It should never need a kernel compile (I'll make an exception for an experimental driver) - they should all compile fine as modules. All the most recent 3rd party Linux drivers I've used just needed the module compiling and then loading - not even a reboot was needed.
      • Comparing the process of loading into memory, compiling and running, which is EXACTLY what this is doing just as perl is unfair?


        I didn't say the kernel is perl. I said that it turned the process into that of a script language, just like perl is. Anyway, it's not unpossible to make your drivers loadable/unloadable. linux already supports this and so does freebsd.


        Still no gain.

  • usefulness? (Score:5, Interesting)

    by FUF (68684) on Wednesday October 27, 2004 @09:26AM (#10641441) Homepage
    Why would anyone *possibly* want their bootloader be able to compile the kernel?
    • Re:usefulness? (Score:3, Interesting)

      by nick-less (307628)
      Why would anyone *possibly* want their bootloader be able to compile the kernel?

      So you never fucked up your .config and tried to boot a kernel that wont support harddisk without having a backup kernel somewhere? Hell, you seem to be a lot smarter than me...
      • Re:usefulness? (Score:3, Interesting)

        by cbreaker (561297)
        I've never made my Linux boxes completly unbootable. I've always put in a link to the old kernel, or something.

        Actually, I can't say that - one time lilo locked up the system while installing, and that caused it to not boot. But since that was a bootloader thing, this nifty compile-at-boot thing wouldn't help anyways.
        • Sorry, didn't mean to post AC.

          I've only ever once made my linux box completely unbootable. But that was because I accidently did rm -rf /. Not really excusable, but I am only 15, and I'd just been rejected, and almost broken my neck......

          Anyway, it deletes in alphabetical order, and I hit control-c when I saw it delete apache2.conf. Too late though, with /boot being the second dir to be deleted.
      • Grub understands ext file systems and gives you a console that is pretty flexible, so unless you intentionally deleted all backup bootable kernels (shame on you) you should still be able to boot in some manner.
        • Re:usefulness? (Score:3, Interesting)

          by Gherald (682277)
          > Grub understands ext file systems and gives you a console that is pretty flexible, so unless you intentionally deleted all backup bootable kernels (shame on you) you should still be able to boot in some manner.

          Yeah, like... ummm, KNOPPIX?

          Been there done that :)
    • Optimizer? (Score:2, Insightful)

      by Anonymous Coward
      Why would anyone *possibly* want their bootloader be able to compile the kernel? ...and I can hardly imagine just how un-optimized the code from the tiny cc compiler must be.
    • Re:usefulness? (Score:2, Informative)

      by Anonymous Coward

      It's called a "hack".

      Have the last nerd left the building?

    • Re:usefulness? (Score:5, Interesting)

      by Walkiry (698192) on Wednesday October 27, 2004 @09:33AM (#10641518) Homepage
      Two words: ATI drivers. These fuckers have to be compiled in the kernel, and I don't doubt there may be some other dumbasses who make similar drivers for other stuff. If the kernel just compiles like that (as in, is designed to just compile on boot), it'd make messing with the drivers less painful.
      • Re:usefulness? (Score:3, Interesting)

        by jimicus (737525)
        There is a world of difference between re-compiling the kernel and actually getting your nicely recompiled kernel working properly.

        However, it's a step in the right direction - I can see Mandrake or SUSE taking this idea and integrating it with some kind of video-driver update system - "Instructions: install this package, reboot."
      • Re:usefulness? (Score:5, Insightful)

        by Jahf (21968) on Wednesday October 27, 2004 @09:50AM (#10641671) Journal
        No it wouldn't. You'd still have to reboot to see the change ... at least if you compile -before- the reboot you know that the compile worked.

        Plus using this mechanism as-is without alternative boots would mean compiling your kernel every time you boot. A waste of time and resources.

        Note that it didn't say it booted in 15 seconds ... only that it -started- to boot in 15 seconds. Even removing all modules I find it impossible to believe that a P4 could compile the entire kernel with -any- compiler faster than it takes to load a precompiled kernel. No matter what you still have a "+ compile time" situation even if it is much faster than the stock gcc.

        This has some "because you can" value, but otherwise I just don't see it as being useful to the user, or even to the vast majority of kernel developers.

        Making C feel like Perl is not a good thing for me :)
        • Re:usefulness? (Score:2, Interesting)

          Agreed that in its present form it is not that useful, but with a couple of features it would become more useful. All they need to do is only have the kernel recompile when the config has changed, and keep an older working kernel around for a failsafe boot. With those two features kernel upgrades become automatic and safe.

          That being said, why not just have it recompile while booted. The install script could install the new kernel in lilo/grub and keep the last kernel for a failsafe. The user would simp
      • Can you not compile the ATi drivers as a module? Should just need a make; make install followed by modprobe to load it.
  • by Anonymous Coward on Wednesday October 27, 2004 @09:26AM (#10641442)
    How long does it take to boot Gentoo?
  • Hmm (Score:4, Funny)

    by Anonymous Coward on Wednesday October 27, 2004 @09:26AM (#10641443)
    If only they could apply this to compiling the rest of Gentoo . . .
  • Yes, but... (Score:4, Funny)

    by Anonymous Coward on Wednesday October 27, 2004 @09:26AM (#10641444)
    does it run Linux?
  • by AKAImBatman (238306) * <akaimbatman@gmai ... m minus language> on Wednesday October 27, 2004 @09:26AM (#10641446) Homepage Journal
    This could allow for platform independent Linux programs! i.e. If programs could be compiled on the fly from source bundles as an acceptable speed, then there would be no need to distribute binaries any longer. One source bundle, and you'll rule them all!

    Failing that, one could always fall back on my previous plan. My thought was that if GCC compiled to P-Code instead of the final binary, the target GCC could complete the P-Code conversion at install time.
    • You'll always need binaries. You'll need your base toolchain as binary in order to compile anything (including a new toolchain).
    • That's pretty much the same idea that was realized in each high-level language that is less than 10 years old (and several that are older):

      1) Compile to some intermediate form (byte code or whatever you like to call it)
      2a) Use an interpreter to run the result
      2b) Compile the result to native code
      3) Profit!

      (Another added benefit is that the user doesn't have to care wether 2a or 2b is choosen, he won't see any difference apart from the speed-increase you'll most likely get from choosing 2b).

      I don't think t
    • You have just desribed Lisp, Python, Perl, etc... ... and then you describe Java, Mono, etc...
    • P-code sucks. If you want to do that, you'd be better off generating Java bytecode - at least some real effort have gone into optimizing execution of Java bytecode.

      Another option is system like Semantic Dictionary Encoding (M. Franz. Code-Generation On-the-Fly: A Key to Portable Software. PhD thesis, ETH Zurich, Mar. 1994. - It's available online on ETH's servers somewhere but I don't have time to dig it up) - which was (is?) in use by the Mac Oberon people to generate CPU independent binaries.

  • But why? (Score:4, Insightful)

    by jolyonr (560227) on Wednesday October 27, 2004 @09:27AM (#10641451) Homepage
    It doesn't actually explain on the site why anyone would want to do this.

    And I'm still not sure! What's wrong with compiling it every time the code changes and booting up quicker than 15 seconds?

    Jolyon
    • Re:But why? (Score:3, Interesting)

      by mbrezu79 (669155)
      Well, I'm no kernel hacker, but I guess this could help speed up the debug cycle for the kernel in some instances.

      It could also be a trap (it runs well compiled with tcc but fails misteriously when compiled and optimized with gcc).

      TCC is a very fast C compiler and it is very nice for development (I used it as a backend to the SmartEiffel Eiffel compiler, it greatly speeds up compiling - waiting for GCC every time was a nuissance) and I guess Fabrice Bellard likes to experiment.

      I guess nobody (inclu
      • Re:But why? (Score:3, Informative)

        by rillian (12328)

        It is indeed very fast, but it wouldn't compile ghostscript for me.

        # apt-get install tcc
        [...]
        $ cd ~/projects/ghostscript/gs
        $ make distclean
        [...]
        $ CC=tcc ./configure && make
        [...]
        tcc -DHAVE_MKSTEMP -DHAVE_HYPOT -O -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long long" -I./src -I./obj -I./obj -I./src -o ./obj/zfcid.o -c ./src/zfcid.c
        In file included from ./src/zfcid.c:23:
        In file included from ./src/bfont.h:24:
        ./src/ifont.h:34: identifier expected
        make: *** [obj/zfcid.o] Error 1

        Co

        • Re:But why? (Score:3, Informative)

          by pclminion (145572)
          Compiler bug?

          Why not give some more information so we can figure out why it doesn't work? It could just be a misconfigured #define somewhere.

      • Re:But why? (Score:4, Interesting)

        by CedgeS (159076) on Wednesday October 27, 2004 @12:42PM (#10644299) Homepage Journal
        fibo.c from GCLS:

        cedric@cedric:~$ time tcc fibo.c -o fibo.tcc

        real 0m0.060s
        user 0m0.020s
        sys 0m0.010s
        cedric@cedric:~$ time gcc fibo.c -O3 -o fibo.gcc

        real 0m0.441s
        user 0m0.150s
        sys 0m0.030s
        cedric@cedric:~$ time ./fibo.gcc
        1

        real 0m0.074s
        user 0m0.000s
        sys 0m0.000s
        cedric@cedric:~$ time ./fibo.tcc
        1

        real 0m0.072s
        user 0m0.000s
        sys 0m0.000s
        cedric@cedric:~$ time ./fibo.gcc
        1

        real 0m0.071s
        user 0m0.000s
        sys 0m0.000s
        cedric@cedric:~$ time ./fibo.tcc
        1

        real 0m0.074s
        user 0m0.000s
        sys 0m0.000s
        cedric@cedric:~$ time ./fibo.gcc
        1

        real 0m0.071s
        user 0m0.000s
        sys 0m0.010s
        cedric@cedric:~$ time ./fibo.tcc
        1

        real 0m0.070s
        user 0m0.000s
        sys 0m0.000s

        I can't believe this is what GCLS uses as a benchmark. The running time is so short it's probably all start-up and shutdown. Anyway, the numbers are pretty fair for a compiler compiling code that was tweaked to get the other compiler to be as fast as possible.
    • As a proof of concept that a 100kb compiler can do what the monster also known as gcc can do and do it considerably faster...
  • by nels_tomlinson (106413) on Wednesday October 27, 2004 @09:28AM (#10641457) Homepage
    I know that the answer to ``why?'' is ``why not?''. but I'm trying to think of some practical use for this.

    Maybe you could use some Knoppix-style hardware detection to probe the hardware at boot-time, then custom-compile a kernel to match? I just can't really see that that would be an improvement over just compiling in everything and the kitchen sink as a module.

    Oh, well, even if it's useless, it's neat.

  • by cbreaker (561297) on Wednesday October 27, 2004 @09:28AM (#10641458) Journal
    The README says it needs some of the binaries and headers on the linux kernel, so you have to pre-compile these first.

    I guess this could have some limited use somewhere, perhaps, but I can't really see how if you need some precompiled stuff.
  • by Solder Fumes (797270) on Wednesday October 27, 2004 @09:28AM (#10641465)
    Now they can compile their kernel with "-mday=Wednesday" for even better optimization.
    • Jesus.

      Look, I know everyone here hates Gentoo because there is some group of nebulous "Gentoo zealots" who go around posting pro-Gentoo stuff on every single slashdot story. I've never actually seen them, but I always hear people complaining about them, so they must exist.

      But how many times can people hear, "Haw haw, they compile stuff and it's slow" and still laugh? Do you guys laugh at every single fart joke you hear? How can stuff like this still get +5 funny?

      Anyone who thinks about posting some "Gent
  • by Ford Prefect (8777) on Wednesday October 27, 2004 @09:29AM (#10641473) Homepage
    For some reason, I'm reminded of the platform-independent device drivers and boot code written in Forth in Open Firmware [openfirmware.org].

    I don't know how useful a processor architecture-independent version of this would be (the compiler itself is pre-compiled for a specific processor, presumably!) but it does seem a rather cool hack. Maybe an ultra-inclusive version of Gentoo?
  • How? (Score:5, Interesting)

    by wowbagger (69688) on Wednesday October 27, 2004 @09:30AM (#10641486) Homepage Journal
    How can this thing:

    Load the needed environment for the compiler.
    Load the source
    Build the source
    Boot the source

    in 15 seconds, when it takes much longer than that for my already booted system to build a kernel? A P4 isn't THAT much faster than an AMD3200! (And I have done the old "drop to RL1 and build" trick, so it is not an issue of other tasks running).

    I want to know a) What kernel options are enabled b) From when are they starting the clock (are they counting the time to load the bootloader and initrd?) and c) is this TRULY a fully functional kernel, or "just enough to get a prompt"?
    • Re:How? (Score:5, Informative)

      by vidarh (309115) <vidar@hokstad.com> on Wednesday October 27, 2004 @09:37AM (#10641561) Homepage Journal
      TCC is an incredibly tiny compiler with practically no dependencies on the environment. It's based on a cleaned up entry to the obfuscated C contest. So you can safely assume it's using every dirty trick in the book and then some. It still sounds incredible though.
    • by r6144 (544027)
      Here [kerneltrap.org] someone compiled kernel 2.5.7 on a 32-way Power4 1.1GHz within 7.52 seconds, in 2002.

      Now suppose TCC is 10 times as fast as GCC (which is true based on my experience), the 32-way machine is 20 time as fast as than a single Power4 (the kerneltrap site said "2246% CPU usage"), and the 2.4GHz Pentium4 is as fast as a 1.1GHz Power4, then building the kernel just takes 15 seconds. Of course, it is a rough estimate, and I suspect the P4 should be faster than a 2002-ish Power4 for cpu-intensive job such as

    • by mattr (78516)
      Lightspeed Pascal on my Mac SE was able to compile into p-code my programs so quickly it was imperceptible. Granted they were not so long..
  • by Eunuchswear (210685) on Wednesday October 27, 2004 @09:30AM (#10641490) Journal
    Recompile your programs EVERY TIME YOU RUN THEM.

    Ricers Rule!
  • Wow (Score:4, Funny)

    by physicsphairy (720718) on Wednesday October 27, 2004 @09:30AM (#10641493) Homepage
    My windows box and I would still be trying to negotiate whether it wanted to boot in "Normal Mode" "Safe Mode" "Last Known Good Configuration" or "Sorry, chap, just not gonna happen."
  • by kbahey (102895) on Wednesday October 27, 2004 @09:30AM (#10641497) Homepage

    I think the main thing here is the TCC compiler, which is 100K or so, and very fast.

    This TCCBOOT is something to showcase the speed of the TCC compiler.

  • I'm posting this from a 2.4Ghz machine myself, and it doesn't compile kernel 2.6 in 15 seconds, let alone boot in that short of a time. It takes at least a couple of minutes.

    Hell, "make clean" takes longer than that.

    • by Godeke (32895) * on Wednesday October 27, 2004 @09:44AM (#10641619)
      Looking at benchmarks for TCC, combined with the fact this needs kernel patches to work, I don't see this as shenanigans.

      15,000 - 16,000 lines per second for GCC vs 134,000 lines per second is a pretty huge speed improvement.

      On the other hand, if "make clean" takes longer than 15 seconds on your machine, I have to wonder what you are doing. I'm typing this on a lowly 550 Mhz Pentium with 512 MB of RAM (running a full KDE install) and I can assure you I would be unhappy if running "clean" took that long.
  • by murderlegendre (776042) on Wednesday October 27, 2004 @09:35AM (#10641540)

    ..with the Gentoo crowd.

    The once impossible dream of actually compiling the Linux kernel on every boot is now a shining reality.

  • Wha? (Score:3, Informative)

    by stratjakt (596332) on Wednesday October 27, 2004 @09:36AM (#10641556) Journal
    It takes a couple minutes to compile my kernel on a 3.06 P4, and of course, forever and a day to boot.

    I guess 15 seconds is to compile without any device support other than the boot drive.

    That said, linux boot time as it is sucks, especially if you want to use it on something like a router/firewall box like I do. The only button I ever press on that machine is reset. VPN not working? Reset.

    That's how it should work IMO, but every time I do it the 'net is out for 10 mintues until it's back up.

    Resetting the whole box should be faster than ssh'ing in and typing a "/etc/init.d/shorewall restart" and "/etc/init.d/openvpn restart".

    • Re:Wha? (Score:2, Insightful)

      by blane.bramble (133160)

      Resetting the whole box should be faster than ssh'ing in and typing a "/etc/init.d/shorewall restart" and "/etc/init.d/openvpn restart".

      Why? Resetting the box requires the whole OS and all support routines to be started. Restarting a couple of services doesn't - why on earth should rebooting the whole lot be faster? That being said, are you using a cut-down desktop distro? That is probably why it takes so long - take a look at the embedded market for hints on how to have a faster booting system.

    • Well, at that point, use acpd to run a script when you hit the reset button, and have the script take down all of the networking stuff, then put it back up.

      Also, I trust your hard drives are all either mounted read-only?

  • by TheRaven64 (641858) on Wednesday October 27, 2004 @09:38AM (#10641566) Journal
    Out of sheer boredom, I just downloaded the demo ISO and ran it inside VirtualPC on a 1.5GHz G4. The emulated system is probably roughly equal to a P2 300. The total time from turning the emulated machine on to a shell was around a minute.
    • by TheRaven64 (641858) on Wednesday October 27, 2004 @09:41AM (#10641589) Journal
      I just ran the same thing again (exactly the same configuration), with a stopwatch. 46 seconds. 15 seconds on a P4 sounds like they were being a bit pessimistic. Note that this doesn't include launching any daemons, or a
      sh-2.05b# ps -x
      PID TTY STAT TIME COMMAND
      1 ? S 0:01 /bin/sh /sbin/init auto
      2 ? SW 0:00 [keventd]
      3 ? SW 0:00 [bdflush]
      4 ? SW 0:00 [kupdated]
      5 ? SWN 0:00 [ksoftirqd_CPU0]
      6 ? SW 0:00 [kswapd]
      15 ? S 0:00 /bin/sh
      17 ? R 0:00 ps -x
  • by jimicus (737525) on Wednesday October 27, 2004 @09:39AM (#10641570)


    Introduction
    TCCBOOT is a boot loader able to compile and boot a Linux kernel directly from its source code.

    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.

    TCCBOOT is based on the TinyCC compiler, assembler and linker. TinyCC is an experiment to produce a very small and simple C compiler compatible with the GNU C compiler and binary utilities.
    Screenshots
    Download
    ISO image demonstation: tccboot.iso (5.9 MB).

    Create a CD from it and boot it to see TCCBOOT in action (PC with at least 64 MB of RAM required). You can also try it with the QEMU PC emulator.

    TCCBOOT source code: tccboot-0.1.tar.gz, and README file.
  • but when does it *finish* booting?
  • The kernel compiles your bootloader!! Oh wait...
  • It compiles and loads itself, then loads the kernel. Still you have to wonder what's doing the compiling and loading of the source? Sounds like one of those compressable compressors.
  • Because TFA doesn't give any details... (what does it say about the article when some of the /. posts on it are longer than the article itself?)

    But I'd say the time they are speaking of is the time from power-up until /sbin/init starts running.

    Given that...15 seconds is not as huge a deal as they imply... although it's pretty darn neat that it can compile the kernel in that amount of time.

    My system starts the init process in only a few seconds too, I've never actually timed it, but it's _DEFINITELY_

  • Consumer Devices (Score:2, Interesting)

    by pritcharda (716158)

    Im wondering if this level of functionality and speed becomes helpful when applied to consumer devices. Or situations where the average user is not able, or capoble, to make changes at this level.

    Things like mobile phones. The consumer wont have the abilities to re compile, if say; they connect device like a camera.

    The mobile can recognize the device, and retrieve the drivers from the hardware. Then a quick rebuild, and the mobile is configured for the new hardware. (of course a re-boot is still necess

  • Imagine a (Score:4, Funny)

    by multiplexo (27356) * on Wednesday October 27, 2004 @10:13AM (#10641975) Journal
    Beowulf cluster of these. Together they'd boot so fast that you'd go back in time!

  • LinuxBIOS (Score:3, Informative)

    by hey (83763) on Wednesday October 27, 2004 @10:26AM (#10642184) Journal
    If you want a more sensible Linux-specific
    BIOS there's the LinuxBIOS [linuxbios.org].
    It looks like its only for clusters but I'd
    like to get it from my next Linux box.
  • This guy is amazing. (Score:5, Interesting)

    by meff (170550) <meff@s p h e r e v i sion.org> on Wednesday October 27, 2004 @10:47AM (#10642516) Homepage
    http://fabrice.bellard.free.fr/ [bellard.free.fr]

    Just look at this guy's work.. It's amazing what this he can do.
    If you haven't tried it yet, definately check out QEMU, it's great, and totally free.
    He also wrote FFMPEG which most definately your linux media player uses..

    I am always wondering what he'll put out next :)
  • I don't care much if my kernel boots from freshly compiled source code or from my last build, but this tcc thing is really incredible.

    I had to download its source code, build it and use it to believe it. 100k for something that compile a C code about 5 times faster (my very rough measures) is something I would have consider a joke if I could not see it in action.

    Obviously, it probably not do all the optimizations gcc implements, but still. Wow.
  • by dbrower (114953) on Wednesday October 27, 2004 @01:00PM (#10644542) Journal
    So I download the source to my Suse 9.x machine with gcc 3.3.3, run configure:
    ./configure
    Binary directory /usr/local/bin
    Library directory /usr/local/lib
    Include directory /usr/local/include
    Manual directory /usr/local/man
    Doc directory /usr/local/share/doc/tcc
    Source path /home/dbrower/src/tcc-0.9.21
    C compiler gcc
    make make
    CPU x86
    Big Endian no
    gprof enabled no
    Creating config.mak and config.h
    config.h is unchanged
    say make and get a compilation error:
    gcc -O2 -Wall -c -o bcheck.o bcheck.c
    bcheck.c:172: error: conflicting types for `__bound_ptr_add'
    bcheck.c:80: error: previous declaration of `__bound_ptr_add'
    bcheck.c:231: error: conflicting types for `__bound_local_new'
    bcheck.c:87: error: previous declaration of `__bound_local_new'
    bcheck.c:247: error: conflicting types for `__bound_local_delete'
    ...

    This is fixed by defining __TINYC__ in the rule for bcheck.o, and you get a tcc executable. Trying to remake it with itself

    rm *.o
    make CC=tcc
    Results in complaints about stddef.h not found. Adding -I/usr/include/linux leaves us with other errors, and as Mr. Costello would say at this point, "I don't give a darn".

    My interest just ran dry for now.

    -dB, on third base.

Thufir's a Harkonnen now.

Working...