Redefining the Operating System | Hacker News Reader

Redefining the Operating System

whydoeseverythingsuck.com

23 pointswhalliburton19 comments

There already is a term for what the browser is becoming:

http://en.wikipedia.org/wiki/Operating_environment

Why are people arguing? Instead of applications running on X or in bash, they run in the browser. No need for arguments, or redefining anything.

p.s. I actually came up with this term, and then googled it, and found out that it already existed :D

"Standing on the shoulders of giants" is the phrase that comes to mind when people say that browsers are the new operating systems.

I helped my neighbor by replacing IE and its default home page of MSDN with Firefox and google and adblock plus and bugmenot.

The next day he was super happy and his exact words were "Wow, it's like a whole new operating system!".

I was glad to help, found it a bit funny how a non techie gets the terminology all mixed up, but I didn't think anything of it.

Until today, now I'm thinking that a whole lot of people really do see the browser as the OS.

When the day comes when it doesn't matter if the user gets the OS, the disk, the browser, and the computer confused, then designers and programmers will have done their job correctly. (And it never happens because they never see these distinctions and don't have to care.)

Right now, the only computer that approaches this is the iPhone.

Too bad this language argument is covering a more interesting point made by one of the two critical articles linked ( http://www.drama20show.com/2008/09/02/chrome-hype-when-non-t... ):

Lots of incremental revenue to Google?

Like Google Docs, which Arrington last year wrote was “tearing the Office wall down”?

Or Google Checkout, which Arrington called “Google’s roundhouse punch to PayPal”?

The fact that Google gets 97% of their revenue from advertisement really puts the impact of all their releases back into perspective. Their browser is a welcome improvement on the browser market, but this might not be such a game-changing event.

And to put my comment into perspective now, I'm not better qualified than all these people blogging about Chrome and Google web applications in general; just noticing that desktop (compiled) software still sells. I would be very interested to see a global comparison between the revenues brought by the sale of software as (web) services and the sale of desktop software. I have a feeling Microsoft Office alone might bring more money than all web companies, though I would be glad to be proved wrong by actual facts :)

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.

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.

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?

Scheduling. It looks like the Chrome process is really a kernel of sorts for the tabs.

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.

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.

Addendum, directly from the design docs, 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.

It's running JavaScript apps which brings up a lot of these issues. Read a little about the history of Firefox and it's memory management and security issues and you can see why they built Chrome. Chrome can gracefully handle a buggy JavaScript application without failing vs. the Firefox issue of one tab locking all of the rest of them. etc.

PS: I don't think browsers are a true kernel but they are getting a lot closer. I am going to wait a few months for chrome to work the major bugs out and then try it.

It handles scheduling as someone said, but it also uses Google Gears which is file system management...right?

Chrome is not trying to be the operating system, it's trying to get out of its way. By using a shared-nothing separate process for each tab and plugin, it's letting the Kernel and libc do the job they were designed to do.

Most modern browsers (especially FF3) are trying to do an operating system's job — scheduling logically independent processes, micro-managing memory allocations, mapping virtual memory, providing an internal windowing system, providing an internal GUI scripting system.

Chrome does none of these things. It parries them off to the real operating system, where they belong.

Hank Williams gets it right. The article at drama20show (which thamer links) looks on the surface like the kind of pedantry that tries to show how smart you are by showing how dumb everyone else is. By this narrow definition that limits the OS to just the kernel, neither Windows nor Linux are OSes. They each include an OS, but they also include one or more desktops and standard applications. Actually, the fact that there exists a distinct word for the kernel - that would be "kernel" - is probably evidence that there's a basic problem with the narrow definition.

BUT ...

This is all just another pointless semantics argument. It fails to see what's really going down here: Google wants folks to write their applications for Chrome. Not for Windows. Not for Linux. Not for Solaris. For Chrome. That's the point. And that's interesting: they want the platform for writing applications to be their browser.

Whether this means you can now call Chrome the operation system is beside the point.

I believe when people call the Browser the new Operating System, and the web a Platform, it's all about perception.

"Operating System" means something totally different to a lay person than it does to a Computer Scientist. Business will normally follow the lay person's perception if it helps marketing campaigns.

Here's what I believe, since business drives I.T., eventually the scientists may have to change their definition of the Operating System to agree with the perception of the public. Alternatively, the phase may be given different meanings with one being it's technical definition. Polymorphism :)

It should be acceptable to have the phrase bare both meanings, this is how language evolves, and develops.

OS are going to evolve. Some will see it as a regression...

Me I'm an old school, I like my apps running under my palms and not on a buzz word (The Cloud...) Having say that distributing and sharing are great features (of The Cloud).

I suggest a compromise. A virtual OS, like the blackberry! An OS that its entire API will be run on a virtual machine. It's like killing the middle man. Instead of writing a kernel and VM that will talk to its API, write a VM that directly talks to the hardware.

By doing so we can achieve a stable, secured OS which enable fast app development.

There are some open source projects out there that are trying to prove the concept...

Perhaps the YouOS folks were a couple years too early?

Reply on news.ycombinator.com