I would certainly hope so. It's what the rest of the industry does for every write. Loss of data that isn't being actively modified should be almost impossible if the people writing the firmware are even halfway competent (ignoring unlucky filesystem metadata changes aborted halfway through).

True, but the question wasn't what sort of career you could choose that can't be replaced by robots. It was what sort of career you could choose that couldn't readily be replaced by a human on the other side of the planet. :-) As for call centers and order taking, I think that's already being done for drive-through lanes in some places.

Yes, you can do surface-mount soldering, but it takes a lot longer than through-hole soldering, which in turn takes a lot longer than replacing socketed components. When repairs take longer, they get more expensive. Expensive repairs + cheap hardware = cheaper to replace.

I think the concern is that this would somehow dramatically increase the probability of data loss caused by powering the drive even while it appears to be inactive. After all, it randomly rewrites flash blocks. However, in practice, this should not be an issue.

Presumably, their firmware never erases and rewrites a flash page in place. And presumably it does not write the log entry that causes the drive to look for those blocks in the new location until after the page has been fully written. Assuming they do, in fact, follow those rules, then a power interruption during a block clone should never result in loss of any data, because the data still exists in the old page, which will not be invalidated in favor of the replacement copy until that replacement copy is fully written. If they aren't doing that, then they are incompetent, and their drives should never be trusted with cat pictures, much less valuable data.

To be pedantic, TV repair shops went away because the technology became so miniaturized that nobody could realistically repair anything anyway and because the cost came down to the point that it was a disposable item. Either one of those would have made it infeasible. They just happened to go hand in hand.

Construction and burger flipping also come to mind.

Or fork the M/R line after Steinway St. I assume they share tracks in that stretch. That would give you two possible routes onto Manhattan instead of one, with a transfer at Queens Plaza for the A/C/E line and a transfer at Lexington Ave. for the 4/5/6 line. If capacity is still a problem, extend the platforms for longer trains, run more trains, or both.

It would be a pain in the backside for anybody trying to get on the 7 line, but you could always change directions at Steinway, 36th, or Queens Plaza, and then change trains at Jackson Heights. Better yet, build an underground tunnel from Queens Plaza to Queensboro Plaza and be done with it.

I think the implied problem is that its location makes it a better choice than JFK or Newark for most travelers, but if all the airlines shifted their flights there for passenger convenience, it couldn't handle the flights because there aren't enough runways and there's no room to add more. The traffic in and out of the area might be the maximum volume for the airspace, but only because the airlines are flying flights into JFK and Newark that they'd prefer to fly into LGA if it could handle it (and if it got a major upgrade).

In principle, this seems like a good idea. It would make the ATCs' jobs simpler to have to manage only two approaches instead of three, and it would have the added advantage of keeping the flights farther away from the skyscrapers for safety reasons.

With that said, they should also tie it to Newark. Ideally, it should be an express train with three stops: JFK, Grand Central, and Newark. They could possibly share the Amtrak route from Newark to Penn Station, adding a new stretch underground that turns northward right before Penn Station (so that trains don't fly through there at speeds approaching 100 MPH) and up to Grand Central), then rejoin the line. Then eliminate the largely redundant LIRR line that parallels the subway in the stretch from Hunters Point to Sutphin Blvd so that you can run at high speeds all the way from Grand Central almost all the way to the airport, and finally, share the short stretch of AirTrain track from Sutphin to JFK.

For a great example of the way JFK and Newark should work, fly into or out of Heathrow and take the Heathrow Express to London Paddington... except underground, obviously. Both airports are only about 10 miles out. A rail line running at the speed of the Heathrow Express would mean about a seven minute trip to Grand Central Station from either airport, versus up to a 45 minute cab ride from JFK to midtown. You'd basically run trains in a 30 minute loop back and forth.

Obviously you'd have to share the tracks with Amtrak, so you might have some slowdowns while their trains are running, but otherwise, it would be a really effective way to reuse some existing lines. And then you could ditch LGA entirely and turn it into... whatever.

Nope. It's a Discworld on the back of a turtle.

Like I said, the minimum requirement is to break the build, so it won't be crashing, because it won't compile. The minimum requirement in a corporate environment is breaking the build plus an explanation of what the code actually does (if it isn't immediately obvious) so that when someone tries to manually enable it on a new architecture and it doesn't work, they know how to rewrite it generically.

I mean, a lot of code is only meant for one platform type. Not writing code compatible with obsolete processors is no great sin.

Fair enough. Ideally, you should include a generic version without any hackish optimizations, but it isn't strictly required if you don't think you'll ever change CPUs in the future. Either way, if you're writing code that you know is likely to break on a different architecture because of its unique characteristics, IMO, you should at least make it fail to build on any other architecture than the ones you've tested....

Depends. Is it wrapped with #if __i386__ || __x86_64__ and followed by a #else clause that contains code without the insane optimization? If so, it is elegant. If not, it is ugly.

To recognize that a line of code is an ugly hack, someone would have to first understand it, and as we all know, only Perl can parse Perl.

C developers are good enough to know when what they're doing is an ugly hack.

If PHP developers were at the same standard, every line would end with // Ugly Hack.

I think the reason PHP is #2 on the list is that the people who are still writing PHP are mostly pretty good. The ones who were awful have all moved on to Python or Ruby or whatever the scripting language of the week is these days.

In fact, I'd be willing to bet that a sizable percentage of the folks who are still actively using PHP are C programmers. I use it for all my web programming because it is exceptionally easy for me as a long-time C programmer. I basically write C with dollar signs and a few other minor tweaks, and it works. Even better, if there's some piece of code that has to be blisteringly fast, I can port it from PHP to C faster than you can say sed 's/\$//sg'. Okay, it really isn't quite that trivial, but it is pretty close.

And yes, I do occasionally take advantage of being able to mix PHP and HTML, but not very often. I mostly just use it as a compile-free web programming language with better string handling and basic support for classes.

C Code EVERYWHERE has the most "ugly hacks"

C code is ugly hacks. But how else are you going to write an efficient ring buffer?