The Long Slog Toward Advancement Of Linux

That is, if it can work.

As noted here last week, it's a bold effort and it should be lauded.

People just want software to work better, to be powerful but easy out of the gate, and to be safe and reliable. But there are technical issues with Unity needing to be fixed and that's easier said than done. On that note, Ubuntu developers have an enormous amount of work still to do before the scheduled April launch of the next version of the OS.

If you don't believe major changes to desktop operating software can take a painfully long time to happen, look around any business that's still using 10-year-old Windows XP. It's only been recently that Windows 7 has been at the center of an ecosystem mature enough to add business-building improvements to the PC.

And, as always, you can look at the open, public development of the next version of the Linux kernel to understand the conversations that take place and work that needs to happen before -- or even if -- developers can effect big changes to an operating environment.

Linux founder and chief developer Linux Torvalds, as he always is, is shepherding through the next kernel version of Linux and, in a back-and-forth that shows the granular level of detail with which he's involved, discusses (on a Linux Kernel development discussion thread) why he is hesitant to rubber stamp a proposed new interface for the OS that would alter how hardware manages crypto keys:

"I really don't like adding interfaces that don't have hard uses associated with them. We've done it in the past, and it tends to be a morass and a bad idea. That's been true even when the idea has been my own, and thus obviously genius-level and clearly the RightThing(tm), like "splice()". And it's why I push back on new interfaces when I see them.

"Btw, it doesn't have to be about performance per se. Does this allow people to use keys without actually _seeing_ those keys? Your example implies that that is not the case, but that's actually one of the few reasons to actually support a kernel crypto interface - the ability to have private personal keys around, but not having to actually let possibly untrusted programs see them.

"For example of why something like that matters, I can well see myself using some program to encrypt things. But maybe I don't trust that program enough to give it my actual private keys. In that case, kernel support is a real feature.

"But in your example, it looks like you just give it the key. Which to me means that you're totally missing one of the major reasons for having a separate protection domain.

"And that makes me think that the interface is bad."

We've reached a point where the expectations -- and the stakes -- are higher now than they've ever been. And bad interfaces, are, well, bad. It's often unpleasant to watch as someone makes the sausage, but in this case it can go a ways toward explaining how this technology is developing.