TCCBOOT Compiles And Boots Linux In 15 Seconds

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."

Too fast...

[smudge8]

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...

[OverlordQ]

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.

Re:Too fast...

[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."

Re:Too fast...

[Dasein]

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.

Re:Too fast...

[Slime-dogg]

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.

Re:Too fast...

[wrook]

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...

Re:Too fast...

[D-Cypell]

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!

Re:Too fast...

[rattler14]

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...

[Zardus]

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

Re:Too fast...

[stratjakt]

I reboot my machines all the time, because it's easier than ssh'ing in, and figuring out what the problem is.

One is mainly an LDAP server/PDC, and for some reason OpenLDAP just dies once in awhile. Has something to do with BDB settings, I'm supposed to know some magical cache size setting or something to make it stable. I have no time for that. It boots from a RO image, which I rarely need to update.

Same for the firewall/gateway. It's just much easier to tell people "if the internet or vpn isnt workin

Re:Too fast...

[SenseiLeNoir]

I think you came with a very good point. Althoguh i "use" Linux a bit, mainly in userland thoguh i have created some workgroup type servers, using wizards provided by Mandrake.

My greatest technical achievement in regards to Linux is trying to compile the kernel after stripping crude from using, and sometiems having the whole thing balls up because I have stripped something that was vital.

I am not your average sysadmin who can figure out every script and knows much about process lists, or Kill Signals.

So

Re:Too fast...

[Bun]

If you're having trouble with a service, and it's started through init.d (which it probably is, if you're using Mandrake or Fedora/RedHat), then simply restart the offending service. So, add this to your list of steps:

1a) /etc/rc.d/init.d/servicename restart

Note that your init scripts might be in a slightly different location.

Re:Too fast...

[pclminion]

/etc/rc.d/init.d/servicename restart

Heh, why do people type so much? On RedHat at least, there is a script in /sbin called "service" which runs the given service for you.

For example, instead of typing:

/etc/rc.d/init.d/httpd restart

You can just type:

service httpd restart

Re:Too fast...

[Fweeky]

Why bloat / with a script when you can do:

alias service /etc/rc.d/init.d/!*

?

Re:Too fast...

[Slime-dogg]

I am not your average sysadmin who can figure out every script and knows much about process lists, or Kill Signals.

That's what an education is for. From this sentence, I get the impression that you are a sysadmin, albeit one that is grossly unqualified for any sysadmin position.

I guess we can pin this sort of thing on Microsoft, who's penchant for wizards and paperclips has led to a flooding of the market by uneducated or unqualified IT workers. It's the same frightful problem that the developer space

How did that get "insightful"?

[khasim]

I reboot my machines all the time, because it's easier than ssh'ing in, and figuring out what the problem is.

I guess that depends upon what the symptoms are. But "insightful"? Only if you only know Windows.

Same for the firewall/gateway. It's just much easier to tell people "if the internet or vpn isnt working, reset this box and wait a minute".

I have problems with Comcast. But I only have to tell people to reset the cable modem. The firewall never has problems.

Linux can have really really long uptimes,

You might want to think about that.

[khasim]

It works so well the other way, though. You Linux people often have no idea what you're doing on Windows, i suppose mostly because you refuse to learn it rather than you're too stupid to.

All computers perform the same functions. Input data, store data, process data, output data. Once you understand that, the rest is just learning the logic and the idiosyncracies behind each system.

You see it ALL THE TIME on here, people bitching about how ugly Windows is, how much useless crap it comes with, how you can't

script?

[sporty]

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?

[vidarh]

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?

[Ford Prefect]

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?

[Alioth]

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.

Re:script?

[sporty]

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.

Re:script?

[vidarh]

Why does TCC require an already running kernel? The only facilities TCC needs is the ability to read source from somewhere, output binary code to somewhere, and allocate memory. All can trivially be supported with a tiny bit of support code. No need for a kernel.

usefulness?

[FUF]

Why would anyone *possibly* want their bootloader be able to compile the kernel?

Re:usefulness?

[nick-less]

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?

[cbreaker]

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.

Re:usefulness?

[lachlan76]

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.

Re:usefulness?

[Hard_Code]

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?

[Gherald]

> 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 :)

Re:usefulness?

[walt-sjc]

Nice troll. That's like saying: "if you CAN drive your car into a tree, then that's a very serious design flaw." There is no way that you can design a general purpose OS that is immune to "operator head-gap errors." Believe me: I can easily screw up Windowsi, MacOS, any flavor of Unix, etc. to the point where they won't boot by going in and playing with the registry, system settings, driver resources, etc.

The only way you can prevent this is to prevent the tinkering in the first place, which is what all the appliance type systems do. Even then, you can always pop the hood and start reflashing the eproms, etc. rendering the device non-functional.

Linux runs on Many different architecturs and supports THOUSANDS of different devices. Because you have the ability to cross-compile and include / exclude support for just about anything, it's trivial to create a non-functional kernel. This is NOT a design flaw.

Back to the topic at hand... It would be very cool to include hardware / device detection and auto-compile all the different modules / support needed to run on any particular platform, even optimizing for the local processor. Furthermore, you do this via netboot / PXE as well as a boot CD. I dont know what capabilities tinycc has for optimization - probably none, but that may be something that could be added.

Optimizer?

[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?

[Anonymous Coward]

It's called a "hack".

Have the last nerd left the building?

Re:usefulness?

[Walkiry]

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?

[jimicus]

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?

[Jahf]

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?

[James McTavish]

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

Re:usefulness?

[Alioth]

Can you not compile the ATi drivers as a module? Should just need a make; make install followed by modprobe to load it.

What we really want to know is

[Anonymous Coward]

How long does it take to boot Gentoo?

Re:What we really want to know is

[nick-less]

How long does it take to boot Gentoo?
look here [slashdot.org] for exact timings... ;-)

Re:What we really want to know is

[lachlan76]

You've never done it, have you? I found it to be one of the most excruciating experiences ever.

Hmm

[Anonymous Coward]

If only they could apply this to compiling the rest of Gentoo . . .

Yes, but...

[Anonymous Coward]

does it run Linux?

Do you know what this means?!

[AKAImBatman]

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.

Re:Do you know what this means?!

[SpaceLifeForm]

You'll always need binaries. You'll need your base toolchain as binary in order to compile anything (including a new toolchain).

Re:Do you know what this means?!

[Rentar]

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

Re:Do you know what this means?!

[cortana]

You have just desribed Lisp, Python, Perl, etc... ... and then you describe Java, Mono, etc...

Re:Do you know what this means?!

[vidarh]

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.

Re:Limited

[SpaceLifeForm]

Yes. TCC is specifc for x86 platform anyway.

Re:Limited

[SpaceLifeForm]

Correction. TCC now generates code for ARM, which is new in this latest version.

But why?

[jolyonr]

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?

[mbrezu79]

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?

[rillian]

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?

[pclminion]

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?

[CedgeS]

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.

Re:But why?

[arivanov]

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...

I'm trying to think of a reason why ...

[nels_tomlinson]

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.

Re:I'm trying to think of a reason why ...

[vidarh]

CPU specific optimizations would be a benefit, but having looked at TCC I doubt it currently does anything of the sort :-) And of course I doubt the tiny performance improvement you could get out of it would make a difference if you're running off a CD anyway... :)

Re:I'm trying to think of a reason why ...

[mkro]

Sounds perfect for a Gentoo live cd ;)

Not a complete compile

[cbreaker]

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.

Great for Gentoo

[Solder Fumes]

Now they can compile their kernel with "-mday=Wednesday" for even better optimization.

Re:Great for Gentoo

[Mornelithe]

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

Re:Great for Gentoo

[Solder Fumes]

I'm so sorry for being distro-ist. I apologize to all Gentoo-Americans for my extreme insensitivity.

Architecture Independence

[Ford Prefect]

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?

[wowbagger]

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?

[vidarh]

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.

Re:How?

[r6144]

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

Re:How?

[mattr]

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..

Re:How?

[Ignignot]

With no optimizations, the compilation should be a relatively quick process. That's what takes so much time when you compile a binary. GCC knows all kinds of weird tricks to speed things up in coding - it almost rewrites the entire program! You can't do that without a lot of passes and a lot of checks.

Re:How?

[maxwell demon]

Non-optimizing compilers can be very fast. Basically you just have to parse it and output pre-defined asm for each bit. According to this page [borland.com], Turbo C 2.01 (a 1989 product) compiles over 16,000 lines per minute. Given that this number is also on the advertisement shown in that picture, which is actually from that time, it's 16,000 lines on the hardware of that time (i.e. 386). Now IIRC the 386 had at most 33MHz, so from the clock speed difference alone, on an 2.4GHz computer it should compile about 1.16 million lines per second; assuming a factor 4 in efficiency (i.e. modern processors can do 4 times as much per clock cycle as an 386), it should be possible to compile the same amount in 15 seconds. Now according to this page [dwheeler.com] the Linux kernel has 1,526,722 lines of code, so if either my efficiency factor of 4 was too low, or TCC can compile about 1.5 times as fast as Turbo C 2.0 could (or maybe a combination of both), it's clearly not that far-fetched that a linux kernel could be compiled in 15 seconds.

Re:How?

[LiENUS]

Actually the TinyCC site lists a speedchart at http://fabrice.bellard.free.fr/tcc/#speed [bellard.free.fr] measurements are done on a 500 MHz K6. That should give you a better idea than just estimating based on Turbo C 2.0

Wow! Ultimate Gentoo!

[Eunuchswear]

Recompile your programs EVERY TIME YOU RUN THEM.

Ricers Rule!

A.K.A.

[Omni-Cognate]

Java

Re:Wow! Ultimate Gentoo!

[maxwell demon]

Well, that's still not the ultimate. The ultimate would be to compile the program while you run it, i.e. a JIT C compiler.

Wow

[physicsphairy]

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."

Main reason for this?

[kbahey]

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.

Re:Main reason for this?

[kbahey]

You are generally right.

But think about it for a bit: this fast C compiler turns the tables, and redefines what we know (paradigm shift anyone?). No longer will C be seen as a compiled language. One can think of it as a scripting language. A construct like this works with tcc:

#!/usr/local/bin/tcc -run
main()
{
DoSomethingHere();
}

Something that was unthinkable under GCC.

As someone else posted, this can mean the proliferation of self contained bundles that are platform independant.

The potential is enormous. Not the boot part, but the compiler and what it can be twisted into doing.

I call shenanigans on this

[Weaselmancer]

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.

Re:I call shenanigans on this

[Godeke]

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.

This should go over BIG..

[murderlegendre]

..with the Gentoo crowd.

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

Wha?

[stratjakt]

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?

[blane.bramble]

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.

Re:Wha?

[SuiteSisterMary]

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?

Wow. That really is fast.

[TheRaven64]

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.

Re:Wow. That really is fast.

[TheRaven64]

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

Blatant Karma Whoring: In case of a slashdotting..

[jimicus]

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.

Yes, it starts booting

[PhilipOfOregon]

but when does it *finish* booting?

In Soviet Russia....

[MetaMarty]

The kernel compiles your bootloader!! Oh wait...

Compiles itself NOT the Kernel

[PetoskeyGuy]

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.

Re:Compiles itself NOT the Kernel

[PetoskeyGuy]

I was wrong.

Pretty impressive if they can do it, still I wonder what modules are loaded? Are they really compiling or just linking? I wonder how fast my P-133 would boot...

So I'm guessing here...

[mark-t]

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

[pritcharda]

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

[multiplexo]

Beowulf cluster of these. Together they'd boot so fast that you'd go back in time!

LinuxBIOS

[hey]

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.

[meff]

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 :)

Tcc seems truly amazing

[herve_masson]

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.

Less than perfect first impression

[dbrower]

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.

Re:What's the point ?

[Anonymous Coward]

I understand how geeky this is but what would its uses be ? Especially when it's now become possible to boot a full featured Linux distro from an USB key ?

You just answered your own question:
I understand how geeky this is

Re:Just-in-time compilation

[maxwell demon]

Well, maybe a BIOS-integrated Emacs automatically launches and allows you to edit the code ...

Owned

[codepunk]

And on the average that means that your junk windows box can be exploited in 30 sec from a cold metal start.

Re:TCC compiler

[TheRaven64]

TCC has a few significant drawbacks.

1. It is not portable (well, technically it is portable, but currently only has an i386 back end).
2. It only supports C (not a drawback if you are just compiling C, but a lot of projects use C++/Objective-C/Whatever).
3. It produces fairly sub-optimal code. The register allocation done by TCC is not very clever, and it performs no serious optimisation steps.

On the other hand, TCC has two huge advantages:

1. It is not GCC. Compiling your code using two or more compilers and ideally for 2 or more CPU architectures is a good way of finding some more obscure bugs.
2. It is very fast. The less time you spend compiling, the more time you can spend testing / debugging.