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

[that this is not und]

They could call it.. oh, I don't know... SeaMonkey!

Of course, add a WYSIWYG HTML editor to the list above (why do people always forget that??)

Re:I have an idea

[pembo13]

Great idea, and we could call it Mozilla, or Seamonkey.

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

[JackieBrown]

But what would Debian call it? Icewm is taken.

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

[Seumas]

Yeah, no kidding. This is why I dropped Mozilla and switched to Firefox/Thunderbird years ago. I want specific applications that do one or two things very damn well. You know, kind of like the linux/unix philosophy. The last thing I want are the guys at Mozilla trying to design my whole desktop experience. Just because it says "Mozilla" doesn't mean I'm going to hate it any less than when Microsoft tried this crap.

Re:I have an idea

[Anonymous Coward]

Hmmm... all they need to do is allow hot-loading and unloading of extensions, and push more of the fundamental firefox / thunderbird / etc. code into extensions.

Desktop is the base - a window running a desktop extension.
Web Browser opens a new window running in the same process, but a new thread, of the firefox extension. ....

Naturally, extensions would have to be capable of controlling the UI... and any other sub-extensions... which really puts them on a level above extensions.

Oh, and of course, security preventing the Browser view from touching the File view. And session support so that a crash of the Browser view, which by nature of the single-process system crashes the Desktop view, can be restored quickly.

OK, this is starting to sound like a complete rewrite significant portions of the system. Maybe they should just do a universal viewer running different processes for each action - one for File, one for HTTP, one for FTP, etc. Copy KIO-slaves, imitation is the sincerest form of flattery, right?

Or just distribute everything as separate processes, each with a different UI for a specialized task, and only able to do that one. Ignoring the memory requirements.

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

[dreamchaser]

Orrrrrr...they could try something truly radical like making the browser a browser and the desktop a desktop.

This is yet another idea doomed to fail. Stick to making a better browser and email client please...k?

Re:I have an idea

[AKAImBatman]

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?

Choice? The entire point of OSS is to provide choice. If you don't like it, don't use it.

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

The Mozilla Platform is a platform first, a browser second. That's why it took them so damn long to develop it in the first place. Modern web technologies actually demand that web browsers be application platforms. Mozilla takes it one step further by being a flexible platform for local applications as well as rich client applications.

When you look at FireFox, you see a web browser. But in truth, that is incidental. All you're really seeing is a XUL-based application. Which is why there are other popular applications like Thunderbird, Composer, Mozilla IRC, SunBird, etc. Should Mozilla also focus on making those applications the best Email/HTML Editor/IRC Client/Calendar applications and forget the platform they're developed on top of?

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

[neersign]

XFCE is the only one of the "big 3" that doesn't have "official" apps that Mozilla provides. It would make much more sense for Mozilla to contact the XFCE team (or vise versa) and work together to integrate Mozilla products in XFCE. I understand that Linux is all about being free to create whatever you want to, but at some point people need to say "there is already a base available, let's use it and expand it" instead of thinking the wheel needs to be reinvented from the ground up.

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

[jimjamjoh]

I actually downloaded and installed Homebase onto my RH8 machine back in '02 and remember being surprised at how very functional it was. It was still raw, but they'd build a good suite of XUL applications, including a media player, etc. It took some doing to get it into my XDM config, but that was the only setup it required, and everything else worked mostly as advertised.

It was mostly a novelty, FAR ahead of its time, but I disappointed at being unable to find its remnants a few months ago when reminded about it after playing with various "Web OSes".

I'm glad to see Mozilla re-investigating this idea, I think it's perfect for a deployment into a Call Center or similarly-specific environment.

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

[Anonymous Coward]

OMG. Look at this, I read your post and then opened Opera on the same pages firefox was using, Opera uses 4 less MB of memory! I am impressed, I should switch to Opera so I could save a shitload of memory! (Fun fact: Opera was using 97% of my CPU at the same time as I was typing this on firefox!)

Since I am just a memory freak and my bandwidth is fine I just reduced firefox's cache from 50MB to 10MB... Yeah, the "tonzors" extra MB firefox's memory usually takes over other browsers is actually a feature... that you can tweak. So could we please stop spreading BS? Thanks.

Re:Think of the memory

[JimDaGeek]

Think about the memory usage.

Do you mean like MS Vista?

I would much rather have a cross platform desktop environment that lets me run on Mac, Linux and MS Windows than some MS-Only desktop programming model. I run all three OS'es I listed. The only one I have problems with from a cross plat-form programming perspective is MS Windows. Gee, I wonder why? Can you say lock-in?

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.

Re:Think of the memory

[Anonymous Coward]

I am running Firefox on a machine with 256 MB of memory. The beast regularly soaks up so much RAM that it becomes unresponsive, and needs to be killed from the command line. With a handful of tabs open after a few hours browsing, I switch back and try to type something in the URL address field, and it puts up about 1 character every 5 seconds. If I try to backspace over a character, there is a 20 sec pause of furious thrashing, obviously the "backspace" text entry code uses an entire different library or something that needs to be swapped in.

Galeon is not much better.

Opera is significantly better. It never gets so big that swapping back in takes a long time.

To tell you the truth, the Mozilla / Firefox team has burned a lot of reputation with me over the last two years. I used to think that they were the heros of the open source movement, the one group that had made significant headway on the desktop and among the Windows using masses, and was of the opinion that all open source projects ought to be immitating them in every way.

Now I saw fuck them. I groan everytime I do an update and see a new firefox package coming down -- not just because it's 50 MB, but because now my web experience will be even more hosed.

The Firefox guys need to stop accepting new code until they clean up and massively trim down the existing code. If a desktop project is needed to lure away a lot of the people who wrote the current shit heap, maybe we should support it.

Re:Think of the memory

[Anonymous Coward]

pfft. Mozilla needs to do one big thing: stop developing their browser, and actually improve what they have. There are lots of issues they could take up, but most important is performance. The performance just sucks, especially around AJAX. Memory leaks (gotten better), security (a audit anyone?), and please, split off gecko from Mozilla, so that its a separate library. Having everything in one codebase is the source of most problems with Mozilla, they need to learn to develop things separately.

Just imagining a Mozilla DE gives me the creeps, i cant stand to even use their browsers (sadly, i cant find any khtml based browsers that are available outside of KDE/QT). Thats face the facts, Mozilla is about as good as X was before 7.0 in terms of quality, one big codebase that no one wanted to develop for, but had no choice.

Re:Think of the memory

[Anonymous Coward]

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.

That cache is cleared when you close the tab. If you open a new window and close all the other windows, all such caches are cleared. It IS leaks/"bloat". (Bloat is defined as memory that isn't leaked - there are still pointers to it - but it is not going to be touched again).

Re:Think of the memory

[FromellaSlob]

and please, split off gecko from Mozilla, so that its a separate library.

That would be XULRunner. Firefox 3 is planned to use it.

Re:Think of the memory

[Anonymous Coward]

It's 2007. You have 256MB of memory. You could double your memory for free by digging in the dumpster on the street. Quit complaining and upgrade.

Re:Think of the memory

[modecx]

That would be XULRunner. Firefox 3 is planned to use it.

They really should have picked a name that doesn't cause anal bleeding upon pronunciation.

Re:Think of the memory

[Anonymous Coward]

What he is saying is that Firefox uses a lot of memory -- no matter how much memory you have.

Re:Think of the memory

[Anonymous Coward]

zool-runner... seems easy enough to pronounce to me.

Re:Think of the memory

[pionzypher]

Absolutely. FF running with 5-10 tabs, after three or four days gives me a memory usage of 628 megs. No fracking way.... They should concentrate on fixing those memory leaks before pushing out.

a desktop/shell replacement that uses 3 gigs of memory just doesn't look that appealing to me.

Re:Think of the memory

[MikTheUser]

Ever run Firefox on a Linux box with 64MB?

Not quite, but I'm running FF2 on a Sun with 64MB of RAM on Solaris 9, and it crawls.

Re:Think of the memory

[Anonymous Coward]

i cant find any khtml based browsers that are available outside of KDE/QT

Er, Safari? ABrowse? Or did you mean "on a specific platform (that I'm not going to mention)"?

Re:Think of the memory

[IAmGarethAdams]

Yes, and the counter-point is... so what?

RAM is designed to provide faster access to data than from disc. If you have RAM not being used, then you're probably losing efficiency (loading things from disc which could be in RAM. Firefox should be able to ask for as much RAM as it needs, up to the maximum available. It's up to the OS to a) allocate the free memory it can spare and b) ask an application to free up memory if the memory is needed for something more immediate.

What it seems Firefox does is mismanage and lose track of the RAM it asks for, so it ends up swapping a lot more in and out of the hard drive and fails to free up some of its own memory.

Just using a lot of RAM isn't a bad idea at all, in fact that's the point of RAM

Re:Think of the memory

[pkulak]

"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." Then it must keep them forever, because after a couple days, Firefox is using over half a gig of memory on my machine.

Re:Think of the memory

[Anonymous Coward]

It might be too close to Yul Brynner for his liking.
http://en.wikipedia.org/wiki/Yul_Brynner

Didn't I hear something about this

[Pikoro]

like 8 years ago. Mozilla was working on a netscape "explorer" replacement or some such...

Moooooohzzzillllaaaaaa !!

[Anonymous Coward]

Moooooohzzzillllaaaaaa !! Moooooohzzzillllaaaaaa !! Moooooohzzzillllaaaaaa !!

this is not the time to be slap happy

Yes, but will it run

[Anonymous Coward]

Windows? Could this be a viable replacement for explorer.exe?

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.

Re:XUL DE?

[MightyMartian]

I've been hearing this "the desktop's right around the corner" since the days of Netscape 3. I've also been hearing "you'll be writing platform independent apps with this language" for about the same amount of time. Let's just make believe for a second that Mozilla could deliver some sort of desktop soon. It would still be years behind KDE and Gnome, which still have very little market penetration compared to Windows and OSX.

Re:XUL DE?

[Chineseyes]

I couldn't agree more as someone who has developed two strictly web based XUL apps for two different companies I'd like to see a few things happen first. 1.) XUL documentation is spotty at best xulplanet is a great resource but when I wrote these apps around the beginning of 2005 or so there were huge gaps in knowledge on refreshing data in several different element types. Getting a real time list of data from a Postgres Database and loading them into listboxes was a huge PITA because certain functionality was just gone or not working in version xyy but it would supposedly be back in version xyz. 2.) Ever try loading large amounts of data into an XUL element? Please don't. I had to load 10,000 rows of data into a grid element horrible idea. It is slow and required an insane amount of memory. When we scaled it down to 5,000 rows of data it was just as bad. I won't even get into refreshing that same data. 3.) Someone anyone please create a COMPLETE IDE for XUL it is begging for one there are 2 or 3 where the authors sort of started and then just abandoned a few months later.

Re:XUL DE?

[Anonymous Coward]

Exactly. A JavaScript-XML desktop environment? No thanks!

JavaScript-XML is just about the the most retarded way possible one could entertain writing a desktop environment. (Well, except maybe one in Java might be worse.)

The bloat of XML and the instability and insecurity of JavaScript have no place as the basis of a desktop environment. I bet you could write a more efficient desktop in Perl. Though C/C++ is just fine thanks.

Re:XUL DE?

[xtracto]

It is the Open Sores syndrome, it is way cool to start a new software project but when you have to maintain it because it is a bug beast it is always better to just start another project!

Ah that and documentation writing. That is the difference between Open and Closed sores

why

[mastershake_phd]

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

Re:why

[feranick]

They would do it simply because they can. It's the Microsoft idea of "since other do it, let's do it". I don't think it's a very good idea, actually. They should stick with what they know best.

Re:why

[charlieman]

They would do it simply because they can. It's the hackers idea of "it seems like a challenge so let's do it". I think they can do whatever they want with their time and efforts. Something good has to come out of this, even if it is "now we know another DE is unnecessary.

Re:why

[feranick]

The best challenge for them would be to fix the many bugs of Firefox, many of which are in the very same XUL engine the DE should be based upon. Better 10 mediocre project or a great one?

Re:why

[DerekLyons]

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

The primary goal of any organization is to survive and grow - it doesn't matter if the name on the door is Microsoft or Mozilla.

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!!

Re:Don't bother clicking links...

[rm69990]

That doesn't stop the majority of Slashdot posters from assuming Mozilla Corp. is working on this as we speak and proceeding to criticize them for it. I'm not sure who to blame, the submitter who didn't clarify that this is simply a bunch of messages and not an official Mozilla project, or the Slashdot posters who are too lazy to read the bloody article.

Imagine a world where Slashdot readers actually read BEFORE commenting...

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?

Re:xul would be the new vbs?

[HomelessInLaJolla]

screaming for holes to be found and malware to creep across boundaries Exactly. It's one thing to have a comprehensive software package--it's another thing entirely to blur the lines of the sandbox (which, inside the web browser, are weak enough to begin with).

I suppose the argument could be made that, with webapps becoming more prominent and virtualization being the hot new buzzword, there's no reason to delay the inevitable. If that were the case, though, then we should be looking to go back to OS on a chip.

Re:xul would be the new vbs?

[Drantin]

Except that we're not talking about making Firefox into a desktop environment; we're talking about making a DE based on the same engine that Firefox uses for it's GUI, that is the buttons and whatnot... It seems closer to the way Star Office used to be (or maybe still is? been a long time since I looked at staroffice...) having a desktop app, and then Firefox and friends would run inside it along with any other apps written for it...

Re:xul would be the new vbs?

[Tim C]

It seems closer to the way Star Office used to be (or maybe still is? been a long time since I looked at staroffice...)

I remember that, and like you, it's been a long, long time since I last looked at StarOffice.

That is pretty much the reason why. I utterly loathed that fake desktop thing. I already have a desktop, thank you, now stop trying to replace it and work with it just like every other application does.

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.

Re:Not necessarily

[Anonymous Coward]

Yeah, instead of loading libgnome and friends, libkde and friends, and libgtk2 and friends, we'd just be loading...

Re:Not necessarily

[Anonymous Coward]

The Mozilla code is bloated by design, first they have the Netscape Portable Runtime (NSPR) that has all the platform specific code, then you have Cross Platform COM (XPCOM) that has a lot of platform specific code, then you have the other components that has a lot of #ifdefed platform specific code.

It really is hacked together.

This is a joke right? riiight????

[protomala]

C'mon! XUL is the worse part of Mozilla/Firefox/Whathever!
It's bloated like hell (just run konqueror and opera and see how it compares to firefox), complicated to program.. and you want a entire desktop written with it?

Oh yes, what's next, a Java slowperating system? :)

And this...

[limecat4eva]

...is why I use Safari.

KHTML and WebKit win, simply put.

Just what we need

[SirGarlon]

More bloat! Yay, team!

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:If history is any guide...

[CamD]

10 Create transistors.
20 Merge components into single chip to reduce cost/size.
30 Steadily add functionality (software) to component until it does everything...poorly.
40 Announce innovative new components--simple and lean--that improve performance.
50 GOTO 20

Re:If history is any guide...

[CamD]

60 ???
70 Profit!

Re:If history is any guide...

[the_bard17]

In that case, we'd need a:
5 GOTO 70

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!

HomeBase?

[Anonymous Coward]

How is this different from HomeBase?

Hell no!

[Anonymous Coward]

One of the main reasons why I'm using Mozilla for webbrowsing is that it does not integrate with my desktop (beyond calling helper applications). The webbrowser is "the internet" domain, my desktop is the local domain. Any program which is designed to cross this line is an unacceptable risk. A Mozilla desktop environment would be a serious design flaw (and a violation of the KISS principle that made Firefox more of a success than its "full-featured" predecessor).

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

Re:Potentially too much like javascript/flash...

[Conception]

Aptana has a firefox plugin for debugging and all, but it's for web development. Don't know on the code specific side.

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.

Re:XUL

[Spy Hunter]

The Mozilla developers aren't enthused about XPCOM either. They're stuck with it as it's deeply entwined with the foundations of Mozilla, but if you read around Bugzilla you'll hear them talking about "deCOMtamination" work they are doing.

Re:XUL

[Paulrothrock]

So you'll take ugly Swing apps and merge them with ugly XUL apps?

That'll compete well against other operating systems.

Re:XUL

[paulkchen]

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.

XPCOM and XPConnect are what give XUL/JavaScript access to C++ code. I'd like to know how KParts can reflect C++ objects into the JavaScript engine "without any extra effort." If it's a hindrance to Mozilla, I think it serves its purpose well enough that no one has attempted the big task of replacing it.

Netscape realized the need for a component architecture, and one of the main requirements was the ability to utilize components from JavaScript. It was never meant to be an all-singing, all-dancing component architecture a la CORBA and DCOM. There was no existing technology to fill the need, so one was created.

Now, that doesn't mean people didn't go overboard and turn things that didn't need to be XPCOM components into XPCOM components. ;-)

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.

Re:The bloat comes from Mozilla itself.

[Anonymous Coward]

That, or you might be using KDE.

Re:The bloat comes from Mozilla itself.

[Anonymous Coward]

That, or you might be using KDE.

Which part of "start from a raw X session", and "As this is the total size in virtual memory for each process, it also includes the overhead of any shared libraries." did you find confusing?

Re:The bloat comes from Mozilla itself.

[Anonymous Coward]

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.

Holy crap. I knew Mozilla was bad, but to actually be beaten by Konqueror, which requires the KDE libraries, by almost a factor of ten?

I think everybody who has ever called KDE bloated owes them an apology.

Re:Oh no! Don't do it!

[HomelessInLaJolla]

XUL is too slow to make an entire DE Some people might try it as an exercise of their personal coding skill but I would hope that, as a whole, nobody in their right mind would standardize on it. I guess that's the problem: if someone (a developer) does it, and it catches on with the other developers, then the rest of us won't have much of a choice because, over the course of a year or two, there will gradually be just too many things which won't work properly unless they are sufficiently similar to the developers' systems.

Can you imagine a desktop environment WRITTEN IN JAVASCRIPT They tried it with Java and decided that the community had enough OSs. I've heard of C compilers written in shell script; similar concept and probably just as comparably slow.

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.

deja vu

[chamont]

Is there anyone out there that remembers Aurora?

Graphical CLI

[Anonymous Coward]

Mozilla XMLTerm was an interesting project, somewhat similar to a Common Lisp CLIM "Listener", though with XML instead of Lisp.

WTF am I talking about? the merger of GUI and CLI. Basically, a shell window where e.g. you type "ls" and the listing has thumbnail icons
that are clickable. Scientists familiar with Mathematica or Texmacs might "get" the idea, too - imagine that sort of UI applied to the whole OS.

http://en.wikipedia.org/wiki/XMLTerm
http://web.archive.org/web/20050207072807/xmlterm. sourceforge.net/
http://en.wikipedia.org/wiki/CLIM
http://userpages.umbc.edu/~hefner1/listener.png

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.)

I think it would be a good idea.

[Tiado]

It might actually work once it is developed more, and is implimented properly. Of course, even though it sounds like a good idea, once it is put to use, it might not be all that great. Another fear that I might have about a Mozilla desktop environment is that it might end up being really resource heavy like I find KDE to be.

I would probably give it a try, and then form an opinion from it. If it doesn't work too well, I would still be happy with the stand-alone brower and email applications that Mozilla makes.

Yeah!

[Anonymous Coward]

Yeah! Let's waste a lot of resources on reinventing the wheel!

Too lat ! We have ByzantineOS since many eyars !

[Anonymous Coward]

http://byzgl.sourceforge.net/old-index.html

ByzantineOS is a software Internet Appliance with a home entertainment bias. It is based on a networked Linux distribution/bootable system with Mozilla providing access to a range of services and applications.

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.

This idea isn't new

[Dracos]

I thought about how cool a Gecko-based desktop environment would be a few years ago, and I'm sure I'm not the only one to think of it. Literally, replace Qt and/or GTK+ with XUL+XBL. Probably not very feasable now, but since the 1.9 branch is moving to the Cairo graphics library, it would be a lot easier. With embedded Python support coming (and other languages soon after), no one would be limited to writing their app logic in C/C++ or Javascript.

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.

Re:not a good idea

[Anonymous Coward]

Mezzo isn't quite the same as Explorer + Active Desctop.

As I recall, they were switching to Xulrunner rather than firefox as Mezzo's core, a runtime to execute local xul/javascript, rather than a full-out browser. And there was also a bit about a small local server running on the desktop, listening only on lookback, to provide allot of the funtionality.

My understanding of it was that its not about having a browser integrated into the desktop (hence the choice to use Xulrunner), but that it'd be interesting to be ableto write destop applications with HTML/CSS/Perl/Javascript and even server-side scripting. Sort of a precursor to Adobe's Apollo.

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?

Re:Is this Mozillas answer to Vista?

[Duggeek]

Who ever can use the most ram and CPU power wins?

Nobody can beat MSFT for churn and bloat.

Nobody.

I got a better idea

[kindbud]

Mozilla is a company developing many of the most popular applications you can find, including the popular Firefox browser and mail client Thunderbird. A discussion that started a few days ago on the mozilla.dev.planning list has given birth to the idea of taking all this one step further by building a complete Desktop Environment, like gnome or KDE.

Instead, why not work in making your browser take hints from the existing desktop like all other well-behaved desktop apps do? Then I don't have to apply a separate theme to my Mozilla browser so it looks like my desktop.

Jesus Christ on a Pogo Stick! (with bong hits) How about that? Ya think?! :-/

Been done before

[Anonymous Coward]

OEOne
http://www.ofb.biz/article.pl?sid=93
and the fork Penzilla
http://sourceforge.net/projects/pendesktop/

If they are serious

[netdur]

They wants to talk to GNOME people about GNOME 3

Re:If they are serious

[Anonymous Coward]

Mod this up,

Most people within Gnome have now recognised that the line between the web and desktop is becoming blurred... as your link says...

Or more simply- our biggest competition in the developer space is not Microsoft, and it isn't Apple. Our biggest competition in the developer space is php, rails, and the web client-server paradigm. C# and Java are great, but as long as they are pretty wrappers on the same style of development we've always done, they are lipstick on a pig. We need to take the plunge and fundamentally make development more web-like while also leveraging the strengths of the client, or else we really are in trouble.

• 
         
• So, what's the constructive takeaway that became clear to me at GUADEC? Our developer platform (really, any developer platform that wants to be relevant in 3 years) needs to be:
         
• braindead easy to start with: if you can't have an app running in an hour, you're in trouble. 80% principle applies here- the rails people say 'we don't care if you can't build Amazon with rails'; we should probably say 'we don't care if you can't build evo with g-rails.' If we can't make developing a desktop app as easy as a web app, people will develop web apps. Simple as that.
         
• dead easy to ship, deploy, and update: probably impossible to be easier than the web here, but we keep saying 'apt is better than windows install tools', which isn't relevant- that's like saying your car is better than a horse and buggy. Might be true, but the web's install/use experience is a formula one car. You must beat that, not the horse and buggy. This is something I'm sure others have realized forever but I never did.
       
• building a collaborative app must be easy: I have been using writely instead of abi at work because I can trivially and transparently collaborate with my co-workers. The development platform must have collaboration as an easy-to-use part of the platform or the web will wipe us out on that feature alone.
         
• easy/powerful integration with search: search is really just the canonical example, for me, of things that are easy do across a desktop but which are hard for, say, GoogleOS to do. Obviously google can make it easy for me to search across all google properties, but never (or at least painfully) across flickr, delicious, etc. Our development platform should make it trivial to automagically instrument your files and let beagle know about them.
         
• easy/powerful integration with hardware: another thing desktops can do well and web apps can't- our platform should make it easy to take full advantage of webcams, microphones, etc. Of course, like many of the other things on this list, this goes way beyond GNOME, but we've done that before, and must keep doing it. [Ed.: added later. I knew I'd forgotten something ;)]
         
• identify the web's weak points, and go after them: search is just one example of things that local, client apps can do easily that web apps cannot. Development platforms (and apps) should be brainstorming hard about all those things, prioritizing them by user impact, and doing them. Every advantage of things you can do that the web can't should be made trivial to develop and brought to users quickly.
  

The difference between GMail and Evolution Email shouldn't exist. Certain Gnome apps should move to becoming web services so that we can compete with these online apps. Access your home desktop should be as simple as browsing to it.

No, just no

[hedwards]

Unless it is meant to replace the Win XP or Vista window manager, no good can possibly come of this.
Already with Linux and the BSDs, there are too many choices, invariably at least a few things require Gnome on a KDE desktop or vice versa. Adding a third major WM seems just bad.

I like Firefox even though right now it is slow and crashes more often than the alphas did. But Mozilla really needs to stick with web stuff until they get that completely right.

Hey Moz-

[cadeon]

Instead of doing a Desktop Environment, do a whole OS.

Ok guys, go ahead and flame me, I know that's a bad idea for a variety of reasons - but hear me out.

Build an OS that runs on low-end devices and gives you nothing but a browser (with multiple profiles, perhaps, to allow multiple users). That's it, nothing else. Build the OS for, and perhaps the device for (Mozilla just may have enough money to do so), a real Internet Appliance. Yes, I'm talking about the things that have been tried many times in the past and have put several good companies out of business.

Why I am advocating doing it again? Well, things have changed. With a fully-functional browser you can do almost everything a full PC can do- thanks to Google apps and others. All the functionality that people look for in a low-end PC can now be provided via a browser. However, the hardware to make these things happen could end up costing significantly less than your run-of-the-mill Dell.

Heck, use the $100 laptop as a reference design, and make Google fund the OS development. The internet appliance can happen now, the technology has caught up to the idea. Make it happen. You'll sell tons of them to all the people who are about to retire.

Re:Hey Moz-

[Anonymous Coward]

"Build an OS that runs on low-end devices and gives you nothing but a browser (with multiple profiles, perhaps, to allow multiple users). That's it, nothing else. Build the OS for, and perhaps the device for (Mozilla just may have enough money to do so), a real Internet Appliance. Yes, I'm talking about the things that have been tried many times in the past and have put several good companies out of business. "

obviously you have not used the latest and greatest bloatware from mozilla. Low end devices are not something you would want to try running firefox in.

CSS on desktop applications

[Urinal Deuce]

Despite very relevant performance concerns, I certainly wouldn't mind being able to use CSS to style every applications look.

It's something I've been wishing for ever since I found Stylish for Firefox. I've tweaked just about every page I visit on a regular basis.

Re:CSS on desktop applications

[Uncle_Al]

I certainly wouldn't mind being able to use CSS to style every applications look.

Actually, for applications using Qt4 you can do just that ;-)
http://doc.trolltech.com/4.2/stylesheet.html

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.

Why?

[MBHkewl]

The real question is "Why?"
Why make another desktop environment, and yet another struggle for users to decide which GUI to use?

It would be much better if they donate their developer's time to successful GUI projects, like KDE & GNOME. Unless, they have in mind a lot of features that are worth implementing & can't be implemented in current GUIs, they shouldn't venture in that field, in my opinion.

Except...

[Brandybuck]

This sure sounds like a possibility for Mozilla as it already has many of the applications needed

Except for a window manager, file manager, task manager, session manager...

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

Browser/File Manager

[rueger]

Mozilla has to expand some of the applications for this to work, though, like adding local file management with Firefox.

Am I alone in finding it annoying to use the same app for file management and Internet browsing?

I know that Microsoft, Apple, and Linux have all tried to present a seamless universe of data and documents, but really they're two entirely different functions and environments, and for me at least they need two distinct applications.

Browser Integration

[mattwarden]

Integrate the browser into the operating system? Brilliant!

Re:Browser Integration

[BluBrick]

Integrate the browser into the operating system? Brilliant!

Don't be silly. Microsoft tried that and lost - well, not much really - a little momentum is all.
But never mind that, we want to do something (almost) totally new! We want to integrate the OS into the browser.
What's that you're saying? It sounds like you're saying... is it "eMax"?

Already been done...

[CTho9305]

...here (apps sometimes fail to launch the first time)

commercial consideration

[pbhj]

no i didn't RTFA but it sounds like a commercial consideration

beancounter1: we have loads of market share for our browser and mail client
beancounter2: yeah but we're not making enough dough
beancounter1: what if we leveraged our name and OSS credentials to push into the DE/OS market
beancounter2: i just wet myself ... don't know how they swing this to create a revenue stream but perhaps that move to mozilla.com went to their heads?

Re:commercial consideration

[Anonymous Coward]

Well, maybe you should have RTFA.

Some person unconnected with the Mozilla Corporation (and unconnected with any part of the Mozilla project) made a post on a newsgroup saying "hey, I think Mozilla should do this", some other person, also not connected with the project blogged about the newsgroup post, and then submitted it to Slashdot making it sound like it was Mozilla themselves discussing it, the Slashdot editors let the misleading article get posted, and then a bunch of people commented on it without RTFA.

Re:commercial consideration

[pbhj]

slashdot roxors!

OEOne Homebase?

[Anonymous Coward]

A trip in the wayback machine reveals... a /. article on an actual product. Maybe the nordicware pc guys can get a patent on their revolutionary new idea.

Sheesh, the kids these days...

Moznix!

[Grinin]

I would love to have a Mozilla based flavor of Linux as a desktop... and if anyone has the cash, and programmers to do it... Its Moz!

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:Did that. It was called "Mozilla"

[Anonymous Coward]

Well. although history is full of failed proposals, this one is still worth a try. Vista can be a resource hungry alternative.... Before such programs mature and debugged properly, they are replaced in the name of taste & style, if not due to hyped popularity. The functionality, however doesn't change much....

The irony is so rich...

[mad.frog]

...that this would be headlined the same day that Adobe Apollo is released in first alpha form.

Let's see, the similarities...

-- Cross-platform runtime? Check. (No Linux for Apollo yet but will be soon.)
-- XML-based UI description language? Check.
-- ECMA-based standard scripting language to drive it? Check.
-- Robust HTML engine? Check.

On the other hand...

-- High quality IDE for developing apps?
-- High quality video and multimedia support?

Hmmm....

Re:The irony is so rich...

[AKAImBatman]

-- High quality IDE for developing apps?

Check
 

-- High quality video and multimedia support?

Check

And now allow me to qualify those statements. :)

MozCreator is still in development. However, the desktop hasn't been developed at all. So there's not much of an issue there, yet. Also, you can always use a generic IDE environment like JEdit until MozCreator is ready. (Seriously? IDEs are overrated anyway.)

VLC is about as high quality as you can get when it comes to video and multimedia support. It regularly shows Windows Media Player the door when a user tries both of them out. And some work has already been done to integrate VLC as a Mozilla plugin. Not that such a plugin is necessary. VLC would run on such a desktop system as-is. The only reason to bother integrating them is to create an embedable media player ala the GStreamer APIs. (GStreamer is also overrated.) Or they could just integrate with GStreamer and be done with it.

So there's no inherent blocks on either of those fronts. And if a Mozilla desktop were really to be created, you can be sure that additional tools and APIs would follow. :)

Robin

[davidroe]

Robin - Remote Operating System Built in Netscape
Created By: Randall Knutson
Version: 0.02

Note the version number, and I don't think it is actively developed, but Robin appears to be someone's pet project that runs a remote desktop written in XUL/HTML/JS/CSS.

I've worked a lot with XUL, but am starting to think that perhaps GWT is a more sensible approach to developing web apps. To present a web front end, XUL on it's own doesn't cut it, as the masses do not run a Mozilla browser, but maintaining XUL + HTML versions side by side means twice as much work.

here's a bad comparison:

[mathfeel]

Remember when we cried fault when an OS/Dekstop maker (name rhymes with micro-golf) decided that since it is doing so well in desktop environment, it'd go into the browser and media player segment? Is this not the same situation in reverse (besides the non-free and monopoly part, of course). My point is this: do one thing, do it well.

It's called Linux

[Rank_Tyro]

And it's being done right now.....

Re:Oh no! Don't do it!

[Anonymous Coward]

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.

Yes, and if this could be made to fit into an ARM based "PC" with no local storage other than a small amoutn of flash and internded to run only web apps, at about 100 USD without a display, it may be a hit. It even could have a local web server for the desktop and most basic apps (talking clock applet and note taker here)

That MAY be a a hit.

I look at Firefox on Linux and

[towsonu2003]

I expect this environment to be slow like a duck. Can't they just fix the browser first?

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.
  

StarOffice

[comp.sci]

I remember when I used StarOffice and it opened its wonderful complete desktop-solution for each file I wanted to edit...
The idea itself sounds great, but why add yet another layer of abstraction? It's the OS's job to provide the desktop and be able to run smaller subprograms to do all your tasks.

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...

don't see the point

[Jessta]

Mozilla is massive. But if you take in to account the factor that a webbrowser is open most of the time on the majority of computers it might not be much of a hit in terms of resources.

But I just don't really see the point.

Excellent!

[Anonymous Coward]

MORE fragmentation is exactly what the OSS scene needs! That way, when MS sweeps you all away in ten or so years, it will be easy. Like a Blitzkrieg! Thank the OSS clowns for their foolishness and stupidity, for it means that all of this crap will be GONE SOON!!! Long live Windows! Long Live BSD!

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

Better idea for Mozilla

[Khyber]

If I were to take on a project like this (which I never will,) I'd start with eliminating all drivers, if possible. I'm sure we can write wrappers with some loss of performance, but after a couple of years, the technology will re-mature and the market will slow down to take advantage of not needing to develop their own drivers and makes sure their hardware is compatible with the software that's running the system. Kinda like the PXE environment. Drivers are natively-stored (or loaded from some obscure ROM in RARE cases) and ready for network booting/reimaging/etc all without windows/linux needing to be installed and configured. I think it's time to develop a faster BIOS and then hard-link the hardware to it's control, not the OS's control. Perhaps this is feasible with EFI, but I'm not so sure with BIOS.

Mod Parent Up

[mad.frog]

Too bad you posted as AC.

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.

Re:Learn to Write Extensible Software FIRST

[Rakishi]

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? What do you mean, most extensions seem mostly self contained in where they are stored. The only thing they may store in other places are preferences but those aren't that much of a problem. I have yet to see any problem with installing/uninstalling extensions.

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. I'm assuming it was to prevent conflicts, they're allowing other ways of naming now so its a moot point for new extensions.

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. Part of this is that they change the format once in a while to make it easier but some extensions still use legacy formats. How exactly were they different, I've found most to have a generally similar structure.

Re:Learn to Write Extensible Software FIRST

[Anonymous Coward]

I posted on Ben Goodgers blog about the UUID thing before he introduced it. My comment back then was that they should allow extensions their own XML namespace. That said, I like XUL and ECMAScript4 with JIT will be fine for building apps. The problem is XBL and XPCom, the stuff of nightmares.

Re:Learn to Write Extensible Software FIRST

[Anonymous Coward]

1. What XML configuration? Nothing is merged (except for extensions.rdf, but it's not configuration, but a file with extension metadata, which will be rebuilt automatically from install.rdf if you delete it).
2. GUIDs were supposed to make name collisions unlikely, but Fx 1.5+ allows IDs in form of {name}@{company} (and previous versions allowed it to, it just wasn't advertised).
3. True, but it's mainly the pain of application developers, not you (user/extension developer).
4. RDF has nothing to do with it. In eclipse you can name your class whatever you like and reference the chosen name from a manifest. "Oh my god, eclipse is totally not extensible?"
5. Ah, a Java person. Die, seriously.

Re:Learn to Write Extensible Software FIRST

[anaesthetica]

"Love heals scars love left." -- Henry Rollins

Are these lyrics to a song in particular (if so which one), or are they just something he said?

OT: Azureus and CPU/memory usage

[Daengbo]

Hell, I've got 2gb and it's not even enough for Zend + Azureus at the same time.

That's because Azureus is a pig!. Try TorrentFlux. Install a web server (you already have Zend, so I'm guessing you're set up on that point) and install TorrentFlux. I even tried Azureus headless with the web interface, but my "server" hit loads of 1.0-2.0 any time I had more than a couple of torrents running. Now my server never runs over .20, even when I'm saturating my connection.

The feature set is great and it's extendable. Look it over.

Would it run on top of Windows ?

[S3D]

Windows users, who are intimidated by Linux, but willing to try some alternative, professionals who have to use win-only applications may welcome such kind of cross-platform desktop. It would make transition to Linux more accessible. I'm also waiting for KDE 4 for windows. Especially interesting question - will KDE 4 work on Vista ? Would it make Vista really usable ?

Adobe Apollo ?

[BuR4N]

Sounds abit like Adobe Apollo http://labs.adobe.com/wiki/index.php/Apollo

Re:Oh no! Don't do it!

[HateBreeder]

Which is why the JNode folks are working on a fully modern OS written in 100% Java. Including the kernel and drivers.

How are they going to pull that off?
Don't you need a Java VM to run Java code?
So if the kernel would be the first thing ran on the system, where would it get its VM?
Seems like a chicken and egg problem...

Well Im waiting for...

[mikek3332002]

the Emacs Desktop Environment.

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.

Obligatory question

[MadJo]

But will it run on Windows?

Please do your research

[synopsis5]

Come on, people!
This was just a newbie brainstorming on one of the newsgroups. He probably has no idea, what entails a Mozilla-based OS or desktop environment and he probably will not make it happen. And for sure all serious Mozilla developers have better things to do, than doing the 10th incarnation of a desktop environment.

So relax, get a good coffee and learn to do your research before you post.

too many usability bugs

[midnighttoadstool]

Until mozilla sorts out the dire usability bugs under windows any talk of desktops should be stopped, since they will surely fail on windows, and if you fail there then you have really failed.

I've recently returned to IE with the release of 7 because mozilla makes me tear my hair out.

One of the most annoying problems is mozilla's clipboard problems. I've looked it up on their bug lists and these problems have been there for ages, with no one doing anything about them. And don;t tell me to fix it myself: I wouldn't have a clue.

So much for the merits of Open Source.

I like this idea

[DeBaas]

A few years ago when I created the proof of concept for the SimPC: http://hardware.slashdot.org/article.pl?sid=05/01/ 13/0033206 we discussed creating the desktop based on XUL. It has a few advantages. The main advantage from my viewpoint is that XUL can also be a remote application. For something like the SimPC that means you can easily change the desktop for all users, and after relogin, they would have the new desktop. Just keep a rudimentary desktop localy that is loaded if the network is down.

I think for organisations that want to control the desktops of the people working for them this would be a powerfull feature. Most users just need a few apps. And with a remote desktop that could easily be managed. Probably a lot better than the roaming profiles of MS.

And I don't think it would actually create much bloat. Most people use firefox anyway, so Gecko will be loaded anyway.

There is an old saying started from EMACS...

[Walter Carver]

...that every application evolves till the point that it sends mail. Well, now every application evolves till the point that it becomes an OS!

So typical...

[Anonymous Coward]

1. Post a stupid suggestion, which has been posted many times before, on a planning mailing list of an open source project.
2. Submit the thread you started to slashdot
3. ???
4. Profit!

Marketing wise...

[arthur5005]

this would be genius. Now I have to agree, any sort of major move to change interface in web browsing would require the current browser to be nearly bug free. Although consider this; from what I've been experiencing in the IT Business world of things, entire businesses are beginning to run nearly strictly on web interfaces. The company I work for (Telus) major telecom in Canada, is as we speak, finishing a MAJOR migration to a strictly web 2.0 interface for all their interfacing of Central Office switches, and port assignments (internet and phone).

Imagine what kind of stir this would be in the operating system market, if you could run your business strictly on this web interface, that's incredibly sleek looking, and incredibly stream lined. Personally, I think it's a great idea, I'll be honest it's 2007 and I'm sick of clicking the back button.

Re:Oh no! Don't do it!

[AKAImBatman]

It's not, "How are they going to pull that off?", it's "How are they pulling that off?". The system may still be in development, but it is very much up and running. It's not all that difficult to imagine when you realize that they wrote the JVM and the JIT in Java, then self-compiled the JVM using its own JIT. Link in a bootloader and a few hundred lines of assembly for hardware-access routines, and you have an executable OS for running Java. Feel free to download the source and see for yourself.

So, presumably...

[Anonymous Coward]

They'll be forced to release a version of this desktop that doesn't come bundled with Firefox & Thunderbird?

I mean, fair is fair, right?

Overreaching

[clang_jangle]

Pretty ambitious for a bunch of people who can't even get it together to provide a binary of their flagship browser for BSD.

I just don't see it.

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:Summary is wildly misleading

[evilviper]

A random person, not affiliated with Mozilla, posted a message saying "hey, you guys should make Mozilla into an OS!!"

Deja Vu!

This time it's an OS instead of an Office Suite, and for some reason, overzealous CNet reporters are nowhere to be found...

What's the plan for javascript performance?

[Anonymous Coward]

Some sort of optimizing JIT compiler for it?

It's bloody slow as is, I have a fast computer and with 10 tabs open, web 2.0 starts to show it's nastiness on the whole damn machine.

Brain fart

[Anthracks]

I meant Simon Paquet, not Stuart Parmenter. The rest of my post stands.

Would be EMACS++ then

[tenco]

FMACS = Fivehundred Megs And Continously Swapping

It's been done

[Ed Avis]

Netscape tried something like this ten years ago. I think it was called Aurora and was to be a desktop environment - I saw some screenshots in Byte magazine of the time. Eventually it shrivelled down to some browser extensions and was included in the original Mozilla Navigator source release in early 1998. You can still see the Aurora Overview on Netscape's 'future products' page - though the screenshots don't have much relevance.

The Byte article also mentioned that one of the head guys at Netscape had instituted a one dollar fine every time an employee called Netscape a web browser. 'It's not a web browser, it's an operating system!'. This was very soon before Netscape's downfall at the hands of Microsoft.

Bad idea if they don't change some things.

[Pedrito]

First of all, don't get me wrong: I use Firefox as my primary browser and I love it. I use IE for a couple of sites because I have to, but I hate it. But there's one glitchy thing in Firefox that I think goes beyond firefox and could have a pretty big impact on a desktop environment based on Mozilla.

The glitch is that, in my case, I have a good number of bookmarks. My bookmarks.html file is 560K. I know that sounds a bit excessive, but I have a single folder that has about 150 booksmarks, each to a specific page of data that I sometimes need access to and since each page has an MD5 checksum in hex as part of the page name, using a bookmark keyword isn't very feasible...

Okay, but anyway, I digress. The issue is that when I hit the bookmarks menu item, there's a 30-40 sec pause the first time while it parses the HTML. Now, if this kind of thing is regularly used for data management by a Mozilla based desktop, then you can expect equally slow responses. So this is one small thing that needs to get fixed before they need to be doing a desktop based system. I want my desktop responsive. And frankly, I'd kinda like my Bookmark button to be responsive, but I'll live with it.

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.

good idea, so much to do.

[chdig]

Straight up, at it's base, this is a great idea that will likely come to fruition in the future. Why?

Look at how many web developers are out there! If a browser OS (a real one, where the scripting was html/javascript/Flash interacting with a server just like they do for websites) existed, it would be the ultimate playpen for web developers and designers, people who already spend their time being concerned about user experience. If it existed, I'm sure most advanced web developers would salivate at the chance to write desktop apps.

But what's needed to make this work, which hasn't been talked about?

- a version of XMLSocket for HTML (ie the Flash socket-connect API which allows a Flash app to remain constantly connected to a server, negating the call-response requirement of AJAX)
- a local web server on the user's computer. In this way apps created in HTML/Flash could connect locally for their functionality. I don't understand why everyone seems to be forgetting that it's a "Browser", which is designed to work in a client-server manner using http.
- for desktop functions, a direct API between javascript and X is needed.

It just seems that most posters here don't understand the power and use of HTML/javascript/Flash, and are the same people that saw their java/VB apps die as much more efficient web-based apps replaced them.

The idea of a browser desktop is great, and it's also the future. Unfortunately, there's so much development waiting if it's to be done properly that it's still several years away from becoming a reality.

Those mozilla guys just like going after people

[Chris_Keene]

First they went after Internet Explorer....

Now they are going after Emacs!

does it interpret perl yet?

--
CJK

all i see is internet explorer in FLOSS form.

[Anonymous Coward]

I dont know about everyone else, but all i see is internet explorer in FLOSS form.

Netcaster Redux

[Anonymous Coward]

Back in the late 90s Netscape demoed a web based desktop using Javascript, Frames and Layers. It was dubbed Netcaster by the marketing monkey.

Peanuts vs. Batman

[HomelessInLaJolla]

Good grief

XUL is not that slow...I don't recommend writing a video game in it Given that the Mozilla/Firefox browsers have such an enormous codebase to be maintained and debugged would you recommend that the efforts of those developers be spent writing a window manager and DE based on it? My experience indicates that, for the greater good of the free software community, it would be wiser for them to devote themselves to perfecting their own code and cross-pollinating with the existing window manager and desktop environment groups.

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 I wasn't aware that the javascript contribution was as strong as this indicates though it does lend itself to an explanation of a large number of issues. Still, though, would you want a comprehensive network application such as a web browser to be directly integrated with the code and memory allocations which make up the display? Maybe if the comprehensive network application were bulletproof. My understanding is that the underlying structure of the javascript environment is too rickety to ensure that an application built within it will ever be bulletproof. Modern web browsers, IMHO, already have too much unrestricted access to the rest of the system. This can be configured away by the user but only at a severe cost to modern day functionality. Cookies are an illustration of this point: disabling cookies for an entire day would tank a normal daily network routine.

Which is why the JNode folks are working on a fully modern OS written in 100% Java. Including the kernel and drivers I appreciate that java, in and of itself, isn't slow but that the slowness is often brought about by layering the jvm on top of the already existent OS. The jvm environment reminds me of the BASIC interpreter which the beloved C=64 provided in that it works like a jit compiler. While I would be interested in working with JNode--in the same way that I'd be interested to work with BSD, Hurd, and AROS--I can't help but ask what java provides to modern day programming that C doesn't.

Re:Peanuts vs. Batman

[AKAImBatman]

Given that the Mozilla/Firefox browsers have such an enormous codebase to be maintained and debugged would you recommend that the efforts of those developers be spent writing a window manager

No. That is why you use a "standard" Window Manager like MetaCity. It's intended to do the heavy lifting of screen layout while the application instructs the WM according to the agreed upon protocols.

Given that the Mozilla/Firefox browsers have such an enormous codebase to be maintained and debugged would you recommend that the efforts of those developers be spent writing a DE based on it?

Do I think that the Mozilla developers should do it as a mainline part of the Mozilla/Gecko codebase? No. Do I think it should be done as a separate project built on top of the Mozilla platform? Yes. The latter does not necessarily mean a reduction in the developer support for the Mozilla codebase, and may actually attract new developers to working on improving the platform.

Still, though, would you want a comprehensive network application such as a web browser to be directly integrated with the code and memory allocations which make up the display?

I do not understand this point. The Mozilla Platform is NOT a web browser. The Mozilla Platform is a collection of desktop and web technologies that can be used to construct a web browser. Or a variety of other applications. This is no different than the Win32 or Cocoa APIs, both of which contain support for Web Technologies in addition to standard desktop technologies. Thus Win32 systems have Internet Explorer (based on MSHTML renderer), Cocoa systems have Safari (based on WebKit renderer), and Mozilla systems have Firefox (based on Gecko renderer).

My understanding is that the underlying structure of the javascript environment is too rickety to ensure that an application built within it will ever be bulletproof.

Your understanding is incorrect. Javascript/ECMAScript is a full language limited only by its APIs. For XUL applications, Javascript apps have access to the complete XPCOM library; an API similar in concept to Win32 or Cocoa.

As touched upon in a recent discussion on a Slashdot book review, the primary issue with Javascript is that the majority of those who think they know how to program in it, do not.

Modern web browsers, IMHO, already have too much unrestricted access to the rest of the system. This can be configured away by the user but only at a severe cost to modern day functionality. Cookies are an illustration of this point: disabling cookies for an entire day would tank a normal daily network routine.

First off, this is neither here nor there. Issues affecting a desktop web browser do not relate to a desktop application unless it choses to provide web browser services. At that point, the standard issues with accessing network resources apply. It is up to the individual application to find a method of dealing with network security. Just as it is up to any network-enabled Windows or Mac application to deal with network security.

I appreciate that java, in and of itself, isn't slow but that the slowness is often brought about by layering the jvm on top of the already existent OS.

Incorrect. Java has surpassed C++ in a variety of benchmarks. Anyone who has paid attention to Java within the last 7 years is aware of these benchmarks. (Example) While perceived performance problems exist (e.g. slow startup, "feel" of GUI, etc.) the Virtual Machine itself is actually quite fast by virtue of runtime optimizations.

The jvm environment reminds me of the BASIC interpreter which the beloved C=64 provided in that it works like a jit compiler.

The C64 did not JIT the BASIC code. It is well known

Re:Peanuts vs. Batman

[HomelessInLaJolla]

Do I think it should be done as a separate project built on top of the Mozilla platform? Yes. True. New projects are always interesting, exciting, and attract new talent.

The latter does not necessarily mean a reduction in the developer support for the Mozilla codebase, and may actually attract new developers to working on improving the platform With Enlightenment, Gnome, KDE, Beryl, and the whole of Freedesktop.org, though, I'd be worried that the desktop environment pool might become diluted. Free software hasn't established desktop supremacy with the consumer-at-large yet.

Javascript/ECMAScript is a full language limited only by its APIs I wasn't suggesting that it was limited. My understanding was that the implementations of those APIs were often buggy and left too many holes for possible exploit. I'll acknowledge that I've never actually programmed in it--I've only read about it and seen it in use on the 'net. What I've seen on the open internet, with the number of pages which don't port well from one browser to the next, the number of exploits allowed, the number of things which are flat out broken (and still deployed), I'm not encouraged about the robustness of JS. Maybe someone needed to solidify the underlying HTML implementation before they jumped into a JS implementation--but that was all part of the .com boom.

the primary issue with Javascript is that the majority of those who think they know how to program in it, do not. That's common with programmers in every language--including English. :-)

Issues affecting a desktop web browser do not relate to a desktop application unless it choses to provide web browser services My point was that the base of consumers-at-large have come to expect a web browser to provide underlying services, aka "seamless integration", mostly brought on by the corporate (mostly Microsoft) trailblazing in the name of embrace, extend, and extinguish. I do appreciate that even a monolithic web browser can be properly locked into its appropriate shell--at that point it becomes marginally useless to most people.

While perceived performance problems exist (e.g. slow startup, "feel" of GUI, etc.) the Virtual Machine itself is actually quite fast by virtue of runtime optimizations Okay, so where do those perceived performance problems come from? You've got to give something somewhere. It's not a hallucination.

The C64 did not JIT the BASIC code...the code was at no point compiled for native execution It was all the same. The interpreter was in the hardware chips and everything used the same core processor.

And I'm only scratching the surface You've posted quite a bit of advertising material but if I write a calculator app in both C and Java, and then independently translate each one to the other (hard to do if I've written both to begin with, but fake it a little), what's the difference in the compiled executables? That's what I'm after.

With all due respect, Mr. Homeless, information about the inner workings of today's software comes across as incomplete and nearly a decade out of date I think I've explained myself quite well. Maybe you're high.

Re:Peanuts vs. Batman

[AKAImBatman]

With Enlightenment, Gnome, KDE, Beryl, and the whole of Freedesktop.org, though, I'd be worried that the desktop environment pool might become diluted. Free software hasn't established desktop supremacy with the consumer-at-large yet.

Choice is the epitome of Open Source. Learn to deal with it.

My understanding was that the implementations of those APIs were often buggy and left too many holes for possible exploit.

Considering that most of those bugs are actually in the Win32 APIs, I'm not exactly sure what you're complaining about. Windows sucks? Yeah, we know that. Internet Explorer sucks? Yeah, we know that too.

What I've seen on the open internet, with the number of pages which don't port well from one browser to the next, the number of exploits allowed, the number of things which are flat out broken (and still deployed), I'm not encouraged about the robustness of JS.

This is an example of taking a complex issue (the general evolution of the web and web technologies) and blaming it on a single scapegoat: Javascript. Unsurprisingly, you're wrong again. What was semi-valid in HTML 3.0 is not valid according to the HTML 4.0/CSS standards. What worked in Internet Explorer thanks to non-standard & windows-specific extensions is not going to work in a general purpose browser. And what was programmed poorly to begin with (e.g. assuming that only IE would support feature X) is going to show through in more robust, modern browsers. Sorry, but the web is only as good as those who develop for it. And as I pointed out in my previous post, the majority don't know the first thing.

Okay, so where do those perceived performance problems come from? You've got to give something somewhere. It's not a hallucination.

Actually, that's exactly what it is. Perceived performance problems are performance issues that don't exist, but "feel" like they do. When a Java application refreshes the controls too quickly, it doesn't "feel" right. When a Java program shows an unpainted box while pulling itself from cache, it doesn't "feel" right. The underlying code and GUI systems are actually operating at a greater speed than their native cousins, but because they don't work the same they cause user frustration. That's a separate issue from the actual performance of the code.

The C64 did not JIT the BASIC code...the code was at no point compiled for native execution

It was all the same. The interpreter was in the hardware chips and everything used the same core processor.

Seriously, you don't know what the hell you're talking about. The C64 was a 6502-based system. The BASIC symbols were about as far from 6502 code as you can get. All they were was a transmutation of a symbol like "PRINT" to a code like "42". Obviously, the latter takes less memory. But you've still got to interpret it with "lda nextSymbol; cmp 42; beq PRINT_API;" type of code. Which is a far cry from a simple (and fast) "jmp PRINT_API".

In any case, your assertion that "the interpreter was in the hardware chips" is a non-sensical statement. The BASIC interpreter was preloaded into ROM. That effectively meant that it was always in memory. (Which is unsuprising given that BASIC was effectively the Operating System.) It did NOT convey any special processing capabilities any more than loading a Java program on a USB Flash Drive (i.e. rewritable ROM) JITs a Java program.

You've posted quite a bit of advertising material

I repeat, you are not up to date on the latest technology. What I mentioned was not "advertising material". It was real, quantifiable advantages that are used on a daily basis.

I write a calculator app in both C and Java, and then independently translate each one to the other (hard to do if I've written both to begin with, but fake it a little), what's the d

A hit

[HomelessInLaJolla]

It belongs on one of these.

Re:GET RID OF X WINDOWS

[Anonymous Coward]

*yawns*

You know, people have been screaming for the death of X since the late 1980's. Yet it's still here, and it still runs. AIGLX/Beryl kills the Aero interface, and can still be run over a network connection to boot.

Despite idiotic screaming, X is not the problem. And it's improving much quicker now than it ever has in it's history (except at the beginning).

0-day, TS and better, free!

[HomelessInLaJolla]

would require the current browser to be nearly bug free It's good that you recognize this mitigating factor.

businesses are beginning to run nearly strictly on web interfaces It's a security nightmare. Even at highly classified military subcontractors they're using webapps for timesheet maintenance. Who audits the code for the webapp? Next thing you know the new intern (maybe even a part-time temp-to-hire who came in just to handle shipping and receiving) has rooted the timesheet server, knows all the project numbers, knows all the project names, and knows who spends their time on exactly what--from the QA secretary up to the full bird colonel divison chief. Next thing after that the new intern has used their root on the timesheet server to spread a trojan to every client web browser which connects to update their timesheet--from the QA secretary up to the full bird colonel divison chief. Now they have a trojan and a keylogger on every employee's computer--from the QA secretary up to the full bird colonel divison chief. Top secret password mania posted the world over--using a few remailers, IRC botnets, and some obfuscated spam--by the end of the next working day! Zero day, totally 'leet, never before seen usernames and passwords to US military bases, installments, depots, CBW stockpiles, nuclear facilities, and technological research organizations.

Personally, I think it's a great idea While I understand your point of view from the ease of use and interoperability side I seriously don't think that the codebases involved are sufficiently bulletproof to be acceptable from the network security side.

Re:Oh no! Don't do it!

[Anonymous Coward]

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.

I do. Wait, no, I don't, I actually use Konqueror or Safari, instead.

I do use Firefox on Windows. Somehow, Firefox's GUI seems slightly snappier there, and I'd rather not deal with Opera's quirkiness for how little I use Windows.

Will XUL stabilize enough to build on it?

[Rob Y.]

As noted before, the OEOne desktop was an early implementation of this. I think it was originally written for a stand-alone appliance (OLPC, anyone?). At the time, it was considered a bit slow and incomplete. And, as I remember, there was some question about whether the XUL platform specs had settled down enough to make it feasible to keep this thing going, let alone to have 3rd parties attempt to target OEOne as a platform.

But having recently tried the Songbird demo, I think it may be time to take a second look at this idea. Songird is a new XULRunner-based iTunes clone, and it's pretty amazing in terms of its desktop app-ness.

XUL as a platform was always a great idea, but using it as a replacement for the entire desktop is bound to run into a chicken-and-egg omelete. Still, if they can build a nice cross-platform suite of apps that can run with or without an XUL desktop, it might take off...

Re:I have an idea!

[Anonymous Coward]

Or, team up with google for the googlzilla... err googlizard? desktop.

Re:Oh no! Don't do it!

[3choTh1s]

My only problem with speed on XUL is the startup times. XUL apps have been fine for me except for when you just start it up.

Meaningful is more readable than just readable

[neofreko]

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. ...and RDF has semantics where XML doesn't.

Firefox Slowness

[crucini]

Yet no one complains that their button presses are too slow.

Firefox's GUI is incredibly slow in places. For instance, if I invoke the File/Save dialog, there's a perceptible pause before a gray, empty dialog box appears; then another pause before it's painted.

After I click "save", the button depresses and stays depressed for almost a second. Then the dialog box goes back to plain gray, and lingers for several seconds before disappearing. This is absolutely ridiculous. I have no idea if it's javascript-related.

Flamebait

[HomelessInLaJolla]

Learn to deal with it This is flamebait and can be ignored. You're worse than MH42.