The common failure mode would be "electronics" and any type of electronic navigation would fall under that. Furthermore, if all a ship's electronics are offline their engines are probably not functioning either.

The traffic isn't transiting Comcast going to another network. It's going to a Comcast subscriber who wants to watch a movie. So, yes, the subscriber is requesting a movie and the data is being delivered to them. There's no other route to the subscriber than through their ISP.

Exactly - keep it in Fedora and Ubuntu for a while before migrating it to the systems that need stability.

Who knows what annoyance are lurking in there.

Well, when I was referring to the original comment, that was the one written by rioki, not you.

I got interested in computers at about the same age as you, but for me that was around 1978 in the US. At that time things like tabulators were ancient history.

We did have a test scoring machine that was semi-standalone when I was in high school but I think it had a microprocessor in it. You could program it with an answer key and then it would mark the Scantron (fill-in-the-bubble) forms based on the answer key. It had an RS-232 interface that it would output data from as well and I spent some time writing software to capture test results on an Apple II.

I agree that the comment that sparked this was talking about special purpose machines (tabulators, etc.) vs computers. I suspect that he went googling for computer history, though, and found the rather specialized definition of "general purpose computer" that the mainframe people created.

For those of us with a computer science, rather than an IT background, general purpose computer means Turing complete. And while doing scientific computing on a BCD machine may be like going to LeMans with your turnip truck, it's still doable and in an era when computers were rare for the average person, many would have been interested in doing it.

You're off by at least a decade, maybe two.

IBM mainframes were never really used that much in scientific applications. They cost too much. That's why minicomputers were so popular. Big business used IBM mainframes starting from the early 50's. COBOL (COmmon Business-Oriented Language) was introduced in '59.

Computing follows the money. The money was initially in the military market, then the business market.

The space age rocked.

The Apollo program and the military (Minuteman missile) pushed integrated circuit technology. Remember that 1969 was the culmination of Apollo, not the start. PARC was founded in 1970, the Alto started in 1972 and they had a working system by '76.

There were a lot of things pushing computing in the 60's and 70's. The space program was a big part but business was using computers as well. The national laboratories were pushing for faster and faster computers. The Cray I supercomputer was available in '76.

I read through half the comments here before twigging to what's really going on. He's got all of $700 for this project. And we're paying attention to this because???

Part of the long build time may simply be to keep the shipyard in business over a longer term. After all, it's not like you can pop out a ship and send everyone home for a couple of years while waiting for the next contract. Building to the pace of the contract acquisition lets you keep your skilled workers on the job.

Postgres seems to do it OK.

The daemon should stop and start itself safely. The shell script is just there to tell it to do so.

But you have to support multiple init systems anyway unless you're going to make your package dependent on the latest distro release.

We have stuff that runs on RHEL, Debian and Ubuntu. We can't ditch RHEL 6 , Debian Wheezy or Ubuntu Trusty Tahr support for quite a few years.

There are no Republican DA's, Secretaries of State, etc. looking for in-person voter fraud? Give it up, doesn't happen.

It used to be that conservatives were opposed to identity cards and they were right. They do not solve problems they simply allow for control of the populace.

The sandbox is a stupid idea.

The reason given for it is to prevent exploitable code. This makes sense on a system that is running in multi-user mode where a non-admin user is trying to escalate to admin and will try any exploits available to do so. This doesn't make sense on a single-user system where the user is running the apps and any exploit that is being targeted would be automated. It doesn't make sense to automate exploits for apps that have a small user base so sandboxing is silly for the majority of App Store apps. It tries to close a door that no one would exploit. It makes sense to sandbox apps like Safari (the web browser) or iTunes or TextEdit or any of the other apps that are installed on every system.

What sandboxing is really for is to allow Apple to sell software and vouch for it without doing any work in terms of vetting either the vendors or the code. To date this has been successful because no one has really tried to break out of the sandbox. However, given the number of exploits that tend to exist in any code base, the odds that there is an exploit somewhere in the sandbox system is pretty high. Sooner or later someone will distribute malware via the App Store and the sandbox is going to be shown to simply be crap.

It is? Give examples. In-person voter fraud is almost non-existent. Ballot box stuffing, payola and other forms of voter fraud are not affected by requiring ID.