ChromeOS disses Linux users, drops ext2/3/4

Trying to figure out why exactly ChromeOS would make such a silly decision.

Sometimes people make decisions that are so baffling – and so far out of left field – that you are left simply... dumb struck.

Case in point: ChromeOS is dropping support for ext2, ext3 and ext4 file systems – the file systems used by the vast majority of Linux systems.

Now, I hear what you're saying. "Isn't ChromeOS... Linux? Don't they simply get full support for these file systems for free?" Yes, it is. And, yes, they do. Which begs the question... why, on Earth, would anyone think this is a good idea?

After digging through issue #315401 (titled "Drop support for ext2/3/4 from") a bit, it turns out there are two reasons given for dropping ext2/3/4 from ChromeOS.

One, as stated by one contributor, is that it is simply an unnecessary feature:

"Every feature comes with complexity. Complexity adds maintenance cost, QA cost, slows down development, and adds surface of security exploits. We should add a feature only if its benefit clearly outweighs its cost, but this particular feature was slipped in for some historical reason."

Two things made me giggle there.

  1. The notion that having support for ext3 is a possible security issue is just plain silly. Note that there isn't actually any security exploit that people are concerned about there – just the nebulous threat of possible security problems because, you know, software is involved. In other words... pointing at an invisible boogie man that nobody has reason to believe even exists. Also, if there is an exploit in these critical file systems, it would undoubtedly be fixed at an astounding speed.
  2. The idea that ext2/3/4 support was a feature that was added to ChromeOS "for some historical reason." Maybe that historical reason is that, just maybe, you got it for free. You know. 'Cuz Linux.

The second reason is that the developers wanted to add feature request #274041 ("Right click and rename USB & SD volumes in the left nav"). Basically, they want to add the ability to rename volumes in the ChromeOS files app. But they were having a hard time doing it with ext2/3/4.

Instead of doing what I like to call "some engineering" and "figuring out how to code that feature in a way that works," they took the easy road. They started taking an axe to any feature – no matter how important to large groups of users – that made their job even slightly harder.

Now, to be fair, being able to cut features is important. Good developers and managers know when to pick up a big old axe and start swinging it at features. Sometimes it simply needs to be done in order to ship. Sometimes those features truly will not be supportable or maintainable. It most certainly does need to happen on occasion.

This is, clearly, not one of those occasions.

The ChromeOS team does not maintain the code for these file systems. They get those features for free thanks to the hard work of other dev teams. And by cutting those features, they make it significantly harder for their Linux users to exchange files with ChromeOS.

Google has already removed any mention of the ext2/3/4 file systems from their ChromeOS support pages. Support for HFS+ (MacOS) and FAT (MS-DOS) are still there, however. Make of that what you will.

In short, this decision is a bad one. It makes the day-to-day life of Linux users harder and alienates an entire section of ChromeOS's most vocal advocates by saying "Google just doesn't care about Linux users."

Is that the message they wanted to send? Did that thought even cross their minds when making this decision? Probably not. But that was the message just the same. And it's a fairly powerful one coming from a company that has benefited so much from Open Source code, such as Linux.

I strongly suggest that the ChromeOS development team rethink this one. Quickly. Not only does it harm their users, but it conveys a negative public perception of Google's commitment to Linux users.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2014 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)