3 ms·

When designing the OS, he "took off the table the largest performance bottlenecks in the operating system: File I/O" by moving the entire OS to RAM, so the new

by cs702 14y ago

When designing the OS, he "took off the table the largest performance bottlenecks in the operating system: File I/O" by moving the entire OS to RAM, so the new OS couldn't really run large (i.e., powerful) desktop applications, which in turn meant that the new OS would have to use "webapps to replace any and all functionality normally found on a desktop." So, in the end, for powerful desktop applications that need a lot of I/O, he ended up replacing file I/O with... over-the-Web I/O that is slower by orders of magnitude. I like Chrome OS, and want it to be successful, but for powerful desktop functionality with heavy I/O, a traditional desktop OS is faster. There's always a trade-off.

pmelendez 14y ago
I agree with you, but there is a flip side. It's OK for powerfull apps to use disk, however, by your definition a browser is not a powerfull app nor it is a word processor nor an email client. His design makes sense in a very specific market but I would very interested in seeing an OS with an hybrid approach
- colinsidoti 14y ago
  I'm working on an OS with a hybrid approach: http://www.projectmeadow.com http://www.projectmeadow.com (The site isn't as fine tuned as I'd like yet...but interested in your thoughts. Thanks!)
  - pmelendez 14y ago
    Hmm looks promising... I just got subscribed to see your updates! :)
Andrex 14y ago
Per the blog post itself, all operations operated locally in RAM except for some asynchronous backing up to permanent media. He didn't mention network I/O at all, because most likely, the web apps were local (see: Chrome packaged apps.) In any case Chrome OS's current architecture is completely different from the version he laid out. It doesn't run completely in RAM; instead, it relies on SSD's in most cases to reduce file I/O times.
- jonknee 14y ago
  > He didn't mention network I/O at all, because most likely, the web apps were local (see: Chrome packaged apps.) This pre-dated Chrome, see the part about it originally being based on FireFox.
  - Andrex 14y ago
    I didn't say they were Chrome packaged apps, but that they were like them. He even says as much: "That's how the seeds of the webapps on the Chromium desktop, albeit originally written in HTML and running on Firefox, were planted."
acg 14y ago
Isn't he replacing disk I/O with network I/O, and unless you are talking about SSD isn't the network faster? http://serverfault.com/questions/238417/are-networks-now-faster-than-disks http://serverfault.com/questions/238417/are-networks-now-fas... Doesn't google's search engine demonstrate this?
- brigade 14y ago
  It seems unlikely that a Chromebook would have a gigabit link within Google's datacenters.
  - acg 14y ago
    That wasn't the point. Is the network really "slower by orders of magnitude" than disk? Why is using the network such a silly idea, considering network speeds are more than keeping up. Was the reference just referring to protocols. I was hoping for some accuracy: something to back up the statement.
    - brigade 14y ago
      No, it was referring to bandwidth and latency. 30ms latency is basically the best-case scenario you can expect for consumer internet (with a nearby datacenter and all that.) 10ms latency is about the worst-case latency for a rotational disk. And almost no consumer internet outside of Japan or South Korea is going to get more than 2 MB/s of real bandwidth, compared to 100 MB/s of real bandwidth from rotational hard drives. Throw wireless or uploading into the mix (who's going to use a Chromebook over ethernet?) and it's even worse.
    - stcredzero 14y ago
      > Is the network really "slower by orders of magnitude" than disk? Congrats on asking this question, because it's a window into a foundational fact of life in computer programming and technology: http://en.wikipedia.org/wiki/Memory_hierarchy http://en.wikipedia.org/wiki/Memory_hierarchy You can feel good about gaining important knowledge. (Advanced exercise: extrapolate from the implications of not having known one piece of fundamental knowledge, then take action.)
lallysingh 14y ago
Synchronous File I/O with async Network I/O.
jeff-nelson 14y ago
Yes, there's a couple performance trade-offs, both good and bad. First, as you observe, File I/O is faster than Network I/O - on a call for call basis. However, current disk-based operating systems may perform thousands of File I/O operations per second when performing seemingly trivial tasks - dramatically slowing down the perceived speed of the operating system. Webapps do not perform thousands of Network I/O operations per second. Instead, webapp authors go to great lengths to maximize that the perceived performance of the app, even on very slow network connections. For example, Gmail perform asynchronous background network operations, so the user rarely perceives any sort of network delay - even on a very slow connection. Another significant trade-off of running webapps instead of locally installed application compiled to machine code - webapps are usually written in some combination of Flash, ECMAscript, or HTML5, all of which are much slower than machine code. However, webapp authors also go to great lengths to insure their apps perform very well, despite the slow language interpreters. In the end if the webapps are written well, they absolutely can run faster than a traditional operating system running local apps.

by cs702 14y ago

pmelendez 14y ago

I agree with you, but there is a flip side. It's OK for powerfull apps to use disk, however, by your definition a browser is not a powerfull app nor it is a word processor nor an email client. His design makes sense in a very specific market but I would very interested in seeing an OS with an hybrid approach

colinsidoti 14y ago
I'm working on an OS with a hybrid approach: http://www.projectmeadow.com http://www.projectmeadow.com (The site isn't as fine tuned as I'd like yet...but interested in your thoughts. Thanks!)
- pmelendez 14y ago
  Hmm looks promising... I just got subscribed to see your updates! :)

Andrex 14y ago

Per the blog post itself, all operations operated locally in RAM except for some asynchronous backing up to permanent media. He didn't mention network I/O at all, because most likely, the web apps were local (see: Chrome packaged apps.) In any case Chrome OS's current architecture is completely different from the version he laid out. It doesn't run completely in RAM; instead, it relies on SSD's in most cases to reduce file I/O times.

jonknee 14y ago
> He didn't mention network I/O at all, because most likely, the web apps were local (see: Chrome packaged apps.) This pre-dated Chrome, see the part about it originally being based on FireFox.
- Andrex 14y ago
  I didn't say they were Chrome packaged apps, but that they were like them. He even says as much: "That's how the seeds of the webapps on the Chromium desktop, albeit originally written in HTML and running on Firefox, were planted."

acg 14y ago

Isn't he replacing disk I/O with network I/O, and unless you are talking about SSD isn't the network faster? http://serverfault.com/questions/238417/are-networks-now-faster-than-disks http://serverfault.com/questions/238417/are-networks-now-fas... Doesn't google's search engine demonstrate this?

brigade 14y ago
It seems unlikely that a Chromebook would have a gigabit link within Google's datacenters.
- acg 14y ago
  That wasn't the point. Is the network really "slower by orders of magnitude" than disk? Why is using the network such a silly idea, considering network speeds are more than keeping up. Was the reference just referring to protocols. I was hoping for some accuracy: something to back up the statement.
  - brigade 14y ago
    No, it was referring to bandwidth and latency. 30ms latency is basically the best-case scenario you can expect for consumer internet (with a nearby datacenter and all that.) 10ms latency is about the worst-case latency for a rotational disk. And almost no consumer internet outside of Japan or South Korea is going to get more than 2 MB/s of real bandwidth, compared to 100 MB/s of real bandwidth from rotational hard drives. Throw wireless or uploading into the mix (who's going to use a Chromebook over ethernet?) and it's even worse.
  - stcredzero 14y ago
    > Is the network really "slower by orders of magnitude" than disk? Congrats on asking this question, because it's a window into a foundational fact of life in computer programming and technology: http://en.wikipedia.org/wiki/Memory_hierarchy http://en.wikipedia.org/wiki/Memory_hierarchy You can feel good about gaining important knowledge. (Advanced exercise: extrapolate from the implications of not having known one piece of fundamental knowledge, then take action.)

lallysingh 14y ago

Synchronous File I/O with async Network I/O.

jeff-nelson 14y ago

Yes, there's a couple performance trade-offs, both good and bad. First, as you observe, File I/O is faster than Network I/O - on a call for call basis. However, current disk-based operating systems may perform thousands of File I/O operations per second when performing seemingly trivial tasks - dramatically slowing down the perceived speed of the operating system. Webapps do not perform thousands of Network I/O operations per second. Instead, webapp authors go to great lengths to maximize that the perceived performance of the app, even on very slow network connections. For example, Gmail perform asynchronous background network operations, so the user rarely perceives any sort of network delay - even on a very slow connection. Another significant trade-off of running webapps instead of locally installed application compiled to machine code - webapps are usually written in some combination of Flash, ECMAscript, or HTML5, all of which are much slower than machine code. However, webapp authors also go to great lengths to insure their apps perform very well, despite the slow language interpreters. In the end if the webapps are written well, they absolutely can run faster than a traditional operating system running local apps.