Interesting... Googling around backs up your memory - systemd's readahead implementation was removed in v217.

The NFS mounts were always mounted at boot and not on demand both before and after systemd. The difference was that because there were multiple NFS mounts only proceeded in serial before the switch. After the switch the waiting of the mounts happened in parallel not just with each other but other services too. Yes it is entirely pathological but it really happened (and presumably other parallel inits would have solved it this way too).

For what it's worth I have an EeePC too. The default Xandros distro was a classic case of not running very much because it was highly custom (e.g. no printing, no mdns, kernel doesn't have to probe for all different kinds of hardware, hotplug of USB devices, io scheduler set to deadline etc) and thus was fast - I would always expect it to outperform a generic "full fat" Linux distribution. I'd expect your FreeBSD to beat my current XFCE Ubuntu setup too because I bet you can get start less. With lots of hand tweaks the boot speed to an XFCE desktop on my EeePC 900 is still 17 seconds...

Anecdote 1: I've just timed a Debian Jessie single CPU hard disk based VM install with BTRFS as the filesystem, a GNOME 3 desktop where the user is auto logged in boot and where an autostart script records the time. Here are my rough systemd and sysvinit results (times are from after the kernel core finished to when the GNOME script ran):
sysvinit (apt-get install sysvinit-core)
First boot: 20 seconds
Second boot: 18 seconds
Third boot: 19 seconds
systemd (apt-get remove sysvinit-core)
First boot: 15 seconds
Second boot: 16 seconds
Third boot: 15 seconds

sysvinit averages 19 seconds, systemd averages 15.33 seconds. In this case it does appear that systemd booted the system faster.

Anecdote 2: Same as above but where the VM's disk is sitting wholly in RAM. Time for sysvinit dropped to 5 seconds and the time for systemd dropped to 4 seconds.

My personal guess is that the more you are running, the slower the disk the more likely systemd is to benefit you. You don't say how you did your comparison though or what type your "disks" were. If your comparison was between different versions of Linux distro then it could simply be that the previous version did less (which is always the fastest way to boot)...

Another anecdote: a few years back I saw Slackware systems at a University converted over to systemd. Boot times (which involved waiting for multiple NFS mounts) went from over three minutes to down to less than a minute because more of the waiting was done in parallel.

Networks are allocated as /64 chunks because it makes autoconfiguration easy. It is often argued by newcomers that this is a huge waste, but really, 128 bits gives you so many addresses that you can stand to do a bit of wasting in order to make things simple. Generally the "what a waste" crowd severely underestimate just how big 128 bits is.

Yes and no. You _can_ allocate networks smaller than a /64, but you can't use SLAAC on such networks. That means you're stuck manually configuring devices or using DHCPv6. I believe Android has no support for DHCPv6, so you're probably very restricted if you choose to use a nonstandard network size.

Oddly enough, yes - ISPs really shouldn't be restricting your internal infrastructure. If your ISP is being a dick about this then the answer is pretty obvious - switch to another ISP, it isn't as if ISPs are thin on the ground.

Its undesirable in _some_ cases, it's absolutely required in others. So if you have a single IP address and you have to NAT everything, you win in the "some cases" situation and you lose for "others" (even worse with CGNAT). If you get rid of NAT and stick a stateful firewall in, you get the best of both worlds and can choose the best for the situation at hand.

That attitude is definitely wrong. The warm fuzzyness you're currently feeling is false security - lots of ways to trick a NAT into giving access to internal machines that you think are unaddressable. What you need is a stateful firewall - that gives you real security without breaking all the stuff that NAT does.

/64 is only big enough for a single network. /48s were quite common for a while, then recommendations were for ISPs to issue /56 to end users. There is no specific recommendation these days, but you certainly want to have more than a /64 if you can. I'd argue that /60 is a pretty reasonable size for a consumer grade ISP to hand out.. maybe /62 at a push, but that's starting to feel unreasonably scrimpy.

In the long term, yes. In the short term, going offline for the 93.69% of their users who don't have IPv6 yet would certainly be seen my most as a completely dickish move - I'm pretty sure their investors would be upset, for one thing.

How does IPv6 yield lower latency? If anything, the latency on IPv6 is often slightly higher than IPv4 owing to the prevalence of IPv6-over-IPv4 tunnels where native IPv6 interlinks aren't available, along with larger headers slightly increasing the latency of cut-through routing.

Does anyone actually implement IP mobility? It requires support from your ISP, and I've not heard anything about any ISPs implementing it.

DHCP does pretty much the same under IPv4 - I can't see this being a boon to Google/Facebook. (TBH I wouldn't be surprised if their infrastructure was too complex for any of these protocols - they've probably got some home baked protocol for doing that stuff).

So no different from IPv6 then... both protocols have ipsec support (I think it's mandatory for IPv6 whereas the IPv4 version is an optional backport, but all major OSes support it in both cases so that's neither here nor there). However, ipsec use is currently pretty much reserved for VPNs - you can do adhoc ipsec but no one does. About the only thing you get from IPv6 is that IP addresses are much sparser, so scanning/attacking by picking addresses at random isn't effective.

While my interaction with storage is "how long did it take for this operation to finish" the answer to that can vary dramatically on a hard disk depending on type and frequency of I/O I was doing (whereas the difference between best and worst values narrows with flash).

Your table doesn't capture the difference in wait time between reading only reading a 1GByte ISO in big chunks that's been laid out sequentially and serving up multiple torrents from big files that are over different parts of the disk simultaneously. You aren't always in the worst case and if the data is already cached in RAM you may be totally unable to perceive a difference because the waiting was decoupled from the request.

Telling people that "wait time" describes what they're seeing feels like it's trying to push latency and throughput into one number when both need to be distributions describing particular patterns of (potentially parallel) I/O and that's not even getting into queue depth. I guess there are parallels to telling people to describe things in terms of load average too...

While PCs continue to ship with legacy BIOS support you should be able to continue booting DOS on bare metal PCs (as you did). However FreeDOS does not yet support UEFI so if/when UEFI only machines come out the grand parent's challenge will become more difficult.

Whilst CFLs worked as a stop-gap until LED lights could become feasible, I do wonder if they have done long term harm to people's acceptance of efficient lighting - for a long time, "energy efficient lighting" is going to be associated with "takes 5 minutes to get bright enough to see" thanks to CFLs...

That said, I might miss CFLs in my bedside lights if I ever have to replace them with LEDs - that's the one place where a slow start-up is quite nice!

Supposedly Chromecast support will be in VLC 3.0.

(I'm not a Slashdot manager just another site user) Since the redesign things like comment boxes and posts have no white space at their left edge. Additionally something strange seems to be up with tags - they only display when you hover over them?