Have you ever tried to use Android in a desktop context? I used it for a while on my netbook (in the form of Android-x86) and let me tell you, it sucked ass.
Android is made for the "singletasking one fullscreen app" paradigm of phones and tablets, with large touch-friendly controls for small-screen devices. There are a couple of Android-based laptops available, and you know what? They're not selling, because Android sucks for the desktop.
ChromeOS on the other hand, is made for the desktop paradigm of multiple simultaneous overlapping windows, with controls that are sized for mouse/touchpad usage, not direct touch usage. Sure, Chromebooks have large touchpads now for gesture controls that are kinda sorta similar to what you get on touchscreen devices, but I know I'd much rather use a touchpad than drag my grubby mitts all over the screen, leaving greasy fingerprints.
Tell us what Android does that ChromeOS currently can't do? Even the most popular apps for Android are severely limited (due to their small-scren touch interface designs), whereas ChromeOS runs the full-on Chrome browser, bells and whistles included. Everything you can do in Chrome on your Windows/Linux/Mac desktop, you can do in ChromeOS. Try that with Android.
You joke, but honest and constructive feedback from users is a huge part of developing quality software. Sometimes the feedback to certain changes gets a bit virulent and aggressive, but even then there might be bits of valuable information on how users view your software.
So keep up the feedback, and try to be as constructive as possible!:-)
I also use Chrome and other Google services, for the same reasons. I'm selling a bit of privacy to buy a gigantic helping of convenience. It is very likely that that particular bit of privacy was imaginary anyway.
Oh no, someone is going to use my search requests and subsequent clicks for statistical purposes, when will the madness end? Google doesn't give a shit about anyone individually, they want broad statistics so their ads can hit the largest possible interest groups.
I've used Keepass for a long time, but I recently moved to Lastpass because getting Keepass to sync reliably is a major hassle, plus Lastpass works really well on Android, even for apps. I have a strong master password, which is easy to change regularly because I only have to remember that one password. I also have 2-factor authentication enabled through Google Authenticator. Every other password is randomly generated, I don't even know them.
AFAIK, you can't directly see everything Google has on you, but you can see a little of it and opt out of the targeted advertising stuff on the ads settings page: https://www.google.com/setting...
It's a per-browser cookie that opts you out of targeted advertising, so you'll have to change the setting on all of your browsers.
Do you have any verifiable proof that they sell this info to third parties? Because it would make a whole lot more business sense to keep that information to themselves and only sell the results, namely the better ad targeting (which you can opt out of, BTW). Knowledge is power, so why would Google want to sell of bits of that power?
Probably the same as I do on my PC, both at home and at work: Web browsing, e-mail, social media, instant messaging, watch videos, read the news, word processing, spreadsheets, presentations. a bit of scripting, play some games. You know, normal computer stuff. Not everyone is a big huge developer or graphic designer.
Of course, I like having a 6-core, 16GB RAM, beefy GPU machine at home with a big monitor and hooked up to a big stereo, for playing games and watching movies with all the needed boom and blast, or whichever other heavy lifting-type tasks I need do do. But for the greatest part of what I actually use computers for, I could do just fine with ChromeOS. I actually made do just fine for a couple of months with only a tablet and a smartphone for when I wasn't at home.
Don't think of Chromebooks as desktop replacements. Think of them as an inexpensive middle ground between tablets and full-size laptops. They're inexpensive, light, small and have good battery life, but they're less limited than tablets and come with decent hardware keyboards built in. Chromeboxes on the other hand are actually desktop replacements, for all those people who literally only need a web browser, an e-mail client and some fun little time-wasting games, as crazy as that may sound to you.
Most of my job could be done through ChromeOS as well. I do web and mobile application monitoring and reporting, presentations for the business people, approve changes to systems, verify that systems are up and fully functional after incidents are solved, propose improvements and upgrades, and sometimes a bit of scripting etc.
For the business side of things, word processing, spreadsheets and presentations can all be handled through Google Docs or Office365. Almost all of the specialty tools I use are either SaaS or hosted by ourselves and accessed through a web interface. We have a few legacy desktop applications and a couple of Java-dependent applications that I wouldn't be able to use directly, but a handful of remote desktop machines could take of those needs for the entire company.
Our IT costs could be reduced by a huge amount if we could have everything as a SaaS or locally hosted web-based tool, and replace everyone's laptops and desktops with something like Chromebooks or Chromeboxes. All with a standard image that could be reflashed in minutes if needed, while all their data stayed backed-up in a central location (on our own servers, of course). If ChromeOS had Java support, I could migrate today.
The "security issue" because of "unnecessary features" may not have been aimed directly at extFS support, that's probably a misunderstanding.
Still, from everything I can see, it was still just a suggestion, although I don't follow the Chromium betas closely. You'll note in the discussion that the first opposing voice against killing extFS support came from an @chromium.org e-mail.
Dropping NPAPI in Chrome was a great, if ballsy move. Flash/Java et al suck serious ass, and the sooner we can be rid of them, the better.
Regarding the extFS issue on Chrome OS, the summary here really tries to fan the (perhaps non-existent) flames. A couple of developers proposed dropping extFS support, but were soundly shut down by a deluge of comments that it was a stupid idea. From what I understand, they want to keep extFS and are looking at how to handle permissions, volume renaming and possible security issues.
Yeah, that's my impression as well. A couple of coders thought they had a brilliant idea, only to have it shot down by other developers (and users). Happens all the time, not every brilliant coder is a brilliant feature designer.
Comment #101 specifically says that he (and a bunch of other developers) would hate to lose extFS support, so they're looking into how they can make it work with volume renaming and how to guard against security issues. The summary here on/. is deliberately inflammatory. No, Google as such has not dropped extFS support in Chrome OS, all that's happened is that a couple of developers have suggested it.
From reading the linked code.chrome.org discussion (yes, all of it), it seems that this was one developer proposing to drop extFS support, ostensibly because of security issues and because the new volume renaming code they're working on doesn't work with extFS. A couple of developers agreed, but then a shitstorm of negative comments appeared. One of the final comments (from a different dev) says that a large number, if not most of the Chrome OS developers want to keep extFS and proposed either a workaround error message when trying to rename extFS volume, and/or implementing extFS in userspace for external drives, for security reasons.
This was a suggestion made by a ChromeOS developer, not Google as a whole. And the suggestion was pretty soundly argued against in the code.google.com link in the summary.
No. From reading the linked discussion (before people started having shitfits), a dev suggested removing extFS support as "an unnecessary feature" because of theoretical security issues and because it interfered with implementing file system renaming (which looks to be surprisingly tricky to do right). In no time at all, objections were posted, some of them rather aggressive in tone.
One of the last comments before disallowing further comments was that they were looking into keeping extFS support, but throwing an error message if you try to rename an extFS volume, and possibly implementing extFS support in userspace for security reasons. All of this seems quite reasonable when considering what ChromeOS is and its usual usecase.
From reading the linked proposal to drop ext2/3/4 support, there has been a lot of pushback from users, particularly developers and other power users. As far as I can gather, especially from comment #101, they are taking this feedback very seriously, and are looking into either making ext2/3/4 work with the feature that was supposedly the reason for dropping support, and/or finding an alternative way of supporting external drives with those file systems.
To me, this smells a lot like a couple of developers thinking they could pull a fast one and drop file systems they considered "unneeded", but now that feedback has been received, the overall feeling I get is "let's find a way to make this work". There may also have been a possible security risk with rogue disk images that needs to be handled.
I was going to say that a purely desktop-oriented distro where everything is at least as slick and user-friendly as current OSX, but it seems that Mint and ElementaryOS are already trying to carve out that niche.
From all accounts, they had teething issues, but are actually working pretty damn well now.
However, one thing that I'm sad to say I missed is that they break compatibility with BSD (especially systemd) for all applications that require them. That's unacceptable and I don't understand why people aren't more up in arms over this. BSD users should be our allies, not our enemies.
A piece of software starts requiring a specific dependency. The distros have a simple choice, either drop that piece of software or satisfy the dependency. They looked at the options and chose the one they considered most beneficial to the distro.
Personally, I would just as easily have dropped Gnome, but I don't run a distro.
Troll? For pointing out that networkmanager, pulseaudio and systemd actually work?
At best, you can accuse me of relying on anecdotal evidence (and you would be right), but trolling? Maybe you need to recalibrate your trolldar, or stop being blinded by your hate of Lennart Poettering.
Slashdot Mirror
Have you ever tried to use Android in a desktop context? I used it for a while on my netbook (in the form of Android-x86) and let me tell you, it sucked ass.
Android is made for the "singletasking one fullscreen app" paradigm of phones and tablets, with large touch-friendly controls for small-screen devices. There are a couple of Android-based laptops available, and you know what? They're not selling, because Android sucks for the desktop.
ChromeOS on the other hand, is made for the desktop paradigm of multiple simultaneous overlapping windows, with controls that are sized for mouse/touchpad usage, not direct touch usage. Sure, Chromebooks have large touchpads now for gesture controls that are kinda sorta similar to what you get on touchscreen devices, but I know I'd much rather use a touchpad than drag my grubby mitts all over the screen, leaving greasy fingerprints.
Tell us what Android does that ChromeOS currently can't do? Even the most popular apps for Android are severely limited (due to their small-scren touch interface designs), whereas ChromeOS runs the full-on Chrome browser, bells and whistles included. Everything you can do in Chrome on your Windows/Linux/Mac desktop, you can do in ChromeOS. Try that with Android.
You joke, but honest and constructive feedback from users is a huge part of developing quality software. Sometimes the feedback to certain changes gets a bit virulent and aggressive, but even then there might be bits of valuable information on how users view your software.
So keep up the feedback, and try to be as constructive as possible! :-)
I also use Chrome and other Google services, for the same reasons. I'm selling a bit of privacy to buy a gigantic helping of convenience. It is very likely that that particular bit of privacy was imaginary anyway.
Oh no, someone is going to use my search requests and subsequent clicks for statistical purposes, when will the madness end? Google doesn't give a shit about anyone individually, they want broad statistics so their ads can hit the largest possible interest groups.
"User dumb" covers the situation much more succinctly.
I know, and I had a reasonable setup running with browser plugins for Firefox and Chrome, while syncing the keystore onto my Google Drive.
Lastpass is like a million times easier, though. Well worth $12/year for the premium version.
I've used Keepass for a long time, but I recently moved to Lastpass because getting Keepass to sync reliably is a major hassle, plus Lastpass works really well on Android, even for apps. I have a strong master password, which is easy to change regularly because I only have to remember that one password. I also have 2-factor authentication enabled through Google Authenticator. Every other password is randomly generated, I don't even know them.
AFAIK, you can't directly see everything Google has on you, but you can see a little of it and opt out of the targeted advertising stuff on the ads settings page: https://www.google.com/setting...
It's a per-browser cookie that opts you out of targeted advertising, so you'll have to change the setting on all of your browsers.
Do you have any verifiable proof that they sell this info to third parties? Because it would make a whole lot more business sense to keep that information to themselves and only sell the results, namely the better ad targeting (which you can opt out of, BTW). Knowledge is power, so why would Google want to sell of bits of that power?
Do you know of any cameras that format their SD cards to extFS? All of the ones I've ever seen, used or even heard about use FAT or exFAT.
Probably the same as I do on my PC, both at home and at work: Web browsing, e-mail, social media, instant messaging, watch videos, read the news, word processing, spreadsheets, presentations. a bit of scripting, play some games. You know, normal computer stuff. Not everyone is a big huge developer or graphic designer.
Of course, I like having a 6-core, 16GB RAM, beefy GPU machine at home with a big monitor and hooked up to a big stereo, for playing games and watching movies with all the needed boom and blast, or whichever other heavy lifting-type tasks I need do do. But for the greatest part of what I actually use computers for, I could do just fine with ChromeOS. I actually made do just fine for a couple of months with only a tablet and a smartphone for when I wasn't at home.
Don't think of Chromebooks as desktop replacements. Think of them as an inexpensive middle ground between tablets and full-size laptops. They're inexpensive, light, small and have good battery life, but they're less limited than tablets and come with decent hardware keyboards built in. Chromeboxes on the other hand are actually desktop replacements, for all those people who literally only need a web browser, an e-mail client and some fun little time-wasting games, as crazy as that may sound to you.
Most of my job could be done through ChromeOS as well. I do web and mobile application monitoring and reporting, presentations for the business people, approve changes to systems, verify that systems are up and fully functional after incidents are solved, propose improvements and upgrades, and sometimes a bit of scripting etc.
For the business side of things, word processing, spreadsheets and presentations can all be handled through Google Docs or Office365. Almost all of the specialty tools I use are either SaaS or hosted by ourselves and accessed through a web interface. We have a few legacy desktop applications and a couple of Java-dependent applications that I wouldn't be able to use directly, but a handful of remote desktop machines could take of those needs for the entire company.
Our IT costs could be reduced by a huge amount if we could have everything as a SaaS or locally hosted web-based tool, and replace everyone's laptops and desktops with something like Chromebooks or Chromeboxes. All with a standard image that could be reflashed in minutes if needed, while all their data stayed backed-up in a central location (on our own servers, of course). If ChromeOS had Java support, I could migrate today.
And it's not like they even wanted to drop extFS support completely, just the handling of it for external drives in their files.app file manager.
The "security issue" because of "unnecessary features" may not have been aimed directly at extFS support, that's probably a misunderstanding.
Still, from everything I can see, it was still just a suggestion, although I don't follow the Chromium betas closely. You'll note in the discussion that the first opposing voice against killing extFS support came from an @chromium.org e-mail.
Dropping NPAPI in Chrome was a great, if ballsy move. Flash/Java et al suck serious ass, and the sooner we can be rid of them, the better.
Regarding the extFS issue on Chrome OS, the summary here really tries to fan the (perhaps non-existent) flames. A couple of developers proposed dropping extFS support, but were soundly shut down by a deluge of comments that it was a stupid idea. From what I understand, they want to keep extFS and are looking at how to handle permissions, volume renaming and possible security issues.
Yeah, that's my impression as well. A couple of coders thought they had a brilliant idea, only to have it shot down by other developers (and users). Happens all the time, not every brilliant coder is a brilliant feature designer.
Read the discussion:
https://code.google.com/p/chro...
Comment #101 specifically says that he (and a bunch of other developers) would hate to lose extFS support, so they're looking into how they can make it work with volume renaming and how to guard against security issues. The summary here on /. is deliberately inflammatory. No, Google as such has not dropped extFS support in Chrome OS, all that's happened is that a couple of developers have suggested it.
From reading the linked code.chrome.org discussion (yes, all of it), it seems that this was one developer proposing to drop extFS support, ostensibly because of security issues and because the new volume renaming code they're working on doesn't work with extFS. A couple of developers agreed, but then a shitstorm of negative comments appeared. One of the final comments (from a different dev) says that a large number, if not most of the Chrome OS developers want to keep extFS and proposed either a workaround error message when trying to rename extFS volume, and/or implementing extFS in userspace for external drives, for security reasons.
s/Google's/A ChromeOS Developer's/g
This was a suggestion made by a ChromeOS developer, not Google as a whole. And the suggestion was pretty soundly argued against in the code.google.com link in the summary.
No. From reading the linked discussion (before people started having shitfits), a dev suggested removing extFS support as "an unnecessary feature" because of theoretical security issues and because it interfered with implementing file system renaming (which looks to be surprisingly tricky to do right). In no time at all, objections were posted, some of them rather aggressive in tone.
One of the last comments before disallowing further comments was that they were looking into keeping extFS support, but throwing an error message if you try to rename an extFS volume, and possibly implementing extFS support in userspace for security reasons. All of this seems quite reasonable when considering what ChromeOS is and its usual usecase.
From reading the linked proposal to drop ext2/3/4 support, there has been a lot of pushback from users, particularly developers and other power users. As far as I can gather, especially from comment #101, they are taking this feedback very seriously, and are looking into either making ext2/3/4 work with the feature that was supposedly the reason for dropping support, and/or finding an alternative way of supporting external drives with those file systems.
To me, this smells a lot like a couple of developers thinking they could pull a fast one and drop file systems they considered "unneeded", but now that feedback has been received, the overall feeling I get is "let's find a way to make this work". There may also have been a possible security risk with rogue disk images that needs to be handled.
I was going to say that a purely desktop-oriented distro where everything is at least as slick and user-friendly as current OSX, but it seems that Mint and ElementaryOS are already trying to carve out that niche.
From all accounts, they had teething issues, but are actually working pretty damn well now.
However, one thing that I'm sad to say I missed is that they break compatibility with BSD (especially systemd) for all applications that require them. That's unacceptable and I don't understand why people aren't more up in arms over this. BSD users should be our allies, not our enemies.
Get Noscript (or ScriptSafe for Chrome) and Adblock Plus with Easylist, Easyprivacy, Malware Domains and Fanboy's Annoyance List.
You'll never be bothered with bullshit video ads again.
A piece of software starts requiring a specific dependency. The distros have a simple choice, either drop that piece of software or satisfy the dependency. They looked at the options and chose the one they considered most beneficial to the distro.
Personally, I would just as easily have dropped Gnome, but I don't run a distro.
Troll? For pointing out that networkmanager, pulseaudio and systemd actually work?
At best, you can accuse me of relying on anecdotal evidence (and you would be right), but trolling? Maybe you need to recalibrate your trolldar, or stop being blinded by your hate of Lennart Poettering.