snom320

In VMC, yes. If you're in IMC in certain air spaces, it is the ATCs responsibility to maintain separation, not yours (because you might not have the information needed to avoid a collision, but the ATC will).

If course, you're still responsible for following instructions, but you can't necessarily blame an IMC mid-air on the pilots.

I think the Amiga was pretty revolutionary when it launched. Without any accessories, it had stereo sound output and pretty impressive color graphics. And it was affordable (esp. the 500). PCs didn't really get anywhere close in that department until the whole Multimedia PC thing happened in the early 90s.

Yep!

I like this idea. And it's the perfect present for anyone you know that are curious about getting into electronics.

I think it would be a very good idea for them to get some prominent bloggers to do a review of the first kit.

Yep. That's my personal experience as well. Looked at FogBugz several times, but the pricing always put us off. Eventually Atlassian came around and made a good enough product.

Light aircraft engines are already _very_ reliable, you'll most likely spend a career flying without ever experiencing a failure. The most popular GA motor, the Lycoming O-360, has been in production for something like 60 years, and is pretty much "debugged" as far as engines go. Still, failures do happen (most often because of user error). You can switch to turboprops, and you'll get more reliability, but higher costs. You can switch to a multi-engine plane, but again costs are higher.

An electrical motor which can provide backup assistance without causing further single points of failure is a nice add-on if they can make it work (I'd be sceptical about trusting this thing without extensive testing.)

> FogCreek should have bit the bullet and re-wrote their application in an open, standardized cross-platform system.

Ah, so you happen to know better than Joel how much resources they had available at the time, how long the rewrite would have taken, how much it would have affected their ability to ship new features?

Fog Creek was a much smaller company back when they wrote Wasabi. Postponing the rewrite until they had more resources to spare was probably a good decision.

There's nothing stopping a contributor from keeping your copyright notice, and adding his own license that only covers his own modifications. The contributor does not technically need to change the license of _your_ work, but he is free to chose whatever license he likes for his own changes to your code.

> No shit. If you want to harm the US, its not a negative action. Else, its a goddamn negative action. I'm trying really hard to figure out why else you would make that argument.

How hard have you tried? Do you honestly think nothing good can come out of this for US citizens?

Has it ever been established that the documents he leaked contained information on operatives?

Your comment is focused about how terrible the GPL is for you as a developer. But the GPL was not created to make life easy for you as a developer, it was made to increase the freedoms of the end users.

No you can't. Well, due to fair use you probably could without losing a legal battle over it, but for more substantial improvements you couldn't do that. Presumably you thought about this when choosing the BSD license (or when choosing to contribute to a BSD licensed project).

Have you analyzed this traffic to see what it is? I would expect some of it to be stuff like NTP, checks for internet connectivity and app store updates.

IMO, the main difference is that Apples gives you more choice in the matter. I can still choose to not enable iCloud, and only sync my iPhone / iPad to my computer. Also, for some data collection Apple explicitly asks you whether you want to share the data to improve its service (location data and crash report data, for instance)

Even with the context, it's pretty bad. And it's not like his other quotes on privacy paint a better picture.

No, you just missed the "2012" part of the headline. :)

Did you work specifically on the engine controllers? Have you considered speaking to the accident board about this?

I'm not sure that's their main problem. Other companies are alive and well selling similar printers to customers that know what they buy.

I think MakerBots biggest problem is that they've marketed (and with Gen5, designed) their products as being "consumer ready" when they're far from it.

With the huge brand name of MakerBot, I can't help feel that this is going to create a setback for the 3D printer market. It's just sad.

I think the important point is not that it just outweighs what can be achieved by modularisation, but that it is fundamentally more difficult to achieve using modularisation. Had that not been the case, you would expect companies that emulated the psychological value _and_ used the modularisation path to make more money than Apple would.

What do you mean when you say that you're not certain user experience is one of those things?

I don't really get what your problem is? You can disable the memory limitations if your use case requires it, or set the limits as high as you want.

How else would you suggest that OpenVZ should handle over-allocation? It is, after all, one of the points of virtualization (and the reason why you can get such containers for cheap).

You can't really blame OpenVZ if the users or sysadmins are unaware that the container has hard limits and that you're able to see if you've run into them using /proc/user_beancounters. Of course, if OpenVZ fails to allocate memory when you're under the limit, that's a separate problem that should be adressed (although I've yet to run into that one).