2009/07/24
TheRegister: Storage start-ups fail to set the world on fire
by Chris Mellor
Try this point of view on for size: there is no general large scale file storage problem. Companies set up to deal with that problem have failed to set the world on fire and over-invested ones, like ONSTor and Copan, are facing difficulties.
Meanwhile, block storage SAN re-invention companies, such as 3PAR and Compellent have done better, showing up the lack of customer need for a panacea for the problem of having too many files and too many large files. The panacea isn't needed because the general problem doesn't exist.
It was not supposed to be like this. Several years ago, engineers, marketeers and entrepreneurs could see a file storage problem looming. The media industry's move from analogue to digital storage was going to create millions, or even billions, of image files, music files and movie files. E-mail use was spreading like a pandemic with overflowing mail boxes, and millions of attachments, many duplicated. Collaborative software like Lotus Domino and SharePoint was causing millions more files to be created.
There was a general and continual rise in the use of unstructured information that needed to be kept, just in case it was needed. It was persistent or reference information and it was held in filer silos, hundreds of them sometimes, located across enterprises, with no co-ordination and no consistent way to search for content. The compliance and eDiscovery dynamics were, and are, often used to strengthen the supposed customer need for these products.
Storage was split into direct-attached storage (DAS) for blocks and files, networked-attached storage (NAS) for files, and storage area networks (SANs) for blocks. SANs were beginning to virtualise the physical storage but there was nothing like that for file storage, NAS being far less consolidated than SANs.
The entrepreneurs, developers and engineers looked at this and saw OPPORTUNITY written large. They started up projects inside storage companies, and even started up new storage companies, to create the next killer storage product. The one that would kick the file storage problem into touch.
Their responses to the problem were different, but hindsight says they all made the mistake of assuming that the problem was larger than it actually turned out to be.
InfoWorld: Twitter hack illustrates danger of chained exploits
by Roger Grimes
Even the most securely coded piece of software can be susceptible to malicious hacking and significant exploits the moment it's linked with less-secure applications or platforms. These multiproduct, multirole exploits (also known as "chained exploits") are among the most difficult security issues to prevent. In fact, though issues may be known, they can be just as challenging to avert.
Two recent security events – one involving net/tun and a Linux compiler and the second involving Gmail, Hotmail, and Twitter – illustrate the challenges that chained exploits create. As I wrote last week in regard to the forthcoming Google Chrome OS, most - if not all - software must interact with other products and features if it's going to deliver the functionality that users demand. The trade-off can be weakened security.
The Linux kernel vulnerability emerged in the open source net/tun program. In this case, the bug was not written in to the net/tun program. Rather, when the program's source code is run through a Linux compiler for optimization, the complier introduces a kernel exploit. In particular, the compiler finds what it thinks is an unnecessary NULL value and removes an important IF-THEN statement. The subsequent exploits work even against improved security versions of Linux, such as SeLinux (see a video of a representative exploit).
The second example of a chained exploit is even more intriguing. In this case, a malicious hacker broke in to one or more Twitter employees' e-mail accounts, then publicly posted both personal and company confidential information.
The hacker accomplished this feat after discovering that a Twitter employee used Gmail and that a request for a new password for the account would be sent to the employee's Hotmail account. However, the employee had not used the Hotmail account in a very long time, so their Hotmail address was available for anyone to adopt.
CNet: Commercial open source's awkward teen years
by Matt Asay
At this week's Oscon conference, someone asked me what the secret to commercializing open-source software is, as if a secret cabal has been jealously guarding some arcane knowledge.
My response? "There is no secret: we simply don't know how to do it very well yet."
One thing, however, is clear: while the Web promises a brave new world of technical and financial prosperity, getting there from here is still very much in doubt. If we think of companies like Google as Software 2.0 and old-school vendors like IBM as Software 1.0, this leaves open-source vendors like Pentaho, MySQL, Zenoss, SugarCRM, etc. as very much Software 1.5 companies.
Or as tech journalist Glyn Moody suggests, we are in a "transitional phase, neither fish nor fowl."
I couldn't agree more.
To borrow Moody's nomenclature, much of the friction between free-software purists and open-source pragmatists stems from the malaise inherent in such an in-between state. The free-software advocates want out of the 1.0 world as soon as possible, but the vast majority of customers aren't ready to dive into Software 2.0, which leaves vendors uneasily borrowing from 1.0 business models while stretching toward 2.0 Web-based delivery mechanisms.
It's an ugly compromise at times, but it's unclear how to navigate it more cleanly than the industry already is.
Those of us working for Software 1.5 companies earnestly wish the future were already here. But after years of trying to abandon any remnants of proprietary software, it has become clear to many of us that the market-while ready to adopt open source on a grand scale-has yet to figure out how to pay for it.
I'd love nothing more than to give 100 percent of my software away for free and then charge for the service of maintaining it over the Web, or selling ads alongside content, or whatever. But the cold reality is that few enterprises actually want this, as measured by dollars they're spending. Not yet, anyway.
We are an industry in transition. Our business models have yet to catch up our delivery models. Until they do, expect a fair amount of conflict between a company's best intentions and the exigency-driven compromise.
