Please create an account to participate in the Slashdot moderation system

 



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: 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: "Google Now" and "OK Google" are different (Score 1) 35

by Sits (#48654201) Attached to: Chromebook Gets "OK Google" and Intel's Easy Migration App

If you have an appropriate Android device Google Now will (apparently) display information based on your current context (e.g. if your phone learns where work and home are it might display information about traffic jams on the route home around the time it believes you will be traveling). You need a logged in Google account to use this feature.

OK Google is a way of using your voice to interact with your device (or Chrome web browser). So if I have the appropriate phone and it's been set to listen I can say "OK Google" and it will activate an app/mode where it will accept further voice input. On the Android phone I saw (and in my Chrome web browser on OS X) I can then ask it "What's the weather like?" and it pops up some weather related information and speaks back "It's ten degrees in ". Sometimes when you ask it questions just does a web search other times (on the device) it would start applications (e.g. mail) and so on. You do not need to be logged into Google to use this feature.

Comment: It's possible to beat good testing... (Score 1) 169

by Sits (#48234295) Attached to: Tetris Is Hard To Test

...but not without a price. If you can mathematically construct your program then you can prove that it is free from defects providing enough assumptions hold (the specification is correct, the tools used to build it are correct, the proof of correctness is correct, you had enough money/time/skill to do the process etc). For the time being, it's not possible to formally most programs that have already been written in mainstream languages so other techniques like testing will remain useful tools.

Comment: ShellShock checker (Score 2) 329

by Sits (#48018603) Attached to: Bash To Require Further Patching, As More Shellshock Holes Found

From Eric Blake's bug-bash post

bash -c "export f=1 g='() {'; f() { echo 2;}; export -f f; bash -c 'echo \$f \$g; f; env | grep ^f='"

If you see anything like the following:

bash: g: line 1: syntax error: unexpected end of file
bash: error importing function definition for `g'
1
2
f=1
f=() { echo 2

you're still vulnerable. There may be other issues the above does not cover.

Comment: Some C compilers already have bounds checking (Score 2) 98

by Sits (#47762927) Attached to: Project Zero Exploits 'Unexploitable' Glibc Bug

You can already ask some compilers to do what you are asking - it's just often not on in shipped builds.

At compilation time warnings can be generated for out of bounds accesses that can be determined statically. Clang has -fsanitize=bounds, GCC has -Warray-bounds.

As an Anonymous Coward pointed out, it can be hard to detect runtime allocations overruns at compilation time. For these something like Clang's AddressSanitizer (GCC has added it too will help but at a cost of both time (slow down factor of 2) and space which is why you're unlikely to find it enabled on your precompiled SSH server binary. It's true there are cheaper checks (such as GCC's FORTIFY_SOURCE) that are less thorough/specialized that are often enabled by distros.

Comment: LLVM for dynamic code generation (Score 1) 61

by Sits (#47746381) Attached to: Virtual Machine Brings X86 Linux Apps To ARMv7 Devices

My understanding is that Apple have done the work to make it viable to use LLVM for certain levels of Javascript JITing so it is now feasible to use LLVM to compile long running dynamic code. Said code needs to be long running to a) build up information about the instructions being run b) offset the overhead of compilation.

Disclaimer: "These opinions are my own, though for a small fee they be yours too." -- Dave Haynie

Working...