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."
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.
Do you actually reboot that often? I'm pissed off if I have to reboot once every 6 months.
There's always an "excuse" to be away from the screen. It's called having a life outside of your computer. If you have let your work enter your personal life so far that you seriously believe you have to be attached you have more problems than you think.
Re:Too fast...
by
OverlordQ
·
· Score: 1, Redundant
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.
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
Anonymous Coward
·
· Score: 0
No! Slashdot/IRC/MSN/AIM/etc is more important than food or sleep!
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!
With boot times getting longer and longer (my system needs 30 seconds just to get to the bootmanager), eventually we're going to spend hours waiting for the damn thing to start up!
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.)
Ah, then you have committed the usual blunder of assuming that a social life is not mutually exclusive to family, and they persuing both doesn't leave a lot of time for sex.
Well, at least once kids and home repairs come along.
-- "Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Hmmm, my work laptop has been recently re-formatted to Win2K. I've been noticing boot times of 2 minutes, 3 minutes, EVEN 5 MINUTES OR MORE! Well, at least that's what it's promising if I send a large sum of money to a certain website.
-- "Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Sex ??
What with the vast world of online pr0n, I have no need to leave my computer for sex......;)
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.
Imagine... if all sysadmins had CS degrees, the majority of all servers would probably be *NIX based, and Code Red wouldn't have happened.
Speaking as a degreed CE, most CS majors _I've_ run into are good at programming FORTRAN but don't have the first clue in troubleshooting a scsi adapter that's heat-creepd off the motherboard.
That's about as broad-brushed a statement as the one YOU just made.
-- "Draco dormiens nunquam titillandus."
Re:Too fast...
by
Fweeky
·
· Score: 2, Informative
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.
I would pin it on two other places: First, certification paper mills that tell you that a housewife can go from 0-$60,000 by just spending two weeks in a class and learning the answers to the MCSE tests. The other would be on the Linux community for "distracting" IT workers from doing their jobs. Too often we hear "Well, we wouldn't have these problems if we used Linux!" Yeah, that's great, when it does everything we need, we'll look into that. In the meantime, stop eschewing everything GUI and figure out that there is an underside to Windows that, if you know what you're doing you can manipulate, surprisingly without having access to any source code whatsoever. Unfortunately, too many people would rather just bitch than learn.
same frightful problem that the developer space deals with, where VB6 allows people to create executables without understanding programming at all
Yes, because only people with CS degrees should be able to create things that might help them be more productive. True that the small VB programs put out by these unwashed masses might be useful from time to time and do exactly what the person wants and no more...but, they're inelegant to the ever-so-helpful developers who are always more than willing to drop everything to create something useful instead of wandering around Slashdot. No, for them, form is much more important than function.
if all sysadmins had CS degrees, the majority of all servers would probably be *NIX based
Yes, because we all know that developers make GREAT sysadmins. I'll give you a clue: developers don't make even LOUSY sysadmins. I'd much rather put a user in charge of a critical system than let a developer touch it. I'm reminded of the infamous Melissa virus...and the programming houses I have friends at who constantly laughed at my use of Exchange instead of a Linux-based solution for my mail. I remember well laughing at their long, long, long hours cleaning up their networks because while I had implemented systems to protect against such attacks, they believed unwisely that Linus would protect them somehow.
and Code Red wouldn't have happened
Huh, odd then as Code Red also affected *NIX servers. Unless Solaris is no longer a *NIX variant? Explain also how the security checklist that comes with IIS provides no less than three checkpoints that would have avoided Code Red (Don't install unnecessary services such as IPP, don't use standard, well-known directories such as the "Scripts" virtual directory, and don't make your directories writable)? Explain also how Code Red was developed based on information from a security patch released by Microsoft a full month prior and therefore came AFTER the patch? Could it be that so many developers in charge of these IIS servers simply followed the wizards to install the servers and failed to follow good post-install security practices? It would be great if you could explain these things in context that makes these issues Microsoft's fault. It would be especially interesting to hear how Solaris being affected by Code Red was Microsoft's fault.
I personally don't know any REAL admin that was affected in any way by Code Red. Those affected were of the "I'm a developer, but I'm also required to be the systems admin as well" variety. Real admins don't blame Microsoft for their problems. They take responsibility for the safety and well-being of their networks and servers and do what they need to to ensure security and availability. Anyone who ever says, "Damn Microsoft for our latest technical woes..." is not a real admin and should be treated with suspicion.
-- Which is more painful? Going to work or gouging your eye out with a spoon? Find out!
http://www.workorspoon.com
I've been using RedHat for a long time, but I had never noticed this. Tab completion works well enough and I don't need to restart services that often (uptime on my server is ~170d and I've had no stalled services in that whole time), so once I learned about the init scripts I didn't really need to go poking around for shortcuts. I like that one, though, and might use it. Thanks.
-- "Anyone that has ever gotten an idea based on any of my work and done something better with it-good for you."--J.Carmack
You almost say that thats a bad thing? Besides you don't need to pee, or get drinks if the things that you have are sufficently close. Drink a bottle of whatever drink and pee it out in the same bottle. Problem solved;-)
Where do you get the idea that CS degree == developer? It sounds like you've pigeonholed about 80% of the CS community into the wrong job.
CS isn't about programming, as many uninformed people tend to think. CS is about learning the mathematics behind languages, logic, and a slew of other things. A CS Major can decide to specify in development, others may choose to go to the database side, another option is communication. The latter is where the true sysadmins are born (unless they hail from pre-historic days, and were around when this stuff was invented).
Believe me, many of those paper-certified people would flop in the earlier parts of a real CS curriculum, which generally requires the minimum of programming (you learn concepts, data structures, etc). Heavy programming shows up once you decide what you want to do, or heavy math does, or heavy... you guessed it, exercise with system administration (which may or may not include sifting through source code.)
Besides, "Developer" is a MS term. I'm doubtful that you have a CS degree (sorry, MS "Developer Certification" is a far cry from that), or if you do, you got it from a second rate institution.
-- You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
Where do you get the idea that CS degree == developer?
When I was in school 13 years ago, CS degrees were for programmers. CMIS (Computer Management and Information Systems) or IT were the degrees that lead you to an administrator's position. It seems times have changed a little bit. Regardless, very little of what I learned in my CMIS program actually helps me in the day-to-day. All of that was theory which has little practical use. Administration and troubleshooting comes from experience.
-- Which is more painful? Going to work or gouging your eye out with a spoon? Find out!
http://www.workorspoon.com
Re:Too fast...
by
Anonymous Coward
·
· Score: 0
All of that was theory which has little practical use. Administration and troubleshooting comes from experience.
Maybe you don't know how to learn from theory and apply what you have learned in practice. Personally, I think this is a skill that can be learned and taught, but I don't see it emphasized much in schools these days. At any rate, I don't think you should be assuming that the theoretical topics covered in you education have "little practical use" in general simply becuase you have not applied them.
no/etc/inittab there to bork your completion, eh? where does init pull its config on your box???
/etc/inittab is not executable. Any decent shell will skip it from the autocompletion. YHL.
--
God, root, what is difference ?
Re:Too fast...
by
Anonymous Coward
·
· Score: 0
I guess we can pin this sort of thing on Microsoft...
No, pin it on the IT worker marketplace. Microsoft just greased the skids for "sysadmin prerequisites" to sink down to zero.
Sure, there is plenty of objective evidence that a properly trained sysadmin will result in some degree of cost savings over untrained help. However, most companies don't know this, and moreover they don't care.
Why don't they care? Because in your average non-tech-oriented firm, $8/hr help is all the help they need. It's expected that there will be occasional downtime, because that's what computers do. But most of the time the machines "just work", without anyone needing to watch over it.
These firms run a huge risk, because if something complex were to occur, they could run up thousands of dollars in consulting fees to fix it. Some companies lose out, and blame "computers" and "software firms" instead of their own foolhardiness. But most companies get away with it.
For evidence, look at the millions of custom-built software installations for mainframe, backoffice, and other applications that are running just fine. No, you can't upgrade them, and yes, things could be more efficient. But they work, and there is no need for a $45k/yr "trained sysadmin" to do anything because Jack the computer boy knows how to restart the Novell server when it dies.
There are two factors that are killing the sysadmin profession. First, popular acceptance of computer problems. Those who realize that these issue can be fixed don't believe that the actual cost is worth hiring a sysadmin. Some of those people are right -- through luck, the actual cost of their inefficient system is less than the cost of a sysadmin. Second, systems are actually getting easier to run, on the surface. Progress is being made in the software business so that $8/hr people can properly install mail servers and web servers without specialized knowledge. They don't do a great job, but it's "good enough."
The reason is simply so that you have one program that you can tell sudo that people can use... last I checked, sudo did not handle wildcards all that well...
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.
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.
Hmm, let me think. Read 200+ MB from disk and compile that versus read ~1.5 MB from disk. Which is going to be faster? They're also running Linux inside an emulator -- TCC needs an already-running kernel. For cold boots, there is no way TCC will be as fast as a precompiled kernel, and I don't see any place that it will be useful.
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.
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.
--
This effectively makes the build process plus the kernel source the kernel. Just like the kernel loading and running can fail, no discs found, or sound card found, so can the build process creating a kernel that will find the disc or sound card.
Yes, but imagin appliying this to modules, you could have a new module installed and compiled directly before insertion.
OK, no real use beyond geek factor and ease of tweaking, but it's still nice
-- Ask 8 slackers a question, get 10 awnsers (a citation, but I can't remember from who)
Source code is generally on a filesystem; you will not get the same behavior from one huge file containing every line of source. The current version of TCC also saves its output to a filesystem. Providing file and memory allocation systems are two of the biggest things a monolithic kernel does. I would say that for PC OSes, the other two are device I/O and IPC, but once you have a file system and memory allocation, you have most of an OS kernel.
Oh, I can think of some novel worms that you could write into this little scheme.
Back in the day you had to trick the kernel into running malware, or gain enough privileges to trick it into loading a module. Now you can write a worm into the Kernel itself!
/There is a particularly nasty chunk of hell waiting for virus writers. I am not one of them.
-- "Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Yes, it's on a filesystem, but if you'd bothered to actually look at the source you would have seen that TCCBOOT includes code to unzip the romfs filesystem and read files from it without any kernel support. And TCC does NOT need to output to a filesystem, it can compile straight to memory and execute the compiled code.
If you seriously think that the approximately 12.000 lines of TCCBOOT code is "most of an OS kernel" you need to have a long look at the core of the Linux kernel some day. Those 12.000 lines contains mostly gunzip, romfs support code, a malloc implementation and a math library.
Of that, less than 500 lines is the filesystem support.
Yes, it's on a filesystem, but if you'd bothered to actually look at the source you would have seen that TCCBOOT includes code to unzip the romfs filesystem and read files from it without any kernel support. And TCC does NOT need to output to a filesystem, it can compile straight to memory and execute the compiled code.
Yes, that covers READING the file, but it doesn't cover how exactly the contents of that file are to be divined from the hardware. It also doesn't cover where the object files for compilation are going to life. Even a ram-disk needs a driver.
2.6.6 is 213MB unpacked. That's just the source, build scripts, and flat-file hardware databases. The compile products (object files) easily blow out to twice that. And the compiler itself consumes a tremendous amount of memory assembling that object files. And then once you have the object files, the linker steps in, which also requires a tremendous amount of memory.
We are talking about consuming 600 MB in just ram disk.
Writing to a disk is a requirement. At least if you want to have any RAM left to boot your OS.
-- "Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Well, boot loader also requires to read the bzImage from the hard drive. I hope you don't think they use a preloaded Linux kernel for that...
As for object files - which word in the phrase "compiles directly to memory" is not clear to you? And do we actually need to store the object files? Couldn't it just be linked on the fly?
As for object files - which word in the phrase "compiles directly to memory" is not clear to you? And do we actually need to store the object files? Couldn't it just be linked on the fly?
No, you can't link on the fly. Linking requires that you have all the object code available for the final product to be able to connect the dots. It's like attaching the hoses and cables of the car before installing the components.
As far as compiling to memory, what part of, 4.8 million lines of code is not registering to you.
In between my last post and this I compiled 2.6.6. The bare source is 233 MB. Compiled, 307Mb. The difference (minus a megabyte or three for the final bzimage and modules) are the object files, dependecy indexes, and other "products" of the compile process. Any RAM based linking would still need to manipulate the same volume of symbols, so you are talking about needing 75 MB just to perform the final link.
And of course the linker will need it's own RAM to work with.
-- "Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Except that code generated by txx is probably quite not as optimized as code generated by gcc. TCC's goal is to be small, and fast, not to generate very optimized code.
I havea hard time seeing the usefulness of this boot-time compile thing, except for coolness factor. It's slower, takes way more space on disk than a binary kernel, and the kernel probably doesn't run quite as good as with a regular compiler.
Yes, that covers READING the file, but it doesn't cover how exactly the contents of that file are to be divined from the hardware. It also doesn't cover where the object files for compilation are going to life. Even a ram-disk needs a driver.
Sigh. No, it doesn't cover reading the file from the hardware because reading the initrd image is the job of the bootloader. Why don't you try learning a bit about the process before spouting crap?
The compile products (object files) easily blow out to twice that. And the compiler itself consumes a tremendous amount of memory assembling that object files. And then once you have the object files, the linker steps in, which also requires a tremendous amount of memory.
TCC doesn't need a separate linker - it can compile and link in one go straight to RAM. It doesn't need to assemble or output object files.
And no, writing to disk is not a requirement - try actually looking at TCCBOOT before you write about it.
You're right it takes a lot of RAM, but it doesn't really matter - this isn't exactly something most people will ever run for anything but testing. And this RAM requirement will be only until the kernel has been compiled, at which point the initrd image and all the RAM used for the compilation can be freed.
I want my bootloader to write the operating system from scratch.
--
Crushing my karma one post at a time.
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.
Yanno, I'm *really* tempted to give this a try just so I can make a new version of/usr/bin/uptime by parsing/bin/uname -v and/bin/date output, and calculating the difference:p
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."
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...
If you even can screw up your Linux install that badly, then that's a very serious design flaw.
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.
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.
Erm...you can do the same thing to Windows NT/200/XP systems. Not that you can recompile your kernel, but you can probably configure the bootloader to load DOS instead of XP.
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.
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...
Haven't you heard of booting from CD? Just boot from CD, mount your hard disks, and fix whatever you screwed up.
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
Anonymous Coward
·
· Score: 0
Linus is my bootloader!
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.
Re:usefulness?
by
Anonymous Coward
·
· Score: 0
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?
by
Anonymous Coward
·
· Score: 0
It doesn't take 15 seconds to boot the kernel
Re:usefulness?
by
Anonymous Coward
·
· Score: 0
ATI drivers DO NOT require compiling 'in' the kernel - they simply need access to the current kernel source, as they are 'kernel' modules.
And that's only if you don't have a distro for which there is a pre-compiled RPM.
You can't compile an SDL program without the system SDL headers, you can't compile a GTK program without the system GTK headers. Stands to reason, doesn't it?
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.
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.
Considering that most sane people use a stock kernel from their distro, this is pointless. For the folks who build their own kernels (self included) this is pointless. Actually it's worse than pointless, it can leave your ass flapping in the wind.
There are so many goofy little things that can go wrong during the build process. How many times have you added a driver to your config file, only to find the build process dies horribly trying to compile it? How many times have you experienced a build that works fine once, then dies, then works again?
And then there is the issue of where exactly you are planning on putting all the object files, index files, temp files, and so on, not to mention the fact that you are relying on this micro-compiler which MAY or MAY NOT work well with future modifications to the code, and may or may not be able to fully exploit your architecture.
This is definitely a nerd mountain.
-- "Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Also, don't forget - not working as root (set up sudo!) - keeping online* and offline backups - keeping a bootdisk/cd - keeping a knoppix cd around - setting up all editors when run by root to create backup files when any file is edited
* = these can be done without needing extra storage space. take advantage of the unix filesystem's hard-link design, and ln (*not* ln -s, but plain ln)!
-- --TheOrangeSquid
Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
You could just have a fairly vanilla kernel handy to boot from.
Of course, you could, for whatever reason, not being able to use it and screw up your regular kernel config at the same time.
But then, you'd have the same risk with tccboot.
Re:usefulness?
by
Anonymous Coward
·
· Score: 0
Actually what I do is keep several old kernels around, that way if something went wrong, you just boot into another one and go again. I actually tend to run out of/boot disk space if I do this more than 20 times, so I have to clean up the boot loader, get rid of old kernels and clean up/lib/modules (get rid of the old loadable kernel modules) from time to time. I always keep at least 3 old kernels around though. If things go really wacky, I use a bootable cd to put my bacon out of the fire.
Re:usefulness?
by
Anonymous Coward
·
· Score: 0
OK, this is one of the greatest things I have ever seen. Very Very Cool.
I vote for all distributions of any linux versions to put this in the root directory by default. Maybe have an explaination of why the file is there inside itself.
Too bad he's already modded down to the gutter before I got a chance to reference Stephenson's Hole Hawg.
Re:usefulness?
by
Anonymous Coward
·
· Score: 0
Point 1. "Making C feel like Perl.." You should never talk that negatively about C again.
Point 2. TinyCC is on the order of several magnitudes faster than gcc, and yes I can give you benchmarks to prove that. It also makes you write non-braindead code. TCC is an ISOC99 compiler, (note that not very many of the projects on *.gnu.org will compile under C99 rules) and the fact that it *CAN* compile the linux kernel with very little patching means that the kernel is at the least C99 compliant and we have another compiler that can handle compiling it.
Other than that, you can pick all you want to, the project still stands as a faster, smaller, more standards compliant compiler than anything else you have out there, and the boot loader, and compiler are very useful for embedded spaces, not to mention giving the slow and bloated gcc a run for it's money on my systems.
Well, IIRC, TinyCC has one optimization option: Size. It only optimizes for the size of the binary, which it is very good at. Fortunately, it does output decently speedy binaries, too........
-- Azh nazg durbataluk, azh nazg gimbatul,
Azh nazg thrakataluk agh burzum ishi krimpatul!
This sig blocked by Slashdot.
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
nick-less
·
· Score: 1
How long does it take to boot Gentoo? look here for exact timings...;-)
Re:What we really want to know is
by
skiman1979
·
· Score: 0, Troll
Aren't these compile time jokes for Gentoo getting a little old? Seems every time there's a story about something compiling, or a story about a linux distribution in general, someone ends up asking how long it will take to do that on Gentoo, or ask if your Gentoo system is still compiling. Even if a Gentoo system takes a while to compile (mostly for big apps like KDE and OpenOffice,) you can still use the system for other activities while you wait. What's the big deal?
-- Having a smoking section in a public restaurant is like having a peeing section in a public swimming pool.
Re:What we really want to know is
by
Anonymous Coward
·
· Score: 0
[TROLL]I hear debian just stepped up to the 2.4 kernel in their latest unstable.[/TROLL]
Re:What we really want to know is
by
Paralizer
·
· Score: 1
It takes the same time as any other distribution; Gentoo is not a kernel.
Re:What we really want to know is
by
lachlan76
·
· Score: 1
You've never done it, have you? I found it to be one of the most excruciating experiences ever.
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.
Re:What we really want to know is
by
SillySnake
·
· Score: 1
We're still waiting.. It's been 9 days so far.. But, the splash screen loaded.. So, a little faster than the average install.
Re:What we really want to know is
by
mattyrobinson69
·
· Score: 1
its not that painful, infact, the universal install (x86) cd includes frame buffer drivers, so you can use links just like a gui browser. it takes a while to finish, but you can browse the net in 16 bit colour, and like i did, use e-messenger.net to talk to my friends on msn messenger.
i upgraded kde from within kde (emerge sync ; ACCEPT_KEYWORDS="~x86" emerge -u kde), which allowed me to continue as i was, until i had to restart the x server to use the new kde once it had finished.
Re:What we really want to know is
by
Tony+Hoyle
·
· Score: 1
So you've recompiled the kernel, and used precompiled binaries for everything else.
That means you have *not* compiled gentoo. In fact you've lost the whole point of running it because you've used someone else's binaries - might as well have used debian.
On an amd64 it takes about 3 days to take gentoo from stage1 to something that runs. That doesn't include KDE, only X (since for some insane reason links on gentoo is dependent on X, you can't even browse during those 3 days).
Last time I tried it KDE wouldn't even compile on amd64, and they didn't support Kerberos or Ldap. That was a few months ago though. Haven't tried since - I can have a working debian in 15-30 minutes and my time is valuable.
Re:What we really want to know is
by
RangerRick98
·
· Score: 1
since for some insane reason links on gentoo is dependent on X
I suspect the reason for that is that you had X in your USE variable when you tried to emerge links. It probably would've emerged just fine by itself with a `USE="-X" emerge links`. Having never done it myself, however, I'm just assuming.
-- "You're older than you've ever been, and now you're even older."
Re:What we really want to know is
by
quantum+bit
·
· Score: 1
On an amd64 it takes about 3 days to take gentoo from stage1 to something that runs. That doesn't include KDE, only X (since for some insane reason links on gentoo is dependent on X, you can't even browse during those 3 days).
3 days?! What is gentoo bundling in the base that make it that long? My freebsd system only takes about 45 minutes to buildworld. Even all of KDE takes less than 24 hours...
Re:What we really want to know is
by
skiman1979
·
· Score: 1
I understand what you're saying. However, if I understand correctly, once Gentoo is installed with binary packages, the entire system can be recompiled while I do other things like browse the web. Of course, a stage3/GRP installation takes a bit of time as well, but if you want to have a usable system sooner, you could always boot off another distro (KNOPPIX) and use its tools to browse the web or whatever while doing a stage1 install of Gentoo on the HD. That method would give you a working system faster than installing Debian, depending on what functionality you wanted during installation.
Yeah, I could just install Debian instead, but I'm already more familiar with emerge and portage, so there's no real need to switch. I can get a working environment in a fairly reasonable amount of time (moreso with something like knoppix) and then recompile everything in the background.
-- Having a smoking section in a public restaurant is like having a peeing section in a public swimming pool.
Re:What we really want to know is
by
Teraiten
·
· Score: 1
Install Gentoo from a knoppix environment. You can even play some games while you let it compile in a minimized terminal window.
I surfed web, chatted with friends and posted on slashdot without problems while I waited for it to finish compiling. That made it much more bearable. And it's not something you do every week... I mean, if you do, you probably have a fully functionable computer standing nearby.
Re:What we really want to know is
by
wastaz
·
· Score: 1
The reason why links is requiring X is that you've got "+X" in your USE flags and that links has a graphical mode which is a real X-application and shows images and all of that fun stuff. Just emerge links with 'USE="-X" emerge links' and you wont have to compile X to compile links. I mean, its not like you actually need the graphical links.
Oh, and what's so wrong about lynx?!
Re:What we really want to know is
by
mattyrobinson69
·
· Score: 1
i didn't have a spare computer, and last time i installed gentoo, i wanted to do it by the (quick install) book. Next time, i'l be installing it from within a different distro (i switched from slackware last time).
Its not as bad as people make out though.
Re:What we really want to know is
by
lachlan76
·
· Score: 1
I did it from Knoppix, but it crashed about 15 seconds from bootstrap. And then 6 hours into OpenOffice. AND 90mins into KDE.
And anyway, I had to go to school, which slows things down.
Hmm
by
Anonymous Coward
·
· Score: 4, Funny
If only they could apply this to compiling the rest of Gentoo . . .
Re:Hmm
by
Anonymous Coward
·
· Score: 0
If only they could apply this to compiling the rest of Gentoo . ..
Do you really want a 36 hour boot sequence?
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.
Re:Do you know what this means?!
by
Anonymous Coward
·
· Score: 0
P-Code? But then shouldn't we allow linux contributions in Pascal?:-P
Re:Do you know what this means?!
by
SpaceLifeForm
·
· Score: 1
You'll always need binaries. You'll need your
base toolchain as binary in order to compile anything (including a new toolchain).
-- You are being MICROattacked, from various angles, in a SOFT manner.
Re:Do you know what this means?!
by
Rentar
·
· Score: 1
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 tccboot is in any way good for cross-platform stuff. If I wanted cross-platform I would have written in a high-level language that was designed to be cross-platform (Python, Ruby, Java, C#, Perl, Brainfuck... pick your poison).
Don't misunderstand me: tccboot is cool and it has a quite high geek value, but it's not The Next Big Thing!
Re:Do you know what this means?!
by
Anonymous Coward
·
· Score: 0
Brainfuck is a high-level language??
Re:Do you know what this means?!
by
cortana
·
· Score: 1
You have just desribed Lisp, Python, Perl, etc...... and then you describe Java, Mono, etc...
Re:Do you know what this means?!
by
vidarh
·
· Score: 1
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:Do you know what this means?!
by
RWerp
·
· Score: 1
Yeah, but that means adding some tens of MBs (kernel source, packed) to the bundle.
-- "Long run is a misleading guide to current affairs. In the long run we are all dead." (John Maynard Keynes)
Re:Do you know what this means?!
by
pclminion
·
· Score: 1
This could allow for platform independent Linux programs!
That would be an interesting idea, except that TCC only targets Intel chips.
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.
It does. Hardly any "real" compiler compiles directly to the target instruction set -- it usually transforms the input into pseudo-machine-instructions, called "quads" or "3-address-ops". Code optimization occurs on these pseudo-instructions before it ever gets translated to the actual instruction set (although there are also optimization applied to the particular instruction set as well). Check out the -d* switches to GCC. It can dump the internal representation at many different stages in the compilation process.
It probably wouldn't be hard to customize GCC to read those dumps back in and start the compilation process from that point.
Re:Do you know what this means?!
by
AKAImBatman
·
· Score: 1
That would be an interesting idea, except that TCC only targets Intel chips.
That's probably a temporary issue. Someone already mentioned ARM support being available.
It does. Hardly any "real" compiler compiles directly to the target instruction set
I know. Where do you think I got the idea from?:-)
The way I see it, a few minor modifications to GCC and the OS would allow for truly platform independent binaries. When the user installs the program, the GCC on their end would pick up the intermediary code and finish the compile. Voila! One cross-platform binary.
The only thing that worries me are the darn pre-processor instructions. If the preprocessor tailors the code to the platform, then it simply isn't portable at all.:-(
Re:Do you know what this means?!
by
Anonymous Coward
·
· Score: 0
"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."
That's never been thought of before *cough*Java*cough*...
Re:Do you know what this means?!
by
AKAImBatman
·
· Score: 1
The idea is that you don't have to rewrite your existing C/C++ programs. i.e. I could make a Mozilla or OpenOffice binary that works on all platforms. This would allow me to switch out the hardware architecture at a whim and still provide customers with backward compatibility. Better than modifying the chip to run old op codes, anyway.
I seem to remember that IBM has an OS out there that already does this. I can't remember what it is, though.
Re:Do you know what this means?!
by
alder
·
· Score: 1
LLVM does exctly that. Though it calls itsel a "compiler infrastructure" or a "ompilation framework" it defines a low-level language, which can be used as intermidiate language in compilers, yet has an external (on-disk) bytecode representation that can be interpreted, JIT-ed, or compiled on a target system. The language is an SSA based representation, so the final compilation can perform various target specific optimizations.
Just-in-time compilation
by
Anonymous Coward
·
· Score: 0
How does it deal with
someint = *null_pointer;
then? A LaTeX-style command prompt?
Re:Just-in-time compilation
by
maxwell+demon
·
· Score: 4, Funny
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.
Re:Just-in-time compilation
by
Anonymous Coward
·
· Score: 0
In regards to your sig, don't you think we realized that already? Why do you think we signed up for subscriptions? To get F1RS7 P0S7 B4BY!!
Now, if I could just figure out a way to have that "Post Anonymously" button ticked automatically.
Re:Just-in-time compilation
by
ricklow
·
· Score: 1
If you've got Emacs in the BIOS, then you don't need Linux, do you?
-- "Oh God help us. We're in the hands of engineers."
Re:Just-in-time compilation
by
iluvcapra
·
· Score: 1
Awesome, I finally have a use for that Emacs NES cartridge I got all those years ago at Funcoland.
-- Don't blame me, I voted for Baltar.
Re:Just-in-time compilation
by
Anonymous Coward
·
· Score: 0
If they could get emacs to even launch in 15 seconds, now you've got somthing.
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 ?
-- Trolling using another account since 2005.
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
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.
With the 2.6 kernel, dependencies are handled much better than in 2.4. The amount of time waiting for a compile after changing a file (as long as it's not a core header) is pretty negligible these days.
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.
It's always possible it's a source bug, but we've only ever had minor trouble on ancient vendor unix compilers.
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...:)
Re:I'm trying to think of a reason why ...
by
mkro
·
· Score: 1
Sounds perfect for a Gentoo live cd;)
-- I shall go and tell the indestructible man that someone plans to murder him.
Re:I'm trying to think of a reason why ...
by
Anonymous Coward
·
· Score: 0
You definately wouldn't be using TCC if you wanted performance improvements.
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. -
Re:Not a complete compile
by
Anonymous Coward
·
· Score: 0
- It's not the Macs I hate. It's the Mac users. -
Don't generalize. Don't categorize. Don't hate.
No. Fucking. Way.
by
Anonymous Coward
·
· Score: 0
It takes that long to just read all the files in the kernel source tree. There is no way this thing does what it says.
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
Anonymous Coward
·
· Score: 0
> Now they can compile their kernel with "-mday=Wednesday" for even better optimization.
lol.
Re:Great for Gentoo
by
Anonymous Coward
·
· Score: 0
while that comment was slightly funny, get over it already. if you don't want to compile your applications from source don't but for the love of god, WHY make fun of others that do? its simply ignorant and shows that you lack a adequate understanding of why someone might want to do such an activity. grow up.
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.
Re:Great for Gentoo
by
Anonymous Coward
·
· Score: 0
and also the fact that you use gentoo...?
Re:Great for Gentoo
by
Anonymous Coward
·
· Score: 0
The anti-Gentoo zealots are much, much more vocal.
maybe because the Gentoo zealots are busy right now compiling the latest firefox
sorry, couldn't resist
I apologize. That wasn't a rant specifically against you, but against people here in general.
From what I've seen, the people complaining about some annoying group are always more vocal and annoying than the original group itself. But I guess that's true almost anywhere.
Anyone who thinks about posting some "Gentoo zealots annoy me" crap (including people who have that in their signatures)
I believe you're talking about me.
Well, you'll find they come out a lot when new software is released.
For example, GZ posts often look like this:
I'm already emerging it. Guess the rest of you guys will have to wait...
I see a lot more Gentoo Zealots these days in other websites like OSNews, for example.
I have nothing against Gentoo--in fact I used LFS systems exclusively for about six months. I really only see a zealot come around about once a week these days--I just keep the signature because of all the replies that create a Gentoo plug out of whatever the topic at hand is.
I applaud Gentoo developers--it's a very well maintained distribution. I've heard horror stories of people having systems breake with a single emerge command, and I personally wouldn't use Gentoo because it does too much hand holding, but hey, to each his own.
-- Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
"Well, you'll find they come out a lot when new software is released.
For example, GZ posts often look like this:
I'm already emerging it. Guess the rest of you guys will have to wait... "
I see. So in rebuttal, we must post 5,000 posts in every Linux (or even not Linux) article about how the Gentoo users are still compiling something, or whatever. Rigth?
I've used Gentoo for quite awhile- it's really pretty good if you give it a chance. Compile times are only bad if you're trying to run Linux on a Pentium 233MMX chip because your Athlon 64 is too busy running Windows XP. With a new system, even X compiles in minutes, not hours.
So it's all blown out of context in one big viscious clusterfuck of a circle. Anti-Gentoo Zealot Zealots bitch about Gentoo, and the Gentoo Zealots are forced to prove Gentoo is good, and meanwhile any of the non-zealot Gentoo users are flamed when they mention it.
Okay, well I promise not to post jokes and complaints about it in every damn article on Slashdot. I wish we could say the same about the people I'm complaining about.
--
I've come for the woman, and your head.
Re:Great for Gentoo
by
Anonymous Coward
·
· Score: 0
By "compiling" do you mean "reading the source and writing equivalent machine code by hand"? Because I think that's the only way "compiling" could make someone "busy".
Heh, I use Crux, a source based distribution, and have been building systems from scratch for a while.
There's nothing new to me in Gentoo.
-- Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
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?
I've always wanted one of those...
by
pyro+jackelope
·
· Score: 0
Hmm...it boots up really fast...but how quickly does it shut down? Sounds like something a nerd invented so he can hide his porn habits from his parents =D. JK/JK...really sweet though. And what's this about a 2.4 ghz p4? Yeah, those were cool a couple months ago =D. They can run what...solitaire?;-).
-- 28:06:42:12 - That is when the world will end...
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.
Here 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 compilation.
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.
-- I submitted this story last night, and it didn't get posted.
Re:How?
by
Anonymous Coward
·
· Score: 0
In reality it isn't at all that incredible. C is pretty fast language to compile if you don't care about optimization or aim to support bazillion different platforms. People have just been used to dog slow gcc -O3.
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
Re:How?
by
Anonymous Coward
·
· Score: 1, Informative
Yes the otcc entry to the ioccc was the beginnings, but the compiler it'self grew out of Fabrice Bellard wanting an ISOC99 compiler that was faster than gcc and other compilers on the market. And well damnit, he did it, it's a beautiful compiler, and the only compiler in the world AFAIK that will let you avoid the compile step in the development process by putting for example #!/usr/bin/tcc -L/usr/lib/python23 -lpython23 as your first line and let it do the compile execute process without dumping the binary. That believe it or not has come in handy for quicker devel time. At least for me.
Re:How?
by
Anonymous Coward
·
· Score: 0
Yep, I think 4 is a much too small factor. I think it is closer to an additional factor of two per processor generation. That is, roughly a factor of 4 (probably slightly below 4) just to get to the first generation of Pentium, and then there is the P2, P3 and P4 too...
At least AMD had a 40MHz 386. I still have a 12 year old computer based on that CPU. That was also the first computer I installed Linux on back in -93. Bet I could still install a modern Linux on it with no problem (but it does have more RAM now than it had back then).
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."
I think the main thing here is the TCC compiler, which is 100K or so, and very fast.
I'd rather have a slow compiler that generates fast code than a fast compiler that generates slow code.
Re:Main reason for this?
by
captaineo
·
· Score: 1
For releases, yes. But for shortening the compile/run/debug cycle a faster compiler would be great.
Re:Main reason for this?
by
Anonymous Coward
·
· Score: 0
I'd not. For 99% of code it's irrelevant whether it uses X units of cpu time or 2X. The rest 1% should be isolated so that it can be compiled with different options/compiler/etc.
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:
Re:Main reason for this?
by
Anonymous Coward
·
· Score: 0
And here I'd just use csh;-)
Re:Main reason for this?
by
Minna+Kirai
·
· Score: 1
Something that was unthinkable under GCC.
The concept would work better with ccache. The compile delay only happens on the first execution, and subsquesent ones are fast, not only to start, but also to execute (because the code has been optimized as normal)
When I first read that comment, I thought cool, independent LiveCDs... but the bootstrap procedure is still architecture-dependant. Whatever program does the on-the-fly compiling, it will need to be architecture-specific.
Correction. TCC now generates code for ARM,
which is new in this latest version.
-- You are being MICROattacked, from various angles, in a SOFT manner.
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.
Slashdot v. Freshmeat
by
Anonymous Coward
·
· Score: 0, Troll
Have we really devolved to the point we have nothing but project announcements? Surely there's news of substance, but if there isn't, why not keep yesterday's important news on the front page? This "story" is absolutely nothing but a project announcement. It's nothing new, nothing special, and nothing newsworthy. How many people here read USA Today for the ads? If you do, would you still do it if you could get just the ads without the news?
Its called a tech site. Thats the beauty of the internet, if you dont like it, go off and log into jackballs.com or something.
Re:Slashdot v. Freshmeat
by
pclminion
·
· Score: 1
Have we really devolved to the point we have nothing but project announcements?
If what I wanted was a product announcement, I would read Freshmeat. I come to Slashdot because of the discussion attached to the stories.
Apparently you do as well, since you are, after all, posting in the comment forum, so I'm left wondering... Why the fuck do you bother?
I call shenanigans on this
by
Weaselmancer
·
· Score: 1, Interesting
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.
Re:I call shenanigans on this
by
stratjakt
·
· Score: 1
That's because you're using GCC.
The submission is misleading, it takes 15 seconds for TCC to compile the kernel (without modules and just enough support to read the HDD). They just jammed the compiling into boot time. So 15 seconds from when your POST screen clears to the time the machine actually starts booting the kernel.
Boot time would still be measured in minutes, it doesn't magically make init.d or all the other crud load up fast.
--
I don't need no instructions to know how to rock!!!!
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.
Re:I call shenanigans on this
by
Anonymous Coward
·
· Score: 0
You need to realize that most time in a compiler (on a large source) is spent optimizing. If you don't optimize, you can be very fast (in fact, you can just output asm/binary as you parse). TCC sounds like it's written to be small and fast, which probably sacrifice things we take for granted in a production compiler; standards compliance and optimizations (which in itself req. a different internal representation of the code which might not be speed efficient to build/traverse)
Re:I call shenanigans on this
by
ciupman
·
· Score: 1
It doesn't compile the whole kernel.. just the the main core and some drivers, wich will be sufficient to boot the machine, start the init process and then a shell! In my AMD XM 2.5 (mobile) inside a VMWare machine it takes 20 to 30 seconds to compile and run! Before posting you should've tried it yourself!
-- I fuse with Mercer every single day...
Re:I call shenanigans on this
by
ciupman
·
· Score: 1
Make it AMD XP and not XM...
-- I fuse with Mercer every single day...
Re:I call shenanigans on this
by
Anonymous Coward
·
· Score: 0
IIRC tcc does do some native x86 optimizations, and if so, it's doing a bit more than just parse, and output asm/binary. and as for standards compliance, tcc is an ISOC99 compiler, you don't have to turn that on via a command line argument like gcc, it's just standards compliant. period. (for all of you going, "command line argument?" look in the man page of -std, many CFLAGS lines use -std=gnu99 which will still let you do inline assembly, something that was never part of the C language among other things, gcc does however also support -std=c99 but the fact that I have to explicitly state that my compiler should be standards compliant instead of having that as the default behaviour disturbs me.)
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:This should go over BIG..
by
Anonymous Coward
·
· Score: 0
wow, your impossibly accurate wit is amazing.... except that you are like the 15th comment about Gentoo. next time show up on time and you won't look like a total jerk by doing nothing but hurting the linux community as a whole! If you don't want to compile your software youself, then don't. but get over that fact that other people take advantage of such an activity. grow up.
Re:This should go over BIG..
by
Anonymous Coward
·
· Score: 0
Hardly. The benefit of Gentoo is that compiling programs specially for your hardware makes them faster on your hardware. A C compiler this fast and small isn't doing a lot of platform-specific optimization.
Re:This should go over BIG..
by
Anonymous Coward
·
· Score: 0
..with the Gentoo crowd.
Not unless TinyCC supports the -funroll-loops switch.
Re:This should go over BIG..
by
Anonymous Coward
·
· Score: 0
I do that anyway. My pc only reboots when it needs a new kernel:p
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!!!!
Re:Wha?
by
Anonymous Coward
·
· Score: 0
wow really sad that you know nothing about the linux kernel that you are making it take forever for booting.
From a CF card in a CF-IDE drive adapter in a box destined as a firewall I have a linux kernel booting in 25 seconds flat. that is from power on to firewall up and running processing and transferring traffic.
I suggest you learn how to deal with the kernel and your init on how to reduce load times.
I also do not use the insane init as found in mandrake and redhat. I use a slackware style init, use busybox for my shell and tools and am able to run the firewall in 32 meg of ram with memory to spare to run a junkbuster proxy on the firewall.
Oh, this is also a Pentium I 166 non MMX.
so either your linux kernel skills are in need of education or your 3.06P4 is an absolute piece of crap.
You are probably running fsck on all of the partitions after you reboot. Just hitting the reset button is an unclean shutdown. You could try dropping apache on it and write a quick cgi script to restart your daemons.
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?
by
Anonymous Coward
·
· Score: 0
It sounds like you're running Mandrake and doing unclean shutdowns or something, my boxes are up rapidly because they run custom kernels with hacked up inits and no X or other crap. The boot speed of your mandrake box (you did set the timeout on your bootloader?) is no reason to be saying 'linux boot time... sucks', mandrake boot time may suck buts that's another matter.
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?
-- Vintage computer games and RPG books available. Email me if you're interested.
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".
So restarting all the services on the box should be faster than restarting a single service? Doesn't that require all the other services to manage to restart themselves in negative time?
Or is it the time taken to type all commands compared to hitting a button? Ever thought of writing a script and binding it to key, or even a button you've attached to the machine? That would seem to solve your problems without having to completely optimise the boot process of the linux kernel, the init scripts, and all services being run by several order of magnitude.
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
After however long it normally takes. It spends 15 seconds compiling the kernel and then boots in the ordinary fashion.
-- I am trolling
In Soviet Russia....
by
MetaMarty
·
· Score: 2, Funny
The kernel compiles your bootloader!! Oh wait...
Re:Wow! Ultimate Gentoo!
by
maxwell+demon
·
· Score: 1
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.
-- The Tao of math: The numbers you can count are not the real numbers.
Reading comprehension is a lost art......
by
Anonymous Coward
·
· Score: 0
Next time read it twice or three times before opening up your reply box...
and STARTS to boot in less than 15 seconds...
compile-time kernel
by
jproffer
·
· Score: 1, Interesting
Hmm very interesting. This could be very useful on embedded systems running linux, using hot-swap or hot-plug technology, and you want to have drivers compiled into the kernel at bootup for faster performance or better stability.
Re:Wow! Ultimate Gentoo!
by
Speare
·
· Score: 0, Redundant
Recompile your programs EVERY TIME YOU RUN THEM.
Oh, you mean like Perl? Or JIT JVMs?
-- [.sig file not found ]
Compiles itself NOT the Kernel
by
PetoskeyGuy
·
· Score: 1
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
by
PetoskeyGuy
·
· Score: 1
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...
Good point. Imagine getting to the point where you can do kernel development and just start qemu to boot and compile the kernel you're working on on the fly...
Testing kernel changes "almost" on the fly can already be done to some extent by compiling the kernel separately, and then starting an emulator or user mode linux, but this could take it one step further.
Please slashback this if it turns out to be untrue.
But...uh ....
by
Anonymous Coward
·
· Score: 0
I can boot Windows from cold metal in 10 seconds.
Specs: 3.4GHz P4, 1024MB Ram, 80GB 8MB 7200 SE WD HDD, etc, etc.
Why is this so special of a story? Just because you can compile code into binaries and then boot from that doesn't mean anything special. Did the article mention HOW MUCH CODE is being compiled? Compiling 10K lines is nothing. Try compiling 15M lines and come back to the show for admittance, kids.
Seriously, how good is the tcc compiler to be used as a default compiler? could it be used as a replacement for gcc (that is so slow)? Does it support debugging information and some optimization?
-- Wondering why i am doing so strange posts? I am trying to get a "+5,Flamebait" or "-1,Insightful" rating.
Re:TCC compiler
by
Anonymous Coward
·
· Score: 0
It's a great development tool but you won't be replacing GCC for production binaries anytime soon.
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.
If you want to compile Objective-C, you can use tcc with the Portable Object Compiler.
If you want to compile C++, there is Lightweight C++, another preprocessor.
Also, you can use tcc as the backend for SmartEiffel.
(You can find any of these via Google.)
Re:TCC compiler
by
Anonymous Coward
·
· Score: 0
As a side-note. C++ cannot be compiled w/ Lightweight C++ [unless it's been revamped].... one major thing that I remember is that the syntax is slightly different in a few places. Other than that, you got it head-on
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_ well under half a minute. For comparison, my system is only a 1.2GHz machine.
It's what happens once/sbin/init has finished loading and starts reading and executing the commands in the/etc/inittab file that seems to take so long as part of a reboot.
By the way, considering that/sbin/init itself is an ELF binary, I don't see any great advantage to being able to recompile the kernel at boot time. There's certainly no portability benefits.
Something fishy...
by
Anonymous Coward
·
· Score: 0
I'm too lazy to check it out, but how can a 5.9M ISO image contain a kernel source tree (30M compressed) *and* boot loader, compiler etc?
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.
Now, the next question is, can you integrate this project into the LinuxBIOS so that it bootstraps the hardware, detects what is there, tftp downloads the source for the linux kernel from a local boot server, compiles an appropriate kernel for the hardware detected, and boots into it? Now that would be cool...
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..
Damn, this guy is a genius, I haven't seen many impressive project lists like this one. And I always thought his name sounded familiar and now I found out why. It seems he also wrote LZEXE over ten years ago, which was used by many people to make their DOS.EXE files smaller. So he's around for quite some time already!
I especially wonder how he can do this all on his own, doesn't he have a job? Or is this his job?:-)
He's also obviously very sick, having won the IOCCC not once, but twice in a row! I looked around, and he seems to be a CS researcher at a French nat'l institute. So, i guess writing useful program is just his hobby;)
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 is, finally, a complete fresh-firmware->compile->boot->operating_system solution. i can imagine this being used in manufacturing, instantly, to do system installs, fresh and clean, from *first power-up*, each system having compiled its own operating system and apps, itself, on production.
why is that good? well, umm.. tinycc is open. i could put encryption in there if i want to..
-- ; -- the corruption of government starts with its secrets. a truly free people keep no secrets.
--
Re:Holy Shit, this is the Coolest Thing Ever!!!!
by
EvilTwinSkippy
·
· Score: 1
I'm not the first to say this. If encrypyion is the solution to your problem, you either don't understand encryption, or the problem.
No matter how good your cipher is, if it contains computer codes it is decoded into plaintext somewhere in the computer's memory. Someone with access to the right equipment will happily trace what is going on inside and copy out the needed data as it goes streaming out from the decryptor.
As far as on-the-spot compiling, your equipment better have a ton of horsepower. We are talking about churning through, and linking, 4.2+ million lines of code. That's a lot of RAM and CPU time for an embedded device.
-- "Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Re:Holy Shit, this is the Coolest Thing Ever!!!!
by
torpor
·
· Score: 1
Someone with access to the right equipment will happily trace what is going on inside and copy out the needed data as it goes streaming out from the decryptor.
yeah, well, pretty much 'soonish' it will mean you'll need a fuck of a lot of really good equipment to do it, because SOC vendors will get online and we'll have your 'encryptor' and 'decryptor' be a few micromillimeters apart from each other.
the fact that you can go from 'CPU firmware' to 'booted OS with Apps' in one fell sweep of a source tree, means you can also easily integrate such a device into a managed software system.
(the way to encrypt software is to keep encrypting software...)
That's a lot of RAM and CPU time for an embedded device.
I was going to knee-jerk "No it isn't!!:P" but then I realized that I have no clue what you're talking about. How much RAM and CPU is in your embedded device?
(mine have lots, and thats why they're embedded)
-- ; -- the corruption of government starts with its secrets. a truly free people keep no secrets.
--
Re:Holy Shit, this is the Coolest Thing Ever!!!!
by
Cyn
·
· Score: 1
by "embedded" he doesn't mean "I sleep with it in my bed".
embedded as in any number of devices that are designed for a specific target purpose with just what they need, and nothing they don't. I'm not going to get into any kind of reasonable definition of it - not worth either of our time.
-- cyn, free software and *nix operating systems enthusiast.
-- Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
The point: code optimization
by
RWerp
·
· Score: 1
A bit offtopic, but: TCC fills the gap left by GCC. The latter was developed as a portable compiler capable of compiling many languages (GCC stands for Gnu Compiler Collection): that means, they had to sacrifice efficiency for the sake of portability. It was good, because it made GNU software more popular. However, there are many poor souls out there who have an x86 and would like to run as efficient code as possible under Linux, without buying some proprietary compiler. Thus, a C compiler written exclusively for x86 architecture (or even especially for AMD CPU's, since Intel gives its ICC compiler for free) would be a Good Thing . TCC is a step in the right direction.
-- "Long run is a misleading guide to current affairs. In the long run we are all dead." (John Maynard Keynes)
I think the question was - what's the point of recompiling for each reboot?
I don't think it's the portability or language-independence that makes GCC as slow as it is, but rather the fact that it hasn't been rewritten from scratch in ages.
Additionally, you can't really compare a simplistic, straightforward compiler to a fully optimizing one. It's always been easy to write a compiler that compiles fast and performs limited optimizations (which are nevertheless "good enough"), but such compilers always avoid the hard optimizations, some of which GCC performs.
The fact that it's language and platform -specific isn't going to make TCC generate better code than GCC without making it much more complex and slower.
Actually I had a quick look at the source code of TCC just the other day. While it is written for the x86-architecture, it seems It would not be very hard to port it to some other architecture, I think it is actually written to be portable (the documentation also indicates this), it just haven't been ported to many other architectures yet.
On the other hand, it seems it does not do as much optimizations as GCC. Thus the simplification and main reason for compilation speedup compared to GCC seems not at all to be that TCC is that much less portable (in fact documentation states that versions targeted towards ARM and TMS320C67xx are coming). It seems it is less optimization and the integration of preprocessor, compiler, assebler and linker within the same program (TCC directly generates an executable from source), that makes it so very much faster at compiling than gcc.
Given that raw CPU performance is not that important for many kinds of programs today since the hardware is getting so fast, a little bit less optimal performance might be acceptable in many cases. I sure know a few situations when I would love to have an ANSI C and/or ISO C complient, free, small and fast compiler.
Actually, I think this is a very cool little compiler with great potential. It is fast, small, it can be used for writing scripts in C, and it seems it can actually be linked into my own programs (libtcc) and allow me to use C as an extension language. Now I just wish there was an m68k version (for my Palm m100) and a SPARC32 version (for may small collection of old SPARCstations) too:-)/Anonymous Coward
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.
--
Re:REALLY, REAALLLY Useful.
by
EvilTwinSkippy
·
· Score: 1
Supplying a complete source to your proprietary kernel doesn't sound like a very secure way of achieving your stated goal.
Much simpler to write your kernel into the BIOS, and have each unit posess a custom build incorporating your key checks with hardware locks elsewhere on the system.
Otherwise it would be short work for someone to simply parse through the code and comment out or write around your hooks.
-- "Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
Re:REALLY, REAALLLY Useful.
by
torpor
·
· Score: 1
Supplying a complete source to your proprietary kernel doesn't sound like a very secure way of achieving your stated goal.
yeah, since i've stated so many goals that you've noticed, i'm surprised you missed the one that says that such a system is to allow the continued-update of custom-compiled code, per machine. on silicon.
okay, if you've got an electron-microscope, its probably going to be fun competing with you, but only if..
-- ; -- 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....
Why? - Explained
by
Anonymous Coward
·
· Score: 0
A bootloader that can compile the kernel is a fascinating idea. The optimal goal would be to have the kernel be recompiled only on a need to basis (ie. hardware changes). Thus when swapping out your graphics card, you would just turn off your machine, switch cards, and then boot. Now your kernel is optimized to your hardware.
I think TCC is a cool project and definitely a useful tool but what does it mean to say it's fast?
The code it makes is very likely not as optimal as GCC can make. Specially something like a Kernel I wouldn't mind some optimizations [even in the form of -O2] And really GCC with -O0 is very fast...
That's like saying memcpy() is the better cipher because it's faster than AES!
You can do that with TCC, though not automatically. TCC comes with a library you can link with to compile C code and execute it at runtime, so you can use C as an extension language for your app and compile it as and when you need it.
OK, so we're all impressed with the speed at which they can compile and boot the kernel. But if we really are looking for speed this is not what we want. TCC generates pretty bad code. So even if the machine is booting quickly every thing else will be slower since the kernel is compiled with a poor compiler.
Duh!
Another gem that shows us exactly how bloated the software we use everyday really is. Way to go!
Soon we will be able to play 3D shoot 'em ups on our 486en! And that's not a joke...a 486 can scream, given proper software.
-- Please correct me if I got my facts wrong.
i'd rather have a more optimized kernel
by
Anonymous Coward
·
· Score: 0
since icc code is meant to speed up the kernel by 10% i have to wonder what the speed of a relativly small compiler project
my understanding is code should be compiled once run often, given new kernels come out at most once a month and you can create modules for new hardware
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.
Re:How did that get "insightful"?
by
lav-chan
·
· Score: 1
But "insightful"? Only if you only know Windows.
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. 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.
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. -___-
(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.)
Re:How did that get "insightful"?
by
BlackHawk-666
·
· Score: 1
i have never once had Windows XP crash, and i've been using it continuously since the beta versions
You're just not trying hard enough. I see WinXP bluescreen once in a while (every six months or so), and I see no end of applications crash out. I've seen it do this on every sort of hardware out there, so it's not _just_ a driver issue. My main Linux server, by comparison, hasn't ever crashed. In fact, I've only ever seen Linux crash once in the four or so years I've been using it. There's the occassional application crash, but that's about it. Also interesting to note, FireFox on Windows crashes on me fairly regularly, but it doesn't on Linux.
-- All those moments will be lost in time, like tears in rain.
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."
I have no time to test it, still I have this question in mind: what about 'make' , 'ldd' and all the other programs that are used in building the kernel? are they all included in the 138Kb that are loaded by the boot loader?
Shame about the name; there was another tiny c
by
dbrower
·
· Score: 1
At the dawn of time, there were two other things called tiny c (small letters), by Scott Guthery d/b/a tiny-c Associates. Both ran on 8080 systems with small memories. One was an interpreter of a small C-like language, that came with full assembly for the interpreter, a listing of the C code from which the assembly was derived, and an excellent loose leaf binder explaining in detail how the whole thing worked. It was a recursive descent parser/interpreter.
I learned a lot from this package in 1980, even though I never had an 8080 to run it on. I hand coded it in assembler to run on Interdata machines instead. Still have the loose-leaf in the garage as a prized memento.
The other was a byte-code compiler for a slightly more expansive language. This ran faster, but I never bought it to see.
-dB
-- "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?
Re:You might want to think about that.
by
lav-chan
·
· Score: 1
If i were getting a blue screen on start-up, i don't think rebooting would fix it, 'cause... it would just take me back to start-up, you know?:/
In any case, i didn't mean to suggest that Windows is flawless or that it will work the same for everyone else as it will for me. But the constant bitching people do about it could, in a lot of cases, be fixed by just learning something about it. e.g., there is absolutely no excuse for whining about XP's (admittedly horrendous) default skin. Three clicks and the fucking thing is gone, Jesus Christ.
Re:You might want to think about that.
by
shyster
·
· Score: 1
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.
Useless, too, is a matter of opinion. And seeing as how ~90% of the market still uses IE, I'd say their opinion overwhelms yours. All OS's have dependencies. And, quite frankly, removing IE and keeping the Windows kernel is not difficult. It's keeping everything that's dependent on IE that's a problem - but I suppose that's why they're called dependencies. (What? *nix has those too? I never knew...)
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?
If you're talking an OS crash...well, then, obviously. It's kind of hard to continue when the kernel has BSOD or a kernel panic. Almost all other crashes can be revived without rebooting. MS releases Service Packs to fix the crash (and add features), not the reboot.
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?
What it usually means is that those crash bugs are so esoteric and out of the mainstream that your chances of hitting one is about 1 in a billion. That's why they escaped MS's testing in the first place. ASP.NET 2.0 currently has 102,000 test cases testing 505,000 scenarios. And it's still in Beta 1 - and isn't a part of the OS. And will be given out for free.
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.
Perhaps you don't find it easy to daignose problems. So, if you think it's easier, then go ahead and reboot. Some of us don't like to reboot Windows or *nix, so you can leave it to us to figure out how to do it without rebooting. Welcome to the world of choice...hope you enjoy your stay.
With Linux, the diagnostic process is easy.
Nice of you to back up that claim.
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?
1. Boot to the aptly named Last Known Good Confinguration.
2. Run Recovery Console chkdsk - since it's usually a corrupt file.
3. Replace from my ERD, or the Repair folder.
4. Copy a software hive from another system.
etc., etc.
And, of course, that's not a problem you reboot to cure. Unless Windows automagically replaces the corrupt file with the LKG copy. Which, come to think of it, I think it does. Yeah - in that case, rebooting is easier than step 1. OMG, MS saved me a keystroke!
If you're point was that the registry is a binary file and can't be fixed with a text editor...well, duh. So are a lot of files in *nix. And it's quite difficult to fix a corrupt text file with a text editor as well.
Re:Wow. That really is fast.
by
Bitmanhome
·
· Score: 1
I ran it under his own QEmu on a 3GHz P4. The Linux image included with QEmu took 4 secs to boot to prompt, while tccboot.iso took about 100 secs. tccboot seems to be a dup of the QEmu sample.
-- Not that this wasn't entirely predictable.
Can someone help me build tcc under Cygwin?
by
toby
·
· Score: 0, Offtopic
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/Toby/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 gcc -O2 -g -Wall -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -o tcc_g tcc.c -ldl tcc.c:48:26: sys/ucontext.h: No such file or directory tcc.c: In function `ieee_finite': tcc.c:914: warning: dereferencing type-punned pointer will break strict-aliasing rules In file included from tcc.c:9137: tccelf.c: In function `resolve_sym': tccelf.c:390: error: `RTLD_DEFAULT' undeclared (first use in this function) tccelf.c:390: error: (Each undeclared identifier is reported only once tccelf.c:390: error: for each function it appears in.) tcc.c: At top level: tcc.c:9277: error: parse error before "ucontext_t" tcc.c: In function `rt_get_caller_pc': tcc.c:9282: error: `level' undeclared (first use in this function) tcc.c:9288: error: `paddr' undeclared (first use in this function) tcc.c:9288: error: `uc' undeclared (first use in this function) tcc.c:9288: error: `EIP' undeclared (first use in this function) tcc.c:9297: error: `EBP' undeclared (first use in this function) tcc.c: At top level: tcc.c:9321: error: parse error before '*' token tcc.c: In function `rt_error': tcc.c:9327: error: `fmt' undeclared (first use in this function) tcc.c:9332: error: `uc' undeclared (first use in this function) tcc.c:9327: error: `va_start' used in function with fixed args tcc.c: In function `sig_error': tcc.c:9347: error: `ucontext_t' undeclared (first use in this function) tcc.c:9347: error: `uc' undeclared (first use in this function) tcc.c: In function `expand_args': tcc.c:10090: warning: dereferencing type-punned pointer will break strict-aliasing rules tcc.c: In function `parse_args': tcc.c:10122: warning: dereferencing type-punned pointer will break strict-aliasing rules tcc.c:10193: warning: dereferencing type-punned pointer will break strict-aliasing rules make: *** [tcc_g] Error 1
-- you had me at #!
Re:Can someone help me build tcc under Cygwin?
by
toby
·
· Score: 1
OK, OK, I should have README:
*** TCC currently only works on Linux x86 with glibc >= 2.1 ***.
-- you had me at #!
Wow that's fast
by
Anonymous Coward
·
· Score: 0
I know it takes me about 15-20 minutes to compile a new linux kernel (with patches). I use GCC. I don't know why you would want to compile a new kernel every time you boot the comptuer though. I think it would be better to just let the boot loader load the kernel into memory and have it load the starting address of the OS initialization routine into the CPU's program counter. How do you run a compiler without a running operating system? Do you try to run the compiler from the bios somehow?
Let's take this technology to an extreme, and see if it enables something like this:
Suppose I create an eVoting machine that uses this technology to compile the kernel and applications whenever the machine is activated, and it doesn't take more than a minute for this to occur.
Now, I submit source code to each group planning to use the voting machine, and to the political parties involved, on a CD. They each have the code audited, and sign off on it. They also retain the CDs. I also post this approved code to my web site, in plenty of time for independent companies to audit the code and raise concerns.
When it's time for voting, all representatives (the parties, the region, and my company) show up with their CDs, and run md5sums from them to make sure they all still contain the correct, approved code.
Then, we put all the CDs in a box, reach in, and pull one out at random. We then use that CD to boot each and every machine in the polling place for that region.
Also, any voter who doesn't trust that the machine is running the publicly-available source code, they can bring in their own source CD (burned from an ISO downloaded from my company's web site), and have it md5sum'd against the CD we used to boot the machines.
For the truly paranoid, one machine would be made available to anyone who then wanted to have the machine booted using their CD instead of ours (assuming, of course, it passed the md5sum). Keeping it to one machine means the lines for average unconcerned voters wouldn't be long, unless a large number of people wanted to self-boot -- and if that were the case, it would make sense to free up more machines for this, as there would be fewer average unconcerned voters using the other machines.
-- Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Well, it's been lovely talking with you.
by
khasim
·
· Score: 1
If i were getting a blue screen on start-up, i don't think rebooting would fix it, 'cause... it would just take me back to start-up, you know?:/
I'd start by hooking another hard drive into that machine and doing a clean install to the new drive. That way you can access the old installation and start the repair process. But that's just me.
In any case, i didn't mean to suggest that Windows is flawless or that it will work the same for everyone else as it will for me.
The main issue that I see is that people are familiar with the architecture of Linux. The same situation with Linux is not difficult to repair. So they compare the two systems and find that Windows is very much lacking.
This is not about being ignorant of Windows.
This is about knowing other systems and seeing how those systems have resolved those problems.
Re:Well, it's been lovely talking with you.
by
lav-chan
·
· Score: 1
I'd start by hooking another hard drive into that machine and doing a clean install to the new drive. That way you can access the old installation and start the repair process. But that's just me.
Or you could just use Knoppix, or... even the Windows XP installation CD?
The main issue that I see is that people are familiar with the architecture of Linux. The same situation with Linux is not difficult to repair.
Well, keep in mind that i wasn't specifically talking about fixing huge flaws in the operating system. I'm not a technician, i don't know that much about drivers and hardware failures and kernel errors and things like that. I just see all this griping on Slashdot all the time about completely trivial things that could be 'fixed' (and some of it isn't even in need of being 'fixed' -- there isn't anything wrong with it, the people bitching just don't like it). Rebooting to fix problems is just one of many many things that i see people talking about all the time.
But what you said doesn't make sense to me. If Linux people think that rebooting is the only (or best) solution to problems with Windows, it is about being ignorant of Windows. If they're doing it just because they're too lazy to figure out how Windows works, OK, feel free to bitch about how Windows doesn't have good error logs or how Windows won't let you do ___ and Linux will or how Windows is sooooooo much more trouble than Linux is, but don't bitch about it not being able to do something at all just because you're too lazy to figure it out (however stupid and illogical it might be).
good
by
Anonymous Coward
·
· Score: 0
I think Linux needs pre-compiling. Why on earth would I want to re-compile thousands of lines of header files for each C file. The way 'make' works on Linux is ridiculous. Sure you can change compile flags on the fly, but are different C files in one make usually compiled with different flags? Is it worth taking 15 minutes to compile a kernel instead of 15 seconds?
If you need references for that statement, then you aren't at a level to comprehend that.
1. Boot to the aptly named Last Known Good Confinguration. 2. Run Recovery Console chkdsk - since it's usually a corrupt file. 3. Replace from my ERD, or the Repair folder. 4. Copy a software hive from another system. etc., etc.
#1. I have never seen this work. Ever.
#2. In my experience it is usually a corrupt hive. Chkdsk won't fix it.
#3. And how many users have current backups? If they had a backup, I wouldn't be called in.
#4. This only works if the systems are almost identical. I've tried this on the same hardware with only a few apps difference and it still wouldn't work. Over time, crap ends up in the hives. The crap from one user won't match the crap from another user. If you want to do this, you'd do better re-installing the OS and apps on a different drive and copying the clean hive over. Too much work.
Particularly when you compare it to Linux where I can boot a CD or floppy and fix any file on the hard drive including the boot files.
While, with Windows, your only option is to have a current backup. Such a shame.
If you're point was that the registry is a binary file and can't be fixed with a text editor...well, duh. So are a lot of files in *nix. And it's quite difficult to fix a corrupt text file with a text editor as well.
Actually, Linux has FEWER binary files necessary to boot and none of those binary files in Linux are difficult to completely recreate and re-install if that is necessary.
Without having a current backup.
Without re-installing the entire OS/apps.
Without needing a second machine similar enough to do an organ transplant.
Linux is easier than Windows.
Re:The sun rises in the East.
by
shyster
·
· Score: 1
If you need references for that statement, then you aren't at a level to comprehend that.
Again. Nice of you to back up that claim. And, you're too ignorant to understand isn't going to cut it. I know that *nix is easier to diagnose in some areas, and Windows in either. By and large, however, it comes down to what you're most familiar with.
1. Boot to the aptly named Last Known Good Confinguration.
#1. I have never seen this work. Ever.
Then you probably haven't tried it enough, don't understand it, or haven't been around long enough.
2. Run Recovery Console chkdsk - since it's usually a corrupt file.
#2. In my experience it is usually a corrupt hive. Chkdsk won't fix it.
Agreed. Usually, the corruption occurs due to a caching or hardware failure. Odds are chkdsk won't fix it - though considering it takes all of
3. Replace from my ERD, or the Repair folder.
#3. And how many users have current backups? If they had a backup, I wouldn't be called in.
Then set up automated backups for them. Regardless, the *.sav files are enough to get you booted with a clean OS. And the Repair folder will be newer than those.
4. Copy a software hive from another system.
#4. This only works if the systems are almost identical. I've tried this on the same hardware with only a few apps difference and it still wouldn't work. Over time, crap ends up in the hives. The crap from one user won't match the crap from another user. If you want to do this, you'd do better re-installing the OS and apps on a different drive and copying the clean hive over. Too much work.
Very little in the Software hive needs to be the same across systems to boot. Location of the Windows folder and possibly Program Files are about the only things I can think of that would be needed. Safe Mode would need even less.
Particularly when you compare it to Linux where I can boot a CD or floppy and fix any file on the hard drive including the boot files.
Ever heard of the Recovery Console, XP Repair process, BartPE, ERD Commander, BlueCon, etc? These are the Windows equivalents of Rescue Linux or Knoppix. Learn to use them.
While, with Windows, your only option is to have a current backup. Such a shame.
You're comparing getting a Linux machine to boot, versus getting a Windows machine to boot and save configuration settings of all your apps. Hardly apples to apples. If your *nix had a corrupt/etc directory, then I think we'd start to see a real comparison.
A possible solution to OpenBoot driver resolution. Many people do not like Forth language as a BIOS boot. Auto- detection at boot time of new hardware, the drivers are compiled during startup, and the modules loaded by the kernel.
Re:How did THIS get "insightful"?
by
batkiwi
·
· Score: 1
10:15:56 up 156 days, 19:54, 1 user, load average: 0.00, 0.00, 0.02
Nice load average there. I'm sure this is a heavily used PDC/file server/some sort of corporate machine and not just some box sitting in your closet doing nothing.
Again. Nice of you to back up that claim. And, you're too ignorant to understand isn't going to cut it. I know that *nix is easier to diagnose in some areas, and Windows in either. By and large, however, it comes down to what you're most familiar with.
No, it doesn't. Someone with the same level of experience in both Windows and Linux will have an easier time diagnosing and even repairing the same problem under Linux than under Windows.
That is because the Windows Registry is extremely brittle. When it breaks, you cannot repair it. You can only restore from a backup or try to copy from another machine.
Then set up automated backups for them. Regardless, the *.sav files are enough to get you booted with a clean OS. And the Repair folder will be newer than those.
Oh dear. Maybe you missed the bit where I said "If they had a backup, I wouldn't be called in."? Yes? Did you? Again, this is just great if the end user has current backups or has had someone make backups for him/her. Oh dear. You mean that Windows doesn't automatically prompt for that? So that would mean that most users don't have a current back up? Oh dear.
The registry is brittle. When it fails (and there are lots of ways to cause it to fail), there is no way to repair it. This is a major design defect in Windows. This defect is not present in Linux.
Linux can be repaired, Windows can only be replaced.
You're comparing getting a Linux machine to boot, versus getting a Windows machine to boot and save configuration settings of all your apps. Hardly apples to apples.
Once a Linux machine is booted, everything can be accessed and repaired. Everything. I can edit and save files. That means I can "save configuration settings of all your apps".
Therefore, it is "apples to apples". So, again, Linux is easier than Windows.
Ever heard of the Recovery Console, XP Repair process, BartPE, ERD Commander, BlueCon, etc? These are the Windows equivalents of Rescue Linux or Knoppix. Learn to use them.
Yep. I've even used them. But, while being able to access the disk allows you to repair a Linux system, it does not allow you to repair a Windows system. Particularly with a corrupted hive.
Very little in the Software hive needs to be the same across systems to boot. Location of the Windows folder and possibly Program Files are about the only things I can think of that would be needed. Safe Mode would need even less.
Ooooh, sorry to tell you, but you're wrong. I've tried swapping the software hive from a Vectra 400 to a d530, both from HP/Compaq. It kept giving blue screens.
The only way to do that is to put another drive in the machine and do a completely new install of Windows. Then you can copy the hive over.
Oh, but that is so much more work than with a Linux system.
And it still doesn't give you the system you had before. All of those apps with all of those registered.dll's just won't work until you re-install them.
With Linux, that isn't ever a problem.
With Windows, you HOPE you have a current, working backup.
With Linux, all you need is a boot floppy/CD.
Re:Wow. That really is fast.
by
_generica
·
· Score: 1
fwiw, it came in at approx 8 seconds on a dual opteron 246 system here
You can read through a slashdot article here about a C/C++ interpreter here.
I wonder how much work it would take to get the kernel to run as interpretted C code?
GNU/Linux
by
Anonymous Coward
·
· Score: 0
There is a much more interesting aspect; before tinycc, Linux could only be compiled with gcc. Therefore, RMS's assertion that it should properly be called 'GNU/Linux' held some water. Now, however (admittedly, after a rewrite of the textutils and binutils), we could escape this quagmire, and when RMS comes along to gripe, we could retort: I'm not running GNU/Linux, I'm running tiny/Linux instead !
Slashdot Mirror
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
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 ?
Trolling using another account since 2005.
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. -
It takes that long to just read all the files in the kernel source tree. There is no way this thing does what it says.
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?
Hmm...it boots up really fast...but how quickly does it shut down? Sounds like something a nerd invented so he can hide his porn habits from his parents =D. JK/JK...really sweet though. And what's this about a 2.4 ghz p4? Yeah, those were cool a couple months ago =D. They can run what...solitaire? ;-).
28:06:42:12 - That is when the world will end...
Is there an advantage in booting directly from the kernel source?
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.
When I first read that comment, I thought cool, independent LiveCDs... but the bootstrap procedure is still architecture-dependant. Whatever program does the on-the-fly compiling, it will need to be architecture-specific.
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.
Have we really devolved to the point we have nothing but project announcements? Surely there's news of substance, but if there isn't, why not keep yesterday's important news on the front page? This "story" is absolutely nothing but a project announcement. It's nothing new, nothing special, and nothing newsworthy. How many people here read USA Today for the ads? If you do, would you still do it if you could get just the ads without the news?
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.
Weaselmancer
rediculous.
..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.
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
Java
"The Milliard Gargantubrain? A mere abacus - mention it not."
but when does it *finish* booting?
The kernel compiles your bootloader!! Oh wait...
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.
The Tao of math: The numbers you can count are not the real numbers.
Next time read it twice or three times
before opening up your reply box...
and STARTS to boot in less than 15 seconds...
Hmm very interesting. This could be very useful on embedded systems running linux, using hot-swap or hot-plug technology, and you want to have drivers compiled into the kernel at bootup for faster performance or better stability.
Recompile your programs EVERY TIME YOU RUN THEM.
Oh, you mean like Perl? Or JIT JVMs?
[
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.
I try to figure out what to do whith this mad project.
The only thing I see for rapid testing of large scale C application like testing an OS.
Maybe to test a kernel new build: rapid boot inside qemu with TCCBOOT. So you don't have to reboot your pc to test your new kernel configuration.
I don't if this scenario is realistic or not...
Other ideas?
Please slashback this if it turns out to be untrue.
I can boot Windows from cold metal in 10 seconds.
Specs: 3.4GHz P4, 1024MB Ram, 80GB 8MB 7200 SE WD HDD, etc, etc.
Why is this so special of a story? Just because you can compile code into binaries and then boot from that doesn't mean anything special. Did the article mention HOW MUCH CODE is being compiled? Compiling 10K lines is nothing. Try compiling 15M lines and come back to the show for admittance, kids.
Seriously, how good is the tcc compiler to be used as a default compiler? could it be used as a replacement for gcc (that is so slow)? Does it support debugging information and some optimization?
Wondering why i am doing so strange posts? I am trying to get a "+5,Flamebait" or "-1,Insightful" rating.
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_ well under half a minute. For comparison, my system is only a 1.2GHz machine.
It's what happens once /sbin/init has finished loading and starts reading and executing the commands in the /etc/inittab file that seems to take so long as part of a reboot.
By the way, considering that /sbin/init itself is an ELF binary, I don't see any great advantage to being able to recompile the kernel at boot time. There's certainly no portability benefits.
File under 'M' for 'Manic ranting'
I'm too lazy to check it out, but how can a 5.9M ISO image contain a kernel source tree (30M compressed) *and* boot loader, compiler etc?
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.
And on the average that means that your junk windows box can be exploited in 30 sec from a cold metal start.
Got Code?
notext
Not P-Code, GCC should compile to Parrot bytecode. Then you just boot into the Parrot VM.
I recompile my kernel every time I boot.
Is this a step in the direction of being able to do an on th4e fly kernel upgrade?
so it takes less time too boot linux then to do a POST on my ASUS P4P800@2.8GHZ...
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.
Are you suggesting that the kernel is line noise, too? ;)
K3n.
bamm!! take that, microsoft!! vmlinuz=undefeatable!
why do i think that this is so cool?
it is, finally, a complete fresh-firmware->compile->boot->operating_system solution. i can imagine this being used in manufacturing, instantly, to do system installs, fresh and clean, from *first power-up*, each system having compiled its own operating system and apps, itself, on production.
why is that good? well, umm
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Mod parent +1000 moronic
Good stuff dude.
Your hybrid is not saving the environment. Its purpose is to make you feel good about buying something.
A bit offtopic, but: TCC fills the gap left by GCC. The latter was developed as a portable compiler capable of compiling many languages (GCC stands for Gnu Compiler Collection): that means, they had to sacrifice efficiency for the sake of portability. It was good, because it made GNU software more popular. However, there are many poor souls out there who have an x86 and would like to run as efficient code as possible under Linux, without buying some proprietary compiler. Thus, a C compiler written exclusively for x86 architecture (or even especially for AMD CPU's, since Intel gives its ICC compiler for free) would be a Good Thing . TCC is a step in the right direction.
"Long run is a misleading guide to current affairs. In the long run we are all dead." (John Maynard Keynes)
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....
A bootloader that can compile the kernel is a fascinating idea.
The optimal goal would be to have the kernel be recompiled only on a need to basis (ie. hardware changes). Thus when swapping out your graphics card, you would just turn off your machine, switch cards, and then boot. Now your kernel is optimized to your hardware.
I think TCC is a cool project and definitely a useful tool but what does it mean to say it's fast?
;-)
The code it makes is very likely not as optimal as GCC can make. Specially something like a Kernel I wouldn't mind some optimizations [even in the form of -O2] And really GCC with -O0 is very fast...
That's like saying memcpy() is the better cipher because it's faster than AES!
Oh and TCC doesn't work on my AMD64
Tom
Someday, I'll have a real sig.
You can do that with TCC, though not automatically. TCC comes with a library you can link with to compile C code and execute it at runtime, so you can use C as an extension language for your app and compile it as and when you need it.
OK, so we're all impressed with the speed at which they can compile and boot the kernel. But if we really are looking for speed this is not what we want. TCC generates pretty bad code. So even if the machine is booting quickly every thing else will be slower since the kernel is compiled with a poor compiler. Duh!
Another gem that shows us exactly how bloated the software we use everyday really is. Way to go!
Soon we will be able to play 3D shoot 'em ups on our 486en! And that's not a joke...a 486 can scream, given proper software.
Please correct me if I got my facts wrong.
since icc code is meant to speed up the kernel by 10% i have to wonder what the speed of a relativly small compiler project
my understanding is code should be compiled once run often, given new kernels come out at most once a month and you can create modules for new hardware
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."
i liking is goat? NO
I have no time to test it, still I have this question in mind: what about 'make' , 'ldd' and all the other programs that are used in building the kernel? are they all included in the 138Kb that are loaded by the boot loader?
Here is a link: TINY_C.ZIP
And to a book about it: Learning C with tiny c
I learned a lot from this package in 1980, even though I never had an 8080 to run it on. I hand coded it in assembler to run on Interdata machines instead. Still have the loose-leaf in the garage as a prized memento.
The other was a byte-code compiler for a slightly more expansive language. This ran faster, but I never bought it to see.
-dB
"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?
I ran it under his own QEmu on a 3GHz P4. The Linux image included with QEmu took 4 secs to boot to prompt, while tccboot.iso took about 100 secs. tccboot seems to be a dup of the QEmu sample.
Not that this wasn't entirely predictable.
Binary directory /usr/local/bin /usr/local/lib /usr/local/include /usr/local/man /usr/local/share/doc/tcc /home/Toby/tcc-0.9.21
Library directory
Include directory
Manual directory
Doc directory
Source path
C compiler gcc
make make
CPU x86
Big Endian no
gprof enabled no
Creating config.mak and config.h
config.h is unchanged
gcc -O2 -g -Wall -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -o tcc_g tcc.c -ldl
tcc.c:48:26: sys/ucontext.h: No such file or directory
tcc.c: In function `ieee_finite':
tcc.c:914: warning: dereferencing type-punned pointer will break strict-aliasing rules
In file included from tcc.c:9137:
tccelf.c: In function `resolve_sym':
tccelf.c:390: error: `RTLD_DEFAULT' undeclared (first use in this function)
tccelf.c:390: error: (Each undeclared identifier is reported only once
tccelf.c:390: error: for each function it appears in.)
tcc.c: At top level:
tcc.c:9277: error: parse error before "ucontext_t"
tcc.c: In function `rt_get_caller_pc':
tcc.c:9282: error: `level' undeclared (first use in this function)
tcc.c:9288: error: `paddr' undeclared (first use in this function)
tcc.c:9288: error: `uc' undeclared (first use in this function)
tcc.c:9288: error: `EIP' undeclared (first use in this function)
tcc.c:9297: error: `EBP' undeclared (first use in this function)
tcc.c: At top level:
tcc.c:9321: error: parse error before '*' token
tcc.c: In function `rt_error':
tcc.c:9327: error: `fmt' undeclared (first use in this function)
tcc.c:9332: error: `uc' undeclared (first use in this function)
tcc.c:9327: error: `va_start' used in function with fixed args
tcc.c: In function `sig_error':
tcc.c:9347: error: `ucontext_t' undeclared (first use in this function)
tcc.c:9347: error: `uc' undeclared (first use in this function)
tcc.c: In function `expand_args':
tcc.c:10090: warning: dereferencing type-punned pointer will break strict-aliasing rules
tcc.c: In function `parse_args':
tcc.c:10122: warning: dereferencing type-punned pointer will break strict-aliasing rules
tcc.c:10193: warning: dereferencing type-punned pointer will break strict-aliasing rules
make: *** [tcc_g] Error 1
you had me at #!
I know it takes me about 15-20 minutes to compile a new linux kernel (with patches). I use GCC. I don't know why you would want to compile a new kernel every time you boot the comptuer though. I think it would be better to just let the boot loader load the kernel into memory and have it load the starting address of the OS initialization routine into the CPU's program counter. How do you run a compiler without a running operating system? Do you try to run the compiler from the bios somehow?
Let's take this technology to an extreme, and see if it enables something like this:
Suppose I create an eVoting machine that uses this technology to compile the kernel and applications whenever the machine is activated, and it doesn't take more than a minute for this to occur.
Now, I submit source code to each group planning to use the voting machine, and to the political parties involved, on a CD. They each have the code audited, and sign off on it. They also retain the CDs. I also post this approved code to my web site, in plenty of time for independent companies to audit the code and raise concerns.
When it's time for voting, all representatives (the parties, the region, and my company) show up with their CDs, and run md5sums from them to make sure they all still contain the correct, approved code.
Then, we put all the CDs in a box, reach in, and pull one out at random. We then use that CD to boot each and every machine in the polling place for that region.
Also, any voter who doesn't trust that the machine is running the publicly-available source code, they can bring in their own source CD (burned from an ISO downloaded from my company's web site), and have it md5sum'd against the CD we used to boot the machines.
For the truly paranoid, one machine would be made available to anyone who then wanted to have the machine booted using their CD instead of ours (assuming, of course, it passed the md5sum). Keeping it to one machine means the lines for average unconcerned voters wouldn't be long, unless a large number of people wanted to self-boot -- and if that were the case, it would make sense to free up more machines for this, as there would be fewer average unconcerned voters using the other machines.
Just a thought. Or a dream.
"the ETA for full boot is almost exactly 1 week!"
Oh wait, that was BSD. "Nevermind."
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
The main issue that I see is that people are familiar with the architecture of Linux. The same situation with Linux is not difficult to repair. So they compare the two systems and find that Windows is very much lacking.
This is not about being ignorant of Windows.
This is about knowing other systems and seeing how those systems have resolved those problems.
I think Linux needs pre-compiling. Why on earth would I want to re-compile thousands of lines of header files for each C file. The way 'make' works on Linux is ridiculous. Sure you can change compile flags on the fly, but are different C files in one make usually compiled with different flags? Is it worth taking 15 minutes to compile a kernel instead of 15 seconds?
Teeheeheee...
Fart Joke...
Nice of you to back up that claim.
If you need references for that statement, then you aren't at a level to comprehend that.
1. Boot to the aptly named Last Known Good Confinguration.
2. Run Recovery Console chkdsk - since it's usually a corrupt file.
3. Replace from my ERD, or the Repair folder.
4. Copy a software hive from another system.
etc., etc.
#1. I have never seen this work. Ever.
#2. In my experience it is usually a corrupt hive. Chkdsk won't fix it.
#3. And how many users have current backups? If they had a backup, I wouldn't be called in.
#4. This only works if the systems are almost identical. I've tried this on the same hardware with only a few apps difference and it still wouldn't work. Over time, crap ends up in the hives. The crap from one user won't match the crap from another user. If you want to do this, you'd do better re-installing the OS and apps on a different drive and copying the clean hive over. Too much work.
Particularly when you compare it to Linux where I can boot a CD or floppy and fix any file on the hard drive including the boot files.
While, with Windows, your only option is to have a current backup. Such a shame.
Actually, Linux has FEWER binary files necessary to boot and none of those binary files in Linux are difficult to completely recreate and re-install if that is necessary.
Without having a current backup.
Without re-installing the entire OS/apps.
Without needing a second machine similar enough to do an organ transplant.
Linux is easier than Windows.
Yeah, but does it boot Linux?
A possible solution to OpenBoot driver
resolution. Many people do not like
Forth language as a BIOS boot. Auto-
detection at boot time of new hardware,
the drivers are compiled during startup,
and the modules loaded by the kernel.
10:15:56 up 156 days, 19:54, 1 user, load average: 0.00, 0.00, 0.02
Nice load average there. I'm sure this is a heavily used PDC/file server/some sort of corporate machine and not just some box sitting in your closet doing nothing.
Hm, well don't I practically do that already? Not for all apps, certainly, but Archive and ROX-Get and other python-based apps at least...
Look out!
Again. Nice of you to back up that claim. And, you're too ignorant to understand isn't going to cut it. I know that *nix is easier to diagnose in some areas, and Windows in either. By and large, however, it comes down to what you're most familiar with.
.dll's just won't work until you re-install them.
No, it doesn't. Someone with the same level of experience in both Windows and Linux will have an easier time diagnosing and even repairing the same problem under Linux than under Windows.
That is because the Windows Registry is extremely brittle. When it breaks, you cannot repair it. You can only restore from a backup or try to copy from another machine.
Then set up automated backups for them. Regardless, the *.sav files are enough to get you booted with a clean OS. And the Repair folder will be newer than those.
Oh dear. Maybe you missed the bit where I said "If they had a backup, I wouldn't be called in."? Yes? Did you? Again, this is just great if the end user has current backups or has had someone make backups for him/her. Oh dear. You mean that Windows doesn't automatically prompt for that? So that would mean that most users don't have a current back up? Oh dear.
The registry is brittle. When it fails (and there are lots of ways to cause it to fail), there is no way to repair it. This is a major design defect in Windows. This defect is not present in Linux.
Linux can be repaired, Windows can only be replaced.
You're comparing getting a Linux machine to boot, versus getting a Windows machine to boot and save configuration settings of all your apps. Hardly apples to apples.
Once a Linux machine is booted, everything can be accessed and repaired. Everything. I can edit and save files. That means I can "save configuration settings of all your apps".
Therefore, it is "apples to apples". So, again, Linux is easier than Windows.
Ever heard of the Recovery Console, XP Repair process, BartPE, ERD Commander, BlueCon, etc? These are the Windows equivalents of Rescue Linux or Knoppix. Learn to use them.
Yep. I've even used them. But, while being able to access the disk allows you to repair a Linux system, it does not allow you to repair a Windows system. Particularly with a corrupted hive.
Very little in the Software hive needs to be the same across systems to boot. Location of the Windows folder and possibly Program Files are about the only things I can think of that would be needed. Safe Mode would need even less.
Ooooh, sorry to tell you, but you're wrong. I've tried swapping the software hive from a Vectra 400 to a d530, both from HP/Compaq. It kept giving blue screens.
The only way to do that is to put another drive in the machine and do a completely new install of Windows. Then you can copy the hive over.
Oh, but that is so much more work than with a Linux system.
And it still doesn't give you the system you had before. All of those apps with all of those registered
With Linux, that isn't ever a problem.
With Windows, you HOPE you have a current, working backup.
With Linux, all you need is a boot floppy/CD.
fwiw, it came in at approx 8 seconds on a dual opteron 246 system here
I wonder how much work it would take to get the kernel to run as interpretted C code?
There is a much more interesting aspect; before tinycc, Linux could only be compiled with gcc. Therefore, RMS's assertion that it should properly be called 'GNU/Linux' held some water. Now, however (admittedly, after a rewrite of the textutils and binutils), we could escape this quagmire, and when RMS comes along to gripe, we could retort: I'm not running GNU/Linux, I'm running tiny/Linux instead !
The ultimate would be to compile the program while you run it, i.e. a JIT C compiler.
DynamoRIO
As in, "#!/usr/bin/tcc -run", which they already implement. You're way too slow.