4 ms·

Moreover, Chromebooks, when paired with a good cloud IDE like https://c9.io https://c9.io, are excellent for writing code - more so than any "traditional" OS, s

by spb 10y ago

Moreover, Chromebooks, when paired with a good cloud IDE like https://c9.io https://c9.io, are excellent for writing code - more so than any "traditional" OS, since the local system is only dedicating resources toward keeping the interface responsive, and not wasting them on background distractions like local search indexing or filesystem defragmentation. Meanwhile, if you accidentally forkbomb a cloud development server, your music player doesn't freeze in an endless sample loop at max volume, and if your battery dies, you don't lose your uncommitted in-buffer file changes. Driver updates never break your system's ability to connect to the network, and (with separate workspaces for separate projects) compilation never breaks due to the installation of a conflicting SDK version. To be frank, I don't know how most developers can tolerate writing their code on anything else.

wrsh07 10y ago
Of course this all works on a MacBook, too. But it's a little sad that my high powered, sleek computer is only being used for SSH...
cheez 10y ago
If I can try and get to the root of what you're saying: with Chromebook and cloud-based applications, you do not have the resources of one computer, but many and the one closest to you is dedicated ONLY to making sure you have good interactivity. Interesting.
- zzkt 10y ago
  you could think of them as a "client" and "server"
jjnoakes 10y ago
I bet I could use it for an hour and come up with a long list of why I would hate that environment. But off the top of my head: Not all developers work on projects which can be hosted by a third party company and require always-on super-stable internet access.
- tuxracer 10y ago
  Web apps can work completely offline if the developer adds support https://codelabs.developers.google.com/codelabs/offline/ https://codelabs.developers.google.com/codelabs/offline/ Not sure why this misconception about web apps requiring "always-on super-stable internet access" persists when this technology has been available for quite some time (in the form of App Cache before Service Workers)
  - stephenr 10y ago
    It may be possible to host the ide component locally in the browser, but that doesn't give you the execution environment (ie you can't run a vagrant image or in the case of a server based ide, a container, in a browser)
    - tuxracer 10y ago
      There is a way to do this actually via https://copy.sh/v86/ https://copy.sh/v86/ Although this is straying from the main point. There are certainly things native apps can do that web apps cannot. But requiring "always-on super-stable internet access" is absolutely not required for web apps. This hasn't been true for at least 5 years now. It also seems to be the most often repeated (completely inaccurate) limitation about web apps. There are certainly limitations. Let's talk about the real limitations, not the mythical ones.
contingencies 10y ago
If you ever visit developing countries or places like China where internet just sucks you can't realistically use cloud services. Out of interest, I wonder what part of the experience of a cloud service aren't you motivated to replicate on your own system for added speed/security/control/learning? Most of your arguments seem Windows-oriented (driver updates) or moot with decent CI/CD workflow practices (conflicting SDK versions).
- spb 10y ago
  It took me like five minutes to parse what you were asking about "replicating" the cloud experience locally - the way you phrase it, you're inherently assuming that a local development environment would be superior in a few factors, none of which end up being so: - Speed: Local development environments are just as slow as cloud ones, when not slower (due to compositor hitches, background downloads, heavyweight UI toolkits, all that bullshit). Speed is part of the reason that I ditched local environments. I can't emphasize enough how little there is to be truly gained from offlining a workspace in terms of performance. When looking beyond pure ideal-world benchmarks and taking the intersecting outliers that impact performance during actual usage into play, the net savings, as I'm trying to convey here, are negative. - Security: The odds are greater that somebody's going to run a buffer overflow on one of the many undermaintained and/or proprietary services and applications running on your machine (when's the last time someone ran Valgrind against f.lux?) and slipstream a rootkit into it, than that somebody's going to attack your dev server with a zero-day against CentOS (and even if they did, you'd have been just as screwed anyway). Put another way: which machine is more secure, the one with a dedicated 24/7 threat response team monitoring port access, or the one that gets left unattended on a table at Starbucks every Tuesday afternoon? - Control: If your development needs more control than root access to the host filesystem, you're doing something wrong, and your codebase is going to be more fragile for it. (Hell, even using root access is a sign that you're being persnickety.) - Learning: Learning time should be allocated toward the systems involved in what I'm actually building, not a http://www.xkcd.com/1579/ http://www.xkcd.com/1579/ hodgepodge of perpetually-obsolete periphery. I don't know WTF you're talking about with my examples being Windows-oriented - the driver example I cited was specifically inspired by an issue with my desktop's network adapter on Linux.

by spb 10y ago

wrsh07 10y ago

Of course this all works on a MacBook, too. But it's a little sad that my high powered, sleek computer is only being used for SSH...

cheez 10y ago

If I can try and get to the root of what you're saying: with Chromebook and cloud-based applications, you do not have the resources of one computer, but many and the one closest to you is dedicated ONLY to making sure you have good interactivity. Interesting.

zzkt 10y ago
you could think of them as a "client" and "server"

jjnoakes 10y ago

I bet I could use it for an hour and come up with a long list of why I would hate that environment. But off the top of my head: Not all developers work on projects which can be hosted by a third party company and require always-on super-stable internet access.

tuxracer 10y ago
Web apps can work completely offline if the developer adds support https://codelabs.developers.google.com/codelabs/offline/ https://codelabs.developers.google.com/codelabs/offline/ Not sure why this misconception about web apps requiring "always-on super-stable internet access" persists when this technology has been available for quite some time (in the form of App Cache before Service Workers)
- stephenr 10y ago
  It may be possible to host the ide component locally in the browser, but that doesn't give you the execution environment (ie you can't run a vagrant image or in the case of a server based ide, a container, in a browser)
  - tuxracer 10y ago
    There is a way to do this actually via https://copy.sh/v86/ https://copy.sh/v86/ Although this is straying from the main point. There are certainly things native apps can do that web apps cannot. But requiring "always-on super-stable internet access" is absolutely not required for web apps. This hasn't been true for at least 5 years now. It also seems to be the most often repeated (completely inaccurate) limitation about web apps. There are certainly limitations. Let's talk about the real limitations, not the mythical ones.

contingencies 10y ago

If you ever visit developing countries or places like China where internet just sucks you can't realistically use cloud services. Out of interest, I wonder what part of the experience of a cloud service aren't you motivated to replicate on your own system for added speed/security/control/learning? Most of your arguments seem Windows-oriented (driver updates) or moot with decent CI/CD workflow practices (conflicting SDK versions).

spb 10y ago
It took me like five minutes to parse what you were asking about "replicating" the cloud experience locally - the way you phrase it, you're inherently assuming that a local development environment would be superior in a few factors, none of which end up being so: - Speed: Local development environments are just as slow as cloud ones, when not slower (due to compositor hitches, background downloads, heavyweight UI toolkits, all that bullshit). Speed is part of the reason that I ditched local environments. I can't emphasize enough how little there is to be truly gained from offlining a workspace in terms of performance. When looking beyond pure ideal-world benchmarks and taking the intersecting outliers that impact performance during actual usage into play, the net savings, as I'm trying to convey here, are negative. - Security: The odds are greater that somebody's going to run a buffer overflow on one of the many undermaintained and/or proprietary services and applications running on your machine (when's the last time someone ran Valgrind against f.lux?) and slipstream a rootkit into it, than that somebody's going to attack your dev server with a zero-day against CentOS (and even if they did, you'd have been just as screwed anyway). Put another way: which machine is more secure, the one with a dedicated 24/7 threat response team monitoring port access, or the one that gets left unattended on a table at Starbucks every Tuesday afternoon? - Control: If your development needs more control than root access to the host filesystem, you're doing something wrong, and your codebase is going to be more fragile for it. (Hell, even using root access is a sign that you're being persnickety.) - Learning: Learning time should be allocated toward the systems involved in what I'm actually building, not a http://www.xkcd.com/1579/ http://www.xkcd.com/1579/ hodgepodge of perpetually-obsolete periphery. I don't know WTF you're talking about with my examples being Windows-oriented - the driver example I cited was specifically inspired by an issue with my desktop's network adapter on Linux.