There is another possible interpretation: that programmers who are very concerned about quality - and hence are happy when their language gives them lots of information about potential mistakes - like using languages with features (such as a strong type system) designed to allow detection of certain types of mistake. That is, it's specific features of the languages, rather than the fact that the languages are "unpopular", that draws quality-focussed programmers to them.

Of course, that is just as much conjecture as any other interpretation :-)

What I said was that there is no distance information in the message received from the satellite. Of course you can derive distance information, or else GPS wouldn't work at all :-)

Right - but there are two problems with this. One is that, by taking measurements over time, you do indeed get more information - but you also introduce more unknowns, because now you have to take into account the fact that you are likely to be moving - so you can't tell what part of the difference in the satellite signal is due to the satellite's motion, and which is due to yours. The other is that, even if you're guaranteed to be stationary, for your different readings from the same satellite to be useful, the satellite has to have moved a substantial distance, or else the errors in measurement will be relatively large compared to the change in timestamp difference - so you can't do an accurate calculation of your position. (This is why receivers won't give you a position readout even if they have 4 satellites, if those 4 satellites are very close together in the sky.) In practice it takes of the order of hours for the satellite to move sufficiently (which then introduces other problems - the quartz-based clocks in typical GPS receivers are not sufficiently accurate over such long periods.)

Yes - which is exactly what I said :-) But differences only give you N-1 measurements for N satellites.

Umm... if you're claiming you can find your elevation, then you can find your distance from the centre of the Earth. It's more or less the same thing :-). I agree you can use the measurements from the satellites though (i.e. you don't need to know any information about your elevation a priori).

I agree that the position of each satellite is known, to high accuracy. That's not the issue - the issue is that, if you have a signal from one satellite, that doesn't tell you your distance from that satellite. The signal basically says "I am satellite 7, I am at (position), and the time by my clock is (time)", and that is all your receiver receives. Receiving that signal tells you nothing about your position (well, possibly you can tell which hemisphere you're in from the fact that the satellite is visible at all, but that doesn't narrow things down much!). You only start getting information about your position when you have signals from more than one satellite, because then you can compare the timestamps - the difference in the timestamps gives you information about the difference in the distance from you to the two satellites.

I agree that 3 points and 3 distances is all you need. The trouble is that the signal from 3 satellites only gives you 2 distances (unless, as jfengel mentions, you happen to be carrying round an atomic clock with you - which is generally not practical!).

I mention probability because, even in the absence of 3 distances to give you a full 3D fix, you can use the fact that, statistically speaking, most people spend most of their time very close to the Earth's surface, to give a good estimate for one of the distances (i.e. estimate "I'm probably at or near ground level"), which then generally gives a pretty good estimate of your horizontal position. This is why even a 2D GPS fix is very useful in practice. But even if you have a signal from 4+ satellites, probability still comes into play: you have to account for radio interference, atmospheric effects and multipath effects, inaccuracies in the receiver's clocks, rounding errors, etc. etc., each of which adds uncertainty to the measurements and calculations and hence to the ultimate position readout.

Yes, I know you can do that, I even mentioned it :) But the person I was repying to claimed "3 satellites are sufficient to find your basic location and elevation" (emphasis mine) - i.e. they were claiming you could find the distance from the centre of the Earth, without assuming it.

You still need to think about probability, because the elevation model only tells you where the ground is - not where you are in relation to it. That said, the asumption "you're probably very close to the surface" is often very good, at least for most people :-)

Then perhaps you can provide a reference?

No: basic geometry dictates that, to find a position in three dimensions, you need three measurements of distance. The trouble is that the signal from one satellite gives you no information about your position: the signal (roughly speaking) tells you where the satellite is, and the time by that satellite's clock - but since you have nothing to compare it against, you have no idea how long that signal took to reach you, so you get no information about your position.

It's similar to if you asked me my height, and I said "I'm a foot taller than Fred". If you don't know how tall Fred is, you're no nearer to knowing how tall I am, even though you've been given one measurement. Sure, if you look at probability distributions of height you can have a good guess at how tall I might be, and this is similar to getting a 2D fix (where you assume that your elevation is "at or near the surface of the Earth"), but you can't know for certain that one of both of us don't have unusual heights.

Once you have a signal from two satellites, you can subtract the timestamps, which doesn't directly tell you position, but tells you which satellite is closer to your position, and by how much. This allows you to constrain your position in one dimension (i.e. you still have two degrees of freedom - a surface rather than a solid), and another satellite's signal will give you another constraint (pinning you down to a line); only with a fourth satellite can you determine your position precisely (well, actually the solution can give more than one point but generally only one is realistic).

There is... and the default is (I believe) not to restart.

Except that this feature of systemd doesn'trequire any rewriting of services, at all. They just carry on sending output to stdout, stderr, and/or syslog, as they have always done - and the "cgroups" feature ensures the logs can be distinguished and stored appropriately. Doing the same consistently for SysV init would actually be genuinely harder, because (for example) when services are started manually this is done by running a service-specific shell script - so to ensure each service ends up in the right cgroup, you have to add a lot of Linux-specific stuff to each service's startup file.

I'm not yet 100% sold on whether the log filtering is worth all the extra code implementing it - but saying it's "not a big deal" to add the same feature to sysvinit is not telling the whole story.

Apparently systemd has support for a watchdog function for services, so it could potentially notice this (though the service needs to have support for it).

Not to mention crashes caused by rare, hard-to-reproduce race conditions. These do happen (correct multi-threaded programming is hard), and personally I'd prefer it if the process crash didn't take down my websites with it - though of course I do want the logs to let me know, loud and clear! Sure, if the service crashes repeatedly on restart, it needs to be throttled, but I assume systemd can do that (after all, this is one of the things SysV init has always done, at least for getty processes).

Note: systemd is not part of the Linux kernel.

Really? I confess I haven't looked at how to configure systemd much, but from what I have seen, that sort of setup could be supported easily enough by writing the right unit files (or whatever they're called) and specifying the dependencies. What's the issue that prevents that working?

Indeed, the syllogism in funwithBSD's post doesn't follow unless one adds an implicit "[but the other one does]" to the first two sentences.

Right - it's not true dependency checking, but it is a way of encoding the the startup dependencies (which is why it's done, after all).

True again - and this is exactly the point; once you do this, and cause the boot process to stall before the point where you can log in, you're just as broken under any init system :)

Sure, anyone can come up with a timeout script that will (effectively) declare a service "ready" if a certain time limit is reached - but again, that will work equally well with any init system. (And did you have a timeout in place for your accidental "sleep 20000"? It's the sort of thing that's easy to add, but usually only with hindsight ;-). Also I think you want $$ rather than $?.

Everything's trivial until you've actually tried it ;-). You can quite quickly do something approximating it, but doing the useful parts (e.g. "start this service, plus everything it needs" - and, better still, "if I were to ask you to start this service, what else would you need to start?") requires a lot more work. In particular, it needs a concept of knowing which services are currently started, which SysV init lacks.

Actually it does, in a clumsy kind of way: you give the services a priority, and services with a lower priority are started before those with a higher priority. So if you have an early-starting service (eg bringing up filesystems) that blocks for a long time, that will delay later-starting services (eg sshd) just as much. If you're lucky, your system's rc scripts may implement a timeout - otherwise you're just as hosed under SysV init as under smf/systemd...

You didn't mention Solaris, only smf, so you could equally have been talking about, say, an Illumos-based distribution... but thanks for clarifying :)

True.

Alas the same is true in practice for SysVinit. And in fact, systemd has better support for overriding the defaults from the vendor/distro packages - though I've never actually used it, so I don't know how well it works in practice.

In practice it's far from trivial.

I can't see how you can make that guarantee. The problem with ssh not starting up was due to the distro/vendor encoding dependencies badly. That can be done just as well with SysV init as with any other system. Depending on how the local "rc" script (or equivalent) is set up, this can lead to the machine hanging indefinitely for no good reason (I've seen it happen enough times!). Alas no init system can protect you from dumb decisions by distros/vendors :-/

It points you to the location of some shell scripts that you have to read and parse in order to find where your particular flavour of *nix stores its Snn* and Knn* symlinks, then look at those... to me that doesn't seem a lot better than having to look at the manpage to find the damn files, but you are entitled to your preference :-)