1.5-2 hours? I had an M12-pre build (the current debian package) up for at least 7 yesterday, and I've had it up for 2 already today with no sign of problems (and moderately heavy use). After 4 or 5 hours the memory-leaking starts to cause problems and slow the whole machine down with thrashing, but 2 hours is a very low estimate from my experience. It's already my primary browser ever since the M12-pre package came out, and at M12 or maybe M13 I hope to switch for email too - then all I need netscape for is SSL and Java!
I was worried by that comment too. I think that there is no reason that it shouldn't be possible to get a "perfect" use of each other's themes.
Note that *both* KDE and GNOME use theme "engines" rather than just pixmap hacks; the common myth that GNOME uses pixmaps is based on the fact that it's a lot easier to make a pixmap theme than to code a real one. So most people use the pixmap engine.
So, my theory is, why not write a Qt theme for GTK, which actually *invokes the current default Qt theme engine* which does all the work of making sure everything is themed correctly. You could of course do exactly the same thing in reverse and write a GTK theme for Qt which invokes the current default GTK engine. Then you could use themes for either and all your applications would look the same, regardless of which toolkit they were using.
You'd just have to be careful to never configure your system so that both these engines were the default for their respective toolkits...!
I read an article a year or so ago in one of those magazines (like SciAm or something... maybe even Time) about a guy who had a theory along these lines. His postulate was that in fact it was possible to *deduce* quantum mechanics from general relativity, if the restrictions were changed a bit. Nobody seemed to be able to do anything about this theory because it relied on mathematics that were far too complex.
As I recall, the explanation given was that if the restriction of strict causality were removed, then all of the "weird" counterintuitive behaviours of quantum physics could be explained by some state in the future affecting the present. For example, "tying", where two particles are linked and appear to have their outcomes linked together even though the information could not travel from one to the other without bypassing the speed of light, can be explained by postulating that the eventual outcome of the experiment on one particle affects the behaviour of the other particle *at the time they separate*.
He had some math that demonstrated that this theory was at least feasible, but doing accurate calculations was claimed to be beyond the math we are currently capable of.
Did anyone else read this article or know of the guy? This theory just sounded too perfectly elegant and intuitive to be wrong. I'd be interested in any information... has the theory been disproven, has any other progress been made on it, or has it just been substantially ignored? If anyone can give a URL to that story, I'd be interested to be able to re-read it, too.
Speaking of which, does anyone know when M10 will be packaged for debian? Everyone says that this one has *finally* reached the point where it is usable for real browsing, but the debian package is still sitting at M9, so I can't tell.
I agree that the only person hurt directly by Sun failing to "get it" is Sun. However, if Sun are hurt, then so are the people who use Sun's products. Most importantly - to me at least - are all the developers working with Java in the (mistaken...?) belief that one day it will really be an "open standard".
To me, the SCSL is an indication that right now, Sun's biggest hope is that it will never be open, but always controlled by Sun and Sun only. Kaffe, Japhar, Jikes and Classpath all provide hope of someday providing some legitimate competition, thereby taking "de-facto" control away from Sun. However, in the meantime, those of us who want to use a powerful, well-designed language like Java have no choice other than using non-free software - and worse yet, a closed "standard". Therefore, we are hurt.
I see this as a far more important issue than whether StarOffice is opened or not, because StarOffice will ultimately be out-competed by KOffice and GNOME workshop. Java cannot be out-competed anywhere near as easily, because the *standards* are controlled by Sun. Remind you of any other companies?
Their license is NOT open source except for this issue (interoperability). It is FAR from it. See below.
First of all, there is an EASY way for Sun to make Java open source and maintain compatibility, because they own the *name*. They can license the code, but only grant licenses to use the *name* java if you are compatible.
Secondly, there are such things as Test Suites. If Sun were even remotely serious about being "open", they would make their test suites freely available. If they did this, too, the compatibility thing would be a non-issue, because every news magazine and hacker would run the compatibility tests on every new JVM released - there would be no way to be incompatible without it being public knowledge *very* fast. As it is now, we pretty much have to take Sun's word for it that a JVM is incompatible (except for Microsoft, who boast about it).
There are at least two other issues apart from the compatibility testing issue where the license falls far short of open source. First is the fact that you are licensed to use the code only for research purposes; you can't even use it internally to your business without that being considered commercial use. Or give a copy to your neighbour. You *certainly* can't include it in your Linux (or xBSD) distribution.
Secondly, there is the matter of what you have to do to escape those restrictions. It's *not* just a question of "keep your version compatible, and pass a test to prove it". You have to get a whole fresh license from Sun, which you have to *pay royalties for*. It's not even just a nominal fee to cover the cost of testing (which is ridiculous anyway - see my earlier point about free test suites) but fully fledged license fees of the same sort as they were charging people for licenses before the SCSL came out.
If Sun were serious about being open, there is a LOT they could do. Don't be fooled by their blurb.
I'm almost certain that proxy support IS in there if you manually edit the prefs. This is a FAQ I see over and over again on the newsgroups, so if you try searching dejanews for it, you'll probably find what pref you have to set.
Wouldn't it be possible to do a perl-like thing and release it under the GPL along with another license? That way it could be a kernel patch on linux but other OS's could use it under whatever license they liked.
Also future enhancements could be shared between the two licenses.
Actually, the panel applets were the thing that wowed me with GNOME. That and the control center, which also appears to use pluggable corba components in the main body pane.
Sure, most of it was always doable with plain X (I remember having xload swallowed in my fvwm panel thingy years and years ago) but the point is that this corba-based architecture is going on *everywhere* throughout GNOME. I prefer to think of GNOME as an application framework, not a desktop environment. The panel and control center are just tools written to that framework. That's why I personally prefer it over KDE - KDE is currently the better desktop environment, but GNOME is the better framework... and the desktop environment on top of it will come with time.
The reason the poster (who was deliberately stating an extreme point of view) suggested people master Slackware before trying Debian, was that then they'd realise how easy they have it with Debian.
Personally, for me, the switch from Debian to RH was an unpleasant shock ease-of-use-wise, and the switch from RH back to Debian was another unpleasant shock ease-of-installation-wise. For ease-of-use (once you get through the install), Debian *CANNOT* be beaten - since 1995 at least it has been able to automatically update itself to use the latest packages, something I've never seen in ANY other operating system, and it includes everything you can possibly think of.
I was recently working on my debian machine with a co-worker, trying to set up a program, and a suggested step was "run smbclient with these options". smbclient: command not found $ apt-get install smbclient $ smbclient... My co-worker was dead impressed:)
I think debian is the ideal distribution to shrinkwrap - it provides the best underlying architecture I've ever seen, it just makes no attempt to hide the complexity of what you are doing. With Corel (hopefully) adding a nice installation interface specifically TO hide those complexities, we could finally get the perfect distro...
... because Debian doesn't even *have* Gnome 1.0 yet.
I think this is because they don't want to put it in with broken dependencies and figuring out the dependencies of gnome is hard... but still, we're talking about the "unstable" distribution here.
I'm longing to be able to show off an appropriately-themed gnome/e setup to my co-workers (they were reasonably impressed with E.14's ugly defaults and gnome 0.99.3's broken setup from the latest unstable I tried, but themes wouldn't work and I couldn't change the gnome window manager from icewm.
It sucks, because that was something that would really have wowed people.
I know that most people are against feature bloat in Mozilla, but I think this was possibly a very good idea. A strong case was made for it in the early "Unity of interface" paper that was referenced from the page, when it was up.
The reason I hated Netscape including AIM wasn't because of the bloat (apart from the truly stupid fact that everything else was an option in the installer, but AIM was compulsory), but because of the fact that it only spoke a single proprietary protocol. Having a generic client which speaks all protocols is IMO a great thing.
As for whether it belongs in Mozilla, I think it does, to the same extent that Mail and News belong. So long as they are optional, it makes sense to share the *huge* amount of common code (UI, HTML rendering, networking protocols...). Although most people consider the mail and news module code bloat (personally I like it and use it everyday), it's a telling point that the "navigator standalone" edition of netscape is at least 2/3 the size of the full product - in other words, the vast majority of the code is shared (unless you really believe that the browser-specific code is FAR more complex, and bigger, than all the rest put together).
As a final point, in response to the comments that "Mozilla should be concentrating on putting out a usable product" - exactly how many people do you think worked on this? The same applies to the Necko networking project, which has 5 people. A while ago everyone was following JWZ's lead in saying that the "30 or so" external contributors were "insignificant"... now it's a life-or-death matter if 5 or 10 internal developers work on something other than getting the first release ready?
Too right - I expected better of IBM, what with their recent open-source moves. Just imagine the press that would have followed an announcement from Big Blue that they were going to be developing MP3 technology...
I want to switch from Red Hat 5.1 to Debian, but I don't have time to break everything and spend days fixing it. How easy is it to make this sort of thing "just work"?
Probably my best bet is to install debian onto a seperate partition and mount my existing install within it... Damn, think I just answered my own question;)
The issue remains, though, for people who don't have a spare partition on their drives...
Stuart.
Your whole point is invalidated by one statement
on
New Mozilla License
·
· Score: 1
Your claim that "he attempts to claim credit by calling it GNU/Linux after the fact" instantly discredits your whole point.
The only "vital" part of what is commonly known as Linux that is not written as part of the GNU project is the kernel. The kernel is the heart of the system - but how useful is a heart without the rest of the body?
The name "GNU/Linux" is not an attempt to claim credit, but an attempt to have credit given where it is due.
Stuart (not affiliated with the FSF, and I disagree with Stallman on many other issues... but that one is simple fact).
This is amazing. Is this code dual-licensed, or will it be? (hmm... looking at the page it looks more like the current license is "WYSIWYG, YMMV, HAND.":) )
What I really, REALLY want to see is JavaScript hooks so that you can write scripts to access and modify CORBA objects, and Java RMI objects. Then, if GNOME has corba as pervasively as it says it does, the whole of GNOME would instantly become scriptable... and ditto for KDE 2.0 (from what I hear).
This is something that could really hit MS hard, because it's something they're just adding now (scriptability of everything through an object model exposed to VBs"crap"t).
1.5-2 hours? I had an M12-pre build (the current debian package) up for at least 7 yesterday, and I've had it up for 2 already today with no sign of problems (and moderately heavy use). After 4 or 5 hours the memory-leaking starts to cause problems and slow the whole machine down with thrashing, but 2 hours is a very low estimate from my experience. It's already my primary browser ever since the M12-pre package came out, and at M12 or maybe M13 I hope to switch for email too - then all I need netscape for is SSL and Java!
Mozilla is *awesome*!
Stuart.
I was worried by that comment too. I think that there is no reason that it shouldn't be possible to get a "perfect" use of each other's themes.
Note that *both* KDE and GNOME use theme "engines" rather than just pixmap hacks; the common myth that GNOME uses pixmaps is based on the fact that it's a lot easier to make a pixmap theme than to code a real one. So most people use the pixmap engine.
So, my theory is, why not write a Qt theme for GTK, which actually *invokes the current default Qt theme engine* which does all the work of making sure everything is themed correctly. You could of course do exactly the same thing in reverse and write a GTK theme for Qt which invokes the current default GTK engine. Then you could use themes for either and all your applications would look the same, regardless of which toolkit they were using.
You'd just have to be careful to never configure your system so that both these engines were the default for their respective toolkits...!
Stuart.
I read an article a year or so ago in one of those magazines (like SciAm or something... maybe even Time) about a guy who had a theory along these lines. His postulate was that in fact it was possible to *deduce* quantum mechanics from general relativity, if the restrictions were changed a bit. Nobody seemed to be able to do anything about this theory because it relied on mathematics that were far too complex.
As I recall, the explanation given was that if the restriction of strict causality were removed, then all of the "weird" counterintuitive behaviours of quantum physics could be explained by some state in the future affecting the present. For example, "tying", where two particles are linked and appear to have their outcomes linked together even though the information could not travel from one to the other without bypassing the speed of light, can be explained by postulating that the eventual outcome of the experiment on one particle affects the behaviour of the other particle *at the time they separate*.
He had some math that demonstrated that this theory was at least feasible, but doing accurate calculations was claimed to be beyond the math we are currently capable of.
Did anyone else read this article or know of the guy? This theory just sounded too perfectly elegant and intuitive to be wrong. I'd be interested in any information... has the theory been disproven, has any other progress been made on it, or has it just been substantially ignored? If anyone can give a URL to that story, I'd be interested to be able to re-read it, too.
Thanks,
Stuart.
Speaking of which, does anyone know when M10 will be packaged for debian? Everyone says that this one has *finally* reached the point where it is usable for real browsing, but the debian package is still sitting at M9, so I can't tell.
Anyone with inside info?
Stuart.
I agree that the only person hurt directly by Sun failing to "get it" is Sun. However, if Sun are hurt, then so are the people who use Sun's products. Most importantly - to me at least - are all the developers working with Java in the (mistaken...?) belief that one day it will really be an "open standard".
To me, the SCSL is an indication that right now, Sun's biggest hope is that it will never be open, but always controlled by Sun and Sun only. Kaffe, Japhar, Jikes and Classpath all provide hope of someday providing some legitimate competition, thereby taking "de-facto" control away from Sun. However, in the meantime, those of us who want to use a powerful, well-designed language like Java have no choice other than using non-free software - and worse yet, a closed "standard". Therefore, we are hurt.
I see this as a far more important issue than whether StarOffice is opened or not, because StarOffice will ultimately be out-competed by KOffice and GNOME workshop. Java cannot be out-competed anywhere near as easily, because the *standards* are controlled by Sun. Remind you of any other companies?
Stuart.
Their license is NOT open source except for this issue (interoperability). It is FAR from it. See below.
First of all, there is an EASY way for Sun to make Java open source and maintain compatibility, because they own the *name*. They can license the code, but only grant licenses to use the *name* java if you are compatible.
Secondly, there are such things as Test Suites. If Sun were even remotely serious about being "open", they would make their test suites freely available. If they did this, too, the compatibility thing would be a non-issue, because every news magazine and hacker would run the compatibility tests on every new JVM released - there would be no way to be incompatible without it being public knowledge *very* fast. As it is now, we pretty much have to take Sun's word for it that a JVM is incompatible (except for Microsoft, who boast about it).
There are at least two other issues apart from the compatibility testing issue where the license falls far short of open source. First is the fact that you are licensed to use the code only for research purposes; you can't even use it internally to your business without that being considered commercial use. Or give a copy to your neighbour. You *certainly* can't include it in your Linux (or xBSD) distribution.
Secondly, there is the matter of what you have to do to escape those restrictions. It's *not* just a question of "keep your version compatible, and pass a test to prove it". You have to get a whole fresh license from Sun, which you have to *pay royalties for*. It's not even just a nominal fee to cover the cost of testing (which is ridiculous anyway - see my earlier point about free test suites) but fully fledged license fees of the same sort as they were charging people for licenses before the SCSL came out.
If Sun were serious about being open, there is a LOT they could do. Don't be fooled by their blurb.
Stuart.
I'm almost certain that proxy support IS in there if you manually edit the prefs. This is a FAQ I see over and over again on the newsgroups, so if you try searching dejanews for it, you'll probably find what pref you have to set.
HTH,
Stuart.
Wouldn't it be possible to do a perl-like thing and release it under the GPL along with another license? That way it could be a kernel patch on linux but other OS's could use it under whatever license they liked.
Also future enhancements could be shared between the two licenses.
Personally I hope this is what they do.
Actually, the panel applets were the thing that wowed me with GNOME. That and the control center, which also appears to use pluggable corba components in the main body pane.
Sure, most of it was always doable with plain X (I remember having xload swallowed in my fvwm panel thingy years and years ago) but the point is that this corba-based architecture is going on *everywhere* throughout GNOME. I prefer to think of GNOME as an application framework, not a desktop environment. The panel and control center are just tools written to that framework. That's why I personally prefer it over KDE - KDE is currently the better desktop environment, but GNOME is the better framework... and the desktop environment on top of it will come with time.
(but until it does, I'll use KDE)
Stuart.
The reason the poster (who was deliberately stating an extreme point of view) suggested people master Slackware before trying Debian, was that then they'd realise how easy they have it with Debian.
... :)
Personally, for me, the switch from Debian to RH was an unpleasant shock ease-of-use-wise, and the switch from RH back to Debian was another unpleasant shock ease-of-installation-wise. For ease-of-use (once you get through the install), Debian *CANNOT* be beaten - since 1995 at least it has been able to automatically update itself to use the latest packages, something I've never seen in ANY other operating system, and it includes everything you can possibly think of.
I was recently working on my debian machine with a co-worker, trying to set up a program, and a suggested step was "run smbclient with these options".
smbclient: command not found
$ apt-get install smbclient
$ smbclient
My co-worker was dead impressed
I think debian is the ideal distribution to shrinkwrap - it provides the best underlying architecture I've ever seen, it just makes no attempt to hide the complexity of what you are doing. With Corel (hopefully) adding a nice installation interface specifically TO hide those complexities, we could finally get the perfect distro...
Stuart.
... and buy *several* Linux distros, THAT's world domination.
... because Debian doesn't even *have* Gnome 1.0 yet.
I think this is because they don't want to put it in with broken dependencies and figuring out the dependencies of gnome is hard... but still, we're talking about the "unstable" distribution here.
I'm longing to be able to show off an appropriately-themed gnome/e setup to my co-workers (they were reasonably impressed with E.14's ugly defaults and gnome 0.99.3's broken setup from the latest unstable I tried, but themes wouldn't work and I couldn't change the gnome window manager from icewm.
It sucks, because that was something that would really have wowed people.
Stuart.
I wouldn't use such strong language, but...
Me too!
;)
I know that most people are against feature bloat in Mozilla, but I think this was possibly a very good idea. A strong case was made for it in the early "Unity of interface" paper that was referenced from the page, when it was up.
The reason I hated Netscape including AIM wasn't because of the bloat (apart from the truly stupid fact that everything else was an option in the installer, but AIM was compulsory), but because of the fact that it only spoke a single proprietary protocol. Having a generic client which speaks all protocols is IMO a great thing.
As for whether it belongs in Mozilla, I think it does, to the same extent that Mail and News belong. So long as they are optional, it makes sense to share the *huge* amount of common code (UI, HTML rendering, networking protocols...). Although most people consider the mail and news module code bloat (personally I like it and use it everyday), it's a telling point that the "navigator standalone" edition of netscape is at least 2/3 the size of the full product - in other words, the vast majority of the code is shared (unless you really believe that the browser-specific code is FAR more complex, and bigger, than all the rest put together).
As a final point, in response to the comments that "Mozilla should be concentrating on putting out a usable product" - exactly how many people do you think worked on this? The same applies to the Necko networking project, which has 5 people. A while ago everyone was following JWZ's lead in saying that the "30 or so" external contributors were "insignificant"... now it's a life-or-death matter if 5 or 10 internal developers work on something other than getting the first release ready?
Stuart.
Too right - I expected better of IBM, what with their recent open-source moves. Just imagine the press that would have followed an announcement from Big Blue that they were going to be developing MP3 technology...
Stuart.
I want to switch from Red Hat 5.1 to Debian, but I don't have time to break everything and spend days fixing it. How easy is it to make this sort of thing "just work"?
;)
Probably my best bet is to install debian onto a seperate partition and mount my existing install within it... Damn, think I just answered my own question
The issue remains, though, for people who don't have a spare partition on their drives...
Stuart.
Your claim that "he attempts to claim credit by calling it GNU/Linux after the fact" instantly discredits your whole point.
The only "vital" part of what is commonly known as Linux that is not written as part of the GNU project is the kernel. The kernel is the heart of the system - but how useful is a heart without the rest of the body?
The name "GNU/Linux" is not an attempt to claim credit, but an attempt to have credit given where it is due.
Stuart (not affiliated with the FSF, and I disagree with Stallman on many other issues... but that one is simple fact).
This is amazing. Is this code dual-licensed, or will it be? (hmm... looking at the page it looks more like the current license is "WYSIWYG, YMMV, HAND." :) )
What I really, REALLY want to see is JavaScript hooks so that you can write scripts to access and modify CORBA objects, and Java RMI objects. Then, if GNOME has corba as pervasively as it says it does, the whole of GNOME would instantly become scriptable... and ditto for KDE 2.0 (from what I hear).
This is something that could really hit MS hard, because it's something they're just adding now (scriptability of everything through an object model exposed to VBs"crap"t).
Stuart.