Every attacker of gamergate has been violent, sending death threads, making up BLATANTLY fake images to make themselves look like victims, and very publicly attacking people on Twitter as well.
I've got to confess I haven't seen any of this. Do you have a link?
the preference of certain personality types for functional, static and strongly typed languages.
Translation: because only very high-skill programmers attempt to use the very unpopular functional languages (like lisp and erlang) the resulting code is, on average, of better quality.
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:-)
No: basic geometry dictates that, to find a position in three dimensions, you need three measurements of distance.
Yes! Why are you assuming there is no distance information? There is!
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:-)
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.
This is where you're falling down. Of course you have things to compare it to. For each satellite, you have consecutive signals giving you new coordinates and a new time reference. You can calculate the distance between those two points. Then you can calculate the change in the difference between the timestamp in the signal and its arrival time. This actually gives you very good distance information, although of course it isn't static. (It could not be.)
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.)
You can also make comparisons between the satellites. That only gives you relative, rather than absolute, distances,
Yes - which is exactly what I said:-) But differences only give you N-1 measurements for N satellites.
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.
No. You are finding your distance from the satellites. Not from the center of the Earth.
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).
But since the 3-D positions of the satellites are known to a fine degree of accuracy, that's all you need.
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.
And yes, 3 points and 3 distances is all you need to find a point in 3D space. It actually defines 2 points, but as mentioned before one is out in space so it obviously doesn't count. The other one is on the surface of the Earth (or in a plane, or whatever).
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!).
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:-)
No. Again, the orbits (and therefore positions) of the GPS satellites are known very precisely. As long as you can receive the signals from them, you could be above the ground, or below the ground, or even at the center of the Earth (at least theoretically), and still get your position and "elevation", even though it may be negative. Probability is not a factor at all, though accuracy certainly is. There are errors that have to be accounted for.
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, and one of those measurements come from knowing your distance from the center of the Earth.
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.
Sure, if you look at probability distributions of height...
Except you don't need to look at probability distributions. GPS setups meant for use in areas with possibly limited reception and no nearby ground station/LORAN alternative to help deal with that can use a detailed elevation model of the Earth to narrow things down quite a bit.
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:-)
No, it is NOT wrong. Your assertion is a common misconception. I assure you: I looked into this technology in depth.
Then perhaps you can provide a reference?
Just as basic geometry would normally dictate, 3 satellites are sufficient to find your basic location and elevation.
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).
If it has been so well thought out, then why isn't there a parameter available for each service that says "don't automatically restart this if it fails"?
There is... and the default is (I believe) not to restart.
Not much harder than rewriting all the services to log to systemd instead of calling syslog(), except that now they're still compatible with non-Linux servers.
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.
If a process locks but does not exit, systemd would not notice,
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).
Many hardware failures are transient, and a process restart is a very effective fix, at least in the short term
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).
Development of Linux kernel is not done by consensus. It is done by 2-3 important firms the likes of Red Hat/IBM/Oracle and the rest/scraps are left for the open source community. [...] Apt-get was an exception, it is not a kernel project.
Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc,
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?
What Sys V does isnt dependency checking, it is simply an order of execution.
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, you could put something in one that hangs the thing, I did myself by accident once but its a very easy fix
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:)
it takes two minutes to come up with a timeout strategy if you want one. Here Ill try ok.
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 $?.
Doing your own dependency checking IS trivial
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.
I can guarantee it because sys V init doesnt enforce dependencies
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...
It wasnt that the vendor (this is Solaris if you remember)
You didn't mention Solaris, only smf, so you could equally have been talking about, say, an Illumos-based distribution... but thanks for clarifying:)
got the dependencies wrong. The dependencies are actually right if you look at it from one perspective (user audit logs should be preserved) and wrong if you look at it from another perspective (I am not interested in standard unix auditing logs and need sshd up)
True.
With systemd type systems the vendor has to choose one and can not know which is right for might feel differently on different occasions.
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.
If you need dependency checking it is trivial for an administrator to set that up using the sys V model.
Point 1. No. I guarantee that on a sys V init system I would have been able to log in and easily see that a filesystem that should have been mounted wasnt mounted and then diagnose and fix it.
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:-/
Point 2. Indeed but/etc/inittab tells you all the places you need to look and you can go and look at them and read them. Sorry but that seems rather tidy to me.
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:-)
It was when I discovered that sshd startup was dependent on utmp being available which depended on filesystem mounting being successful that I knew for sure that systemd style init was nothing I wanted.
How would this have been any different with SysV init? That would have translated into sshd being started later than the filesystem, utmp etc - so you'd have had the same issue. In fact it can end up being worse, because a higher-numbered service can end up being delayed by a lower-numbered one, even if it doesn't have any dependency on it at all...
For me, scanning through/etc/inittab and being able to see exactly what is going on in the initialisation stage is the essence of Unix.
But/etc/inittab only tells a tiny part of the story; you also need to look in/etc/init.d,/etc/rc*.d etc - so not really all that different to what you'd have to do with systemd (except that at least with SysV init you presumably already know where to look;-)
Re:replacing line feeds with terminators is not a
on
Tetris Is Hard To Test
·
· Score: 2
46 lines (statements), actually
No, statements are not the same as lines. Lines have real semantic significance in BBC Basic, in a few different ways: for one, GOSUB-type subroutines can only start at the start of a line (because that's where the line number is), and you also can't terminate an "if" without starting a new line. That (plus the 256-byte limit) makes writing one-liners in the language more of a challenge than in other languages where line breaks genuinely aren't significant.
Vista, which is the lowest currently supported version of Windows.
That's actually not true, strictly speaking... XP is still supported, for those (usually governments and large companies) who are willing to pay Microsoft for it...
... and may chance you didn't read my post:
(There was a LOT more to my presentation that just this; this single part presented here to convey the concept).
The trouble is - the single part that you presented is clearly broken (eg it doesn't work well with the way many mailing lists work), so if it conveys the concept of your whole presentation, people are naturally going to assume that the whole presentation was broken...
That's true, but it seems that the real problem the OP is trying to solve is huge variance in the latency (i.e. jitter) - that is, the idea is to trade a very small amount of extra latency for the latency being much more consistent (without the massive spikes currently being seen). I'm not sure how well it would work in practice (e.g. if some of the spikes are due to local RF interference, it's possible they will affect both connections at the same time), but there's potential at least for a much smoother gaming experience.
Well, for one thing the servers have to cope with that, because internet service in general doesn't guarantee that packets don't get duplicated. But in what OP is suggesting, the servers won't see duplicate packets - the idea is that every packet gets sent out of both internet connections to one, private, hosted VPN server - and that server runs a service that forwards whichever copy of the packet arrives first to the "real" destination (and discards the losing packet) - so the game server will only get one copy of each packet in the stream.
Slashdot Mirror
Every attacker of gamergate has been violent, sending death threads, making up BLATANTLY fake images to make themselves look like victims, and very publicly attacking people on Twitter as well.
I've got to confess I haven't seen any of this. Do you have a link?
the preference of certain personality types for functional, static and strongly typed languages.
Translation: because only very high-skill programmers attempt to use the very unpopular functional languages (like lisp and erlang) the resulting code is, on average, of better quality.
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 :-)
No: basic geometry dictates that, to find a position in three dimensions, you need three measurements of distance.
Yes! Why are you assuming there is no distance information? There is!
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 :-)
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.
This is where you're falling down. Of course you have things to compare it to. For each satellite, you have consecutive signals giving you new coordinates and a new time reference. You can calculate the distance between those two points. Then you can calculate the change in the difference between the timestamp in the signal and its arrival time. This actually gives you very good distance information, although of course it isn't static. (It could not be.)
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.)
You can also make comparisons between the satellites. That only gives you relative, rather than absolute, distances,
Yes - which is exactly what I said :-) But differences only give you N-1 measurements for N satellites.
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.
No. You are finding your distance from the satellites. Not from the center of the Earth.
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).
But since the 3-D positions of the satellites are known to a fine degree of accuracy, that's all you need.
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.
And yes, 3 points and 3 distances is all you need to find a point in 3D space. It actually defines 2 points, but as mentioned before one is out in space so it obviously doesn't count. The other one is on the surface of the Earth (or in a plane, or whatever).
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!).
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 :-)
No. Again, the orbits (and therefore positions) of the GPS satellites are known very precisely. As long as you can receive the signals from them, you could be above the ground, or below the ground, or even at the center of the Earth (at least theoretically), and still get your position and "elevation", even though it may be negative. Probability is not a factor at all, though accuracy certainly is. There are errors that have to be accounted for.
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.
you need three measurements of distance.
Yes, and one of those measurements come from knowing your distance from the center of the Earth.
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.
Sure, if you look at probability distributions of height ...
Except you don't need to look at probability distributions. GPS setups meant for use in areas with possibly limited reception and no nearby ground station/LORAN alternative to help deal with that can use a detailed elevation model of the Earth to narrow things down quite a bit.
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 :-)
No, it is NOT wrong. Your assertion is a common misconception. I assure you: I looked into this technology in depth.
Then perhaps you can provide a reference?
Just as basic geometry would normally dictate, 3 satellites are sufficient to find your basic location and elevation.
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).
If it has been so well thought out, then why isn't there a parameter available for each service that says "don't automatically restart this if it fails"?
There is... and the default is (I believe) not to restart.
Not much harder than rewriting all the services to log to systemd instead of calling syslog(), except that now they're still compatible with non-Linux servers.
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.
If a process locks but does not exit, systemd would not notice,
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).
Many hardware failures are transient, and a process restart is a very effective fix, at least in the short term
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).
Development of Linux kernel is not done by consensus. It is done by 2-3 important firms the likes of Red Hat/IBM/Oracle and the rest/scraps are left for the open source community. [...] Apt-get was an exception, it is not a kernel project.
Note: systemd is not part of the Linux kernel.
Funny that rc dealt with that ages ago by having S01mount S05network S10networkmount but I'm sure there's a very good reason systemd is incapable of using mount -a -t nfs,cifs,smb,afs,etc,
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?
Interesting, I did not say Science proved, I said Religion did not.
I thought you were implicitly saying that one did what you said the other did not. I still think that's what you meant and this post is backpedalling.
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.
What Sys V does isnt dependency checking, it is simply an order of execution.
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, you could put something in one that hangs the thing, I did myself by accident once but its a very easy fix
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 :)
it takes two minutes to come up with a timeout strategy if you want one. Here Ill try ok.
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 $?.
Doing your own dependency checking IS trivial
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.
I can guarantee it because sys V init doesnt enforce dependencies
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...
It wasnt that the vendor (this is Solaris if you remember)
You didn't mention Solaris, only smf, so you could equally have been talking about, say, an Illumos-based distribution... but thanks for clarifying :)
got the dependencies wrong. The dependencies are actually right if you look at it from one perspective (user audit logs should be preserved) and wrong if you look at it from another perspective (I am not interested in standard unix auditing logs and need sshd up)
True.
With systemd type systems the vendor has to choose one and can not know which is right for might feel differently on different occasions.
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.
If you need dependency checking it is trivial for an administrator to set that up using the sys V model.
In practice it's far from trivial.
Point 1. No. I guarantee that on a sys V init system I would have been able to log in and easily see that a filesystem that should have been mounted wasnt mounted and then diagnose and fix it.
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 :-/
Point 2. Indeed but /etc/inittab tells you all the places you need to look and you can go and look at them and read them. Sorry but that seems rather tidy to me.
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 :-)
It was when I discovered that sshd startup was dependent on utmp being available which depended on filesystem mounting being successful that I knew for sure that systemd style init was nothing I wanted.
How would this have been any different with SysV init? That would have translated into sshd being started later than the filesystem, utmp etc - so you'd have had the same issue. In fact it can end up being worse, because a higher-numbered service can end up being delayed by a lower-numbered one, even if it doesn't have any dependency on it at all...
For me, scanning through /etc/inittab and being able to see exactly what is going on in the initialisation stage is the essence of Unix.
But /etc/inittab only tells a tiny part of the story; you also need to look in /etc/init.d, /etc/rc*.d etc - so not really all that different to what you'd have to do with systemd (except that at least with SysV init you presumably already know where to look ;-)
46 lines (statements), actually
No, statements are not the same as lines. Lines have real semantic significance in BBC Basic, in a few different ways: for one, GOSUB-type subroutines can only start at the start of a line (because that's where the line number is), and you also can't terminate an "if" without starting a new line. That (plus the 256-byte limit) makes writing one-liners in the language more of a challenge than in other languages where line breaks genuinely aren't significant.
Vista, which is the lowest currently supported version of Windows.
That's actually not true, strictly speaking... XP is still supported, for those (usually governments and large companies) who are willing to pay Microsoft for it...
That's a sanitized WHO number. That ends with a zero? Unlikely.
Not really that unlikely, especially as fatality rates are often given to the nearest 5%...
tag!
... and may chance you didn't read my post: (There was a LOT more to my presentation that just this; this single part presented here to convey the concept).
The trouble is - the single part that you presented is clearly broken (eg it doesn't work well with the way many mailing lists work), so if it conveys the concept of your whole presentation, people are naturally going to assume that the whole presentation was broken...
Wouldn't it be quicker to just type the second d?
I guess the apostrophe stands for "erat"?
That's true, but it seems that the real problem the OP is trying to solve is huge variance in the latency (i.e. jitter) - that is, the idea is to trade a very small amount of extra latency for the latency being much more consistent (without the massive spikes currently being seen). I'm not sure how well it would work in practice (e.g. if some of the spikes are due to local RF interference, it's possible they will affect both connections at the same time), but there's potential at least for a much smoother gaming experience.
Well, for one thing the servers have to cope with that, because internet service in general doesn't guarantee that packets don't get duplicated. But in what OP is suggesting, the servers won't see duplicate packets - the idea is that every packet gets sent out of both internet connections to one, private, hosted VPN server - and that server runs a service that forwards whichever copy of the packet arrives first to the "real" destination (and discards the losing packet) - so the game server will only get one copy of each packet in the stream.