throwaway092834

That would be limited to west oakland which has always been extremely politically insular (tied up in racism and racial politics from last century). The east bay at large, especially the suburbs, is quite welcoming to tech and success.

The wife was mentioned because she was called out in the earlier article as a problem. We don't know if she was actually a problem or not. We, and specifically you, don't know enough to make the claims you're making.

Please, stop speculating. Have patience, wait for actual information.

It sounds like you're describing KAL007: http://en.wikipedia.org/wiki/Korean_Air_Lines_Flight_007

There's a larger list of airliner shootdowns here, and this is the only incident which seems to match your recollection: http://en.wikipedia.org/wiki/List_of_airliner_shootdown_inci...

There's nothing in the wikipedia article about the USA's ability to track planes. We did have a radar station in AK, which may be what you're thinking of? According to wikipedia it didn't produce useful information, and wasn't necessarily tracking the plane at all points anyway: http://en.wikipedia.org/wiki/Korean_Air_Lines_Flight_007#U.S...

I don't think we've ever had the ability to track all planes in the world.

Correct.

You're hinting that it's not in POSIX, and this is true.

There are many standards and cross-platform interfaces defined outside of POSIX. Some explicit and top-down, some organically evolved.

The spec for /dev/*random is here, as was published in the mid-90s: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-sta...

These aren't myths, they're platform guarantees. It just so happens that a few of the most common unixes (Linux, BSD) implement a very good /dev/urandom and the author is suggesting that we write non-portable software that depends on implementation details of these platforms.

There can be benefits from depending on non-portable implementation details but also significant drawbacks.

It's not important because you should use it in your projects.

It's important because other people will use it, sometimes inadvertently.

Let's be fair: Starting out famous is an enormous boon.

At the same time it's possible for nobodies to be heard as well, provided their message is well presented.

The subject I'm responding to is "winning the lotto." That's why it's a poor comparison.

It's not an exceptional level of wealth for this region. Not even top 10%.

"Except that we don't see CPUs being astonishingly creative in coming up with reasons why they shouldn't have to follow a clear, unambiguous program instruction."

That's the compiler's job ;-)

The bank didn't make the laws and doesn't run OFAC. The government does.

Neither do I, but they almost always mention my employer -- that's what we're talking about.

You may be the odd one out then. I've spent a fair amount of time in lines at the bank and most people are quite chatty.

Really? That reaction strikes me as quite odd. Do you not chit-chat with tellers at your bank in person?

To be fair there's some circular reasoning here. A contract itself is only valid and legal according to the law of a particular nation. Those pieces of paper had no equivalence of legal meaning in the Native American culture prior to the founding of the colonies and the forced application of English common law.

There's plenty of room for both. Many useful, worthwhile applications won't ever really push a machine to its limits, rather they primarily involve bringing structure and order to mounds of complex business logic. And that's OK. Not everything needs to be optimized.

On the other side of the same token, many useful, worthwhile applications will absolutely depend on this level of optimization. There are some problems which simply can't be solved in a practical manner without it. And that's OK too.

Can you elaborate? I don't understand this perspective.

There are plenty of ways to kill pid 1. The major concern is simply software error, which is another reason why the current systemd design is poor. But if you'd like a concrete example, go ahead and attach gdb and use your imagination.

That is indeed my point. The reason: pid 1 is special on unix. Here's a pretty decent article on the subject: http://ewontfix.com/14/

We already do. I think most people in this discussion aren't realizing that the current sysV init system is an extremely small pid 1 /sbin/init, and most of the logic in external rc scripts. Moving rc scripts to systemd declarative syntax is fine.

The important part with respect to software architecture is less complexity in pid 1. Subprocesses of init can be safely updated and restarted. More code in init is a real problem -- that's why systemd as pid 1 is controversial.

"But there are technical reasons for systemd to run as init: A key feature is to precisely track whether or not a service is running or not"

This is not true. Tracking a running service doesn't require being init. Any process can do it.

"sysv init can not do this."

Nor should it. Services running under sysV init can, however.

"More importantly, since there's no ordering or dependency control"

Yes, there is -- it's implemented by the rc system. It's crude, but it's also just a bunch of shell scripts and completely pluggable. The systemd logic could trivially be inserted here either in place of /etc/rc, or by something that sits directly under init and drives the rest of the process.

"In practice, while Daemontools for example is well written and as stable as it can be, by virtue of running outside pid 1 it is not immune to the effects of the surrounding system. It can, and does, end up orphaning monitored processes in a variety of circumstances"

Any process can daemonize away from a process manager. systemd adds cgroups for tagging or containing process trees -- this is possible under runit/daemontools and it would only take minor changes to the supervise process to instantiate the cgroup and supervise accordingly.

To be clear: Any process can add cgroup support to track forked children. Solving this problem by adding cgroup support has absolutely nothing to do with becoming init.

"By running as pid 1, systemd is protected against being killed."

No, that is false. There is no such protection -- killing pid 1 is easy. Rather, by running as pid 1 systemd will cause a kernel panic and bring down everything with it.

"By then applying cgroups it can precisely track whether or not what was spawned is still running, even if it forks more stuff. By applying this to the boot process, it can provide this functionality to everything that gets started during boot."

sysV already exports most boot ordering into subprocess. It is trivial to achieve these tasks with systemd as a child of init.

"This is functionality that init does not provide, and none of the process-monitors running outside of pid 1 can provide."

It is true that init doesn't provide these features, nor should it. Your second statement is false -- a common misconception as I've hopefully explained.

If you have any further technical questions about how one CAN perform all these actions as a child of init I would be happy to explain in detail.

Your assertion is strictly false. All features of this new process invocation system could be implemented without making a "new init system." That's my primary point in commenting here. It is a false dichotomy.

Sure. What I think is unclear that I intend to highlight is that systemd (and yes, upstart) have intentionally and unnecessarily created this technical conflict.

There is no "turtles" issue here. Pid 1 is special - if it dies, the system panics. It is good design to keep pid 1 as simple as possible and put the complex job logic in a sub-process. There are only two things on unix which init must do: reap any children it inherits, and start something else to do the heavy lifting.

Even sysV init works this way. The current sysV init is very simple -- the invocation complexity lives in /etc/rc and the related rc.d scripts which operate as subprocesses.

"Smart people" is a silly thing to say. We're all smart people and sometimes smart people make poor technical decisions. Let the matter lay upon its technical merit, not upon empty platitudes.

It's possible, but it's not designed to. It was designed to run under init, as a daemontools clone. Explained further here: http://smarden.org/pape/djb/daemontools/noinit.html

"In contrary to Richard Gooch, I suggest not to implement service dependencies and runlevel handling in the Unix process no 1, /sbin/init, keep it small and simple, that is why I wrote the runit package"

This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd.

There's a little piece of insight which seems to escape many: there is no serious technical reason why systemd must run as init. Systemd could have been written to coexist in a number of various ways following previous models, running under init and doing things for init.

Systemd is winning this war because it created the war, by conflicting with sysv init.

We're discussing different things. You're talking about fame and internet comments which have no real impact, at least, not to me. I don't have a problem with people insulting the code I publish under my real name.

I'm talking about the potential for real life harassment (folks calling my employer, showing up at my house, swatting, etc) if I were to say something controversial. I am specifically concerned with being doxxed and criminal harassment.

There's a vast world of difference between people making comments in poor taste over a game and the level people sometimes go to if they engage in an argument and lose in an embarrassing way. I would not recommend that anyone freely engage in internet debates in a non-anonymous fashion.

Because I have found the internet in general to be at times crude, ignorant and destructive. I don't want to concern myself with considering self-censorship to ensure self-preservation. Instead I chose to contribute anonymously so that I may challenge the status quo or speak truth to power without personal concern.

I assure you it has nothing to do with embarrassment. It's unfortunate, but speech often has very serious consequences.

I have to say yes, I would have no problem with being known for inventing a toilet brush, or flappy bird. I'd be proud, even.

I know that people can have strangely fragile egos but the idea of being upset for being known for something, no matter how benign, is completely foreign to me.