Brad Ideas - Sysadmin - Comments

The key waits can be avoided.... sort of

Moz — Sun, 28 Feb 2010 23:56:20 -0800

Yeah, the key waits do just time out and booting continues, but they also have issues if I (for instance) put a book on the ESC key to trigger the "hit ESC to continue or F1 for setup" option. It means that I can get a (slightly) faster boot by sitting there watching it and hitting ESC F6 ESC ENTER at the right moments. But that's more irritating than just doing something else and waiting for the boot cycle to finish.

Interestingly, tweaking my laptop BIOS to suppress the key waits (it's called "security" for extra amusement value) means that I can boot it using only the TrueCrypt boot password then much later the Windows signon password. But my desktop does not allow that because it lets every device interrupt the boot process to bug the user. The laptop just requires me to remember that I can hit the blue Thinkvantage button to interrupt normal booting, otherwise it's full speed ahead.

That's why I think a jumper is a better option than a high speed boot - and I expect that very quickly every case manufacturer would add a "BIOS switch" on the outside that you could plug into the jumper. Many laptops already have a special button for this.

I suspect parallelising the various bus timeouts and detection cycles already happens, at least on the hardware side. Doing the same at an OS level might be harder, and it might be simpler to work with a "fast default" setup. Basically, you boot as though whatever you had at shutdown is still there. So the BIOS looks for the bootloader that's first in the list, that bootloader loads the first OS in it's list, the OS loads all the devicde drivers and so on from last time. If anything fails it drops back (or even restarts) from the current "what's out there" position. I think we'd be 90% of the way to your suggestion in a more easily reached manner. It's basically an extension of the Windows "boot into safe mode" screen, or the Unix "fsck everything" failure recovery.

The 5 seconds

brad — Sun, 28 Feb 2010 10:47:54 -0800

For the bios is the POST. The 10 seconds for the RAID are presumably to wait for the keyboard, right, it goes ahead if you don’t type?

That is the reasoning behind the idea of being able to abort at any time. That way you don’t have to wait for keystrokes — you just go ahead, and if keystrokes come, you abort what you were doing and act on them.

10 seconds for POST... oh I wish

Moz — Sun, 28 Feb 2010 03:07:12 -0800

I'd love to speed up my POST because I've got two RAID subsystems (MB+PCIe) that each want 5 seconds for me to hit a key before they'll let the boot continue. Just knocking that out would dramatically improve my boot times. So I suggest a jumper or something that you have to set while powered down before any of the boot-interruption options show up. For the other 99% or more of boots you wouldn't even have the option of hitting F1 to go into BIOS setup.

Having roughly timed that particular box the boot sequence it actually quite speedy once the user interaction options are removed - it's on the order or 10 seconds. Plus the 10 seconds of RAID key-waiting, 5 seconds of BIOS wait and I suspect 5 seconds of Windows key waiting.

Have you talked before about a suspend-to-static-RAM option? That would interest me, because currently I hibernate my laptop and desktop rather than using sleep. Being able to plug in a fast USB stick and hibernate to that would be handy. Ideally internally, however, rather than yet another thing hanging off the laptops. I suppose if booting was as fast as un-hibernating it would matter less (though not much less, I autostart a few things like FireFox that take another 5-10 seconds and un-hibernating doesn't suffer that delay).

Standby is great

brad — Fri, 19 Feb 2010 13:55:14 -0800

And should be used as much as possible, but it doesn’t stop the need for faster boot. In some sense, with my linux servers, I boot most of them very rarely — one has stayed up for a year at a time several times — so you would wonder why I would want fast boot. It’s because when you are working at them, configuring them, changing hardware around, you often do many reboots in a row. And in one case, my mythtv server, there is some bug I have not yet worked out which seems to be easiest to fix with a reboot when it stops talking to the cable box over 1394.

The DVR uses power when “off” because most DVRs never really go off. The smart them for them to do when turned off is to look at the recording schedule, and if they see they have to record a show in 6 hours, go to sleep for just under 6 hours in standby and then come back up again to record it. But few seem to do that.

However, everything needs rebooting from time to time, even phones. It is the phones, oddly, which frustrate me with their inability to abort a boot. With phones, sometimes you don’t know if they are asleep or truly off, and if you press the power button (which tends to turn on the screen if asleep, or boot if off) you often find yourself having booted the thing by accident, and have to sit and wait for 20 seconds just to turn it off again.

But we have computers that can multitask just fine today but they sit and wait around for 10 seconds doing POST when they could be sucking in the disk blocks that 99% of the time, we know we want them to read.

I just use standby

Joel Upchurch — Fri, 19 Feb 2010 11:15:54 -0800

I have a EEE PC Netop. I hooked a KillAWatt power monitor to it and noticed it only pulls 1 watt on standby. It only takes about 6 seconds to come out of standby. I reboot it every couple of weeks when it starts getting sluggish. I figure at 1 watt it isn't worth powering off.

What annoys me is that the cable company hd-dvr pulls 29 watts on or off. You have to unplug it to stop using electricity and you really don't want to do that since it takes several minutes to boot up. I checked on the AvsForum and apparently this is normal. There are better SetTop chips in the pipline, but it will take years to displace all the equipment in the field.

I notice what you are talking about on the POST on my Acer Quad-core. The USB enumeration is especially tedious.

This is pretty close to what I propose

brad — Fri, 19 Feb 2010 10:02:36 -0800

But the OS needs to participate as it needs to know about the blocks that are in ram, and to know where they are and what ram not to step on until done with the cache.

Because if that, I figure it’s easier for the OS to also make note of the blocks being loaded. I don’t want the BIOS to be so complex that it puts the OS in a virtualizer. I propose relatively simple changes to the BIOS, where it does minimal POST (CPU, memory, expected disk drives) and then immediately moves to loading prepared contiguous blocks from the disk drives into RAM while doing POST on other hardware and immediately invoking the (abortable) bootloader.

That the bootloader and OS are fully abortable is key. That way if your plan was to load a different OS this time, you can abort the boot of the default OS well into it and get back to the BIOS or bootloader to do what you wanted, but the default OS did not wait for your input. The main issue is if the default bootloader and OS will hang the machine to an extent the BIOS can’t abort them. You need a way to signal that so the BIOS never runs the bootloader at all.

Another way to accelerate disk block access during boot

Shachar Tal — Thu, 18 Feb 2010 23:33:03 -0800

Both Intel and AMD have virtualization technologies built into their CPUs. Intel's is named VPro, not sure about AMD. Both allow OEMs to create software that would run BELOW the CPU's ring 0, and:

1. record (in a non-volatile space) which disk blocks are being loaded in the first 30-60 seconds of the OS boot up (do note that the OS also has many services/daemons that need to start for you to enjoy it).
2. preload those blocks into RAM on the next boot (this can be done EASILY, TODAY in parallel to POST, no BIOS changes required).

Now you have ramdisk-level performance during boot. way better than SSD even.

i was hoping you'd mention

Anonymous — Sat, 28 Mar 2009 19:03:01 -0700

i was hoping you'd mention these ports tress are too big.

it's like the 'nix version of the monstrosity that is the windows registry. these are like a ball and chain that we carry around. all this 'stuff' we don't need, and which can just 'break' and give us probems.

as you say, it should be an external database. if databse people can agree on sql why can't we agree on a way to install/patch/upgrade/deinstall software? heck, while we're at it we could set standards for software. we could have tiers. from trendy bloated crap to no BS 'eternal' stuff like sed.

great Brad idea

Sairy — Sat, 20 Oct 2007 00:44:06 -0700

I like this. It makes a lot of sense. And I think you're right on with the mobile point as well. I've run into that problem in the past especially when passwords have characters that aren't easy to find with mobile keyboard interfaces.

What irritates me (as a user) more than delays, FWIW, are the sites that assume your username is correct and default to telling you the password is wrong vs. noting that it could be either one. I've wasted much more time hammering on passwords when the username was incorrect than I have from typos in the passwords. (Not that the delays aren't a nuisance.)

My credit union has a simple

Charles Merriam — Thu, 18 Oct 2007 22:24:05 -0700

My credit union has a simple password. After three tries, you need to talk to the branch.

Yes, be careful

brad — Wed, 17 Oct 2007 11:44:34 -0700

Yes, I don't say one should not be careful in design of these systems. I just rant about making a choice that frustrates the legitimate user as well as the attacker, when there could be choices to only frustrate the attacker.

Keeping usernames secret requires a tradeoff. Doing so can frustrate users, who may think they have got their password wrong (and keep retrying it until they get locked out) when actually they have their userid wrong. On the other hand, attackers may have various easy methods available to test usernames independently on many of today's sites, in which case hiding them helps nothing. (Many sites will let you enter usernames to get the password emailed without also asking for the email, for example, or put usernames in public web pages and URLs. In addition, it is very, very common for users to keep the same username over many systems.)

Can be source of security vulnerabilities too

Tim Farley — Wed, 17 Oct 2007 04:26:55 -0700

If you're not careful how you implement the time delay, you can create a security vulnerability with this too.

There was an old version of Novell NetWare that would delay the reply packet if the request contained a bad password. However, it did NOT also do the same thing on bad username. As a result, you could brute-force a list of usernames for that server by simply watching for whether the delay occurred.

It's merely an information leak, but it could be an useful early step in an attack.

Alias?

Moz — Fri, 27 Apr 2007 22:04:41 -0700

Surely rather than rename (or as well as) you'd just want an "alias" command of some sort. Being able to say BlogFartz 4.9.2 is also SpellCheckMyBlog 2.4.0.27365 is probably only going to happen a few million times, so it is probably worth including.

But I admit that I'm a complete knucklehead on this stuff, I invariable spend much time cursing when I have to upgrade anything significant.

finally someone with the same problem :)

David — Sun, 18 Mar 2007 07:12:18 -0700

Thanks for your article. It's hard to find articles that go as deep in the dependency problem. For the moment I'm having this problem. I want to run kdenlive on kubuntu breezy. And I found there is no proper way to do it for a non technical linux user as I am. No breezy package in the backports and the klikable package (http://klik.atekon.de/)does not run on my system because it can't find an rpm on the packmanrepository. Sometimes I think I'm the only one who run a linuxdistribution longer than 1 year :)...and run their system with a minimum of updates because I don't have a broadband internetconnection.

I do use apt

brad — Sat, 09 Dec 2006 18:42:32 -0800

In fact, I even use it on Fedora as well as Debian and Ubuntu.

The problem, as I noted, is that new packages are tested and built only with very recent versions of their dependencies. So, in order to try out a cool new program or to get an updated version of a program I use which has bug fixes or new features, I must also get new versions of all the dependencies.

And worse than that, these new versions simply aren't made available in binary forms for releases that are just a year old in many cases. Debian, for example, as stable, testing and unstable. But in reality, unless you want no ability to install new software, you have to run unstable. Now unstable is not nearly so unstable as the name suggests -- but this is still stupid. The truth is these new software packages you want to run don't really depend on all these new libraries and tools, that's just what the guy who built the DEB or RPM file had on his system at the time.

Running a stable system with older, more tested base packages is not an invalid goal. But it shouldn't prohibit you from running new software that doesn't actually and truly need something more modern.

Again, compare it to the Windows user running 7 year old Windows 2000 and having done one update to SP2. They can download and install almost every piece of Windows software out there. Try to run a 3 year old linux and you can't even get close to that.