3 ms·

> 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

> 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?
- cnvogel 12y ago
  It's not that bad in practice ;-)... Let's assume random distribution of used features among your customers. If you shoot randomly at your users with a 2% hit rate [alienate them by dropping a feature], your user will stay with your product with 98% probability. Do it 50 times, any user will have a 0.98^50 = 36% chance of not having been hit [having at least one important feature taken away from him that makes him stop using your product...], so only (100%-36%) 64% of users will drop your product and go elsewhere.
  - nitrogen 12y ago
    Someone should have explained this to the GNOME team.
- Intermernet 12y ago
  It's putting a positive spin on Xeno's Paradox. 100% minus 2% leaves 100% of the remainder! Until you remember that the quantum of a user-base is a user. I really don't know why they haven't adopted the (already existing) code from Android, or maybe even Gnome, KDE etc. that seems to solve the problem they purportedly face. If other projects (one of which is also a Google product) have solved this, why can't the ChromeOS team? I may be being naive, but why hasn't this issue arisen in other, similar projects? I understand that they want to keep the codebase simple, but keeping HFS+ and VFAT while ditching ext* due to possible future security issues seems like a cop-out.

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?

cnvogel 12y ago
It's not that bad in practice ;-)... Let's assume random distribution of used features among your customers. If you shoot randomly at your users with a 2% hit rate [alienate them by dropping a feature], your user will stay with your product with 98% probability. Do it 50 times, any user will have a 0.98^50 = 36% chance of not having been hit [having at least one important feature taken away from him that makes him stop using your product...], so only (100%-36%) 64% of users will drop your product and go elsewhere.
- nitrogen 12y ago
  Someone should have explained this to the GNOME team.
Intermernet 12y ago
It's putting a positive spin on Xeno's Paradox. 100% minus 2% leaves 100% of the remainder! Until you remember that the quantum of a user-base is a user. I really don't know why they haven't adopted the (already existing) code from Android, or maybe even Gnome, KDE etc. that seems to solve the problem they purportedly face. If other projects (one of which is also a Google product) have solved this, why can't the ChromeOS team? I may be being naive, but why hasn't this issue arisen in other, similar projects? I understand that they want to keep the codebase simple, but keeping HFS+ and VFAT while ditching ext* due to possible future security issues seems like a cop-out.