4 ms·

I'm not entirely convinced by this: the fact that the OS is still there and operating means that there's still a layer of abstraction. That's important not beca

by unalone 18y ago

I'm not entirely convinced by this: the fact that the OS is still there and operating means that there's still a layer of abstraction. That's important not because it gets in the way, but because it helps out. For instance, on OS X, the Command-Control-D shortcut to auto-define any word you're overing over. Or the universal spell-check. Things that make things easier for developers and users alike. I think a part of it is the operating system in question. Some really do stay out of your way, and it makes the browser in question something of importance. Others are much more pervasive. I said on another thread that I couldn't imagine using a desktop mail app until I got my Mac, because it wasn't until Mail that I had something that really felt like a part of the system. And from what I know of fellow Mac-using students, they all feel the same way. I know a lot of Windows students who use Meebo as their default chat. Linux users almost all use Pidgin or Kopete. Mac users almost always stick with iChat. On Windows, where Meebo is more accessible than downloading something new, the web will be used more often. With more well-rounded platforms, though, the web isn't seen as being quite so pervasive.

scott_s 18y ago
Technically, your example has nothing to do with the operating system itself, and is just the desktop environment. I know, I'm being pedantic, but I have a real point to make. All nontrivial systems programs converge on an operating system. By which I mean the kernel, not the desktop environment. Google's Chrome is, I think, the closest a browser has gotten to being an OS kernel. This is an interesting development because if browsers have to replicate much of the same behavior as an OS kernel, then functionality can move from the actual OS kernel up into the browser. OS kernels may then become leaner as more applications are run inside the browser instead of natively on the OS kernel. Which is close to a micro-kernel architecture, except in a form I don't think anyone anticipated 10 years ago. Where the desktop environment lies may change, too. Will browsers start co-opting that as well, or is it still best to run that directly on top of the OS kernel? I think so, but I'm going on intuition, not experiment or practice.
- michael_dorfman 18y ago
  In what way is Google's chrome close to being an OS kernel? Is it handling device drivers, or scheduling, or address space management, or file system I/O?
  - scott_s 18y ago
    Scheduling. It looks like the Chrome process is really a kernel of sorts for the tabs.
    - blasdel 18y ago
      NO, it is not a scheduler, it is not a kernel. That is exactly what Chrome is not. It's not a monolithic process, with a large pool of green threads being scheduled to run on native threads using runtime trickery. Instead it's just a bunch of shared-nothing exec-ed processes that are scheduled by the OS kernel, have their mallocs handled directly by the OS libc, and have their address space mapped and reclaimed by the OS kernel's VMM.
      - scott_s 18y ago
        In my own work, when I fork threads that are run and executed by the kernel, I still make decisions outside the kernel about how those threads run. I may tell threads to go to sleep, wait for another thread to finish something, or prefer a certain thread to run over others. Yes, they are still scheduled by the OS kernel, but they are also being controlled by my own scheduling algorithms. I call this scheduling, because it's the same problem as OS level scheduling. And if I have to do it, I imagine Chrome has to do it. In this scenario, if you want to understand the runtime behavior of the threads, you must consider both OS kernel level decisions and my scheduling decisions. I would also be surprised if there was no Chrome memory management inbetween malloc and the OS kernel.
        scott_s 18y ago
        Addendum, directly from the design docs, http://dev.chromium.org/developers/design-documents/process-models http://dev.chromium.org/developers/design-documents/process-...: "Web content has evolved to contain significant amounts of active code that run within the browser, making many web sites more like applications than documents. This evolution has changed the role of the browser into an operating system rather than a simple document renderer. Unlike current browsers, Chromium is built like an operating system to run these applications in a safe and robust way, using multiple OS processes to isolate web sites from each other and from the browser itself." Emphasis mine.

by unalone 18y ago

scott_s 18y ago

Technically, your example has nothing to do with the operating system itself, and is just the desktop environment. I know, I'm being pedantic, but I have a real point to make. All nontrivial systems programs converge on an operating system. By which I mean the kernel, not the desktop environment. Google's Chrome is, I think, the closest a browser has gotten to being an OS kernel. This is an interesting development because if browsers have to replicate much of the same behavior as an OS kernel, then functionality can move from the actual OS kernel up into the browser. OS kernels may then become leaner as more applications are run inside the browser instead of natively on the OS kernel. Which is close to a micro-kernel architecture, except in a form I don't think anyone anticipated 10 years ago. Where the desktop environment lies may change, too. Will browsers start co-opting that as well, or is it still best to run that directly on top of the OS kernel? I think so, but I'm going on intuition, not experiment or practice.

michael_dorfman 18y ago
In what way is Google's chrome close to being an OS kernel? Is it handling device drivers, or scheduling, or address space management, or file system I/O?
- scott_s 18y ago
  Scheduling. It looks like the Chrome process is really a kernel of sorts for the tabs.
  - blasdel 18y ago
    NO, it is not a scheduler, it is not a kernel. That is exactly what Chrome is not. It's not a monolithic process, with a large pool of green threads being scheduled to run on native threads using runtime trickery. Instead it's just a bunch of shared-nothing exec-ed processes that are scheduled by the OS kernel, have their mallocs handled directly by the OS libc, and have their address space mapped and reclaimed by the OS kernel's VMM.
    - scott_s 18y ago
      In my own work, when I fork threads that are run and executed by the kernel, I still make decisions outside the kernel about how those threads run. I may tell threads to go to sleep, wait for another thread to finish something, or prefer a certain thread to run over others. Yes, they are still scheduled by the OS kernel, but they are also being controlled by my own scheduling algorithms. I call this scheduling, because it's the same problem as OS level scheduling. And if I have to do it, I imagine Chrome has to do it. In this scenario, if you want to understand the runtime behavior of the threads, you must consider both OS kernel level decisions and my scheduling decisions. I would also be surprised if there was no Chrome memory management inbetween malloc and the OS kernel.
      - scott_s 18y ago
        Addendum, directly from the design docs, http://dev.chromium.org/developers/design-documents/process-models http://dev.chromium.org/developers/design-documents/process-...: "Web content has evolved to contain significant amounts of active code that run within the browser, making many web sites more like applications than documents. This evolution has changed the role of the browser into an operating system rather than a simple document renderer. Unlike current browsers, Chromium is built like an operating system to run these applications in a safe and robust way, using multiple OS processes to isolate web sites from each other and from the browser itself." Emphasis mine.