Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment: systemd was in native mode for the first two (Score 1) 442

by Sits (#49644789) Attached to: Debian 8 Jessie Released

Anecdotes 1 + 2 were running in native mode because it was initially a fresh install that was then switched sysvinit-core. Anecdote 3 I don't know (most likely compatability mode as it was several years ago). Even if all the anecdotes were only running in compatibility mode the results show systemd finishing quicker...

Does the above make things any better and how fast do you expect things to go when you're bottlenecked on I/O throughput? Is 15 seconds for a hard disk or 4(!) seconds for a RAM disk so bad?

Comment: Re:Systemd vs sysinit boot speed anecodote (Score 1) 442

by Sits (#49554705) Attached to: Debian 8 Jessie Released

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...

Comment: Systemd vs sysinit boot speed anecodote (Score 4, Informative) 442

by Sits (#49554167) Attached to: Debian 8 Jessie Released

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.

Comment: Re:IPv6's day will come, but... (Score 1) 390

by FireFury03 (#49523063) Attached to: Why the Journey To IPv6 Is Still the Road Less Traveled

So, the designers of IPv6 could not conceive that somebody could have less than 2^64 devices and still want to put them in separate networks?

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.

So now my ISP will have a say in how many internal networks I have?

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.

And this is supposed to be better than IPV4 with NAT?

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.

Comment: Re:IPv6 and Rust: overhyped and unwanted! (Score 3, Insightful) 390

by FireFury03 (#49518233) Attached to: Why the Journey To IPv6 Is Still the Road Less Traveled

People who think they need end-to-end connectivity for everything don't understand networking. It's not only not required, it is undesirable in most cases.

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.

Comment: Re:IPv6 and Rust: overhyped and unwanted! (Score 1) 390

by FireFury03 (#49518221) Attached to: Why the Journey To IPv6 Is Still the Road Less Traveled

As someone who's not really a networking guy, this!

I like the extra layer NAT provides. It's no substitute for a firewall of course, but having your internal boxes not publicly addressable at all adds an extra layer of warm and fuzzy.

Is this attitude wrong? Probably. But it is also pervasive.

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.

Comment: Re:IPv6's day will come, but... (Score 1) 390

by FireFury03 (#49518207) Attached to: Why the Journey To IPv6 Is Still the Road Less Traveled

WTF do you need a /48 for? A /64 isn't big enough for you?

/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.

Comment: Re: Waiting for the killer app ... (Score 2) 390

by FireFury03 (#49517841) Attached to: Why the Journey To IPv6 Is Still the Road Less Traveled

IPv6 would help both enormously.

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.

Lower latency on routing means faster responses.

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.

IP Mobility means users can move between ISPs without posts breaking, losing responses to queries, losing hangout or other chat service connections, or having to continually re-authenticate.

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

Autoconfiguration means both can add servers just by switching the new machines on.

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).

Because IPv4 has no native security, it's vulnerable to a much wider range of attacks and there's nothing the vendors can do about them.

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.

Comment: Unusual way of looking at it (Score 1) 162

by Sits (#49517237) Attached to: New PCIe SSDs Load Games, Apps As Fast As Old SATA Drives

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...

Comment: Whoopie Do (Score 1) 117

Being able to 3D scan something from your phone would be neat, if a bit niche, but the printer will not be mobile, and just like the current desktop scanners, your highly precise model will only be of the visible OUTSIDE of the object. That might be fine if you just want a cheap plastic replica of that sculpture, but pretty much useless if you wanted a replacement for anything but the crudest of mechanical parts.

Comment: Not all speed limits are signposted (Score 1) 287

by POPE Mad Mitch (#49334219) Attached to: Ford's New Car Tech Prevents You From Accidentally Speeding

Its all well and good it looking for new speed limit signs, but some speed limits are contextual in the UK e.g. National Speed limit (black line crossing a white circle), and most 30 limit areas are not signposted at all as its implied by the urban setting and street lighting.

Comment: Re:price? (Score 1) 328

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!

And on the seventh day, He exited from append mode.

Working...