Ah ha...I see you aren't familiar with SAP then. Their IT based cash cow pulls in $20 billion a year.

MariaDB is taking the MySQL code via the GPL and then building on top of it with new code. Those changes are all having their copyright assigned to MariaDB, and in some cases the GPL will also require a public release. Eventually MariaDB is expected to have a non-trivial set of improvements, and the copyright ownership of all the new code will be to MariaDB. That allows selling the combination of GPL core plus some explicitly owned private code, the exact same way MySQL was sold to Sun.

This is the same scam that let Monty cash out once already, using the work of open source contributors who assigned their copyright to his original company. No reason he can't do it again, if people are gullible enough to fall for it twice.

Concerns about MariaDB's long-term plans are appropriate too. Monty has setup his new company with contributor copyright assignment such that he can sell it off again, the same way he did with MySQL. If you actually taste the FUD here, you should be migrating away from both of these uncertain projects, not deciding which of them to use.

If you're developing kernel components, having a kernel that crashes cleanly can make development much easier. Being able to shut down your buggy kernel level program and then try again sure beats rebooting after a panic. Even though this isn't directly helpful to users of the system, making the test side of development easier can lead to the program evolving more quickly over time. The Hurd design has been filled with taking the side of various trade-offs that take longer, but are believed to be more powerful in the end.

It takes a while when you have to fetch web pages from other sites by sending mail to a program that fetches them, much like wget, and then mails them back so you can then look at them using a local web browser. (Seriously!)

And Google+ is second to no one when it comes to counting incidental users as active ones! I have an "active" Google+ account attached to my work e-mail address now, because someone I do work with invited me to a Hangout once. People can't stay on the edge of Google's infrastructure for very long now before being likely to have a + account.

Still a better love story than Twi...actually, that's almost the same story.

Edison's electrified furniture was so good, it could handle an elephant!

Your incoming mail can easily be unencrypted for some number of hops between the sender and your ISP. There aren't that many SMTP systems that support transport encryption still. And I would wager the odds someone sending this sort of message is sending is originating via an unencrypted channel is even lower than average.

Rolling Stone's Matt Taibbi recently apologized to conspiracy theorists after realizing they were right all along about the financial side of things.

The VIC-20 was named for its VIC display chip. It uses character definitions instead of bits, which means code for it is unique to running on VIC-based systems. There's a completely different video chip in the C64, they're not at all alike.

The VIC20 doesn't have a bitmapped display mode. To show graphics you have to redefine the character set. The usual solution to that limitation was to throw RAM at the problem of holding the character definitions. I suspect it will be a lot more complicated than the C64 for the sort of code you're running.

Line drawing can have a lot of complexity to it beyond just picking the best of the usual approaches. A simple implemtnation of Bresenham's line algorithm may or may not be optimal given the system's other constraints. One common change is to recognize that horizontal and vertical lines are both common enough that they should get their own optimized code paths. If it's possible the code might run on a grey scale display one day, you might code in a way that later allows anti-aliasing. On a computer like the Apple ][, the odd mapping of video memory to the display can favor lookup table driven approaches. And on systems where the code has to run at a consistent speed on each loop to maintain vertical sync like the Atari 2600, you'll have to carefully modify the Bresenham approach, since the d>0 path has more computations than the other side. Those are just a few of the possibilities I remember from my 6502 coding days.

Of course it did. If it was possible to compress the program usefully and distribute a smaller version, he would have done that too!

So same as it is now?

Your comments about exact calculations in this context strike me as kind of funny. The whole reason BLAST exists is because it replaces an expensive search for an optimal match with a heuristic method. It is at its core cheating to optimize a process that wasn't running fast enough. And if you take a look at how the original Smith–Waterman algorithm has been sped up, you'll see that clever ways to cut the code down so it will run on specialized hardware are exactly what people in the industry do. There are a lot of problems in the medical space that the classic demo scene skills wouldn't apply to, but improving BLAST is exactly the sort of thing I would hire one of those guys to do.