Experiment in booting Linux fast
gentooexperimental.org
gentooexperimental.org
There is no network and most functionality is missing. There are not services or anything else.
So no point comparing this to Windows or OSX or anything else that requires any functionality other than kernel and filesystem.
In fact, I'm pretty sure that if the author stopped using OpenRC and used systemd instead, to initialize the same things, it would have made a noticable difference.
And a little self-promotion now :P As far as network config is concerned, using my NCD[1] software, it can be set up in no time (that is, not much more than the time it takes to negotiate a DHCP lease). In fact if you were super crazy, you would drop systemd and just run NCD as init, doing both basic initialization, as well as network config, all in one NCD process. I've even tried it some time ago, and got some very basic stuff working[2].
I suspect that it's not actually directly doing some low-level ARP magic; rather the DHCP client may just be sending multiple DHCP request packets to past DHCP servers, and only the one whose automatic ARP request succeeds actually gets sent out. At least that'd how I would implement it.
The UI becomes responsive before all services are loaded.
My MBA gets to sleep again before I can type my login password, so I have to press something (usually arrow) to keep it awake till UI responds. If I type the password before UI responds, then there is a good chance that the first characters are lost.
I should probably reinstall the system or do some clean up, but it is still an UI/UX issue.
Booting to a full featured Gnome. NetworkManager is the showstopper...
My 2012 MBA with an SSD and 8GB of RAM cold boots to the desktop in ~8 seconds. (It was ~6 when I bought it..)
I'm hoping a clean install of 10.9 will speed it up again a bit.
I have not measured either. But the OSX boot time is still measured in seconds with the SSD.
My solution of course is to just suspend/hibernate instead of powering down, but it is a little disappointing that I don't get to play the "fast boot" game.
I've run down my battery a few times while not suspended (just me being neglectful with plugging in) and haven't run into this issue. Is this just because the hardware kills power to the processor before the battery actually hits zero?
The boot to a desktop in 5 seconds on an EEE PC 701 is still impressive.
Noodling through the author's site it's pretty interesting to see what they did to cut times, and they're honest about this just being about boot time.
Does anyone else do this kind of optimization, or does it carry too much risk or cost?
reboot, not boot, boot was already a non-issue after booting into sh and removing most of the services.
The later posts deal with shutdown, mostly by removing sleeps... which are there to wait for lying hardware to finish flushing its caches. So some of TFA's fixes are really recipes for data corruption if you're not using a readonly FS (which TFA is, so it's no problem for his precise use-case).
It's not like the layers above can just go "nuh-uh, tell me when it's actually really written for real", if the storage device is going to lie it's going to lie every time.
http://thecodeartist.blogspot.com/2012/08/hdd-filesystems-os...
The more common being the case where there is an additional VFS driver between the app attempting sync-I/O and the AHCI driver which simply issues an asynchronous I/O command to the disk and returns immediately. The new data is guaranteed to be on the HDD but NOT guaranteed to be written to the non-volatile platter of the HDD. Data is often still in the HDD internal-cache, waiting to be written to the disk platter.
The 2nd case (very rare) is when the application attempting sync-I/O opens the HDD in raw mode i.e. opens the block device directly(without any VFS layer in between) with O_SYNC. Now following each disk-write, the AHCI driver issues a CMD_FLUSH to ensure that even the HDD cache is immediately flushed to the platter. As this eliminates any chance for NCQ to kick in, the performance drops by an order of magnitude but data-integrity is ensured.
Demo: http://www.youtube.com/watch?v=4Fjfqz6FxC8 It seems to be 3 to 4 seconds.
It is however for a specific use and I don't know how polyvalent it is.
This guy stripped a Renesas SH7724 boot-to-UI from 19.44 seconds down to 0.77.
http://elinux.org/images/f/f7/RightApproachMinimalBootTimes....
The tl;dr is that there's a lot in the kernel you can disable or strip away if your target system doesn't need it. The section on optimizing your application for block-oriented storage (like NOR flash) is a great one too.
That said, when I installed a virgin system on Monday, I was sad to see that systemd is creating a .local directory in the home directories of users (even root). This is on a system with no Xorg what-so-ever. Call me old fashioned but I don't think an init system should be creating directories in a user's home directory.
though i did have to screw around with uEnv.txt for a while to get it booting as seamlessly from eMMC rather than external SD card. this has since been fixed (as of 9/21) [1]
btw, it's much much smaller and faster than the distro BBB comes with, Angstrom. Arch boots in a quarter the time and also has many more up-to-date packages. Embedded nginx stack ftw!
[1] https://github.com/archlinuxarm/PKGBUILDs/issues/554
[EDIT] sorry, responded to wrong post. should have been this sibling post: https://news.ycombinator.com/item?id=6521531
http://standards.freedesktop.org/basedir-spec/latest/ar01s02...
https://bugzilla.redhat.com/show_bug.cgi?id=1012842
In any case, I know it is for systemd because if I dig down into the directly, it eventually ends into a dead systemd symlink for a directory in ~/.config, which doesn't yet exist. I think it is suppose to provide the ability to add and run end user units, but I am not sure.
I hadn't installed a linux distro that wasn't a *buntu since Gentoo ~8 years ago when I started a new job a couple of months ago. They gave me a Lenovo laptop, and when it came to picking a distro I thought I'd try Arch.
I just followed the beginner's guide[1]. Apart from the first bootmanager I tried (uefi is a new experience for me) not working right everything just worked as easily as you'd expect. Wifi worked ootb, graphics acceleration was as easy as installing the right driver package. For anything else I wanted to install (eg xfce) I just read the wiki page for that particular package on the arch site, and did what they said.
I was actually blown away at how easy it was to install a command line "do it yourself" distro. I'm guessing from your comment that's not the standard experience then :-/
The first one was an old netbook. I hadn't done an Arch install in a long time (I've been spoiled by the simplicity and convenience of the Wubi installer) and wanted the learning experience. I also wanted the HDD to be encrypted using dmcrypt and LUKS.
The main problem I had was wrapping my head about the various partition schemes. This was made more difficult by my insistence to have the HDD be encrypted which meant I needed a separate /boot partition along with the special 1MB linux boot partition required to use GPT with BIOS (I missed that in the instructions and it tripped me up for quite a while). Altogether, it took three fresh installs before everything was exactly the way I wanted it but the last one was quite quick and was really on a fresh install because I wanted to make absolutely sure I had everything nailed down.
The second laptop was a midrange, 2 year old HP "media"-style laptop. With my new knowledge, partitioning and installing was easy even while maintaining an existing Windows install. But this laptop has both Intel and Nvidia graphics shared via PowerXpress whereas the netbook has simple Intel graphics. I still haven't taken a stab at the proprietary drivers but using the open source intel and nvidia graphics in tandem (after some fumbling around but it seemed counterintuitive to simply install both drivers side-by-side) it works well enough for what I'm using it for. I don't really relish the prospect of installing the proprietary Nvidia drivers, though.
I've probably spent 20 hours installing Arch on both of these machines but I've learned a lot in the process. It's been good.
The majority of those installs have been on my main computer (a laptop) because I couldn't find the source of my issues with X not initializing. You could argue full re-installs are overkill, but I say no.
Fun-fact, Turned out to be a fault with GDM (I use Gnome Shell), and I finally fixed my pains with a total of three commands.
That said, I still contend that pacman is hands-down the best package manager in existence. I just prefer to use it on Frugalware nowadays.
Not to say that it doesn't have it's downsides, like scaring off new users.
Simple, because no one wanted to maintain it. I don't miss it, either.
Well, I'm not being fair here, the commands are not really obscure (except the ones they made up), and I'm sure they had a reason. But I just recently had to reinstall Arch after many years, and found the new "installer" strange and kind of daunting compared to the old one.
Pacman is really the best. I had to be reminded of that recently when I had the luxury of dealing with a Ubuntu system. Granted I don't have to deal with that system everyday but having to use apt, aptitude, dpkg to accomplish different things? What a fucking mess.
But it's probably just me that got used to a simple and easy life with pacman... There was a time that I even had to create an ubuntu package, well, don't get me started, I cried a little and lost around 3 days.
Last time I installed arch was before they removed the menu driven installer and it sure had some problems and bugs, so even if I have not tried it yet, I think I prefer this way of installing. It's cleaner, simpler, so better.
I have tried Arch on three machines (old netbook, laptop, desktop) and all went fine during installing (all LUKS cryptorooted). What made me mad was when some stuff broke on two of them due to infrequent updates this spring (didnt use both netbook+desktop for a longer time). Alas, I can't remember details any more.
Made me switch back (to debian) I almost never use aptitude and dpkg only for low level stuff (e.g, when there are errors). Apt alone is in almost all cases sufficient.
[1] single GPT partition, no lvm, no encryption, no fancy devices.
[2] simple unix tools : disk, mkfs., *chroot. arch : netctl (network setup), pacman and a bit of systemd (not traditional yet ;)
But between the official and unofficial install guides, I got it working.
Yeah human errors that threw the entire process off.
However the journey was really fun, I learned a lot, and I highly recommend other to try the same as once you get it running, it really is amazing. My crappy netbooks boot time went from 2 minutes with win7 to 14 seconds with arch.
Really? I find it pretty easy to find instructions to configure a particular device or install a certain software. If you want to install a DE, just Google how to install a DE to Arch Linux, or if you have a Broadcom wireless, you can Google how to install the wireless card.
There's little laptop-specific instructions you'll need, and you don't need to be a guru since there's very good instructions available, especially in the Wiki.
is that a correct understanding? if so, is that a reasonable risk i see (filesystem corruption at times)?
Unfortunately, most consumer-grade mass storage devices lie about syncing. Disk drives will report that content is safely on persistent media as soon as it reaches the track buffer and before actually being written to oxide. This makes the disk drives seem to operate faster (which is vitally important to the manufacturer so that they can show good benchmark numbers in trade magazines). And in fairness, the lie normally causes no harm, as long as there is no power loss or hard reset prior to the track buffer actually being written to oxide. But if a power loss or hard reset does occur, and if that results in content that was written after a sync reaching oxide while content written before the sync is still in a track buffer, then database corruption can occur.
… part of me hopes there's a very special hell for the people making disks where the OS can never be sure if the data is safe or not.
Early Intel SSDs were known to be particularly prone to this issue: http://www.mysqlperformanceblog.com/2009/03/02/ssd-xfs-lvm-f... http://www.evanjones.ca/intel-ssd-durability.html
Edit: after some googling:
On Linux, sync is guaranteed only to schedule the dirty blocks for
writing; it can actually take a short time before all the blocks are
finally written. The reboot(8) and halt(8) commands take this into
account by sleeping for a few seconds after calling sync(2).
This page describes sync as found in the fileutils-4.0 package; other
versions may differ slightly.
On Linux, sync is guaranteed only to schedule the dirty blocks for
According to the standard specification (e.g., POSIX.1-2001), sync()
schedules the writes, but may return before the actual writing is done.
However, since version 1.3.20 Linux does actually wait. (This still
does not guarantee data integrity: modern disks have large caches.)
Also, counting on sync() to write everything within two seconds seems problematic as well.
The issue here is storage devices may lie about it[0]. The 2s sleep is problematic, but IIRC devices don't (and have no way to, and would not anyway) report when the data is actually written to permanent storage, so you can't do much besides waiting a bit and hoping for the best.
Which `sync` uses. My comment was probably unclear, but the point I was trying to make is if they're lying to sync they're probably not going to provide other accurate ways to get the information.
It is not a reasonable risk on a normal system, but TFA uses a readonly filesystem (squashfs) so it's not an issue: there's no data to be written.
Startup finished in 2.480s (kernel) + 623ms (initrd) + 570ms (userspace) = 3.674s
Fedora 18 on Dell Precision M4700
Not quite 0.25 seconds though ;-)
Here's one way to get there: http://www.harald-hoyer.de/personal/blog/fedora-17-boot-opti...
Is there a way to shut that off, or a Linux DHCP client that doesn't do that?
26s to login screen, another 13s from pressing enter after login to having Chrome show me a useable Outlook Web Access.
And I haven't performance optimized anything. Steam, 2 VPN clients, Trillian and Directory Opus all load on login.
Man, that thing was fast.
On a side note I somewhat recently booted up our old Amiga 2000, running an upgraded cpu (68020 I think, maybe 10 Mhz) -- booting off its ancient 40 MB scsi hd -- and I was surprised how slow bootup was. Can't remember that I gave bootup time much thought when the thing was new (then again, most reboots were done to boot into a game off of floppies...).
On a desktop or laptop, you probably use hibernation, and your biggest time sinks are typing your password and having your network connection go back up. Rebooting these things is rarely needed.
http://cafbit.com/entry/rapid_dhcp_or_how_do
http://news.ycombinator.com/item?id=2755461 <-- good discussion
> qemu-kvm -nographic -kernel kernel -boot c -drive file=./kvm-squashfs,if=virtio -append "quiet root=/dev/vda console=ttyS0 init=/sbin/halt"
I attended Google I/O this year and received a Pixel. It's a really nice piece of hardware, but as a developer it's worthless. I saw Google presenters using a lot of Macs and a ThinkPad running Linux. Not a single Chromebook.
https://chrome.google.com/webstore/detail/secure-shell/pnhec...
(https://lwn.net/Articles/299483/)
Here's an article trimming boot time of Fedora 17 to 3 seconds.
(http://www.harald-hoyer.de/personal/blog/fedora-17-boot-opti...)
There's some overlap between the two different approaches.
If you wanted some esoteric hardware you could make an always powered RAM disc.