5 ms·

Decision to drop ext support from ChromeOS Files.app reversed due to outcry

114 points by soundsop 12y ago

morsch 12y ago
What's the native filesystem on a ChromeOS device? FAT32? That can't be right.
- onli 12y ago
  They dropped support only for external devices. See https://news.ycombinator.com/item?id=8444603 https://news.ycombinator.com/item?id=8444603. Don't know what they use for their own filesystem though, I thought it was just ext4, but didn't find that anywhere.
  - tankenmate 12y ago
    They need a filesystem that can support the notion of users; very little of the software on ChromeOS runs as root for security reasons. FAT doesn't support the notion of file permissions on a user basis; so it would be insecure. ext4 is the most widely used and tested Linux filesystem at the moment. Therefor the least effort filesystem to use for your root filesystem is ext4. On external devices however you'd probably want to "squash" the users (all files are effectively treated as owned by the one user; the user/person who inserted the external device) and also mount with noexec and nodev; don't allow the kernel to run any programs on external devices (avoid malware, hacks etc), and don't allow device files to be used on external devices (you don't want someone to put a crwxrwxrwx copy of /dev/kmem on an external device and allow someone to access it; then an unprivileged user can read all of kernel memory).
  - icebraining 12y ago
    From what I could understand, their rootfs (a readonly partition with the OS) uses ext2 and the user data partitions use ext4. But I'm not sure about this.
- jrockway 12y ago
  On a recent build of ChromiumOS, / is ext2 and /usr/local is ext4.
andymoe 12y ago
This is actually too bad. These kind of decisions, compounded, is why Googles stuff is arguably so much less usable for the average Joe/Jane than Apple and why their ecosystem is such a mess for developers to work with. They don't have the will be ruthless and cut features at the expense of geeks like me in order to make the system more usable for the average consumer.
- vertex-four 12y ago
  In this particular case, there really isn't anything that dropping this makes more usable. It's pretty much solely an internal thing.
- Guillaume86 12y ago
  Sorry if it's not very constructive but If you want Apple you should buy Apple. I have an Android phone because I like to be able to build small programs when I want without cost and when they removed SD Card write access it broke some usages I had. If it continues on this way I might as well buy an iPhone the next time. I know it's a very specific case but in this case, some more common usages were broke as well (put the sd card from your camera in your tablet to organize/clean the pics, not possible anymore)
- tankenmate 12y ago
  ChromeOS uses ext4 for it's root filesystem; so it would still affect the Downloads directory (it needs the isolation of user permissions for its sandbox w.r.t. the root user). In other words they will still need to make a workaround. They might as well do the right thing and support it properly; and it can be supported and still be easy to use, it just requires more work on Google's part.
- jiggy2011 12y ago
  How does dropping ext4 support make it more usable?
  - andymoe 12y ago
    The whole let the user rename their media card name thing in the referenced ticket..?
higherpurpose 12y ago
Wasn't the outcry mainly because of a misunderstanding - thinking Google is dropping support for ext4 for internal storage, when in fact it was dropping for external storage? (microSD, etc)?
- jrockway 12y ago
  No. I don't think anyone cares what the internal storage uses; that's just an implementation detail. People want to connect random drives to their ChromeOS machine and have them Just Work, which is quite reasonable. At least on my main Linux box, the VFAT driver and USB3 driver collude to corrupt everything I store as FAT, so I've been using ext3 for my flash drives. Actually I gave up on flash drives and just use Google Drive, but that is neither here nor there.
- ithinkso 12y ago
  No actually, most people stated that theirs external storages - sd cards, usb, disk are all ext4.
- agumonkey 12y ago
  I don't think so, even for external devices it seems a big regression.
Fastidious 12y ago
Slightly on topic. I thought OS X was the only OS the named their applications Something.app. ChromeOS does it too?
- pjmlp 12y ago
  Something.app comes from NeXTStep actually.
  - Fastidious 12y ago
    Succeeded by OS X.
    - djtriptych 12y ago
      s/Succeeded/Consumed/
      - malkia 12y ago
        you forgot the g s/Succeeded/Consumed/g
antman 12y ago
"Thanks for all of your feedback on this bug. We’ve heard you loud and clear." Kudos to Google for hearing loud and clear the 127 people in that thread and potentially helped the numerous chromeOS community! And here [1] are the cries of few thousands of souls that lost full access to their android sdcard. Hope you also hear their feedback louder and clearer! On the upside we learned how "Bring it back" is written in multiple languages. [1] https://code.google.com/p/android/issues/detail?id=67570 https://code.google.com/p/android/issues/detail?id=67570
- Guillaume86 12y ago
  This issue was the "original": https://code.google.com/p/android/issues/detail?id=65974 https://code.google.com/p/android/issues/detail?id=65974 But is closed, I wonder how many of these there is... Don't forget to star these issues.
- fpgeek 12y ago
  While frustrating, the SD card situation is very different. With SD cards, the "old way" had serious problems (security and robustness issues because apps could stomp on each other's data, all sorts of complexity and confusion on multi-user devices, orphaning private app data on the SD card when apps are uninstalled, no sensible backup possibilities for apps that depend on SD card data, apps not knowing whether data would be on internal or external storage because "/sdcard" means different things on different devices, etc.) that Google is trying to solve. Google's solution required a compatibility break, but that doesn't mean they're just dropping all of the SD card use cases. KitKat introduced app-specific private data on external storage, apps can enable some simple sharing by the adding read permissions to their private data, the storage access framework can be used to support more complex structured sharing between and so on. Among other things, Google is even adding a new API in Android L that lets apps properly publish media (images, audio, video, etc.) from their private storage (including private SD card storage, which is when it is most useful) to the shared MediaStore. Is this transition bumpy? Absolutely, especially for people who upgrade their OS or use an old SD card on a new device. Nevertheless, I don't think Google will go back no matter how loud the cries get. Google tried neglecting SD cards from Honeycomb through Jelly Bean (hoping they'd "wither away", I suspect). That failed. Now they have no choice but to do the hard work of putting external storage on a reasonable foundation.
krakensden 12y ago
It's really heartening to see a response from a user experience team to "you broke my workflow" that isn't "get fucked". I'd basically found forgotten that was a possibility.
Jedd 12y ago
"Thanks for all of your feedback on this bug. We’ve heard you loud and clear." In stark contrast to the same style of comments provided by the chrome/chromium developers regarding two bugs / features identified on the GNU/Linux releases of same: a) snap-back (move the scrollbar up or down, and then move your mouse more than 50px from the scrollbar, and it instantly flips the position back to where you started dragging -- a very MS-Windows experience), and b) clicking in the URL / address bar automatically selects the entire address bar -- again, a very MS-Windows experience. Both these features were added in chrome/chromium about 11 months back, were met with something between disdain and disgust, and though the developers said they heard the complaints loud and clear, discounted these concerns, as MS-Windows users preferred this MS-Windows-centric approach. Bless. (Yes, I'm still grumpy about all of the above.)
- jessaustin 12y ago
  It has been years since I used Windows more than once a month, but a) seems like a convenient feature, while I'm pretty ambivalent about b).
sklogic 12y ago
Lack of NFS support in chromeos kernels is also extremely annoying.
- juanbyrge 12y ago
  Lol, nobody uses NFS except lunix tools.
  - sklogic 12y ago
    The problem is, if you install chrubuntu, you have to share the same kernel with chromeos. Why did not they build an NFS module?
muyuu 12y ago
This thread got big in r/linux http://www.reddit.com/r/linux/comments/2iyplo/chromeos_will_no_longer_support_ext234_on/ http://www.reddit.com/r/linux/comments/2iyplo/chromeos_will_...
lnanek2 12y ago
Google has been working hard to break compatibility in a lot of places, like XMPP and calendars. They just don't care about interop and want to lock people in. Pretty sad coming from a company that made fun of Microsoft on stage at Google IO for breaking interop. It is sort of like a person who litters and creates an obnoxious environment to live in complaining the other people gets to litter more than them.
juanbyrge 12y ago
I bet with these types of fiascos, Google will be less likely to publish the source code of their projects in the future. When an uproar like this happens, it's impossible to engage in a technical discussion and find compromise. Sometimes fewer features make a better product.
- jrockway 12y ago
  Flamewars are nothing new on the chromium.org issue tracker. Pretty much every bug looks like this one. Ultimately, the transparency and ability to accept external contributors outweighs the effort required to mitigate the flamewar. It is nice to hear directly from users; something engineers thought was unimportant turns out to be a little more important than they thought. That's useful information.

114 points by soundsop 12y ago

morsch 12y ago

What's the native filesystem on a ChromeOS device? FAT32? That can't be right.

onli 12y ago
They dropped support only for external devices. See https://news.ycombinator.com/item?id=8444603 https://news.ycombinator.com/item?id=8444603. Don't know what they use for their own filesystem though, I thought it was just ext4, but didn't find that anywhere.
- tankenmate 12y ago
  They need a filesystem that can support the notion of users; very little of the software on ChromeOS runs as root for security reasons. FAT doesn't support the notion of file permissions on a user basis; so it would be insecure. ext4 is the most widely used and tested Linux filesystem at the moment. Therefor the least effort filesystem to use for your root filesystem is ext4. On external devices however you'd probably want to "squash" the users (all files are effectively treated as owned by the one user; the user/person who inserted the external device) and also mount with noexec and nodev; don't allow the kernel to run any programs on external devices (avoid malware, hacks etc), and don't allow device files to be used on external devices (you don't want someone to put a crwxrwxrwx copy of /dev/kmem on an external device and allow someone to access it; then an unprivileged user can read all of kernel memory).
- icebraining 12y ago
  From what I could understand, their rootfs (a readonly partition with the OS) uses ext2 and the user data partitions use ext4. But I'm not sure about this.
jrockway 12y ago
On a recent build of ChromiumOS, / is ext2 and /usr/local is ext4.

andymoe 12y ago

This is actually too bad. These kind of decisions, compounded, is why Googles stuff is arguably so much less usable for the average Joe/Jane than Apple and why their ecosystem is such a mess for developers to work with. They don't have the will be ruthless and cut features at the expense of geeks like me in order to make the system more usable for the average consumer.

vertex-four 12y ago
In this particular case, there really isn't anything that dropping this makes more usable. It's pretty much solely an internal thing.
Guillaume86 12y ago
Sorry if it's not very constructive but If you want Apple you should buy Apple. I have an Android phone because I like to be able to build small programs when I want without cost and when they removed SD Card write access it broke some usages I had. If it continues on this way I might as well buy an iPhone the next time. I know it's a very specific case but in this case, some more common usages were broke as well (put the sd card from your camera in your tablet to organize/clean the pics, not possible anymore)
tankenmate 12y ago
ChromeOS uses ext4 for it's root filesystem; so it would still affect the Downloads directory (it needs the isolation of user permissions for its sandbox w.r.t. the root user). In other words they will still need to make a workaround. They might as well do the right thing and support it properly; and it can be supported and still be easy to use, it just requires more work on Google's part.
jiggy2011 12y ago
How does dropping ext4 support make it more usable?
- andymoe 12y ago
  The whole let the user rename their media card name thing in the referenced ticket..?

higherpurpose 12y ago

Wasn't the outcry mainly because of a misunderstanding - thinking Google is dropping support for ext4 for internal storage, when in fact it was dropping for external storage? (microSD, etc)?

jrockway 12y ago
No. I don't think anyone cares what the internal storage uses; that's just an implementation detail. People want to connect random drives to their ChromeOS machine and have them Just Work, which is quite reasonable. At least on my main Linux box, the VFAT driver and USB3 driver collude to corrupt everything I store as FAT, so I've been using ext3 for my flash drives. Actually I gave up on flash drives and just use Google Drive, but that is neither here nor there.
ithinkso 12y ago
No actually, most people stated that theirs external storages - sd cards, usb, disk are all ext4.
agumonkey 12y ago
I don't think so, even for external devices it seems a big regression.

Fastidious 12y ago

Slightly on topic. I thought OS X was the only OS the named their applications Something.app. ChromeOS does it too?

pjmlp 12y ago
Something.app comes from NeXTStep actually.
- Fastidious 12y ago
  Succeeded by OS X.
  - djtriptych 12y ago
    s/Succeeded/Consumed/
    - malkia 12y ago
      you forgot the g s/Succeeded/Consumed/g

antman 12y ago

"Thanks for all of your feedback on this bug. We’ve heard you loud and clear." Kudos to Google for hearing loud and clear the 127 people in that thread and potentially helped the numerous chromeOS community! And here [1] are the cries of few thousands of souls that lost full access to their android sdcard. Hope you also hear their feedback louder and clearer! On the upside we learned how "Bring it back" is written in multiple languages. [1] https://code.google.com/p/android/issues/detail?id=67570 https://code.google.com/p/android/issues/detail?id=67570

Guillaume86 12y ago
This issue was the "original": https://code.google.com/p/android/issues/detail?id=65974 https://code.google.com/p/android/issues/detail?id=65974 But is closed, I wonder how many of these there is... Don't forget to star these issues.
fpgeek 12y ago
While frustrating, the SD card situation is very different. With SD cards, the "old way" had serious problems (security and robustness issues because apps could stomp on each other's data, all sorts of complexity and confusion on multi-user devices, orphaning private app data on the SD card when apps are uninstalled, no sensible backup possibilities for apps that depend on SD card data, apps not knowing whether data would be on internal or external storage because "/sdcard" means different things on different devices, etc.) that Google is trying to solve. Google's solution required a compatibility break, but that doesn't mean they're just dropping all of the SD card use cases. KitKat introduced app-specific private data on external storage, apps can enable some simple sharing by the adding read permissions to their private data, the storage access framework can be used to support more complex structured sharing between and so on. Among other things, Google is even adding a new API in Android L that lets apps properly publish media (images, audio, video, etc.) from their private storage (including private SD card storage, which is when it is most useful) to the shared MediaStore. Is this transition bumpy? Absolutely, especially for people who upgrade their OS or use an old SD card on a new device. Nevertheless, I don't think Google will go back no matter how loud the cries get. Google tried neglecting SD cards from Honeycomb through Jelly Bean (hoping they'd "wither away", I suspect). That failed. Now they have no choice but to do the hard work of putting external storage on a reasonable foundation.

krakensden 12y ago

It's really heartening to see a response from a user experience team to "you broke my workflow" that isn't "get fucked". I'd basically found forgotten that was a possibility.

Jedd 12y ago

"Thanks for all of your feedback on this bug. We’ve heard you loud and clear." In stark contrast to the same style of comments provided by the chrome/chromium developers regarding two bugs / features identified on the GNU/Linux releases of same: a) snap-back (move the scrollbar up or down, and then move your mouse more than 50px from the scrollbar, and it instantly flips the position back to where you started dragging -- a very MS-Windows experience), and b) clicking in the URL / address bar automatically selects the entire address bar -- again, a very MS-Windows experience. Both these features were added in chrome/chromium about 11 months back, were met with something between disdain and disgust, and though the developers said they heard the complaints loud and clear, discounted these concerns, as MS-Windows users preferred this MS-Windows-centric approach. Bless. (Yes, I'm still grumpy about all of the above.)

jessaustin 12y ago
It has been years since I used Windows more than once a month, but a) seems like a convenient feature, while I'm pretty ambivalent about b).

sklogic 12y ago

Lack of NFS support in chromeos kernels is also extremely annoying.

juanbyrge 12y ago
Lol, nobody uses NFS except lunix tools.
- sklogic 12y ago
  The problem is, if you install chrubuntu, you have to share the same kernel with chromeos. Why did not they build an NFS module?

muyuu 12y ago

This thread got big in r/linux http://www.reddit.com/r/linux/comments/2iyplo/chromeos_will_no_longer_support_ext234_on/ http://www.reddit.com/r/linux/comments/2iyplo/chromeos_will_...

lnanek2 12y ago

Google has been working hard to break compatibility in a lot of places, like XMPP and calendars. They just don't care about interop and want to lock people in. Pretty sad coming from a company that made fun of Microsoft on stage at Google IO for breaking interop. It is sort of like a person who litters and creates an obnoxious environment to live in complaining the other people gets to litter more than them.

juanbyrge 12y ago

I bet with these types of fiascos, Google will be less likely to publish the source code of their projects in the future. When an uproar like this happens, it's impossible to engage in a technical discussion and find compromise. Sometimes fewer features make a better product.

jrockway 12y ago
Flamewars are nothing new on the chromium.org issue tracker. Pretty much every bug looks like this one. Ultimately, the transparency and ability to accept external contributors outweighs the effort required to mitigate the flamewar. It is nice to hear directly from users; something engineers thought was unimportant turns out to be a little more important than they thought. That's useful information.