Hacker News Reader

Comment by dwc | Hacker News Reader

Laptop: open lid and resume. Server: RAID startup dwarfs OS startup.

Does super fast booting matter much these days? It's just about ceased to matter to me completely.

I try to avoid using sleep/resume when I'm away from home, because it partially defeats the purpose having full-disk encryption on my laptop. A thief who steals it when it's powered off has no access to my files. On the other hand, a thief who steals it when it's asleep might be able to get around the login once it wakes up.

So yes, it sucks to wait 30-40 seconds for a reboot.

While I like a fast boot, you've go to get these things a little into perspective, a minute to the desktop isn't that bad.

But 20 seconds is even easier. When I switched to an SSD in my laptop I saw boot times from drop almost one minute to just about 15 seconds. I no longer dread having to reboot after system updates.

It's not bad, but spread over X million workers on desktops 5 days a week means a lot of wasted time, and maybe energy.

If 5 million people save 1 minute every day for 200 days a year. Then you have saved 1 minute every day per person, not 5 000 000 * 1 * 200 minutes in total per year.

That kind of math just doesn't work.

Yeah but you don't have to just sit there and twiddle your thumbs while your machine boots. You can just do something else. I'm sure we waste far more time during the day doing other things. We don't necessarily obsess over those types of time inefficiencies. If you wanted to save time you could brush your teeth in the shower etc.

A minute to the desktop is exactly why the tablets are so useful.

If I'm sitting on the couch the instant on nature of my tablet is the main reason I'll reach for that to look at something rather than my laptop.

Wouldn't the ideal solution then be to modify the OS to purge the disk encryption keys from memory on sleep? If you're concerned about unencrypted file contents in memory, purge the page/buffer cache while you're at it.

Then ask the user to re-enter the key on resume and get back to business...am I missing some obvious problem here?

I guess depending on one's level of paranoia, there might be sensitive non-file data sitting in memory...you could then quit the applications you're concerned about, and have the kernel wipe any unallocated memory before sleeping (I think by default it doesn't wipe pages until they're reallocated to something else, on Linux at least).

Obviously with flushing caches and quitting applications and so forth you're trading off some of the benefit of keeping the system alive, but presumably it still beats a cold boot every time you come back to your laptop.

I've been reading guides on getting lion to do just that, snow-leopard supposedly supported it, with filevault.

Unfortunately, lion/filevault 2 no longer supports it, and if you try to force the options, the computer simply crashes on resume.

FileVault 2 does support purging keys on sleep:

  sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25

From the pmset man page:

  destroyfvkeyonstandby - Destroy File Vault Key when going to
  standby mode. By default File vault keys are retained even when
  system goes to standby. If the keys are destroyed, user will be
  prompted to enter the password while coming out of standby
  mode.(value: 1 - Destroy, 0 - Retain)

and

  hibernatemode = 25 (binary 0001 1001) is only settable via pmset. The
  system will store a copy of memory to persistent storage (the disk), and
  will remove power to memory. The system will restore from disk image. If
  you want "hibernation" - slower sleeps, slower wakes, and better battery
  life, you should use this setting.

So, under Lion, turn on FileVault, run that command and always sleep your Mac (close the clamshell, Apple Menu > Sleep, or Option-Command-Eject) when you want to be secure.

If your computer crashes under resume after having done so, something's amiss. Remember that you'll need to auth twice on wake-from-sleep if you are logged in – once to unlock the volume, and again to unlock your user's session.

Which operating system? On OS X Lion, you can make the system hibernate when the lid is closed, writing encrypted memory to disk. Slower wakeup times than suspend, but quicker than a full startup.

https://news.ycombinator.com/item?id=3785762

If hibernate is quicker than a clean boot on OS X 10.7, you either A) need an SSD, or B) need more RAM.

Hibernate takes a full 48 seconds on my laptop. A clean boot takes 8-9 seconds.

How long does re-opening all of your apps and files take? People who dislike rebooting usually tend to have plenty of things open.

I wish my Ubuntu desktop booted in 40 seconds. Thanks to btrfs, a reboot is a 30-minute affair.

Is it doing a full fsck every time? Or is this just... the beta tax?

Since my SSD-equipped, btrfs using laptop (Thinkpad X60s running Debian testing, kernel 3.2.15) boots from power on to graphical login in 27 seconds (13.5s of which is the time taken to get through the BIOS boot sequence) I suspect it's something specific to the parent poster's system.

I have btrfs (with lzo compression) on a rotating disk, and the boot feels a little slower (one or two minutes total?) for reasons I haven't really examined. I'll have to check if something messed with ureadahead.

It's a 2TB drive doing a full fsck each time, though I don't know why.

Linux still has lots of problems with suspend/hibernate/resume on laptops (Oneiric broke hiberanate on my laptop for example), so booting is still kind of important for that reason.

Resume from hibernate is another area where I'd like to see improvements. I hibernate instead of suspend because I never know if I'll make it back to an outlet in time.

Sounds like a problem with Ubuntu, really, not Linux.

It's more of a problem with hardware more interested in coding to "works on Windows" than "complies with spec."

And honestly, Startup is as fast as resume these days - the problem is applications that don't remember last known state and window managers that won't remember the rest. Why don't we fix that instead rather than chasing down all the suspend bugs?

Restoring app last state? Like terminal emulator recreating tmux session wrapping screen session with package manager working under sudo? SSH unHUP-ing processes on remote machine? Python VM resuming all scripts in a precise place and state they were stopped?

The problem is that there is no such thing as isolated "application" on Linux or any other real OS.

Restoring is hard. Let's go shopping!

Suspend-to-RAM, as opposed to suspend-to-disk, is way faster than booting.

Why chase down suspend bugs? because they are bugs.

I'm with you on fixing window managers, generally speaking.

I've never had it work reliably with Fedora. Reliable sleep is about the only reason I use Windows now.

I definitely could be wrong in my conjecture. I've used sleep reliably under Arch Linux in the past. (Not using it now because my laptop doesn't work anymore without being plugged in.)

On the same hardware that Ubuntu (and friends) didn't work on? I've been having problems with resuming, and wondered if going to Arch would help, but couldn't think of a real reason why it would.

Newer drivers, for one. Also, it's a lot easier to mess with Arch's internals than Ubuntu's.

It's not a fair test; haven't tried a recent Ubuntu, but: suspend to ram and suspend to disk were broken on Ubuntu 10.04 and 10.10 with my Eeepc 900. Arch + TuxOnIce has worked great for suspend to disk for about a year now.

I've had some problems with Intel graphics on my DELL in Fedora 14. Sometimes video, sometimes full screen flash, and sometimes sleep caused it to crash. On my older IBM with ATI, everything worked just fine. Anyway, in Fedora 16 the graphics and sleep works just fine for me.

Note that Ubuntu disables hibernate by default in the current release 12.04 ("Precise Pangolin").

https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuD...

Well suspend/hibernate/resume are kernel functions so it is a Linux problem.

I'm aware that they're kernel functions, but it's not necessarily that simple.

As has been mentioned full disk encryption loses a lot of its efficacy if you just put your laptop in standby all the time. I'd add that as long as a faster boot doesn't compromise your system in other ways, why wouldn't you want it?

It doesn't - if done right.

When hibernating my laptop it writes the memory contents into swap - which is also encrypted. Yes, de-hibernating is slower if contents need to be read from disk. OTOH it's still faster than booting from disk.

I do believe standby and hibernate are different as standby keeps memory contents hot whilst hibernate actually shuts the computer completely down. I was talking about the former in my post above.

I this bizarre problem that whenever my fridge turns on, it wakes my laptop from sleep, even if the laptop's not plugged in.

The joys of student life!

Reply on news.ycombinator.com