Posted by
timothy
on 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."
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...
by
stratjakt
·
· Score: 3, Interesting
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 working, reset this box and wait a minute".
Linux can have really really long uptimes, but only if you have an admin who can babysit it and solve problems without rebooting.
I'm not an admin, and I don't have time to figure out why "dhcpcd" or "dnsmasq" decided they dont need to spawn anymore. While such problems could probably be easily fixed by deleting some lockfile or clearing some log, rebooting is just easier.
Linux needs to be able to boot fast to move forward, especially in the world of "embedded" or single-function PCs.
--
I don't need no instructions to know how to rock!!!!
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
-- my last sig was too controversial...
now, a new and improved useless sig!
Re:Too fast...
by
SenseiLeNoir
·
· Score: 2, Interesting
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 although I do view Linux as vastly more stable than Windows, if i get frustrated with a problem i usually follow the following steps.
1) CTRL ALT BACKSPACE to kill and restart X which is great for getting rid of dodgy X-Apps 2) init 1 / init 5 sequence to deal with services or errant processes. 3) reboot.. if the above fails
To be honest I dont mind doing the above, and as i learn more about Linux, i am sure i will learn to avoid such drastic measures. However, until then, anything that speeds up the reboot would be great.
Maybe some sort of "snapshot" feature like the Windows Hibernate, so that you can take a snaphot of Linux post boot/ pre X and instead of going through the entire bolava of booting the kernel, and OS, just loading the snapshot?
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.
-- "Anyone that has ever gotten an idea based on any of my work and done something better with it-good for you."--J.Carmack
Re:Too fast...
by
bhirsch
·
· Score: 2, Insightful
The best is web surfing in links/lynx. Terminals = hard work!
Re:Too fast...
by
marcansoft
·
· Score: 2, Informative
Since I'm using Gentoo on an AMD64, which even on its stable flavour is more "experimental", if X locks down hard and alt+sysRq+R (unRaw) doesn't let me switch VT, I usually alt+sysRq+E (tErm all tasks) or alt+sysRq+I (kIll all tasks). I then have a simple script that removes all the lockfiles in/var/lib/init.d/started which correspond to actual daemons (faster than calling "zap" for all the initscripts) and then just "rc default". (or rc 5, or init 1; init 5, or whatever you can do on other distros to start everything that's stopped and should be started)
This usually fixes many problems quickly (just the sysrq, login, run the script, and then tell it to start everything again; you can continue using X and since KDE or Gnome will mostly be cached in RAM it will start fast.)
Re:Too fast...
by
Zardus
·
· Score: 2, Interesting
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 installed Gentoo on something, which would have been more productive. But, nah...
--
You can mod your friends, you can mod your nose, but you can't mod your friend's nose.
Re:Too fast...
by
Slime-dogg
·
· Score: 2, Informative
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 deals with, where VB6 allows people to create executables without understanding programming at all.
I apologize, if I'm being offensive. It is frustrating to see the industry that I work in crumble because of the antics of a single company and the bloat in salaries a few years back. I'm not saying that you, in particular, have no chance of learning, it looks like you're interested in what you're doing... But there are quite a few more capable and qualified people out there without jobs that can fill a sysadmin position that is filled by an MS drone.
Imagine... if all sysadmins had CS degrees, the majority of all servers would probably be *NIX based, and Code Red wouldn't have happened.
-- You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
All of which are possible from in front of the screen:
Social Life: On-line chat. MMORPG.
Family: See the next one:
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.
-- You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
Re:Too fast...
by
pclminion
·
· Score: 2, Informative
/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...
by
Fweeky
·
· Score: 2, Informative
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:-)
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.
manufacturing makes a machine, it has tccboot in firmware. product is finished, goes to be tested. first test: turn it on, it compiles its own kernel, its own operating system, its own libs. its own app. there is no 'image copied' for mfr'ing; the machine makes its own software itself (source code is served to the firmware over network).
why would this be cool? it would mean an end to the 'all systems run the same binary' dilemna, you know.. the reason for the success of software piracy?
i predict that there will be a distro of linux, using tccboot, in the very near future, which offers the ability to encrypt everything to a unique system key, probably something on-chip. per-processor, custom binaries, it will only run what it compiles itself.
-- ; -- the corruption of government starts with its secrets. a truly free people keep no secrets.
--
Why would anyone *possibly* want their bootloader be able to compile the kernel?
Re:usefulness?
by
nick-less
·
· Score: 2, Interesting
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?
by
Anonymous Coward
·
· Score: 2, Informative
It's called a "hack".
Have the last nerd left the building?
Re:usefulness?
by
cbreaker
·
· Score: 2, Interesting
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.
-- - It's not the Macs I hate. It's Digg users. -
Re:usefulness?
by
Walkiry
·
· Score: 4, Interesting
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?
by
jimicus
·
· Score: 2, Interesting
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."
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:)
-- It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
Re:usefulness?
by
Gherald
·
· Score: 2, Interesting
> 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?
by
James+McTavish
·
· 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 simply reboot whenever it was convienent and it would boot straight into the next kernel.
Bottom line, it could become more useful, but there are already better ways to do it.
-- Karma: Abstruse (Mostly as a result of using words nobody understands)
Re:usefulness?
by
walt-sjc
·
· Score: 3, Insightful
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.
Run this in your root (and other important directories):
echo "" > -i
You'll thank me if you do something stupid like that again. The "-i" will be seen as an argument to/bin/rm, and it'll ask you to confirm each item. Sure, this could be a pain in the ass, but I can't think of a good reason to "rm *" in an important directory like that.
--
-Hal
What we really want to know is
by
Anonymous Coward
·
· Score: 4, Funny
How long does it take to boot Gentoo?
Re:What we really want to know is
by
skiman1979
·
· Score: 2, Insightful
As a matter of fact, I have compiled on Gentoo. I run Gentoo at home as my main system. Although I haven't compiled all of Gentoo (i.e., stage1), I have recompiled the kernel a few times and compiled a few other larger applications. They just compile in a konsole window in the background while I work on other things. So, like I said, what's the big deal? It's not like I need my new kernel *now*.
-- Having a smoking section in a public restaurant is like having a peeing section in a public swimming pool.
Hmm
by
Anonymous Coward
·
· Score: 4, Funny
If only they could apply this to compiling the rest of Gentoo . . .
Yes, but...
by
Anonymous Coward
·
· Score: 4, Funny
does it run Linux?
Do you know what this means?!
by
AKAImBatman
·
· Score: 5, Interesting
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.
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 (including Bellard) believes TCC is any good for delivered apps (it doesn't optimize etc.) but it can provide a huge boost to edit-compile-debug cycles.
So yes, TCC is very cool, but not useful for the general public.
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
Compiler bug?
I also like how it has an auto-run switch to invoke the compiler output. So you can make C source executable from
the command line by putting #!/usr/bin/tcc -run at the top. I would use that for quick test programs in C. Once it's debugged you can run it through gcc.
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?
by
pclminion
·
· Score: 2, Informative
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.
I'm trying to think of a reason why ...
by
nels_tomlinson
·
· Score: 3, Insightful
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.
Re:I'm trying to think of a reason why ...
by
vidarh
·
· Score: 2
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...:)
Not a complete compile
by
cbreaker
·
· Score: 4, Informative
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.
-- - It's not the Macs I hate. It's Digg users. -
Great for Gentoo
by
Solder+Fumes
·
· Score: 5, Funny
Now they can compile their kernel with "-mday=Wednesday" for even better optimization.
Re:Great for Gentoo
by
Mornelithe
·
· Score: 2, Funny
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 "Gentoo zealots annoy me" crap (including people who have that in their signatures) should think about the fact that 80% of the visible stuff about Gentoo around here is lame jokes, and another 10% - 15% are people complaining about Gentoo zealots. So don't tell me the pro-Gentoo zealots are annoying you. The anti-Gentoo zealots are much, much more vocal.
--
I've come for the woman, and your head.
Re:Great for Gentoo
by
Solder+Fumes
·
· Score: 4, Funny
I'm so sorry for being distro-ist. I apologize to all Gentoo-Americans for my extreme insensitivity.
Architecture Independence
by
Ford+Prefect
·
· Score: 2, Informative
For some reason, I'm reminded of the platform-independent device drivers and boot code written in Forth in Open Firmware.
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?
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"?
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.
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, 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 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.
-- The Tao of math: The numbers you can count are not the real numbers.
Actually the TinyCC site lists a speedchart at http://fabrice.bellard.free.fr/tcc/#speed 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!
by
Eunuchswear
·
· Score: 5, Funny
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."
Re:Main reason for this?
by
kbahey
·
· Score: 4, Interesting
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:
Optimizer?
by
Anonymous Coward
·
· Score: 2, Insightful
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.
This should go over BIG..
by
murderlegendre
·
· Score: 3, Funny
..with the Gentoo crowd.
The once impossible dream of actually compiling the Linux kernel on every boot is now a shining reality.
-- There's a Starman, waiting in the sky / He'd like to come and meet us, but he hasn't got the time.
Re:What's the point ?
by
Anonymous Coward
·
· Score: 2, Funny
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
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".
--
I don't need no instructions to know how to rock!!!!
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.
Wow. That really is fast.
by
TheRaven64
·
· Score: 5, Interesting
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.
Blatant Karma Whoring: In case of a slashdotting..
by
jimicus
·
· Score: 3, Informative
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.
Re:Wow. That really is fast.
by
TheRaven64
·
· Score: 4, Interesting
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
"The Milliard Gargantubrain? A mere abacus - mention it not."
Yes, it starts booting
by
PhilipOfOregon
·
· Score: 2, Interesting
but when does it *finish* booting?
In Soviet Russia....
by
MetaMarty
·
· Score: 2, Funny
The kernel compiles your bootloader!! Oh wait...
Re:I call shenanigans on this
by
Godeke
·
· Score: 3, Interesting
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.
-- Sig under construction since 1998.
Consumer Devices
by
pritcharda
·
· Score: 2, Interesting
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 necessary)
If you want a more sensible Linux-specific BIOS there's the LinuxBIOS. It looks like its only for clusters but I'd like to get it from my next Linux box.
Re:TCC compiler
by
TheRaven64
·
· Score: 5, Informative
TCC has a few significant drawbacks.
It is not portable (well, technically it is portable, but currently only has an i386 back end).
It only supports C (not a drawback if you are just compiling C, but a lot of projects use C++/Objective-C/Whatever).
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:
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.
It is very fast. The less time you spend compiling, the more time you can spend testing / debugging.
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 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.
REALLY, REAALLLY Useful.
by
torpor
·
· Score: 2, Insightful
It means you can now make a computer that'll only run its own binaries, finally, and not only that but the process that allows it becomes an essential part of the manufacturing/QA stage.
TCCBOOT is what is going to defeat the DMCA, because pretty soon, from firmware on, we can all be encrypting our own executable binaries to a safe and unique internal system key. TCCBOOT makes it possible to integrate even the operating system build into a key-based, locked-down-in-sillicon, complete computing system.
As a manufacturer of equipment, this is exciting to me. As a consumer, it sorta is a bit scarey, but I don't wanna be much of a consumer any more anyway, so I'm not that freaky about it.. as a programmer, this really interests me because it means I could probably make money from software again; it'd mean I'd have to *only distribute source* (i.e. the death of precompiled binaries), but then, I like that anyway, being an F/OSS activist, as I am..
TCCBOOT is a big wind in a very small place.
-- ; -- the corruption of government starts with its secrets. a truly free people keep no secrets.
--
My computer runs this neat program called ScanDisk like 5 times(just to make sure) before I can ever get it to do anything useful, so there's no way MY OS can crash once it's up and running.
-- I'm determined to reclaim my karma. Now, if I can only find a groundbreaking article and something witty to say....
How did that get "insightful"?
by
khasim
·
· Score: 2, Insightful
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, but only if you have an admin who can babysit it and solve problems without rebooting.
There's no need to "babysit" Linux. Once you've set it up correctly, it keeps running.
I'm not an admin, and I don't have time to figure out why "dhcpcd" or "dnsmasq" decided they dont need to spawn anymore.
There's a problem waiting to happen. Will you know if you've setup something wrong on your firewall and you get cracked?
Rather, you are a good example of why ISP's need to offer "managed" services. The Internet is not a safe place to connect a computer and too many people are unwilling to take the time to learn how to protect their systems.
Less than perfect first impression
by
dbrower
·
· Score: 2, Informative
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.
-- "It if was easy to do, we'd find someone cheaper than you to do it."
You might want to think about that.
by
khasim
·
· Score: 2, Insightful
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 change ___ (which just means you don't know where to look), how it crashes non-stop, how it's so slow, et cetera.
Ugly is a matter of opinion.
The useless crap can be removed, UNLESS you're talking about IE which is a problem because it is bolted to the OS which makes the security problems in IE operating system holes.
The crashes can usually be mitigated by rebooting the system. Remember, Microsoft has issued a couple of service packs to deal with problems such as that. Until you get the service pack that fixes the crash bug you're experiencing, you don't have much in the way of options, do you?
None of it is true if you have any idea at all what you're doing, but more often than not some moron whining about how Windows crashes all the time (i have never once had Windows XP crash, and i've been using it continuously since the beta versions) will get his post modded up insightful. -___-
What that actually means is that you've never triggered any of the crash bugs that Microsoft has admitted to.
If you don't use a sub-system that has a crash bug in it, is it because you know how to use Windows or because you are avoiding those bugs?
(This doesn't necessarily reflect on you, per se, but your 'only know Windows' comment leads me to believe that you might be one of these people after all, because i know i certainly don't fix problems by just rebooting.)
The problem with Windows is that it isn't designed for easy diagnostics. It is easier to just reboot it than to actually find the problem.
With Linux, the diagnostic process is easy.
Go ahead. Show that I'm wrong. What would you do if you were getting a blue screen on startup with a message about the software hive?
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.
Perl5 does the same thing. read, compile, run..
So what are the uses for this?
-
ping -f 255.255.255.255 # if only
Why would anyone *possibly* want their bootloader be able to compile the kernel?
How long does it take to boot Gentoo?
If only they could apply this to compiling the rest of Gentoo . . .
does it run Linux?
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.
Javascript + Nintendo DSi = DSiCade
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
Please read my Canon EOS tech blog at http://www.everyothershot.com
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.
See what I've been reading.
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.
- It's not the Macs I hate. It's Digg users. -
Now they can compile their kernel with "-mday=Wednesday" for even better optimization.
For some reason, I'm reminded of the platform-independent device drivers and boot code written in Forth in Open Firmware.
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?
Tedious Bloggy Stuff - hooray?
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"?
www.eFax.com are spammers
Recompile your programs EVERY TIME YOU RUN THEM.
Ricers Rule!
Watch this Heartland Institute video
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."
When things get complex, multiply by the complex conjugate.
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.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
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.
..with the Gentoo crowd.
The once impossible dream of actually compiling the Linux kernel on every boot is now a shining reality.
There's a Starman, waiting in the sky / He'd like to come and meet us, but he hasn't got the time.
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
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".
I don't need no instructions to know how to rock!!!!
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.
I am TheRaven on Soylent News
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.
I am TheRaven on Soylent News
Well, maybe a BIOS-integrated Emacs automatically launches and allows you to edit the code ...
The Tao of math: The numbers you can count are not the real numbers.
Java
"The Milliard Gargantubrain? A mere abacus - mention it not."
but when does it *finish* booting?
The kernel compiles your bootloader!! Oh wait...
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.
Sig under construction since 1998.
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 necessary)
cheap labor conservatives - they want to keep you hungry enough to be thankful for minimum wage.
If you want a more sensible Linux-specific
BIOS there's the LinuxBIOS.
It looks like its only for clusters but I'd
like to get it from my next Linux box.
- It is not portable (well, technically it is portable, but currently only has an i386 back end).
- It only supports C (not a drawback if you are just compiling C, but a lot of projects use C++/Objective-C/Whatever).
- 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:I am TheRaven on Soylent News
http://fabrice.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.
It means you can now make a computer that'll only run its own binaries, finally, and not only that but the process that allows it becomes an essential part of the manufacturing/QA stage.
..
TCCBOOT is what is going to defeat the DMCA, because pretty soon, from firmware on, we can all be encrypting our own executable binaries to a safe and unique internal system key. TCCBOOT makes it possible to integrate even the operating system build into a key-based, locked-down-in-sillicon, complete computing system.
As a manufacturer of equipment, this is exciting to me. As a consumer, it sorta is a bit scarey, but I don't wanna be much of a consumer any more anyway, so I'm not that freaky about it.. as a programmer, this really interests me because it means I could probably make money from software again; it'd mean I'd have to *only distribute source* (i.e. the death of precompiled binaries), but then, I like that anyway, being an F/OSS activist, as I am
TCCBOOT is a big wind in a very small place.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
My computer runs this neat program called ScanDisk like 5 times(just to make sure) before I can ever get it to do anything useful, so there's no way MY OS can crash once it's up and running.
I'm determined to reclaim my karma. Now, if I can only find a groundbreaking article and something witty to say....
I have problems with Comcast. But I only have to tell people to reset the cable modem. The firewall never has problems.
There's no need to "babysit" Linux. Once you've set it up correctly, it keeps running.
10:15:56 up 156 days, 19:54, 1 user, load average: 0.00, 0.00, 0.02
There's a problem waiting to happen. Will you know if you've setup something wrong on your firewall and you get cracked?
Rather, you are a good example of why ISP's need to offer "managed" services. The Internet is not a safe place to connect a computer and too many people are unwilling to take the time to learn how to protect their systems.
This is fixed by defining __TINYC__ in the rule for bcheck.o, and you get a tcc executable. Trying to remake it with itself
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.
"It if was easy to do, we'd find someone cheaper than you to do it."
Ugly is a matter of opinion.
The useless crap can be removed, UNLESS you're talking about IE which is a problem because it is bolted to the OS which makes the security problems in IE operating system holes.
The crashes can usually be mitigated by rebooting the system. Remember, Microsoft has issued a couple of service packs to deal with problems such as that. Until you get the service pack that fixes the crash bug you're experiencing, you don't have much in the way of options, do you?
What that actually means is that you've never triggered any of the crash bugs that Microsoft has admitted to.
If you don't use a sub-system that has a crash bug in it, is it because you know how to use Windows or because you are avoiding those bugs?
The problem with Windows is that it isn't designed for easy diagnostics. It is easier to just reboot it than to actually find the problem.
With Linux, the diagnostic process is easy.
Go ahead. Show that I'm wrong. What would you do if you were getting a blue screen on startup with a message about the software hive?