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.
It makes sense if you think of what the purpose of Chrome OS is. The point is not to make inexpensive hardware to run any OS on. The point is not to create a new general-purpose open OS that people can build on. The point is to get people to put there stuff in the Google Cloud to become bigger Google customers. Period.
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.
The issue at hand isn't the purpose, it never was. It is how it limits the purpose of the user, even after Google benefited greatly from said users (everyone who uses open source software contributes to it, small or large; using, coding, documenting etc). "Hi! Mind helping us for a bit? Thanks for helping us. Now, how about you stop doing that stuff that is useful to you and start doing some stuff that is useful to us?" Not a very good narrative.
I'm actually wondering why would people spend money on a chromebook - the hardware is crap and the price isn't that great. If I was looking for a cheap portable web browsing device I'd get something like : http://www.onda-tablet.com/onda-v975w-quad-core-win-8-tablet... - that's a 10 inch Windows 8.1 tablet with 2048*1536 resolution, quad core atom and 2 GB ram for 220$. Throw in 20$ and you can find a USB case with keyboard.
Portable, better performance, better screen, can be used as a "internet machine" with Win 8.
I recently bought a Chromebook and I love it. I am a college student - and I have a powerful desktop machine, but wanted something I could take to classes. I could have bought a low powered laptop, but I didn't need all the features of Windows 8. The Chromebook is perfect for me, as it starts up within about 3 seconds, and does everything I need to it do quickly. I even have Crouton on it, meaning I can switch to a debian installation with a keyboard shortcut. Every now and then, if I want to run a steam game, for example, I use this. But even without that ability, it's nice to have a device that 'Just Works'.
> I'm actually wondering why would people spend money on a chromebook - the hardware is crap and the price isn't that great.
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.
If you think that tablet is going to have the build quality of a Chromebook then you've obviously never spent much time with cheap iPad knockoffs before.
No, it's not locked. But you can't install Ubuntu there (at least not easily). Google for "32-bit UEFI" if you need any more details about the sorry state of affairs with booting Linux on latest crop of Atom Bay Trail hardware. The only out-of-the-box working distro for it is "fedlet" - some obscure fedora 21-alpha fork.
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'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.
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)
My 14 year old daughter runs chromeOS and xubuntu on her Chromebook and she takes it to school and she has never had a problem with it being wiped. She is, however, aware that files stored on that machine internally could be lost and she takes precaution.
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.
The only reason I can think of that anyone would implement something so inane would be to discourage people from dual booting.
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.
That may be true for the Pixel (I don't have one). But I've drained the battery on both my Chromebooks (HP 14 and c720) a number of times, and have never lost data on the stateful partition. I have replaced the SSD on both of them, however, so it could be hardware specific.
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.
Original Samsung ARM chromebook doesn't have any write protect screw, this is a device about which I have zero complaints so far. (I've owned it for only a few weeks so far.)
I wish it came with a newer kernel, but all for reasons that "you can compile your own kernel" are really a valid response.
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.
> 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.
The way I look at it is that if ext* support is left in the system, it still needs tested thoroughly. Removing it from UI tools just means that it will be tested less, so while it may reduce complexity and increase security in one app, it actually could make things worse for the OS in general. It feels that mentioning security as part of the reason was just trying to justify the decision after the fact.
> The way I look at it is that if ext* support is left in the system, it still needs tested thoroughly.
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.
Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered.
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.
> Say there is an exploit in the OS ext* implementation, if ext* is not included in userland, then it will be subject to far less testing, so the exploit is less likely to be discovered.
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.
I sympathize with the general sentiment, but it misses the point.
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.
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.
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.
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.
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.
> 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.
> 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?
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?
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.
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.
> 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.
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.
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#c...
>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.
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.
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.
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.
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.
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.
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.
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...
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.
> 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.
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.
First, reverse engineering in some cases may violate the DMCA regardless of what you do with the code.
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.
Last I checked reverse engineering without paying licenses was legal. And that's what this open source implementation of exFAT is.
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.
The rationale behind using MTP is that "in the old days", the android device had to unmount its "/sdcard" partition and hand over the block-device to the PC, that mounted it just like any single-partition usb-stick. Downside is, that a) the PC mounting the android device could arbitrarily corrupt the filesystem structure and b) all programs accessing the filesystem on the android side needed to shutdown, and c) you only could use a filesytem well supported by all major computer operating systems: hence FAT.
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.
But it doesn't work like "rsync/scp/sftp over USB". No seek or partial transfer support makes it a dog. Very poor cross-platform support makes it a terrible choice.
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.
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.
>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.
> 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.
5579517 is pre-gatt, so it is 17 years from date of grant, which for it is Nov 26, 1996 + 17 years => Nov 26, 2013 - so 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.
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.
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"
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?
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.
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.
> 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).
OK, I actually asked a kernel dev friend about this because it affects my work on sandstorm.io, and he says that defense against malicious filesystems is in fact something Theodore Ts'o, the ext4 maintainer (and Googler), cares deeply about. Awesome!
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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_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.
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.
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.