Slashdot Mirror
PC Makers Try To Pinch Seconds From Their Boot Times
Some computers are never turned off, or at least rarely see any state less active than "standby," but others (for power savings or other reasons) need rebooting — daily, or even more often. The New York Times is running a short article which says that it's not just a few makers like Asus who are trying to take away some of the pain of waiting for computers, especially laptops, to boot up. While it's always been a minor annoyance to wait while a computer slowly grinds itself to readiness, "the agitation seems more intense than in the pre-Internet days," and manufacturers are actively trying to cut that wait down to a more bearable length. How bearable? A "very good system is one that boots in under 15 seconds," according to a Microsoft blog cited, and an HP source names an 18-month goal of 20-30 seconds.
My later Amigas typically had a boot time of 10 seconds. Full blown AmigaOS on an internal HD on the A3000. I miss them dearly.
We've managed to stav off the usefulness of moore's law by creating the world's worst software to run on them.
It's not fair to judge modern systems with those older ones however; we ask a lot more of our software and our GUI's than we once did. But there is no excuse in the way that windows configures itself by default, it sets itself up for failure by having a re-sizable swap partition on the main OS partition.
When I install Windows on a new PC, I always create 3 partitions: An inner partition of 5 - 10 GB for a fixed size swap file only, then an OS partition, then an applications partition, and defrag regularly. I can keep my machines going for many years without much performance degradation in this manner.
Even if you are scrupulous, bad software and bad uninstall jobs will eventually bloat out your system a little bit.
A little common sense goes a long way, unfortunately those who do not deal with computers for a living aren't going to know these little tips and tricks, and will continue to be frustrated. OS manufacturers, in particular windows need to set up a default OS install for success, not failure. Software manufacturers need to create very clean installs and uninstall routines. Unfortunately this is not always possible in the OS environment. It's a joint effort.
The tin-foil hatters will think that M$ is doing this on purpose so people will feel compelled to upgrade more frequently, but I don't really give them that much conniving intelligence.
--Mike
I got sick of these outrageous boot times a long time ago.
here is how i fixed it:
I have an old IBM PS/1 that i picked up in the early 90's. (for the kids: 386 processor, 2 megs of RAM)
When I turn it on, the system is usable in about 5-10 seconds.
I can have a word processor open AND be typing away happily within 15 seconds of hitting that button.
now it takes me a minute to load my OS, and another 20 seconds before my word processor is usable
what the hell happened?
-I only code in BASIC.-
I'm going to have to link to an article I read a few days ago: http://lwn.net/Articles/299483/
In short it's about some Intel hackers makes Fedora boot in 5 secounds on an EEE PC, not exactly the best hardware.
My Sinclair ZX Spectrum is ready in less than 2 seconds. Now I have made an ethernet card for it, I can be on IRC within 5 seconds of power up!
Oolite: Elite-like game. For Mac, Linux and Windows
Obviously, we must stop using using pansy C/C++/Java/Ruby/etc... languages and go back to writing everything in assembler. Then boot times will rock!
Duh.
Maybe you intended for a funny, but i'd rather give insightful if I had points. I can't forget the wonderful playing experience with ELITE on Commodore 64... and those days it was all machine code!
Nowadays the philosophy is that you can afford to be a sloppy programmer and use absurd languages (VirtualBasic?) just because Moore's law will eventually compensate... given a year or two.
"If it took long enough for you to notice then something must have been wrong"
Actually that is one of the reasons why things are still slow in general - because though CPUs and hardware get faster and faster, we're still living in a human world. So the "human notice" times remain important.
Lots of programmers have their programs wait for one second if they have to wait a minimum time for hardware or for other reasons, after all most seem to think "it's only one second".
A few 1 seconds here and it all adds up.
Silly? Maybe in many cases, BUT often you really do have to wait in seconds because it says "press ctrl-A for SCSI controller config" and so if the computer does not wait _seconds_ for the human and only waits _milliseconds_, the human is also going to be pissed off.
For a similar reason a windows PC can't boot faster than the X seconds for you to press F8 to enter "Safe Mode". Well it can, but it'll have to be "hold F8 down while booting", and that means some changes in the keyboard hardware and config stuff, some user education etc etc.
Also often the threshold for determining that something has gone wrong is more _human_ related. Say a hard drive has gone slightly flaky and takes a bit longer to spin up for whatever reason.
How long will a human wait for a harddrive to spin up? Pretty long in many cases. Even if it takes 30 seconds, they might still wait.
The BIOS could just assume it's dead, after all it's not behaving like a _normal_ hard drive. But the specs for _failure_ are often human related - they are determined by how long it is expected that a human will wait.
It's just like network connectivity timeouts are in the order of tens of seconds. Instead of say minutes. A tree might be willing to wait minutes or even days, but most humans don't want to wait minutes.
They're not in the order of milliseconds because the speed of light is too slow (light takes more than a few milliseconds to cross the world) and people are willing to wait seconds.
Why doesn't every company / office apply a policy, that every desktop computer is configured to hibernate itself after e.g. one our of idling? Startup time will become meaningless and evergy savings would be huge (compared to 24/7 workstation uptimes). Personally I've never understood this boot time debate. I never shutdown my Macbook, which will wake from sleep in a second. AFAIK modern desktops are able to sleep/hibernate as well, maybe excluding some poor 3D drivers on Linux which cannot recover from sleep state. In the name of energy saving, every computer sold should be configured by default to sleep/hibernate after unused period of time, like every Mac does (don't they?).
Come on, BeOS fanboys. Tear back the nostalgia and BeOS was awful. Everything from disk I/O performance, networking, graphics was miserably slow. It was an OS designed to give good demos to get more investment capital. There was no reason to actually /run/ it and then live with it in the real world.
Pervasive multi-threading is premature optimisation bullshit, built in to the core of the OS. That BeOS fanboys loved this shows how much they're really related to ricers rather than actual users. The strategy in "pervasive multi-threading" is "if we're not sure how to fix it, add more threads". Threads of course, as any developer ought to know, add overhead. In a simple application this strategy means that you have one thread and one window. So you're in the same boat as on every other OS. Feeling excited and special yet? You shouldn't be.
Now if you add networking to the program you get one thread per connection. (Everyone who has ever worked with network software slaps their forehead at this point). But that's not the most fun thing. If you add a window, just a humble, probably not even particularly UI dense window, then you get another thread for that. "What for?" I hear every sane person ask. Well, because it was simpler for Be's engineers that way, and the ricers like it. However if you add sixteen tab widgets each with a dozen other UI elements in them, well, no extra automatic threads for that, you'll have to design your own multiplexer if you want one (good luck)
On any other OS you can divide stuff up nice and easily, maybe you've got a ton of lightweight UI, some code shuffling data over the network and a heavy compute load, so you give them one thread each. Simple. BeOS won't let you do that. It makes its own decisions about threads, and you'll have what you're given or else. As well as frustrating any programmers on their own platform (including their own engineers) who knew what they were doing and didn't want all these superfluous threads, its a portability nightmare. Programs from other platforms obviously don't have one thread per window (why would they?) so everything with a GUI is a bear to port.
Meanwhile, because you've got all these superfluous threads that need to communicate with each other and with the OS, every application is sending lots of messages, but again Be's engineers took the easy way out, when a message queue fills up they just drop the messages. So sometimes, when things get busy, your app will lose vital messages and get confused. Awesome.
That's why I say "premature optimisation bullshit". Who went out and profiled hundreds of applications to see whether adding one thread per window was the right approach? Nobody. The engineers hit a wall, and saw "one thread per window" as a way around that wall that every other OS just scaled. And then they sold it as a feature and couldn't admit failure by going back and fixing it. Next week: Why giving every user full system privileges is actually a "good thing" and why you'll never need more than 1GB of RAM, from the creators of BeOS.
And don't bother to tell me that Haiku (a reimplementation of BeOS) somehow "proves" that BeOS was good. People reimplement almost /everything/ there are guys out there cloning OS/2, NeXT, Amiga, Windows of course - even people trying to make a new Commodore 64. Haiku is nothing special except maybe it can get a Guinness record for taking more than seven years to produce an Alpha.
> I've been using standby/sleep extensively on my desktops and laptops for the last 10 years,
> and I still can't understand why people with a modern machine don't use standby.
Because it still doesn't work for everyone. I tried it a month ago, followed the instructions in the suspend HOWTO, made that suspend script and ran it. The machine suspended, but didn't resume - everything spun up, but looked dead. Sure, it might be easy to fix, but doing so would entail poring through hundreds of forums posts written by clueless idiots for that one little bit of information, followed by dozens of reboots for test-fail-retry cycles. I might get around to it, when I have a month to spare. Many things on Linux [don't] work like that...
Why does it take the Wii a good 30 seconds to start playing a game from the time you push the power button? (I'm including in here the time it takes to acknowledge the safety warning and click through the Wii menu.) I'm sure that the 360 and PS3 are just as bad.
And (probably unique to the Wii), why do I have to see one or two more safety warnings every time the game loads?
And (definitely not unique to the Wii), why do I have to watch multiple studio logos before I even get to the start screen. The record that I found, was one game that had EIGHT studio ads!!
But, how about DVD players. My player takes somewhere in the 20 second range to load a disc and then I have usually a few (usually) skippable ads followed by 10-15 seconds of unskippable menu animations.
I'm still holding out on Blu-Ray because one recent review of a new Sony player was talking about how fast it was - 1 minute to start up - 1 minute to load the disc. That's two full minutes before even the ads start to play!
I kinda miss the 80's, when you stuck your VHS tape in and the movie started right away. Any ads? Then just rewind back only to the start of the movie and you'll never see them again. You took Super Mario Bros and put it in your Nintendo. In under five seconds, you're asked if you wanted to play with one or two people. After you make that choice, within a second you're playing the game.
This is sooo close to the overall truth to why Windows (and Linux) take so long to boot.
The systems in the DOS world were hard-coded via boot / initialization files to load exactly the hardware drivers for the hardware configured in the machine. Hardware was hand configured by a person, set to IRQ/DMA/Memory addresses that were generally accepted as appropriate, and conflicts were reconfigured manually. The autoexec.bat and config.sys files were manually tweaked by hand to reflect the different cards - and Boom! it all loaded lightning fast because it was simply following instructions - computers do this very well.
Current OSs have a gazillion different permutations of hardware that could present when they boot each time and they have the drivers for all the hardware present. They interrogate the hardware, every subsystem they can find on the different places that could have hardware and then one by one they load the different drivers for the cards, dynamically allocate the hardware (Plug n Play) with IRQs and DMAs and Memory locations and try it out to see if it works, try again if it doesn't. But it's a matter of 'Hello PCI slot #1 - what kind of card are you?' and then negotiating the drivers, hardware allcations, etc. That's why you can install the drivers for two different video cards, and each time you shut down / restart the system you can swap the video card for the other one and - the system boots up and works nicely - that's one nice benefit, the other benefit being that it's "easier" for the common user to get a system up and running.
The above is the reason that ultra-fast hard drives don't really make much difference in boot times, why stripping out processes make some but not a ton of difference - because the hardware interrogation / allocation / driver load process is not a particularly quick endeavor.
If we had a way to hard-code the list of hardware, and even the resource allocation (IRQ / DMA / Memory locations / etc) that the computer is running and guarantee to the OS that it is the same each time the system boots - that OS could boot a LOT faster than current systems boot. It might possibly be a way to boots that are faster than restoring a 'hibernate to disk' session because a 'hibernate to disk' session has to restore the complete system state regardless of system state, meaning it actually has to populate the entire system state including swap file, etc. A hardware boot with a predefined system configuration can configure the system and load the drivers for the base OS, leave the rest of the system basically uninitialized for use by programs as they allocate the memory once the user logs in and starts running programs.
It's one step backwards, and three steps forwards. Worth it? If someone decides so - go for it (just give me credit for the idea - that's how GPL works, right?)
Glonoinha the MebiByte Slayer
In about 1985 I was able to reboot my MS-DOS computer in eight seconds. My TSR ran at the end of AUTOEXEC.BAT and stored an image of all lower memeory into an L.I.M. RAM card bank. Press Ctrl+Alt+Ins and the TSR would reload lower memory from the RAM bank. Eight seconds to reboot.
Linux suggestion: save ASCII config file timestamps and corresponding kernel structures. If the ASCII config file is unchanged, then reload the internal structure without any recomputation.