Sure, that's fine. No one's saying it isn't. It's your choice that your work doesn't overlap with your hobbies.

But for some people, they do overlap. While it might be limiting to say, "I won't hire someone who doesn't code in their spare time," it does act as a reasonable filter. I think it's safe to assume that the set of people who do code in their spare time has very few bad programmers in it. The set of people who don't code in their spare time, however, likely has a much larger proportion of bad programmers. (You could also say that the average quality in the codes-for-fun group is likely higher.)

If you have a limited amount of time and energy to deal with hiring, and your applicant pool is large enough, using a "must code for fun" filter saves you some effort by removing a large population of bad (or even just average, probably) programmers. Does that also remove some great programmers from consideration too? Almost certainly... but it's a trade off. It's a filter with a decent number of false positives, but likely very few false negatives.

It is true that we're pretty fond of paying with CCs, but I think in your case the ice cream vendor was just surprised you didn't have smaller change. Many small vendors (or anyone who sells items of very low value) will not accept bills over $50, or even $20, simply because they don't carry that much change on hand, or are afraid of getting passed counterfeit bills.

Personally I rarely carry around more than $100 in cash on a regular basis, but even if I did, I'd find carrying a $100 bill around to be a nuisance.

Even less, sometimes. As a US citizen, I once traveled from Munich to Venice by air, and there wasn't anyone at the Venice airport checking passports. I think the flight was treated as the equivalent of a US domestic flight.

It's likely not to work well for good quality stuff. It can handle DVD and ok-quality divx/xvid standard-def encodes, but the CPU in the Wii is just too slow to play any hi-def content. A 700-ish MHz PPC CPU doesn't get you very far for media playback these days.

Not sure if it's possible to make use of any graphics acceleration hardware to do decoding, but this certainly isn't implemented yet and I don't think anyone's working on it.

"It's easy to implement" isn't a criterion for patent acceptance/rejection.

Well, you can't get to most bootloaders without initializing some hardware, like, say, the disk controller (which presumably requires at least a part of the PCI bus to be initialized). Of course, if you put the bootloader (or even the entire kernel) into the BIOS itself, then it doesn't matter.

I always wondered how that works. My current Linux kernel is 3.7MB compressed... I doubt most BIOS chips have that kind of space on them.

I guess that's fine, depending on the users' needs. If "typical" edits require spending 20 minutes fiddling around with a web form before the user clicks the save button, I bet they're gonna be pretty pissed when they get a rejection message and their 20 minutes of work gets thrown away.

With this in mind, if you're going to use your optimistic locking approach, you'd need to add more code that, instead of rejecting conflicting changes outright, presents the user with options, possibly listing the conflicting changes.

Personally I'd find the auto-expiring lock option to be the best (the user will know going into it that someone else is editing), though hitting the DB to update the timestamp every 10 seconds doesn't scale to a large number of users. But there are other options, like ones some wiki software uses, where you get a longer locking period (on the order of several minutes), and you have to manually refresh the lock before it expires. Or you can possibly refresh the lock automatically, by checking to see if the user isn't idle.

Yeah, that would be ideal, but may not be practical. The article poster says they're migrating a native app to a web app, so changing the users' workflow may not be an option.

Assuming this guy has been scamming the whole time and didn't just start in the past few years (or didn't stop in the 90s and just start up again), it's pretty sad that it's taken 11 years from the original complaint to get any meaningful actions taken. Though you could argue that's 13 years, and not 11, since apparently he hasn't complied with the court order for 2 years, with no consequences until now.

Indeed, good for him. At least he can admit he was wrong (even if he was a dick about it) and adopt a new viewpoint. He may not be a "nice guy" in the traditional sense, but at least he doesn't try to hide his mistakes when he realizes he's made them.

If the creator of Linux says Linux is bloated, people tend to be interested in what he has to say.

If some random semi-anonymous guy who calls himself "Slash.Poop" says the same thing on a discussion board, he's ignored or worse.

Surprised? I'm not.

He was referring to the original poster who said, "BSD however, really only has one user base - and they largely want the same thing. Stability, security, and performance. So all the cute little desktop friendly stuff that Linux keeps adding and all the server-specific stuff that Linux keeps adding aren't there." So he (semi-jokingly) asked, if BSD doesn't have "server" or "desktop" stuff, then what does it do?

Yeah, I don't get it either. More like Offtopic is the new "I disagree with you".

True, but given a set of conditions including "value" or "complexity" of the submission, it'd be damn-near impossible to judge the final result. Your hypothetical example is easy: if the dirt-simple algo got a 10.2% improvement, whereas the algos with magnitudes greater complexity netted a 10.4% improvement, it'd be easy to say the simple algo is more "valuable." But what if the complexity differences are much smaller? How do you judge them when the improvement is also close? I think Netflix was smart by providing a numerical target and detailing specifically how the numerical results are calculated. While there's always room for people to argue a result, it's harder when the criteria are simple.

It is? I only see a bit in a question about licensing (somewhat tangential) that suggests that Netflix hopes that participants will be able to build a business out of the algorithm they design, but that sounds pretty weak, and doesn't have all that much to do with what the participants got, aside from the prize money.

The contest has been going on for three and a half years, and the winning team of seven will be splitting a cool million, which gives each person just under $145k, minus taxes. Now, I don't know how much time these guys spent on it, but even if they only worked a year's worth of regular work hours over the 3.5 years, $145k per year each for seven developers is a pretty damn good bargain from Netflix's perspective for what they got (not just the new algorithm, but a lot of good PR and buzz).

I'm not saying the BellKor guys got the shaft; they were certainly compensated (not just monetarily; I'm sure their employability went up as well), and I'm sure a big part of their desire to compete was the challenge itself. But I'd bet that Netflix would've had to pay quite a bit more.

And it's not like the BellKor team did all the work; all the other teams did some of the same work independently. I imagine many (most?) of them didn't stand a chance, but let's just throw out a conservative number and say the top 5% of teams managed to improve on Netflix's existing algorithm (even if not by 10%). It's conceivable to believe that an in-house team of paid developers/researchers would end up doing an analogous iterative process, achieving smaller gains, eventually reaching the 10% goal. Depending on Netflix's hiring skills, it's possible they wouldn't reach a 10% increase without many more man-years of work.

This contest was a very smart move on Netflix's part: their only real downside is that their -- self-imposed -- competition terms will allow the contest participants to competitively license their implementations to other companies.