16 ms·

SD cards

cpks 12y ago
All I have to say is fuck Google. I would never use a Chromebook, for a hundred reasons. However, sabotaging Linux support in this way is both shortsighted, aggressive, and moronic. Our kids need to learn to use computers. Not just use Word and Internet Explorer, but learn to hack. Not just consume, but create. Computers 30 years ago were tinkerable. Google is doing everything in its power to take away that tinkerability, and worse, to undermine tinkerable systems.
bert2002 12y ago
luckily notices this before my trip... what the hell?
Dewie 12y ago
I guess that chromebook laptops are cheap (?). Chrome OS seemed appealing to me initially, because of the short start up time. But then, reasonably sized SSDs became affordable[1], and any faster boot times than what Linux + SSD can give me is kind of meh, to me. What are the advantages of ChromeOS over other operating systems? [1] And if you are considering a Chrome OS laptop, chances are that you won't be needing something like >500GB storage for it, I would presume.
deleted 12y ago
[deleted]
dingaling 12y ago
Thereby entrenching the FAT patent fee scheme. This is a very odd decision that originated in the difficulty of renaming external volumes ( why was this considerd important? ) and then became conflated with 'security'. I believe the kernel modules are still there, though, so you can mount extx from the command line in dev mode. But not much use for everyday users.
- danmaz74 12y ago
  BTW, when will those patents expire? Shouldn't be long I guess..
  - techrat 12y ago
    The issue is exFAT and Fat32 long filenames. exFAT was introduced with Windows Vista and is what 32GB+ flash media tends to be formatted in. It'll be a long time before this one expires.
    - overcertified 12y ago
      There are at least 4 patents involved, extensible file system, name hash lookup, transactional fat, contiguous file allocation. If you look at overcertified'a recent slideshare presentations on exFAT, including the recent HTCIA 2014 exFAT presentation, the patent numbers are listed on the ending reference slides.
    - caf 12y ago
      Does anyone know exactly what innovation(s) in exFAT is/are newly patented? Which patents read on it?
      - techrat 12y ago
        From wiki: >exFAT is a proprietary file system. However exFAT is protected under US patent law, and its initial application was issued on 10 July 2009 under the application number US2008168029.[7] On 12 November 2013, the patent was granted by the US patent office under US8583708. Patent length is 20 years, so we're looking at least until 2033 before exFat is expired and (safely) freely usable.
        cowsandmilk 12y ago
        > Patent length is 20 years, so we're looking at least until 2033 before exFat is expired and (safely) freely usable. Nope. For the dates this was filed, length goes from filing date. Depending on how dangerous you want to be, you could argue it expires anywhere from 2024-2028.
riffraff 12y ago
what is the root filesystem in ChromeOS?
- pjmlp 12y ago
  It is a browser based OS, so you shouldn't care. :)
- shaurz 12y ago
  ext4
higherpurpose 12y ago
Does it support F2FS then? That would be for the best.
imrehg 12y ago
Of course as per Comment #21 someone has to make project management decisions, but decisions like "Chromium OS is for consumer devices which should not need support for mounting external ext4 storage" is just so painful to read. It's just a pile of assumptions that goes against the evidence of given my a lot of comments.
- VLM 12y ago
  "is for consumer" Generally speaking whenever someone starts speaking for the "other" they're doing something wrong and they know it and the othering is just CYA speech.
lucb1e 12y ago
And thus we returned to the stone ages of unjournaled FAT(-like) filesystems or bad NTFS driver implementations (the only good one is Microsoft's, and I doubt they'll be handing over the code for Chromium). It's not even something consumers see, it's a driver for crying out loud. It doesn't even make sense to remove it for "product simplicity" as they are claiming now. Edit: Left a comment with another argument about FAT being a bitmap filesystem (versus ext4's binary trees) and that developers are the people that are going to code for their OS. Ignoring the 1% is not the smartest move. https://code.google.com/p/chromium/issues/detail?id=315401#c45 https://code.google.com/p/chromium/issues/detail?id=315401#c...
- wutbrodo 12y ago
  >It's not even something consumers see, it's a driver for crying out loud. It doesn't even make sense to remove it for "product simplicity" as they are claiming now. I may be confused, but isn't the discussion about removing support in the files app UI (while actual ext support remains in the console)? That would mean the exact opposite of what you're saying: it's a UI change, not a driver change.
nkuttler 12y ago
> On a related note, we may want to re-evaluate whether we'd like to continue supporting ext2/3/4 filesystems (~2% of users, and the majority is probably Chrome OS developers) in File.app. Yes, please, drop support for something the developers use, what could go wrong? The title seems misleading though, it seems that only the built in file manager will drop support for ext, and even then, maybe only for a specific feature?
- lucb1e 12y ago
  > it seems that only the built in file manager will drop support for ext I spend a lot of my time in a terminal each day and can easily navigate filesystems on it, but even I would prefer filemanager support. Android does the same: I can mount ext4 micro-SD cards just fine, but forget about seeing them in ES File Explorer or any other part of the Android system. Apps can't open the folder where I mounted it and "Settings" prompts to format it for me. No thank you.
  - shams93 12y ago
    Naw it blew my chroots off, couldn't even reach them from the console in dev mode. Now I'll have to try installing ubuntu directly on the thumb and then see if I can use legacy boot, which will likely work since booting off the thumb instead of running chroot should just bypass chromeos, but annoying I have to jump through hoops when everything was working great.
- logicallee 12y ago
  >~2% of users 2% seems pretty high! If you make 50-70 kinds of these project management feature-drop decisions, then if the groups are mostly distinct, you'll have dropped 100% of your users (2% * 50 or 1.42% * 70 = 100%.) Think of it this way. If only two percent of your users have a first name that isn't in the top hundred first names in America, would you drop support for first names that aren't on your whitelist, in some form field? (because you want it to contain real data.) I think it's better to think through the rationale for dropping support (for example: If the people using this feature have a clear alternative, that is also better, and that they know about and will try and like. Then it might be acceptable In the first name example, the only rationale would be if this were some kind of game or something and people weren't expected to use their actual first name, and you also present them the list. Then it might work.) The rationale presented here is very weak. "Only highly-paid people (developers) trying to get work done use this, about 2% of our sales." Marketing win?
nodata 12y ago
Because they can't relabel an extX volume? How does that make any sense?
shams93 12y ago
Yeah I was wondering why I suddenly couldn't load my crouton on external 64 gig stick, really annoying google blew off my entire android development environment.
- redthrow 12y ago
  Is there any reason why you want to keep ChromeOS at all? https://www.distroshare.com/distros/get/14/ https://www.distroshare.com/distros/get/14/
microcolonel 12y ago
ChromiumOS developers can't even implement a script to relabel EXT volumes? No wonder their kernel tree is such a mess, they must barely know what they're doing. Also, I'd say you can safely assume that those 1-2% of users that use EXT volumes externally(which by the way, is a LOT of people, several million at least) are developers, and this will surely piss them off.
- pjmlp 12y ago
  Also looking at the quality of NDK, I sometimes doubt why Google makes such hard admission interviews.
- cnvogel 12y ago
  Obviously no one can defend this decision with the labeling non-issue while keeping a straight face, so time to guess: What they are probably bitten by is the issue of ext4 actually keeping proper uid/gid associations with files. The other FS they seem to support [exFAT, FAT, UDF, NTFS] all are (as far as I know, and under Linux) completely agnostic to permissions and user-IDs: everything gets squashed to one uid/gid and fixed permissions. Probably that is the actual problem they want to get rid of and which causes pains? They only mentioned the labeling as "features such as...", so there might be more bugreports/requests... Android (at least the Cyanogenmod variety on my phone) works around it with a small fuse-shim that fixes user-visible permissions on the fly, for all FS, including ext4. And ext4 makes for a very nice and well-performing fs on my phone.
  - asveikau 12y ago
    > FS they seem to support [... NTFS] all are (as far as I know, and under Linux) completely agnostic to permissions and user-IDs Uhhh... On Windows this definitely not true. The NT security descriptiors are kind of complex and I could imagine nobody wanting to sit down and map them to a Unixy system. But they are definitely there.
    - cnvogel 12y ago
      That's why I added: ...and under Linux. I'm well aware of NTFS permissions, and use them daily, both in UI and programmatically. Under Windows, though.
xg15 12y ago
It looks like this ticket was opened a year ago, during which almost no discussion took place. People only started to voice objections after the patch was already written and submitted. I think it would be useful if tickets with breaking changes could come to the public's attention a bit earlier than this time. I have no idea how to find such tickets of course. The search function of the issue tracker doesn't seem very helpful...
- Intermernet 12y ago
  Very good point. It seems that this was tagged "Type-Feature" which is meant to mean "Request for new or improved features". I'm not sure how removing functionality is a "new or improved" feature, except from the developers POV due to reduced complexity. This is probably not how the users would define "new or improved". They possibly need a new tag for "Type-FeatureRemoval" or similar.
- zorbo 12y ago
  > I think it would be useful if tickets with breaking changes could come to the public's attention a bit earlier than this time. Given the reactions here and at the bug tracker, I don't think that would be a very good idea. People are having knee-jerk reactions without apparently even having read the first few comments. If the Hacker News crowd can't be arsed to understand what's going on, then the last thing you want is "the public's attention" on the decision making process.
dscrd 12y ago
Given that this is the main filesystem in Linux, and is thereby automatically well supported by anything that leverages Linux, this choice makes absolutely no sense. Somebody in Google decided this; somebody in Google is a total idiot.
- Guillaume86 12y ago
  Looks like Google have a politic to drop support for external storage and push the cloud (or force it on us depending of your PoV), same story on Android: https://code.google.com/p/android/issues/detail?id=65974 https://code.google.com/p/android/issues/detail?id=65974
mrmondo 12y ago
I am actually left speechless. Who on earth thought this was a good idea?
chris_wot 12y ago
One of the comments said that there was some sort of security exploit because of extra features. I really have to question what sort of reasoning this is, and what sort of maintenance burden they expect from this?
- kentonv 12y ago
  It is true that the ext4 filesystem driver is a large attack surface that is probably not well-vetted for the possibility of a maliciously-crafted filesystem (since the usual threat model comes from the opposite direction). If it has vulnerabilities, this could allow someone to create a USB stick that pwns the host system when inserted. This is, of course, equally true of all the other filesystem drivers. But fewer total drivers available clearly means less attack surface. So, yeah, it's a legitimate concern.
  - danieldk 12y ago
    It is true that the ext4 filesystem driver is a large attack surface The problem is that reasoning can be applied to any feature you want to get rid of. A good reason would be, we had N vulnerabilities in ext4 in the last six months, which is more than the kernel FAT support, which had only M vulnerabilities. Besides that, the attack vector seems fairly theoretical to me. Most users will take a blank SD card and format it as ext4 themselves.
    - kentonv 12y ago
      > The problem is that reasoning can be applied to any feature you want to get rid of. Well, of course it can. That's more or less the Chrome team's point: they want to remove any feature that isn't widely used, because every feature is an attack vector. > A good reason would be, we had N vulnerabilities in ext4 in the last six months, which is more than the kernel FAT support, which had only M vulnerabilities. Not really, no. The absence of reported vulnerabilities in a time period could mean that there are none, but more likely it just means no one has looked, like with Bash. The things you need to ask yourself when considering attack surface reduction are: * How complicated is this piece of code? (More complication = more bugs.) * Is it likely that this code has been well-studied with respect to the proposed threat model? (For ext4, probably not -- it's designed to be used on your internal disk, which is not an attack vector.) * How painful would it be for users to simply remove it? (Obviously, removing ext4 harms far fewer users than removing FAT, developers notwithstanding.) > Besides that, the attack vector seems fairly theoretical to me. Most users will take a blank SD card and format it as ext4 themselves. Theoretical? Flash drives loaded with malware are an actual, widely-used attack vector, used by everyone from simple identity thieves to governments (look up Stuxnet, which was used to damage Iran's nuclear infrastructure). Things have gotten better since Windows stopped auto-running software on such drives, but a filesystem exploit that kicks in on mount would be more effective and harder to detect (no telltale files visible in the file browser).
mike-cardwell 12y ago
Even if I didn't care about Ext support, there's no way I'm going to buy into Chrome OS now. Who knows what other important features they'll remove in future for the sake of "simplicity"
ghshephard 12y ago
This issue was closed July 21st, 2014 - anybody care to comment what inspired its discussion today?
- pinkythepig 12y ago
  As the OP of the /r/linux thread... What inspired the thread is that I bought an SD card and while on the dev build of chromeOS I was unable to use it with ext4. I distinctly remembered it being listed as supported at one point a year or so ago and then I ran upon this thread: http://www.reddit.com/r/chromeos/comments/2iuix3/trying_to_install_crouton_to_sd_card_parting_not/ http://www.reddit.com/r/chromeos/comments/2iuix3/trying_to_i... So I made a thread on /r/linux and it absolutely exploded. I made it figuring that a number of users would click through and post that this was a stupid change and hopefully get the decision reverted. They claimed there was no userbase for such a feature and I knew exactly where to find one. That said, it blew up way more than I was expecting.
- cowsandmilk 12y ago
  pushed out in the last week as part of stable release version 38 of chromeOS? There are hundreds of thousands of tickets, end users won't follow those, they care once stuff lands on their systems.
DCKing 12y ago
The title of this article is needlessly inflammatory. Can some mod change it? ChromeOS is not dropping support ext* at all; its files application that is meant to be used with external drives is. That's a pretty huge difference. I actually think the rationale for this is pretty good: > Re #19, we understand that this was an undesirable decision for some users, but we sometimes need to make a product decision like this. Chrome and Chrome OS strive for simplicity. Every feature comes with complexity. Complexity adds maintenance cost, QA cost, slows down development, and adds surface of security exploits (as mentioned in #12). We should add a feature only if its benefit clearly outweighs its cost, but this particular feature was slipped in for some historical reason. It's a shame for the people who were actually using this. But lots of people are overlooking that this is just about the ChromeOS files application: ChromeOS can still mount and access ext* drives in general through its Linux kernel and utilities, Crouton and the likes can still use it, and people who specifically need to use the files app for whatever reason have plenty of choices for a file system.
- lotsofmangos 12y ago
  If the worry is that ext* support widens the attack surface, how does removing support from the files app but not the OS, actually help much? The security argument sounds like excuses being made on the fly if a feature is left in and just hidden from userland.
  - DCKing 12y ago
    > If the worry is that ext* support widens the attack surface Clearly, security is not the worry. The worry is that they have to lose time, effort and code simplicity on making te files app work with ext* systems. Additional code complexity has many downsides [1], only one of which is the security concern. Security is a concern that the ChromeOS developers and end users share, so that is why it is mentioned. Maintaining code dealing with ext* in the file manager app has many small disadvantages, of which the security risk is also one. This is not about the risks of "having ext exist in the system in general", this is about the disadvantages [2] of maintaining "your own additional code to handle ext systems". [1]: I feel this issue is waved away so many times, while HN especially should know better. [2]: I'm aware that these things appear to be really small disadvantages, but the ChromeOS developers argue that the advantage of supporting it in the context of a program meant for external storage are even smaller, which I think is understandable.
antman 12y ago
Android KitKat and ChromeOS SDCard blunders pretty much show Google's policy. They have me searching the forums for another unnecessary rooting procedure. Simplicity should be optional and easily disabled through a checkbox in settings. I am afraid FirefoxOS will make the same assumptions.
- zanny 12y ago
  > I am afraid FirefoxOS will make the same assumptions. I'll punch myself in the face the day Mozilla stops supporting patent unencumbered free and technically better filesystems for patent encumbered proprietary Microsoft specific crap.
logicchains 12y ago
I wonder how the cost of maintaining ext2/3/4 support compares to the revenue loss from Linux developers abandoning your platform in droves...
nickthemagicman 12y ago
Is is possible to just wipe chromeOS off of a chromebook and install a full Linux (with reasonable driver support)?
- redthrow 12y ago
  Yes, there's even a customized Ubuntu distro just for Acer C720: https://www.distroshare.com/distros/get/14/ https://www.distroshare.com/distros/get/14/ It's a great Linux machine. Everything works out of the box.
  - deleted 12y ago
    [deleted]
- zmmz 12y ago
  Yep, that's what I did on my Dell 11 (wolf) with Xubuntu and almost everything working out of the box.I just created a vanilla Xubuntu USB, turned on developer mode and made a bios patch (the Dell has a bug, other Chromebooks don't require it), and installed. After installation, I had to run something like two scripts to get the trackpad and suspend working. Battery life is not 10+ hours as it is with chromeOS, probably closer to 7/8. Further reading: https://www.reddit.com/r/chrubuntu/ https://www.reddit.com/r/chrubuntu/ (I didn't follow the Chrubuntu instructions, but used the community to get a touchpad fix) and https://wiki.archlinux.org/index.php/Chromebook https://wiki.archlinux.org/index.php/Chromebook
- ewoodrich 12y ago
  Yes, you can. And Chrubuntu has great driver support for the c720 and other popular models, but I still ran into some bugs with suspend and Wifi, so I stick with a chroot.
  - nickthemagicman 12y ago
    What is chroot? Just popping outside of the GUI and using the linux underneath?
  - nickthemagicman 12y ago
sah88 12y ago
First you have to void your warranty to properly dual boot now this? They want to drop support for a file format so they can make renaming drives easier? I'm actually in the market for a new laptop/netbook. I was very close to purchasing a ChromeOS device as I work primarily on a desktop and have a laptop for travel but its pretty old, heavy and battery unfriendly. Then I found out I had to void the warranty to properly dual boot. Seems like a giant fuck you to the Linux community given how much Google has benefited from Linux(ChromeOS even runs on the Linux kernel) and they put out laptops that are more locked down than your average windows laptops? Pretty disappointing. I am assuming the write protect screws are there at the behest of Google.
- ewoodrich 12y ago
  >I'm actually in the market for a new laptop/netbook. I was very close to purchasing a ChromeOS device as I work primarily on a desktop and have a laptop for travel but its pretty old, heavy and battery unfriendly. Then I found out I had to void the warranty to properly dual boot. I assume you mean having to wait or hit Ctrl-D and manually start a shell? Personally, in some ways I prefer it that way. I have two Chromebooks, and mostly use Crouton, but I've restored them back to factory state with a single keystroke several times, and it makes me confident that I can easily revert after messing with the OS. EDIT: Seems like a giant fuck you to the Linux community given how much Google has benefited from Linux(ChromeOS even runs on the Linux kernel) and they put out laptops that are more locked down than your average windows laptops? Pretty disappointing That's pretty unfair, Google contributes upstream for both ChromeOS and Android, and from the start they allowed an easily accessible developer mode, while prioritizing the security and simplicity for normal consumers.
  - deleted 12y ago
    [deleted]
  - sah88 12y ago
    My opinion was primarily based on this: http://www.reddit.com/r/chromeos/comments/207wlm/is_it_possible_to_avoid_someone_else_from/ http://www.reddit.com/r/chromeos/comments/207wlm/is_it_possi... I can't think of one good reason why a SINGLE keypress at boot can wipe everything and revert to factory settings. Moreover it isn't even password protected. If you don't reflash the bios and you are dual booting ANYONE can walk over, turn your computer on, press space, and tada your computer is wiped. This is the screen: http://imgur.com/wMtvgX3 http://imgur.com/wMtvgX3 I'd be willing to bet the majority of people would press space faced with that, especially after 15-20s of it sitting there doing nothing. (it sits at that screen for 30s unless you hit Ctrl-D) The only reason I can think of that anyone would implement something so inane would be to discourage people from dual booting. edit: I don't disagree that Google has contributed a lot to the Linux community. Overall I'm a pretty big fan of Google and I use a lot of their products. That said I still think their approach to ChromeOS has been very unfriendly towards Linux users. (they're bad vs. what they did was bad)
userbinator 12y ago
Security. Simplicity. Convenience. Does it seem like these words are being used as a generic reason to justify almost anything these days? I think that and the continued trend of removing "developer-only" features are really going to decrease the number of future developers (because of all the hoops they have to jump through), so they're basically shooting themselves in the foot.
- Dewie 12y ago
  Yeah... the following (which I assume that you're referring to) > > Re #19, we understand that this was an undesirable decision for some users, but we sometimes need to make a product decision like this. Chrome and Chrome OS strive for simplicity. Every feature comes with complexity. Complexity adds maintenance cost, QA cost, slows down development, and adds surface of security exploits (as mentioned in #12). We should add a feature only if its benefit clearly outweighs its cost, but this particular feature was slipped in for some historical reason. Sounds reasonable enough. But it could be used to justify pretty much anything.
vxNsr 12y ago
I'm disappointed to see Chrome dropping features but it's even more disappointing to see the comments after this hit HN front page: >#37 vitalifs...@gmail.com >Are you idiots to remove ext support? Don't want to explain more than that. >Today (5 hours ago) #38 StromCl...@gmail.com >Sounds very very stupid (to remove Linux standard file systems)! >#42 Shve...@gmail.com >Sorry but you guys are mentally retarded at best.
- cbhl 12y ago
  Looks like they've locked comments in the bug as a result of the increased mail volume.
- wutbrodo 12y ago
  Seriously: I was reading through the whole bug and finding the conversation (both complaints and responses) to be quite informative until I hit 100 posts of angry lunatics with nothing to contribute and often a misunderstanding of the issue in the first place.
  - ecspike 12y ago
    It probably correlates to when it made Slashdot.
derpenxyne 12y ago
A member of the team has just opened a potential solution to the problem through the new chrome.fileSystemProvider API: crbug.com/422764
- Vendan 12y ago
  And, as I already posted, it's a rather idiotic one. Does the project member not understand the issue? Kernel support hasn't been removed yet, just the userspace stuff. Last thing we need is to rewrite existing, solid code in JS.
kzahel 12y ago
I'll be glad if ext* support is removed from Files.app. I once had it corrupt my externally mounted ext3 hard disk and lost a ton of data. I never should have been doing that kind of thing with Files.app in the first place. It's really only designed to be used with your "Downloads" folder where there's a warning that all your files might be auto-deleted anyway.
mcguire 12y ago
The important takeaway: "Chromium OS is for consumer devices which should not need support for mounting external ext4 storage."
- shaurz 12y ago
  Am I not a consumer then in their eyes? I use ext4 on all my external media and I don't develop for Chrome OS.

cpks 12y ago

All I have to say is fuck Google. I would never use a Chromebook, for a hundred reasons. However, sabotaging Linux support in this way is both shortsighted, aggressive, and moronic. Our kids need to learn to use computers. Not just use Word and Internet Explorer, but learn to hack. Not just consume, but create. Computers 30 years ago were tinkerable. Google is doing everything in its power to take away that tinkerability, and worse, to undermine tinkerable systems.

bert2002 12y ago

luckily notices this before my trip... what the hell?

Dewie 12y ago

I guess that chromebook laptops are cheap (?). Chrome OS seemed appealing to me initially, because of the short start up time. But then, reasonably sized SSDs became affordable[1], and any faster boot times than what Linux + SSD can give me is kind of meh, to me. What are the advantages of ChromeOS over other operating systems? [1] And if you are considering a Chrome OS laptop, chances are that you won't be needing something like >500GB storage for it, I would presume.

deleted 12y ago

[deleted]

dingaling 12y ago

Thereby entrenching the FAT patent fee scheme. This is a very odd decision that originated in the difficulty of renaming external volumes ( why was this considerd important? ) and then became conflated with 'security'. I believe the kernel modules are still there, though, so you can mount extx from the command line in dev mode. But not much use for everyday users.

danmaz74 12y ago
BTW, when will those patents expire? Shouldn't be long I guess..
- techrat 12y ago
  The issue is exFAT and Fat32 long filenames. exFAT was introduced with Windows Vista and is what 32GB+ flash media tends to be formatted in. It'll be a long time before this one expires.
  - overcertified 12y ago
    There are at least 4 patents involved, extensible file system, name hash lookup, transactional fat, contiguous file allocation. If you look at overcertified'a recent slideshare presentations on exFAT, including the recent HTCIA 2014 exFAT presentation, the patent numbers are listed on the ending reference slides.
  - caf 12y ago
    Does anyone know exactly what innovation(s) in exFAT is/are newly patented? Which patents read on it?
    - techrat 12y ago
      From wiki: >exFAT is a proprietary file system. However exFAT is protected under US patent law, and its initial application was issued on 10 July 2009 under the application number US2008168029.[7] On 12 November 2013, the patent was granted by the US patent office under US8583708. Patent length is 20 years, so we're looking at least until 2033 before exFat is expired and (safely) freely usable.
      - cowsandmilk 12y ago
        > Patent length is 20 years, so we're looking at least until 2033 before exFat is expired and (safely) freely usable. Nope. For the dates this was filed, length goes from filing date. Depending on how dangerous you want to be, you could argue it expires anywhere from 2024-2028.

riffraff 12y ago

what is the root filesystem in ChromeOS?

pjmlp 12y ago
It is a browser based OS, so you shouldn't care. :)
shaurz 12y ago
ext4

higherpurpose 12y ago

Does it support F2FS then? That would be for the best.

imrehg 12y ago

Of course as per Comment #21 someone has to make project management decisions, but decisions like "Chromium OS is for consumer devices which should not need support for mounting external ext4 storage" is just so painful to read. It's just a pile of assumptions that goes against the evidence of given my a lot of comments.

VLM 12y ago
"is for consumer" Generally speaking whenever someone starts speaking for the "other" they're doing something wrong and they know it and the othering is just CYA speech.

lucb1e 12y ago

And thus we returned to the stone ages of unjournaled FAT(-like) filesystems or bad NTFS driver implementations (the only good one is Microsoft's, and I doubt they'll be handing over the code for Chromium). It's not even something consumers see, it's a driver for crying out loud. It doesn't even make sense to remove it for "product simplicity" as they are claiming now. Edit: Left a comment with another argument about FAT being a bitmap filesystem (versus ext4's binary trees) and that developers are the people that are going to code for their OS. Ignoring the 1% is not the smartest move. https://code.google.com/p/chromium/issues/detail?id=315401#c45 https://code.google.com/p/chromium/issues/detail?id=315401#c...

wutbrodo 12y ago
>It's not even something consumers see, it's a driver for crying out loud. It doesn't even make sense to remove it for "product simplicity" as they are claiming now. I may be confused, but isn't the discussion about removing support in the files app UI (while actual ext support remains in the console)? That would mean the exact opposite of what you're saying: it's a UI change, not a driver change.

nkuttler 12y ago

> On a related note, we may want to re-evaluate whether we'd like to continue supporting ext2/3/4 filesystems (~2% of users, and the majority is probably Chrome OS developers) in File.app. Yes, please, drop support for something the developers use, what could go wrong? The title seems misleading though, it seems that only the built in file manager will drop support for ext, and even then, maybe only for a specific feature?

lucb1e 12y ago
> it seems that only the built in file manager will drop support for ext I spend a lot of my time in a terminal each day and can easily navigate filesystems on it, but even I would prefer filemanager support. Android does the same: I can mount ext4 micro-SD cards just fine, but forget about seeing them in ES File Explorer or any other part of the Android system. Apps can't open the folder where I mounted it and "Settings" prompts to format it for me. No thank you.
- shams93 12y ago
  Naw it blew my chroots off, couldn't even reach them from the console in dev mode. Now I'll have to try installing ubuntu directly on the thumb and then see if I can use legacy boot, which will likely work since booting off the thumb instead of running chroot should just bypass chromeos, but annoying I have to jump through hoops when everything was working great.
logicallee 12y ago
>~2% of users 2% seems pretty high! If you make 50-70 kinds of these project management feature-drop decisions, then if the groups are mostly distinct, you'll have dropped 100% of your users (2% * 50 or 1.42% * 70 = 100%.) Think of it this way. If only two percent of your users have a first name that isn't in the top hundred first names in America, would you drop support for first names that aren't on your whitelist, in some form field? (because you want it to contain real data.) I think it's better to think through the rationale for dropping support (for example: If the people using this feature have a clear alternative, that is also better, and that they know about and will try and like. Then it might be acceptable In the first name example, the only rationale would be if this were some kind of game or something and people weren't expected to use their actual first name, and you also present them the list. Then it might work.) The rationale presented here is very weak. "Only highly-paid people (developers) trying to get work done use this, about 2% of our sales." Marketing win?

nodata 12y ago

Because they can't relabel an extX volume? How does that make any sense?

shams93 12y ago

Yeah I was wondering why I suddenly couldn't load my crouton on external 64 gig stick, really annoying google blew off my entire android development environment.

redthrow 12y ago
Is there any reason why you want to keep ChromeOS at all? https://www.distroshare.com/distros/get/14/ https://www.distroshare.com/distros/get/14/

microcolonel 12y ago

ChromiumOS developers can't even implement a script to relabel EXT volumes? No wonder their kernel tree is such a mess, they must barely know what they're doing. Also, I'd say you can safely assume that those 1-2% of users that use EXT volumes externally(which by the way, is a LOT of people, several million at least) are developers, and this will surely piss them off.

pjmlp 12y ago
Also looking at the quality of NDK, I sometimes doubt why Google makes such hard admission interviews.
cnvogel 12y ago
Obviously no one can defend this decision with the labeling non-issue while keeping a straight face, so time to guess: What they are probably bitten by is the issue of ext4 actually keeping proper uid/gid associations with files. The other FS they seem to support [exFAT, FAT, UDF, NTFS] all are (as far as I know, and under Linux) completely agnostic to permissions and user-IDs: everything gets squashed to one uid/gid and fixed permissions. Probably that is the actual problem they want to get rid of and which causes pains? They only mentioned the labeling as "features such as...", so there might be more bugreports/requests... Android (at least the Cyanogenmod variety on my phone) works around it with a small fuse-shim that fixes user-visible permissions on the fly, for all FS, including ext4. And ext4 makes for a very nice and well-performing fs on my phone.
- asveikau 12y ago
  > FS they seem to support [... NTFS] all are (as far as I know, and under Linux) completely agnostic to permissions and user-IDs Uhhh... On Windows this definitely not true. The NT security descriptiors are kind of complex and I could imagine nobody wanting to sit down and map them to a Unixy system. But they are definitely there.
  - cnvogel 12y ago
    That's why I added: ...and under Linux. I'm well aware of NTFS permissions, and use them daily, both in UI and programmatically. Under Windows, though.

xg15 12y ago

It looks like this ticket was opened a year ago, during which almost no discussion took place. People only started to voice objections after the patch was already written and submitted. I think it would be useful if tickets with breaking changes could come to the public's attention a bit earlier than this time. I have no idea how to find such tickets of course. The search function of the issue tracker doesn't seem very helpful...

Intermernet 12y ago
Very good point. It seems that this was tagged "Type-Feature" which is meant to mean "Request for new or improved features". I'm not sure how removing functionality is a "new or improved" feature, except from the developers POV due to reduced complexity. This is probably not how the users would define "new or improved". They possibly need a new tag for "Type-FeatureRemoval" or similar.
zorbo 12y ago
> I think it would be useful if tickets with breaking changes could come to the public's attention a bit earlier than this time. Given the reactions here and at the bug tracker, I don't think that would be a very good idea. People are having knee-jerk reactions without apparently even having read the first few comments. If the Hacker News crowd can't be arsed to understand what's going on, then the last thing you want is "the public's attention" on the decision making process.

dscrd 12y ago

Given that this is the main filesystem in Linux, and is thereby automatically well supported by anything that leverages Linux, this choice makes absolutely no sense. Somebody in Google decided this; somebody in Google is a total idiot.

Guillaume86 12y ago
Looks like Google have a politic to drop support for external storage and push the cloud (or force it on us depending of your PoV), same story on Android: https://code.google.com/p/android/issues/detail?id=65974 https://code.google.com/p/android/issues/detail?id=65974

mrmondo 12y ago

I am actually left speechless. Who on earth thought this was a good idea?

chris_wot 12y ago

One of the comments said that there was some sort of security exploit because of extra features. I really have to question what sort of reasoning this is, and what sort of maintenance burden they expect from this?

kentonv 12y ago
It is true that the ext4 filesystem driver is a large attack surface that is probably not well-vetted for the possibility of a maliciously-crafted filesystem (since the usual threat model comes from the opposite direction). If it has vulnerabilities, this could allow someone to create a USB stick that pwns the host system when inserted. This is, of course, equally true of all the other filesystem drivers. But fewer total drivers available clearly means less attack surface. So, yeah, it's a legitimate concern.
- danieldk 12y ago
  It is true that the ext4 filesystem driver is a large attack surface The problem is that reasoning can be applied to any feature you want to get rid of. A good reason would be, we had N vulnerabilities in ext4 in the last six months, which is more than the kernel FAT support, which had only M vulnerabilities. Besides that, the attack vector seems fairly theoretical to me. Most users will take a blank SD card and format it as ext4 themselves.
  - kentonv 12y ago
    > The problem is that reasoning can be applied to any feature you want to get rid of. Well, of course it can. That's more or less the Chrome team's point: they want to remove any feature that isn't widely used, because every feature is an attack vector. > A good reason would be, we had N vulnerabilities in ext4 in the last six months, which is more than the kernel FAT support, which had only M vulnerabilities. Not really, no. The absence of reported vulnerabilities in a time period could mean that there are none, but more likely it just means no one has looked, like with Bash. The things you need to ask yourself when considering attack surface reduction are: * How complicated is this piece of code? (More complication = more bugs.) * Is it likely that this code has been well-studied with respect to the proposed threat model? (For ext4, probably not -- it's designed to be used on your internal disk, which is not an attack vector.) * How painful would it be for users to simply remove it? (Obviously, removing ext4 harms far fewer users than removing FAT, developers notwithstanding.) > Besides that, the attack vector seems fairly theoretical to me. Most users will take a blank SD card and format it as ext4 themselves. Theoretical? Flash drives loaded with malware are an actual, widely-used attack vector, used by everyone from simple identity thieves to governments (look up Stuxnet, which was used to damage Iran's nuclear infrastructure). Things have gotten better since Windows stopped auto-running software on such drives, but a filesystem exploit that kicks in on mount would be more effective and harder to detect (no telltale files visible in the file browser).

mike-cardwell 12y ago

Even if I didn't care about Ext support, there's no way I'm going to buy into Chrome OS now. Who knows what other important features they'll remove in future for the sake of "simplicity"

ghshephard 12y ago

This issue was closed July 21st, 2014 - anybody care to comment what inspired its discussion today?

pinkythepig 12y ago
As the OP of the /r/linux thread... What inspired the thread is that I bought an SD card and while on the dev build of chromeOS I was unable to use it with ext4. I distinctly remembered it being listed as supported at one point a year or so ago and then I ran upon this thread: http://www.reddit.com/r/chromeos/comments/2iuix3/trying_to_install_crouton_to_sd_card_parting_not/ http://www.reddit.com/r/chromeos/comments/2iuix3/trying_to_i... So I made a thread on /r/linux and it absolutely exploded. I made it figuring that a number of users would click through and post that this was a stupid change and hopefully get the decision reverted. They claimed there was no userbase for such a feature and I knew exactly where to find one. That said, it blew up way more than I was expecting.
cowsandmilk 12y ago
pushed out in the last week as part of stable release version 38 of chromeOS? There are hundreds of thousands of tickets, end users won't follow those, they care once stuff lands on their systems.

DCKing 12y ago

The title of this article is needlessly inflammatory. Can some mod change it? ChromeOS is not dropping support ext* at all; its files application that is meant to be used with external drives is. That's a pretty huge difference. I actually think the rationale for this is pretty good: > Re #19, we understand that this was an undesirable decision for some users, but we sometimes need to make a product decision like this. Chrome and Chrome OS strive for simplicity. Every feature comes with complexity. Complexity adds maintenance cost, QA cost, slows down development, and adds surface of security exploits (as mentioned in #12). We should add a feature only if its benefit clearly outweighs its cost, but this particular feature was slipped in for some historical reason. It's a shame for the people who were actually using this. But lots of people are overlooking that this is just about the ChromeOS files application: ChromeOS can still mount and access ext* drives in general through its Linux kernel and utilities, Crouton and the likes can still use it, and people who specifically need to use the files app for whatever reason have plenty of choices for a file system.

lotsofmangos 12y ago
If the worry is that ext* support widens the attack surface, how does removing support from the files app but not the OS, actually help much? The security argument sounds like excuses being made on the fly if a feature is left in and just hidden from userland.
- DCKing 12y ago
  > If the worry is that ext* support widens the attack surface Clearly, security is not the worry. The worry is that they have to lose time, effort and code simplicity on making te files app work with ext* systems. Additional code complexity has many downsides [1], only one of which is the security concern. Security is a concern that the ChromeOS developers and end users share, so that is why it is mentioned. Maintaining code dealing with ext* in the file manager app has many small disadvantages, of which the security risk is also one. This is not about the risks of "having ext exist in the system in general", this is about the disadvantages [2] of maintaining "your own additional code to handle ext systems". [1]: I feel this issue is waved away so many times, while HN especially should know better. [2]: I'm aware that these things appear to be really small disadvantages, but the ChromeOS developers argue that the advantage of supporting it in the context of a program meant for external storage are even smaller, which I think is understandable.

antman 12y ago

Android KitKat and ChromeOS SDCard blunders pretty much show Google's policy. They have me searching the forums for another unnecessary rooting procedure. Simplicity should be optional and easily disabled through a checkbox in settings. I am afraid FirefoxOS will make the same assumptions.

zanny 12y ago
> I am afraid FirefoxOS will make the same assumptions. I'll punch myself in the face the day Mozilla stops supporting patent unencumbered free and technically better filesystems for patent encumbered proprietary Microsoft specific crap.

logicchains 12y ago

I wonder how the cost of maintaining ext2/3/4 support compares to the revenue loss from Linux developers abandoning your platform in droves...

nickthemagicman 12y ago

Is is possible to just wipe chromeOS off of a chromebook and install a full Linux (with reasonable driver support)?

redthrow 12y ago
Yes, there's even a customized Ubuntu distro just for Acer C720: https://www.distroshare.com/distros/get/14/ https://www.distroshare.com/distros/get/14/ It's a great Linux machine. Everything works out of the box.
- deleted 12y ago
  [deleted]
zmmz 12y ago
Yep, that's what I did on my Dell 11 (wolf) with Xubuntu and almost everything working out of the box.I just created a vanilla Xubuntu USB, turned on developer mode and made a bios patch (the Dell has a bug, other Chromebooks don't require it), and installed. After installation, I had to run something like two scripts to get the trackpad and suspend working. Battery life is not 10+ hours as it is with chromeOS, probably closer to 7/8. Further reading: https://www.reddit.com/r/chrubuntu/ https://www.reddit.com/r/chrubuntu/ (I didn't follow the Chrubuntu instructions, but used the community to get a touchpad fix) and https://wiki.archlinux.org/index.php/Chromebook https://wiki.archlinux.org/index.php/Chromebook
ewoodrich 12y ago
Yes, you can. And Chrubuntu has great driver support for the c720 and other popular models, but I still ran into some bugs with suspend and Wifi, so I stick with a chroot.
- nickthemagicman 12y ago
  What is chroot? Just popping outside of the GUI and using the linux underneath?
- nickthemagicman 12y ago

sah88 12y ago

First you have to void your warranty to properly dual boot now this? They want to drop support for a file format so they can make renaming drives easier? I'm actually in the market for a new laptop/netbook. I was very close to purchasing a ChromeOS device as I work primarily on a desktop and have a laptop for travel but its pretty old, heavy and battery unfriendly. Then I found out I had to void the warranty to properly dual boot. Seems like a giant fuck you to the Linux community given how much Google has benefited from Linux(ChromeOS even runs on the Linux kernel) and they put out laptops that are more locked down than your average windows laptops? Pretty disappointing. I am assuming the write protect screws are there at the behest of Google.

ewoodrich 12y ago
>I'm actually in the market for a new laptop/netbook. I was very close to purchasing a ChromeOS device as I work primarily on a desktop and have a laptop for travel but its pretty old, heavy and battery unfriendly. Then I found out I had to void the warranty to properly dual boot. I assume you mean having to wait or hit Ctrl-D and manually start a shell? Personally, in some ways I prefer it that way. I have two Chromebooks, and mostly use Crouton, but I've restored them back to factory state with a single keystroke several times, and it makes me confident that I can easily revert after messing with the OS. EDIT: Seems like a giant fuck you to the Linux community given how much Google has benefited from Linux(ChromeOS even runs on the Linux kernel) and they put out laptops that are more locked down than your average windows laptops? Pretty disappointing That's pretty unfair, Google contributes upstream for both ChromeOS and Android, and from the start they allowed an easily accessible developer mode, while prioritizing the security and simplicity for normal consumers.
- deleted 12y ago
  [deleted]
- sah88 12y ago
  My opinion was primarily based on this: http://www.reddit.com/r/chromeos/comments/207wlm/is_it_possible_to_avoid_someone_else_from/ http://www.reddit.com/r/chromeos/comments/207wlm/is_it_possi... I can't think of one good reason why a SINGLE keypress at boot can wipe everything and revert to factory settings. Moreover it isn't even password protected. If you don't reflash the bios and you are dual booting ANYONE can walk over, turn your computer on, press space, and tada your computer is wiped. This is the screen: http://imgur.com/wMtvgX3 http://imgur.com/wMtvgX3 I'd be willing to bet the majority of people would press space faced with that, especially after 15-20s of it sitting there doing nothing. (it sits at that screen for 30s unless you hit Ctrl-D) The only reason I can think of that anyone would implement something so inane would be to discourage people from dual booting. edit: I don't disagree that Google has contributed a lot to the Linux community. Overall I'm a pretty big fan of Google and I use a lot of their products. That said I still think their approach to ChromeOS has been very unfriendly towards Linux users. (they're bad vs. what they did was bad)

userbinator 12y ago

Security. Simplicity. Convenience. Does it seem like these words are being used as a generic reason to justify almost anything these days? I think that and the continued trend of removing "developer-only" features are really going to decrease the number of future developers (because of all the hoops they have to jump through), so they're basically shooting themselves in the foot.

Dewie 12y ago
Yeah... the following (which I assume that you're referring to) > > Re #19, we understand that this was an undesirable decision for some users, but we sometimes need to make a product decision like this. Chrome and Chrome OS strive for simplicity. Every feature comes with complexity. Complexity adds maintenance cost, QA cost, slows down development, and adds surface of security exploits (as mentioned in #12). We should add a feature only if its benefit clearly outweighs its cost, but this particular feature was slipped in for some historical reason. Sounds reasonable enough. But it could be used to justify pretty much anything.

vxNsr 12y ago

I'm disappointed to see Chrome dropping features but it's even more disappointing to see the comments after this hit HN front page: >#37 vitalifs...@gmail.com >Are you idiots to remove ext support? Don't want to explain more than that. >Today (5 hours ago) #38 StromCl...@gmail.com >Sounds very very stupid (to remove Linux standard file systems)! >#42 Shve...@gmail.com >Sorry but you guys are mentally retarded at best.

cbhl 12y ago
Looks like they've locked comments in the bug as a result of the increased mail volume.
wutbrodo 12y ago
Seriously: I was reading through the whole bug and finding the conversation (both complaints and responses) to be quite informative until I hit 100 posts of angry lunatics with nothing to contribute and often a misunderstanding of the issue in the first place.
- ecspike 12y ago
  It probably correlates to when it made Slashdot.

derpenxyne 12y ago

A member of the team has just opened a potential solution to the problem through the new chrome.fileSystemProvider API: crbug.com/422764

Vendan 12y ago
And, as I already posted, it's a rather idiotic one. Does the project member not understand the issue? Kernel support hasn't been removed yet, just the userspace stuff. Last thing we need is to rewrite existing, solid code in JS.

kzahel 12y ago

I'll be glad if ext* support is removed from Files.app. I once had it corrupt my externally mounted ext3 hard disk and lost a ton of data. I never should have been doing that kind of thing with Files.app in the first place. It's really only designed to be used with your "Downloads" folder where there's a warning that all your files might be auto-deleted anyway.

mcguire 12y ago

The important takeaway: "Chromium OS is for consumer devices which should not need support for mounting external ext4 storage."

shaurz 12y ago
Am I not a consumer then in their eyes? I use ext4 on all my external media and I don't develop for Chrome OS.