A Mozilla Desktop Environment?

Andreas writes "A discussion at the mozilla.dev.planning list has given the birth to the idea of a Mozilla Desktop Environment. This sure sounds like a possibility for Mozilla as it already has many of the applications needed; and the company is thoroughly familiar with XUL, which is a more-than-potent language upon which to build a desktop environment. By building a desktop environment Mozilla wouldn't have to worry about drivers (and such) and could choose from a variety of kernels, and still be in the center of attention. Mozilla has to expand some of the applications for this to work, though, like adding local file management with Firefox."

Comments

I have an idea

[Bob54321]

Why don't they just pool their web browser, e-mail client and calender application into one big package. That would be a great start...

Re:I have an idea

[jonbritton]

I think it's a great idea. Mozilla would make a great OS.

All is needs now is a decent web browser. *ducks*

Re:I have an idea

[adiether]

This very much could be a step in the direction they already took.

Before they shipped browser, email client, calender, HTML editor, and all the core technologies to support it.

Now, instead of shipping a browser and the core technologies to support the browser, just ship the core technologies. The browser could simply be an extension you can install if you want it.

Re:I have an idea

[sankyuu]

Not a bad idea! Mozilla would be the Emacs of browsing.
Vi users can stick to lynx.

=)
/vim user

Re:I have an idea

[AKAImBatman]

Mozilla would make a great OS.

First off, it's not an OS. It's a Desktop Environment. ("Graphical Shell" in old skool parlance.) The Desktop Environment goes on top of the OS. Which could be Linux, FreeBSD, or even OpenSolaris.

Secondly, it's not that crazy of an idea. I've played around with the concept a bit myself. Both through the HTML engine and the XUL engine. The HTML engine makes more sense for "thin" (or "rich") applications that are downloaded on the fly and communicate with a server. The XUL makes more sense if you want a heavyweight desktop that can integrate with the X11 framework. Programs based on the XUL/XPCOM framework would use XULRunner to launch. All neat and tidy; though a bit of a pain to develop XPCOM interfaces between Javascript and C/C++.

The concept works because X11 is about as flexible as you can get for a desktop system. All you need is a Window Manager that recognizes standardized messages and Atoms (the X11 kind, not the Mozilla kind) and you can position, place, float, stick, minimize, or maximize any window you want pretty easily. So you throw a taskbar window out there to track the other windows, throw a start menu applet on there, have a file-browser application stuck as the Desktop, and you're pretty much ready to go.

XPCOM is even reasonably complete enough to where it provides services similar to the NeXT/Cocoa APIs. They'd need to be extended some if you wanted to support access to the complete environment (especially fixing that mess they have for File I/O), but it's a very workable base.

Re:I have an idea

[Seumas]

So is it a desktop environment? A Window Manager? A bloated shell on top of a bloated desktop environment? Why in the hell would I want a Mozilla desktop environment over Gnome, KDE, XFCE and others which have been doing a great job for a long time?

Here is what I want my browser to do: Browse the internet.
Here is what I want my email client to do: Handle email.
Here is what I want my FTP client to do: Transfer files.

Just make a good fucking browser and stop trying to branch out.

Re:I have an idea

[Excelsior]

Just make a good fucking browser and stop trying to branch out.

No kidding! Good thing Apache stuck to what they were good at after they made the httpd.

Oh, wait, they went on to make dozens of other great products. My bad.

Re:I have an idea

[Crayon Kid]

This very much could be a step in the direction they already took.

Doesn't have to be. Actually, this idea has already been done, and done beautifully. It was called OEOne Homebase Desktop. It was a complete desktop environment built on XUL, and incidentally "XUL desktop environment" is the appropriate name for something like this. "Mozilla" is either the foundation or the former browser suite built on XUL. XUL is the platform.

So, you can see what the OEOne desktop looked like if you search Google images for oeone or oeone homebase. It was a fully integrated environment, which means mail, calendar, contacts, browser, text processor, image album, music and video player, basically everything you'd need for your basic office/home desktop.

OEOne still appears in the Mozilla Hall of Fame as such, even though they renamed themselves Axentra.com at some point. The Homebase desktop still appears in their press releases up to 2002, then it was released as open source as the Penzilla Desktop and abandoned as far as OEOne was concerned. But while it ran it also sponsored a few other developments, such as AbiMoz, which integrates AbiWord inside Mozilla.

Homebase wasn't a "traditional", "generic" desktop, but more of a specialized environment, aimed specifically at office productivity and entertainment. It had a "home page" which aggregated news, weather, contacts, new mail and whatnot. It would have been ideal for PDA's. I never understood why it was so poorly publicized and why it seems to have missed so many trains.

Re:I have an idea

[Walter Carver]

It's very very different. A Firefox extending analogous to the Apache extending would mean to include a Mail client . But Firefox is an evolution (not a necessarily good one) of the Mozilla Suite, so it would be like going backwards.

Re:I have an idea

[Paulrothrock]

But did they integrate Tomcat with httpd? Of course not. GP is saying that they shouldn't integrate a browser with all the other things they're making.

Re:I have an idea

[Tim C]

Yes, they went on to make dozens of other products (some great, some not so great), but what they didn't do was make them all part of (or modules for) httpd. I can use Tomcat standalone, or with httpd, or IIS, or any other web server. I can use anything from Jakarta without having to install httpd; httpd isn't trying to manage my desktop as well as serve my files, and so on.

No-one is suggesting that Mozilla shouldn't create their own desktop environment if that's what they want to spend their time doing - I personally would question the sense of it, but that's up to them. However, they certainly shouldn't make it part of Mozilla (or Firefox) or even an extension to it, which is essentially what was being suggested.

Re:I have an idea

[AKAImBatman]

But did they integrate Tomcat with httpd?

Yes, actually. It's shocking to me that you don't know that.

The mods usually do a pretty good job, but when it comes to this topic it would seem that they've all been on crack. :-/

Think of the memory

[I_am_Rambi]

Think about the memory usage. Firefox struggles enough, think about running a full desktop environment. I won't until some of the memory usage comes down quite a bit.

Re:Think of the memory

[Clazzy]

To be fair, most of the memory issues in Firefox are because of the way it keeps previously visited pages stored so they can be quickly opened again. Unless their text editor/email client/whatever acted in the same manner then it shouldn't be too big an issue.

In my opinion, Mozilla should really leave this kind of idea to other developers. Songbird developed by itself just fine and I'm sure after this idea's been mentioned there will be other random developers toying around with the idea. Firefox and Thunderbird are good but attention should be focused on them before moving on to bigger, wilder ideas.

Re:Think of the memory

[Azarael]

The memory footprint would likely be a lot smaller if all of the desktop apps were using the same libraries. The real question is if it would be as functional as KDE and Gnome.

Re:Think of the memory

[adiether]

Flawed logic.

Given
-Your machine has lots of memory
-Firefox uses lots of memory

False assumption
-Firefox's base technology is a memory hog.

Could be more accurate
-Firefox scales well.

Ever run Firefox on a Linux box with 64MB? Its still snappy and very usable. Firefox seems to do a decent job at scaling back its memory usage. But if you have the GB of memory, why not let Firefox use it? Every run Minimo? It runs on handhelds.

XUL DE?

[SirTalon42]

XUL is already blamed for a lot of the speed issues with Firefox, why would I want the DE to be even slower? And why would Mozilla do this other than to try and get more attention? Do they have any ideas that are different enough from the existing environments (like KDE and GNOME or even enlightenment and XFCE) that they need to make a NEW environment?

In all honesty, unless Mozilla Corporation/Foundation has an actually INCREDIBLY AMAZING NEW idea that CANT be done with any of the existing DEs this is probably the stupidest ideas I've heard in a LONG time.

why

[mastershake_phd]

What are the goals? How will it be different? Or are they doing it just to do it?

Oh no! Don't do it!

[HomelessInLaJolla]

Quote:

I'm only proposing that we make a desktop environment, the same thing that KDE and Gnome, are. I can understand the desire to make everything XUL from top to bottom but, unless they have completely fixed (not improved--fixed) all possible bugs in the browser, their efforts are better directed elsewhere. Unless they plan on replacing the X11 system then it would be better for the community (as a growing whole) for them to maintain a diverse and working relationship with the existing groups. Cross-pollinate--don't assimilate.

The only reason I mentioned a "Mozilla OS" is because we'd probably also want to release distributions for one of more specific kernels as a whole OS Most distros have Mozilla packages. Is this a proposition for another distro?

other applications built with the Mozilla platform available then. Currently there are plenty of kernels to put a Mozilla desktop environment on. That's really the point. Unless they plan on making a true MozillaOS, converting all the middle layers of the OS into a ROM chip, and putting MozOS in the boot sector then, again, the efforts of a project are best spent improving code, debugging, and interfacing with the other prominent community projects.

Maybe we need to remind ourselves of the trials, tribulations, and pitfalls of both cruft (old junk) and feature creep (glitz and glam just for the sake of glitz and glam are neat--but they don't make for a good project path until it's stabilized).

Don't bother clicking links...

[Anonymous Coward]

The link which masquerades as being informative is to the submitter's website. It is no more informative and filled with just as much random conjecture as the summary here. And you get the thrill of seeing ads.

The Google Groups link is a dozen or so messages from a handful of people. It's a thread of "I like XUL and I think this could be a neat idea but there's no special work being done on this."

This is an article about something being possible, a something which has been thought of a hundred times before.

Breaking news!!

xul would be the new vbs?

[Felonius Thunk]

Ok, I'm no moz dev, though I loves me some Firefox, but didn't we learn not to mix our browser and desktop scripting languages before? What is there about this arrangement that would not be screaming for holes to be found and malware to creep across boundaries? It could be very cool, but it could really suck bigtime, too. Where do you want your file system to go today?

Deja vu

[HomelessInLaJolla]

Why don't they just pool...That would be a great start I feel like we've been here before. :-)

Not necessarily

[EmbeddedJanitor]

It depends on where the bloat is coming from. Potentially using common components/shared libs could reduce bloat relative to having mozilla browser + kde + gnome apps, each of which need their own bloat libs.

If history is any guide...

[pushing-robot]

10 Create web browser and email client.
20 Merge applications into single suite.
30 Steadily add programs and functionality to suite until it does everything badly.
40 Announce innovative new project to create simple, lean apps that break up bloated suite.
50 GOTO 10

Re:If history is any guide...

[Anonymous Coward]

Error in algorithm.
line 50 should be:
50 GOTO 20

Re:If history is any guide...

[Anonymous Coward]

GOTO 10 represents the memory leaks.

Re:Oh no! Don't do it!

[SirTalon42]

XUL is too slow to make an entire DE. Can you imagine a desktop environment WRITTEN IN JAVASCRIPT?!?!?! (or technically emca script?) My god, thats one freakishly scary (and slow, and memory intensive) desktop environment... I think it would make the people running XFCE and enlightenment scream, and the people running blackbox, rat poison, and other tiny WM head's explode.

And don't forget that on *nix XUL uses GTK's widgets... I can see the OOM Killer going wild already!

Potentially too much like javascript/flash...

[RyanFenton]

Don't get me wrong - I like the idea, and think it could work really well for the environments that will support Firefox across its (potentially unlimited) lifetime, but it seems to greatly overlap with javascript/flash. Each is practically limited to either specialist uses, or else work as least-common-denominator products for the potential Firefox environments. That means a lot of sprite games with simple interactions, graph and UI effects in popularized widgets, web portal software, and even the occasional spyware exploit finding a way to mark a user's trail. There will be ports of simple software from other environments, but limited interaction with the outside environment (by design), being chained to a time-limited browser session, and lack of the easy ability to really exploit the running environment will severely limit what toys and tools can really be created.

That's why I've taken a liking to Eclipse recently - it takes a nice set of the fast-development architecture of java development, and allows them to be used by C/C++, Python, and others cross-platform. Has anyone started working on a really nice integration of Eclipse into a Firefox plugin?

Ryan Fenton

XUL

[Bluesman]

I've done a bit of stuff with XUL.

It's great if you want to do things like, say, a custom web browser or write your own iTunes -- The kind of thing that you'd usually write as a web-based app but you need local file storage and maybe access to online content that cross-site scripting preventative rules would prevent you from accessing in a regular browser.

If you need to do more than that, it's quite a chore. You have to start writing your own XPCOM components, which you'll have to compile on each target platform separately. There goes your easy cross platform compatibility.

The documentation for XUL and XPCOM isn't very helpful or well organized, and that's putting it nicely.

Language support is thin. C++ and Javascript are pretty much your only choices, although Python support is coming soon, apparently.

The question is, if you were going to develop a desktop environment from scratch, would you start by writing XUL? Would you then extend that by embedding JavaScript? I don't think so. Both Gnome and KDE tried the whole component thing with CORBA and abandoned it for performance and complexity reasons. Cross-platform is nice, but Java, GTK+, QT, and even C# provide better cross platform benefits with greater support and language compatibility than the XUL suite of tools.

Not only that, but I'd wager a Java desktop environment would be a better performer than one based on XULRunner. Not to mention, it would support more languages through Jython, JNI, etc.

It's a shame, because XULrunner could be a great platform. I hope they focus more on documentation and supporting other languages than redundant pie-in-the-sky projects like this one.

Re:XUL

[SirTalon42]

"Both Gnome and KDE tried the whole component thing with CORBA and abandoned it for performance and complexity reasons."

Actually KDE came up with KParts, which are used all throughout KDE. In fact, Konqueror is pretty much just a universal KParts viewer (which feeds the KParts info from KIO-Slaves).

Re:XUL

[Bluesman]

KParts is an excellent example of what I'm talking about. KDE previously tried something like XPCOM, found it to be overkill and too complex for what they were doing, and came up with KParts instead, a much simpler, better solution. But it's not even close to doing what CORBA tries to do, (and that's a good thing).

Comparing XPCOM to KParts will give you an idea of the insanity of this proposal. Heck, just comparing the documentation for the two is evidence that the XUL desktop is a non-starter. From this page

When the KDE core-developers realised that Corba was becoming an unmanagable nightmare, they wrote in a few days a lightweight and efficient component technology to replace it: KPart.
KPart is based on Shared Libraries. This makes the component appears directly as a C++ object. There is no need to wrap its features with an IDL language, everything is accessible without extra effort.

What I'm guessing is happening is some guys started working with XUL, thought it was pretty cool, and said, "Hey! We could make a WHOLE desktop environment out of this if we wanted to!" But just because you can do something doesn't mean it's a good idea. There's plenty of history here to back that up, too.

It's also possible that XPCOM itself is a hindrance to the Mozilla project. Have they realized the assumed benefits of using a component architecture? Not when I can only write for their platform in maybe four languages, if we're being generous.

It wasn't that long ago that CORBA and DCOM were new and exciting, people were running around talking about how you could assemble standard applications like word processors that pulled components from "all over the Internet." It never happened, because quite frankly, it's a stupid idea for desktop apps. Not everything needs to be a distributed application.

XPCOM came along at about this time, and I'm afraid it's still around more because it's a holdover from that era than because it's a good idea. There are benefits to using a component architecture, but the much simpler KParts, QT, or wxWidgets approaches have those same benefits, are much more usable.

The bloat comes from Mozilla itself.

[Anonymous Coward]

If you've got both Seamonkey and Konqueror installed on your system, browse the same set of sites with both. Make sure you disable caching for both, to prevent such caching from inflating each browser's memory usage. Also start from a raw X session, just to further eliminate any sources of inconsistency.

I just did that sort of a test on my Linux system, visiting a variety of sites (Slashdot, BBC, Tom's Hardware, FSF, Digg, etc.) with both Seamonkey 1.1.1 and Konquerur 3.5.5. I've also used Opera 9.01. Checking via top, I see that Seamonkey currently has a virtual memory image of 357 MB. Konqueror, on the other hand, is using a rather minimal 43 MB. Opera is just over Konqueror, at 45 MB. As this is the total size in virtual memory for each process, it also includes the overhead of any shared libraries.

So from those results, I think it's safe to say that there's a major problem with Seamonkey. Both Konqueror and Opera manage to keep their memory usage within reasonable bounds. As for the cause of Seamonkey's excessive memory usage, I can't say. It could be due to memory leaks. I'd guess it's partially due to their extreme overarchitecturing of their software. Regardless, it's a troublesome issue for them.

Ick

[Anonymous Coward]

XUL seems like a decent enough idea to begin with, but in practice it's horrible. Anything more complex than your average browser extension, and it really starts showing its design weaknesses. It's buggy as hell too. That last point is particularly difficult to emphasise properly. It's buggy as hell. It seems like a natural step from the web to cross-platform desktop applications, but quite frankly, you are better off using your favourite scripting language and whatever bindings you can get to Qt/Gtk/whatever.

They keep pushing back XULRunner further and further - the first "stable developer preview" is a year old, there's no sign of the next version, and half the APIs available in the preview are obsolete. If it weren't for Firefox committing to it, everybody would have admitted it was dead already. Songbird? Democracy Player? Yeah, those projects are really zooming along development-wise *rolls eyes*. How about you build the simplest little MP3 player that actually works properly before thinking about anything as ambitious as a desktop environment.

I love the idea of XUL, I really do. But its only got one implementation, which totally sucks and is the kiss of death to almost everybody using it. I can't imagine the suckitude of an entire desktop environment built on top of it. I genuinely believe that if XULRunner doesn't get some gigantic improvements, it will eventually drag even Firefox down with it.

Huh?

[Orange Crush]

I thought the whole point of Firefox was to create a slimmed-down-yet-extensible browser that wouldn't suffer from the "kitchen sink" mentality that plagued the Netscape/Mozilla suite in the past. Sure, I guess it's possible to do a whole XUL based desktop environment . . . but why??

(and yeah, I know the same logic of Firefox --> d.e. bears similarities to the GIMP --> GNOME, it just seems odd to me to go through the massive effort required when there are so many simpler options to do mostly the same thing these days.)

Mezzo Desktop Environment & Symphony OS

[Gavin86]

I remember searching for such a Desktop Environment a year or two ago after experimenting with XUL, I ran across Symphony OS (http://www.symphonyos.com/) which uses the Mozilla platform for rendering and applications. It is called the "Mezzo Desktop Environment" (http://en.wikipedia.org/wiki/Mezzo_%28desktop_env ironment%29), and is available in Debian package format.

I remember testing a live-cd of symphony about a year ago and it seemed pretty intriguing. I really liked the desktop interface.

But anyway, from what wikipedia says, the Mezzo Desktop Environment is an incomplete platform (whatever that means), and if it is correct there appears to be work unfinished. However, anyone interested in contributing might want to take a peek under the hood and see if that project can be helpful and exactly what is "incomplete" about it.

Symphony OS

[Anonymous Coward]

This project http://www.symphonyos.com/cms/ seems to have something of the same ideas. Their GUI is simply based on FF.

Reminds me of SymphonyOS

[reybrujo]

SymphonyOS is a Linux distribution which uses a special desktop based in a browser.

not a good idea

[Anonymous Coward]

Lets look at history so we don't repeat ourselves... Microsoft thought that embedding IE into windows (and when I say embedding I mean fusing together with no hope of separation) was a great idea but it turned into a disaster for security and to some extent usability. Now I do realize this is coming from a different angle, where a browser is going OS instead of an OS going browser, but in my mind, as far as security goes, local and non-local should be kept as separate as possible. Closely integrating the two is just asking for problems. You learn history so as not to repeat it.

Is this Mozillas answer to Vista?

[CrAlt]

Is this Mozilla's answer to Vista? Who ever can use the most ram and CPU power wins?

If they are serious

[netdur]

They wants to talk to GNOME people about GNOME 3

quick take

[mrtexe]

Let's look back in history. Dr Dos/Quarterdeck tried to create their own desktop environment, Desqview/X. Then Novell tried it with Dr Dos and WordPerfect. It didn't work because OS was not core to their business, and the desktop OS business is far more competitive than what they were used to. Overall this is a very bad idea. Mozilla makes middleware, not client OS components. If Mozilla does this, it may unfortunately be the iceberg that hit the Titanic.

Didn't Netscape want to do this 10 years ago?

[lord_mike]

I believe the project was called WebTop... it would have been a desktop environment that could run on top of any OS, and applications could be written for it using it's API... allowing the creation of totally portable applications and, if done right, making Windows essentially irrelevant. It was a revolutionary concept and was aimed right at the heart of Microsoft.

Unfortunately, Netscape was in the crosshairs of Microsoft already, and with the company losing money like crazy, WebTop never saw the light of day...

Until now!

Thanks,

Mike

Did that. It was called "Mozilla"

[Animats]

We've been through this already. Remember Mozilla, and how it turned into bloatware, then had to be slimmed down for Firefox? Rmember how XUL was going to be a "platform" that would make Netscape into a Microsoft competitor?

Then there was XPCOM, the Mozilla answer to Active-X, Microsoft's bad idea.

We don't need another stupid "platform". If you want to run programs in the client, we have Javascript and Flash for the simple stuff, and Java for more complex tasks. Cross-browser compatibility, even.

Re:Oh no! Don't do it!

[AKAImBatman]

Good grief. The whole lot of you need a good whack upside the head to straighten you out.

• XUL is not that slow. I don't know where you get this idea, but it's performance is more than acceptable for pretty much any GUI you might make. I don't recommend writing a video game in it, but that should go without saying.
  
• ECMAScript/Javascript *is* slow. However, it's also just glue code. The time it takes to shunt a button press from the Javascript system to underlying C/C++ code is negligable.
  
• Despite the slowness of Javascript due to interpretation (which is a feature, not a bug), it's more than fast enough to run a lot of applications. The FireFox GUI, for example, is a Javascript application sitting on top of the XUL/XPCOM system. Yet no one complains that their button presses are too slow.
  
• Java is definitely NOT slow. I'm not going to open this can of worms again (you can search my 5,000 other posts on the topic), but I am going to point out that your example is so much FUD. JavaOS didn't fail because of its GUI, it failed because it wasn't a very good system. In fact, it wasn't actually a full desktop system. More of a rich client type of thing. Which is why the JNode folks are working on a fully modern OS written in 100% Java. Including the kernel and drivers.
  

Byzantine Linux -

[ami.one]

Byzantine has been doing this for the last few years. Not bad to use. Surprisingly, even though it uses mozilla as a desktop it has much less memory usage than almost all other distros. And opening a browser is always instant on since it's already in memory. http://byzgl.sourceforge.net/old-index.html http://byzgl.sourceforge.net/wiki/index.php/Main_P age

Learn to Write Extensible Software FIRST

[Baby Duck]

Why not? I'll tell you why not ... if the desktop environment is anything like developing Firefox extensions, it'll be a piece of crap.

1. Why, oh why, when I install an extension, it merges XML configuration with several other files? Do you know how hard it is to manually take all that crap out if the uninstall works (which it often does)? And still leave Firefox stable? Didn't they learn ANY lessons from Windows Registry Hell?

2. To make this "your configuration is scattered and merged with other VERY IMPORTANT FILES" phenomenon worse, why are they linked with GUIDs? GUIDs?!?! So now, if I want to uninstall "Craptastic Extension 0.7", instead of searching for "Craptasic", I have to find out what its GUID first and then hunt down instances of the GUID. Thanks a lot.

3. RDF. Ugh. Wouldn't a domain-specific XML schema have been better. I find RDF too abstract, not human readable, and contrarian to many of the design goals XML was supposed to bring in the first dang place.

4. Inconsistency of layout structure across extensions. How is this possible? The too-open-endedness of RDF. When I first tried to learn how to develop a Firefox extension, I decompressed the archives of four of my favorite popular extensions. To my dismay, the severe differences in project layout structure from extension to extension didn't allow me to see any pattern. Because the RDF can make anything point to anything, the individual developers could just layout all the directories however they damned pleased. Constrast this a Java project organized by Ant and you'll want to scream.

5. Look at Eclipse, ffs! Now THAT is how you build extensible software! Consistent. Clean install. Clean uninstall. No Registry Hell. No &$^#ing GUIDs. No RDF as obfuscated as a bad Perl or Lisp program.

OEOne Desktop

[unapersson]

This was already done a few years ago, there was a company that did a complete desktop environment based on Mozilla. I was sold as a kind of appliance PC for the living room.

Here's an article on it (from 2002).

If I remember correctly that was where the original calendar code came from.

Re:StarOffice

[Arimus]

No no and thrice no.

The OS should have one and only job IMHO (or not so HO): Manage and control access to resources.

The desktop layer and even the command shell should in an ideal world be divorced from the underlying OS core layer. And taking this one stage further if a common OS interface API (something akin to POSIX) existed I should be able to take core-OS and put whatever GUI or CLI (yes CLI is still better for some tasks) I like ontop of the base layer.

The base layer can then concentrate on running the hardware, preventing rogue programmes from compromising the rest of the system etc - ideally:

core-os --> [sandbox 1] --> [desktop gui] --> [sandbox for each app]

With the user/admins being able to define very tightly which files can be shared between sandboxes. Programmes which interact heavily with other programmes could run in their own sandboxes...

Summary is wildly misleading

[Anthracks]

I know this is Slashdot and all, but the article summary is grossly misleading. This is a public newsgroup. A random person, not affiliated with Mozilla, posted a message saying "hey, you guys should make Mozilla into an OS!!"

Mike Beltzner and Stuart Parmenter, who actually work for Mozilla, respond by saying "no, that idea actually sucks".

Somehow, this makes it onto Slashdot as "ZOMG Mozilla is making an os CONFIRMED!!!!!111oneeleventy!!11" Please stop spreading ridiculous, baseless claims.

Re:GET RID OF X WINDOWS

[Fordiman]

I dunno. The protocol, far as I can tell is fine. The implementation, at least the standard X server, is a POS.

Meanwhile, some of the purpose-built X-servers do a good job. X-Glx with Beryl makes Aero look like ass. KDrive is light enough to fit on a floppy. X-Ming is a great tool for porting X apps to windows.

Also, your demands for an end to X-Windows based on a story about Mozilla Desktop Environment is kinda dumb; MDE would run atop XWin, just like any other DE.

'course, you're just trolling AC, so you don't care about things like facts; just so long as you get a rise out of people. Once again, normal human + anonymity = rabid idiot.