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.
That's why they make it difficult to dual boot and allow all your files to be wiped with a single key. That's also why anything you do on the Chromebook before you login to Google for the first time isn't saved. The point is to make everything on the laptop appear impermanent and to get you to think of the cloud as the place your digital stuff is actually stored.
Portable, better performance, better screen, can be used as a "internet machine" with Win 8.
Battery life. Most Chromebooks get good to great battery life and in my opinion good battery life is a requirement on any laptop; no matter how cheap.
My experience with low-end Windows laptops is that the battery life is usually atrocious. 2-3 hours on my last one. If I want to be plugged in all the time I'll buy a desktop.
There is at least one product with a Bay Trail CPU in it that runs Linux: http://www.phoronix.com/vr.php?view=19836.
Unlike most Atom CPUs, the graphics driver for Linux on Bay Trail CPUs is completely open (like it is on Intel Core CPUs), which I guess makes it doubly sad that some manufacturers of products with Bay Trail CPUs in them are screwing up with the boot loader.
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.
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.
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 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)
I bought our first HP Chromebook 14 as refurb off and love it so much I bought a second one. They are both in constant use in our household. My wife even prefers to use hers over her desktop.
Or, as an example, to make sure that you won't "mod" your Grandma's computer and silently break auto-updates or cause performance issues without her knowing. The screen is clearly designed for non power-users, and Google wants it to look as scary as possible to dissuade consumers who are just following a tutorial online, or something.
EDIT: I'm surprised this is controversial. It's one of the express reasons for verified boot warnings.
The devices have to be reset each year. Administration of thousands of laptops across an entire district is easier with Chromebooks than with any other device. The angst many posters are expressing is possibly alleviated by Elementary OS.
http://imgur.com/wMtvgX3 (renabling wipes the hard drive)
You have to remove a screw that voids the warranty and reflash the bios. That said, there could be some devices that don't have a write protect screw but every laptop I looked at had one.
I wish it came with a newer kernel, but all for reasons that "you can compile your own kernel" are really a valid response.
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.
The security argument sounds like excuses being made on the fly if a feature is left in and just hidden from userland.
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 , 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  of maintaining "your own additional code to handle ext systems".
: I feel this issue is waved away so many times, while HN especially should know better.
: 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.
Could you explain why? Especially 'thoroughly'.
> It feels that mentioning security as part of the reason was just trying to justify the decision after the fact.
No doubt. The actual reason is "we don't want to maintain this piece of code anymore because of the added complexity". Security concerns are merely a consequence of this added complexity. That does not mean it is false to say it, though.
edit- the way I look at code security is that trying to write good code in the first place is not as important as the testing regime to find bad code, so while there is a risk of introducing new bugs by supporting ext* in the files app, this is counterbalanced by the risk that the underlying ext* implementation will not be included in as many tests.
If you want to mount an external ext* partition yourself in ChromeOS from now on, you'll have to do some manual work going down to Linux using a terminal or Crouton. If there's an exploit in any of that, it will also affect millions of other Linux computers around the world as ChromeOS is no different from any other Linux distro with respect to ext* anymore (just Linux + ext kernel modules + e2fsprogs). Google will not feel obliged to cover that use case in their tests, and rightly so I think.
In fact, they have described their "support" of ext* as accidental in the original thread, so it doesn't appear they ever tested it in the first place.
Linux + ext kernel modules + e2fsprogs is tested daily by developers of many Linux distributions. There's really no problem with verifying that some module works. Furthermore, Google tests this system implicitly by haveing ChromeOS use ext4 as its root file system. So everyone is right to be confident it works correctly.
However, testing whether or not something works is totally different from testing whether it is secure. Many people testing whether OpenSSL works correctly (which happens every single day) would not have shown Heartbleed at all.
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.
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.
That layer comes from AOSP, yes - unfortunately, it also screws up symlink support, which is bad for some cross-platform applications. You can still use the underlying fs directly if you have root, though.
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.
I'm well aware of NTFS permissions, and use them daily, both in UI and programmatically. Under Windows, though.
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?
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?
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.
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.
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.
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#c...
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.
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.
>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)!
>Sorry but you guys are mentally retarded at best.
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.
> > 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.
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...
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.
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.
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.
If a patent is valid, then reverse engineering doesn't get you anywhere. Patent is not copyright. You can sit down and write your own implementation of the code, not copying anything, and still violate the patent.
Most of the people who complain about having to pay for exfat are the open source people who are used to getting what they thought was free software. However with the Heartbleed and shell shock issues this year the crditbity and false notions that open source are free are going down the drain. Meanwhile, Microsoft successful defense of the vfat (long for name in fat32) and mapping parents against Tom Tom has minimized cases where someone goes against those patents and almost all major distributions of Linux will not (and probably can't) add exfat to the distribution. That leaves most using FUSE and there are many complaints over the various forums about issues, bugs, and corruption ISO g the FUSE drivers.
As a monopoly on PC's, why is Microsoft allowed to collect royalties on the filesystem anyway? Is there another way to connect external media to a Windows PC without having to pay Microsoft royalties?
If there is not, that should be an anti-trust issue.
I think UDF is well supported by everything now and has several advantages over FAT (including large file and basic rwx permissions support).
MTP doesn't work on the level of a block-device, but rather works like, e.g. "rsync/scp/sftp over USB". So the Android handset can leave the partition mounted, all program can stay running, any filesystem can be used on the handset side, and potential for data corruption is minimized.
>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. 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.
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.
http://www.google.com/patents/US5579517 expires next year.
http://www.google.com/patents/US5758352 expires in 2016.
http://www.google.com/patents/US6286013 expires in 2017.
There is one more, which looked to have already expired:
5758352 is post-gatt, so it is 20 years from earliest priority date, the earliest priority date is Apr. 1, 1993 + 20 years = Apr. 1, 2013 - so also already expired (unless it has any term extension).
6286013 is also post-gatt, also with a priority date of Apr. 1, 1993 + 20 years = Apr. 1, 2013 - so also already expired (unless it has any term extension).
5745902 is pre-gatt, it patented Apr. 28, 1998 and gets 17 years from that date, so Apr. 28, 1998 + 17 years => Apr. 28, 2015 - it expires in about six months.
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.
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.
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).
Now, that doesn't automatically mean it's safe, but given this new piece of information, I'd say that the case for removing ext4 for attack surface reasons is significantly weakened.
Simplicity should be optional and easily disabled through a checkbox in settings. 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.
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/ (I didn't follow the Chrubuntu instructions, but used the community to get a touchpad fix) and https://wiki.archlinux.org/index.php/Chromebook
It's a great Linux machine. Everything works out of the box.
Crouton is a install script that uses a chroot to install Ubuntu through the shell on ChromeOS. You still need to enable developer mode, and it uses the ChromeOS kernel, but other than that it looks and feels like a "normal" Ubuntu installation.
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.
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.
What are the advantages of ChromeOS over other operating systems?
 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.
"Chromium OS is for consumer devices which should not need support for mounting external ext4 storage."