Right. That's what happened to newspapers. Newspaper production used to require a huge labor force. Look at all those people. 67 linotypes! A room full of proofreaders to catch typesetting errors. Hundreds of people moving paper around, making printing plates, loading them onto presses, running the presses, handling the printed newspapers. Compared to the army needed to print the papers, the reporting staff was tiny, a small expense. The reporting and editing staff, the composing room, and the printing plant were all in the same building. Any separation would slow things down, and the competition would "scoop" them.

Now compare a modern large newspaper plant. There are people around, but not many. There's essentially no direct labor. All paper and plate handling is mechanized. The files to be printed are created elsewhere and come in over a data connection. The printed newspapers leave in big trucks. Many different papers are printed in the same plant. The plant is far from the reporting and editorial staff, and is run by a separate corporation from the "newspaper".

So, to newspaper management, reporters are now the big labor cost, the first thing to cut.

The intent of the new syntax is that &char[n] buf means passing a reference to an array of size n. char[n] is an array type, something C currently lacks. Syntax like this is needed so that you can have casts to array types.

I've had a few go-rounds at this syntax problem. See "Strict pointers for C". Unfortunately, there's no solution that's backwards-compatible with existing code. However, mixing files of old-style and new-style code is possible, and mechanical conversion of old-style code to new-style code looks possible.

It's worth looking at this again now that C's market share is back above that of C++.

You do realize most of us would still have the PC for gaming and surfing and coding and whatever else we do right? So the only extra cost I had was the HDMI cable. It's one device less so less cable clutter, it's less shelf waste - I have a collection of discs and they're all collcting dust. And I can put it on my laptop or iphone or ipad, I can easily have a backup, browsing a folder is easier than searching through discs. I'm not going to make a mountain out of a mole hill but in an ideal world I'd still pick having my movie collection on a PC.

What porn? I have over 10,000 edits on Wikipedia and don't recall seeing any porn. Wikipedia has bios of porn stars and links to their work, but they rarely host actual porn content. It has to be both notable and freely licensed to get into Wikipedia. Commercial porn doesn't qualify.

Is the problem here some religious group with a modesty fetish, or what?

If you want porn, search videos with Google or Bing and you'll find whatever you're looking for.

It wasn't exactly atheist movements being persecuted, various minority/fringe religious groups were persecuted and fled to a country where they could make their own little wacky religious community. They weren't trying to get away from religion, just the dominant one in the country they left. Not sure why you'd think otherwise, the Bible Belt is far more religious than any area I know of in Europe. Oh maybe not in the Christianity statistics, but in the number of people that truly are deeply religious. Here in Norway almost 80% are technically in the state church and get counted as Christian, but only about 2% visit church weekly and 12% for Christmas. To most people church is a place for ceremonies like baptism, confirmation, marriage, funeral and the occasional memorial service with a dash of religion.

Google Shopping isn't even in their main toolbar. It's now hidden under "more".

The article is stupid. But the language and OS problem is real.

First, we ought to have secure operating system kernels by now. Several were developed and passed the higher NSA certifications in the 1980s and 1990s. Kernels don't need to be that big. QNX has a tiny microkernel (about 70KB) and can run a reasonable desktop or server environment. (The marketing and politics of QNX have been totally botched, but that's a different problem.) Microkernels have a bad rep because CMU's Mach sucked so badly, but that was because they tried to turn BSD into a microkernel.

If we used microkernels and message passing more, we'd have less trouble with security problems. The way to build secure systems is to have small secure parts which are rigorously verified, and large untrusted parts which can't get at security-critical objects. This has been known for decades. Instead, we have bloated kernels for both Linux and Windows, and bloated browsers on top of them.

On the language front, down at the bottom, there's usually C. Which sucks. The fundamental problems with C are 1) "array = pointer", and 2) tracking "who owns what". I've discussed this before. C++ doesn't help; it just tries to wallpaper over the mess at the C level with what are essentially macros.

This is almost fixable for C. I've written about this, but I don't want to spend my life on language politics. The key idea is to be able to talk about the size of an array within the language. The definition of "read" should look like int read(int fd, &char[n] buf; size_t n); instead of the current C form int read(int fd, char* buf, size_t n); The problem with the second form, which the standard UNIX/Linux "read" call, is that you're lying to the language. You're not passing a pointer to a char. You're passing an array of known size. But C won't let you say that. This is the cause of most buffer overflows.

(It's not even necessary to change the machine code for calling sequences to do this. I'm not proposing array descriptors, just syntax so that you can talk about array size to the compiler, which can then do checking if desired. The real trick here is to be able to translate old-style C into "safe C" automatically, which might be possible.)

As for "who owns what", that's a language problem too. The usual solution is garbage collection, but down at the bottom, garbage collection may not be an option. Another approach is permissions for references. A basic set of permissions is "read", "write", "keep", and "delete". Assume that everything has "read" for now. "write" corresponds to the lack of "const". "delete" on a function parameter means the function called has the right to delete the object. That's seldom needed, and if it's not present, the caller can be sure the object will still be around when the function returns. "Keep" is more subtle. "Keep" means that the callee is allowed to keep a reference to a passed object after returning. The object now has multiple owners, and "who owns what" issues come up. If you're using reference counts, only "keep" objects need them. Objects passed without "keep" don't need reference count updates.

Do those few things, and most low-level crashes go away.

I won't live to see it.

True, but those systematic flaws to would be there every year. So unless there's some reason to believe people would lie more today than they did before then that the poll hasn't changed since 1982 probably means people's real opinions haven't changed either. That is to say, 30 years of science and evidence detailing the evolutionary process means absolutely nothing to them. Extrapolation is of course always dubious but I suspect that holds true both forwards and backwards in time, that is nothing we've done have changed their minds and nothing will.

So it was like winning in "special" olympics.