If it makes you feel any better, unless you watched a completely different video than I did (something other the what has been in the news recently), you didn't see a beheading. Did you see the blood spurt/drain out as the carotid/jugular were severed? Did you see the disarticulation of the spine? Those weren't in any version of the video I saw. It moves from a guy making a sawing motion with a knife in front of a guy throat, to a picture of the disembodied head sitting atop the body.

That's not to say that the guy is any less dead, or that it was any less horrific. But there was a lot of somewhat creative editing going on in that video. Shadows seem to shift at different points relative to the background, indicating that some of the later parts may have been recorded an hour or two after the earlier parts. There is some analysis that seems to indicate the "terrorist" may have been two different people at different points in the video. There are a lot of cuts, and quite a bit you don't see.

I'm not saying the video is a complete fake. The guy obviously suffered a horrific death, and the perpetrators need the full weight of the western worlds power brought down upon them. But don't beat yourself up about watching a beheading -- what was shown was both sad and shocking, but it left out the actual beheading part (again, unless there is some special uncut version out there I haven't heard about).

Yaz

Actually more often I have seen the opposite: claims the new stuff is going to be faster, the compiler is not smart enough to figure out that they are the same, and thus you should use the new stuff.

There was a coworker who insisted that using C++ std::foreach for loops was faster because "the compiler knows you can't break out of it and thus can optimize the whole thing". I had two objections to this: first of all it would be a really stupid optimizing compiler that could not figure out there are no "break" statements inside the for loop. And second the C++ was still allowed to throw exceptions in both cases.

The other objection I had was that the functors were unreadable.

Yet another objection is my suspicion that the optimization would be far worse on the functors due to the enormous header files of templates they actually used and I expected the optimizer for the simple for loop to have fewer bugs in it. But I did not test this.

Is there some particular quality of an "automated driving system" that will make it signficantly more reliable than a home computer? I'm sure the auto manufacturers will try their best to avoid bugs, but then again Apple and Microsoft also try their best.

No worries -- to handle those scenarios, we'll download the app and steer the car using our phone. Bluetooth FTW!

No, of course not. However, in America, HR runs the company, so there's no way around this idiocy.

It's worked fine for me for 16 years (mine was the very first model, not the later touchscreen models), except for the big mold issue (which after a couple years they did a factory recall and sent a technician to my place to install a bunch of new, redesigned parts in the door and front area), and the water pump failed a couple years ago which I replaced myself. There haven't been any electronic issues. I have read of some people having problems with the wax motor (the thing that controls the door locking) control circuit.

... and a hacked prosthetic arm is the worst possible kind of security breach -- the hackers could literally hold your neck for ransom.

There are, but the feature doesn't work as a theft deterrent unless almost everybody has it. If only a few people have it, thieves will steal phones anyway, because the likelihood is they can resell most of the phones they steal. If/when we get to the point where almost all phones auto-brick after they are stolen, cell-phone thieves will lose their profit incentive and move on to something else.

It can be very hard to get a new programming job if you haven't been doing it for a while. It doesn't matter how competent you are or if the language hasn't changed in 20 years. Many companies outright refuse to interview someone if they've been unemployed for more than 6 months.

You want a surgeon working on you who isn't passionate about medicine, and just wants to put in his 8 hours and go home?

So how do the Europeans do it? Just look at how cheap and high-quality cellphone and ISP service are in western European countries. Government regulation seems to work pretty decently over there.

That depends on the game, which supports my thesis.

Strong AI is difficult to do, and can be the real differentiator between a great game and a cheap copycat. Likewise for a physics engine or a rendering engine.

If your game doesn't feature any form of AI, or is easily reproduced with off-the-shelf physics and/or rendering engines, then your game is probably trivial. And if it took you years to put together your trivial game when it only takes the next guy days to replicate it -- than as I've said, you did something wrong.

Yaz

Chess has evolved over time, and wasn't the product of a single development team, so it's not exactly an apples-to-oranges comparison. It took roughly 900 years of evolution for chess to take on its modern form, and there have been many variations of chess (Wikipedia claims more than 2000 published variations).

Early versions of chess weren't unplayable, in-development versions. They were proper, stand-alone games. You could think of modern chess as actually having been a "rip-off" of these earlier games. Indeed, several of the basic game mechanics were seen in earlier games that predated chess by centuries (pieces on an X-by-Y grid, for example, was used 600 years before the earliest variants of chess in Ludus latrunculorum). Indeed, if chess hadn't freely borrowed from games that came before it, it wouldn't exist today.

As such, chess evolved in exactly the way this article is railing against. Over the years, people who had nothing to do with the original "developers" of the earliest chess forked their own versions with slightly different rule-sets, and those with rule-sets that provided for an improved game were adopted by others, who then adapted those rules with their own improvements. Without these "copy-cats", we'd be sitting down to play Chaturanga right now instead of chess.

Yaz

You have a fair comment, so I should clarify somewhat. I'm assuming that whomever does the copy is not only generating their own code, but is also generating their own resources. If they're copying your resources you have the ability to go after them for copyright infringement. That's not really a new thing in game development, and there is legal recourse (and yes, I know it's a shitty thing to have to go through, as it has happened to me personally with someone who ripped off both code AND resources from an OSS game a friend of mine and I coded 8 years ago).

But the summary is talking about differing orders of magnitude here. If you've developed something that took years and someone is able to replicate your work (without stealing code or resources) in days, then yes -- I still submit you're doing something wrong.

Yaz

Personally, I've never known a team of that size to be able to ramp up development all that quickly. What that many devs, you'd probably wind up with a month of design meetings before any coding got started.

Yaz