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.
- Three Big Questions On Apple’s Mountain Lion
- Do We Even Need A Google Drive?
- How Windows 8 Beta Could Underwhelm Us
- Three New Features For Business We Want In iPad 3
- How Meg Whitman Can Save WebOS
- 'Extra-PC Era' Describes It Better
- LibreOffice’s Bold Course for the Tablet
- Leaving Your iPhone In The Back Of A Cab
- Analysis: Ubuntu's 'Open for Business' Sign To Developers
- Firefox Memory Leaks Once Again Causing Frustrations
- Microsoft’s Windows 8 To Do List Short, But Serious
- The Door Cracks Open for the BlackBerry PlayBook
- Today’s Daily App: Maven Web Browser for iPad
- Will Ubuntu Again Benefit From Industry Turmoil?
- Samsung Takes Swipe At Google With Its Windows 7 Slate
- Intel Inside Android, via McAfee Security
- Why Michael Dell Is Right About PCs, And HP Could Be Wrong
- Why 2011 Is The Year Of Open Source
- What If They Had A Tablet Price War And Nobody Came?
- Why Google Needs to Get a Grip on Security