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.
[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.
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].
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.
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.
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.
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.
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).
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.
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...).
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...
Is there a way to shut that off, or a Linux DHCP client that doesn't do that?
> qemu-kvm -nographic -kernel kernel -boot c -drive file=./kvm-squashfs,if=virtio -append "quiet root=/dev/vda console=ttyS0 init=/sbin/halt"
(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.
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
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...