throwaway092834

6 ms·

1.
by throwaway092834 12y ago
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.
2.
by throwaway092834 13y ago
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,
3.
by throwaway092834 13y ago
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 rec
4.
by throwaway092834 13y ago
Correct.
5.
by throwaway092834 13y ago
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
6.
by throwaway092834 13y ago
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 th
7.
by throwaway092834 13y ago
It's not important because you should use it in your projects. It's important because other people will use it, sometimes inadvertently.
8.
by throwaway092834 13y ago
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.
9.
by throwaway092834 13y ago
The subject I'm responding to is "winning the lotto." That's why it's a poor comparison.
10.
by throwaway092834 13y ago
It's not an exceptional level of wealth for this region. Not even top 10%.
11.
by throwaway092834 13y ago
"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 ;-)
12.
by throwaway092834 13y ago
The bank didn't make the laws and doesn't run OFAC. The government does.
13.
by throwaway092834 13y ago
Neither do I, but they almost always mention my employer -- that's what we're talking about.
14.
by throwaway092834 13y ago
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.
15.
by throwaway092834 13y ago
Really? That reaction strikes me as quite odd. Do you not chit-chat with tellers at your bank in person?
16.
by throwaway092834 13y ago
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 t
17.
by throwaway092834 13y ago
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
18.
by throwaway092834 13y ago
Can you elaborate? I don't understand this perspective.
19.
by throwaway092834 13y ago
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.
20.
by throwaway092834 13y ago
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/
21.
by throwaway092834 13y ago
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 decla
22.
by throwaway092834 13y ago
"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
23.
by throwaway092834 13y ago
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.
24.
by throwaway092834 13y ago
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.
25.
by throwaway092834 13y ago
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
26.
by throwaway092834 13y ago
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 R
27.
by throwaway092834 13y ago
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-hab
28.
by throwaway092834 13y ago
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 t
29.
by throwaway092834 13y ago
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
30.
by throwaway092834 13y ago
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,

More ›