"If I'm not mistaken, you could run Gnome under FreeBSD with Linux compat"
Why would you want to? Linux compatibility is primarily useful for running closed-source apps built to run on Linux. GNOME can simply be compiled for FreeBSD by whoever maintains the FreeBSD packages for GNOME.
GNOME is supposed to be a Unix desktop, not just a Linux desktop, so portability across Unices would be a goal anyway. I doubt that KDE had much to do with it.
I don't think that *anyone* is going to get total Word compatibility as long as Microsoft has control over Word's file format. IMHO, what is really needed in the long run is not compatibility with Word, but a way to make the ubiquity of MS Office inevitable.
What the poster said was that Linux was useful *almost* at the moment it was posted, and the link to which you pointed actually confirms that. Let's see:
Linux 0.01: Uncompilable
Linux 0.02: Compilable but not very usable
Linux 0.03: Hey, pretty usable
Linux 0.10 (jump in version number) Starting to work pretty well
Linux 0.11: Now has a small following
Linux 0.12: Actually a pretty stable kernel
Linux 0.95 (jump in version number again): Good enough to have a 0.9x version number
All this occurred between July 3, 1991 and January 5, 1992, a space of about six months, so the first poster was actually pretty much correct.
AFAIK, an example of "deliberately obfuscated code" would be code that was preprocessed somehow to make it hard to understand, i.e. running the code through the C preprocessor.
"could someone pleaseg ive a decent explanation of why the Mozilla GUI is so sluggish?"
I think it's because 1) because the Mozilla builds are compiled with debugging info, which makes them slower and heavier, and 2) because "premature optimization is the root of all evil, and the Mozilla developers are probably avoiding optimizing Mozilla until they work out most of the bugs, so that the optimization itself doesn't introduce subtle bugs.
"Linux must have a personal dislike for me, since I can usually kill it pretty easily."
"I've had X applications totally lock up the system on many occasions."
Do you have a problem with Linux crashing on you *and* a problem with X locking up, or is it just X that's the problem. If Linux itself is crashing, then you probably have a hardware problem. If it's just X locking up, then, well, you're stuck.
DMCA forbids circumventing access control schemes, encryption schemes, copy protection, and the like. The trouble with the DMCA is that for the most part, it doesn't take into account whether or not one may have a legitimate reason for breaking the encryption or copy control scheme; you are even forbidden to break an encryption scheme that keeps you from viewing a copy of data that you bought, paid for, and otherwise have the legal rights to. It is as if a law was passed forbidding people to break locks--even the lock to one's own house!
Hardly. I have gone back and forth between KDE, GNOME, and assorted window managers more times than I can count. Not everyone is going to find KDE to be the be-all and end-all of desktops.
"while Nautilus is very cool, it's almost like they forgot about the issue of speed."
I believe a wise programmer whose name I forget said "Premature optimization is the root of all evil." The developers probably want to bang out the bugs before sizzling the code.
"I was trying to ask is whether, because of the 'linking to GLP'd libraries' issue, applications will need, in order to have first class support on either of the desktop environments -- that is, to be able to use their graphics toolkits, component technologies, etc. --, need to also be GLP'd or otherwise follow the licensing of the DE."
Short answer: no.
Long answer:
The libraries that a GNOME application links to are LGPL'd, not GPL'd, which means that proprietary applications can legally link to these libraries.
Developers of proprietary applications that link to Qt, including proprietary KDE applications, have to pay Trolltech to use Qt. Because of the dual license for the Qt Free Edition, Qt is in effect considered to be GPL'd when the software that links to it is GPL'd, or QPL'd when the software linking to it is under any other free license. The KDE libraries themselves are LGPL'd.
Oh, boy. This is a question that could lead to a lot of flamage.
This is about the size of it:
1) The source code of an executable work, according to the GPL, includes the source code of all the work's modules, except for those modules that are normally distributed with the operating system on which the executable runs.
2) The source code of a work must be available *as a whole* under the terms of the GPL. That in effect means that the pieces of the source code of a work must either be available under the GPL, or a license whose terms are a subset of the GPL terms, i.e. the X license or the new BSD license.
3) If the licensing terms of a module of a GPL'd work is not a subset of the terms of the GPL, then the terms of the GPL are breeched, and the work cannot be distributed at all.
4) RMS and others consider libraries to be modules of the software that links to them, i.e. GTK+ is a module of the GIMP.
Point 4 was essentially the crux of the entire controversy. If Qt is considered a module of KDE, then its licensing terms must be the same or a subset of those of the GPL, else KDE cannot be legally distributed. Up until several months ago, the free edition of Qt was only under the QPL, whose terms were *not* a subset of the terms of the GPL. Those who considered Qt a module of KDE came to the conclusion that distributing KDE was illegal. Obviously, the KDE developers disagreed with this. Flamage and a great headache ensues.
Trolltech has since release the free version of Qt under a dual license: a choice of either the QPL or the GPL. This means that even if Qt is considered a module of KDE, KDE--or the vast majority of it--is in the clear, because Qt is now available under the GPL.
There was arguably some minor cleanup to do, according to RMS. There is a handful of third-party GPL'd code in KDE that was modified to be used with Qt, without the third-party author's express permission. If linking that third-party GPL'd code with Qt was illegal at the time that it was done, then those who modified said third-party code violated the GPL and forfeited their rights to those bits of third-party code. That little nit couldn't be fixed by any action of Trolltech, only by the authors of the third-party code regranting permission to use their code, which RMS correctly but impolitically referred to as "forgiveness." Another brief period of flamage ensued, mostly by those who misread "forgiveness" as meaning some sort of display of wailing and contrition. That flamage has pretty much died down.
That's the nutshell of the arduous story of KDE's licensing issues.
The problem is that the "copy protection" thwarts both illegal copying and copying that falls under fair use. You don't have to believe that proprietary software is evil to find that disturbing.
Re:In action yes...but gives lip-service to BSD
on
ESR On XML-RPC
·
· Score: 1
"Fetchmail is supported on BSD, but NOT by the author."
Um, might that be because BSD ports are usually supported by someone other than the author of the software?
"Or get FreeBSD and simply install KDE by typing 'cd/usr/ports/X11/kde-2.0.1; make install'"
Um, that's as silly as saying "Go get Debian, and type apt-get update; apt-get upgrade". The kind of folks who would feel the need for a KDE installer really wouldn't be installing another OS on a lark.
Re:Oracle/Java on FreeBSD
on
Is BSD Dying?
·
· Score: 1
"I wouldn't call the Linux support in FreeBSD emulation (although I admittedly tend to use that word lacking a better one). FreeBSD simply implements the Linux ABI."
I know, but like you, I "admittedly tend to use that word lacking a better one". I've also seen the emulation at work, and found it uncanny. Quite a credit for both the FreeBSD developers, for making it work in the first place, and for the Linux developers, for using an open ABI that lets the "emulation" work so well. Kudos all around.
"And frankly, I don't think Oracle would refuse anyone to run their servers under FreeBSD."
I doubt that, too, though the previous poster made it appear that the Oracle developers did something that made running Oracle on FreeBSD problematic somehow. That's why I wondered what could be the matter with Oracle that could have thwarted the Linux "emulation".
Re:Oracle/Java on FreeBSD
on
Is BSD Dying?
·
· Score: 1
"Lately though, we have been forced to adopt Linux simply because the latest Oracle & Java 1.3 environments are unavailable on FreeBSD."
You mean that the stuff in the FreeBSD handbook on get Oracle running on FreeBSD doesn't work anymore? What did Oracle do to thwart the Linux emulation? Hmm.
BTW, at freshports.org, there's a port of linux-jdk13. Maybe it'll do what you need it to do?
"even though I haven't had a problem with BSODs on a properly configured machine, and win2k doesn't seem to need to reboot."
Ah, you're using Win2k. Most Linux users who have had stability problems with Windows have had problems with the DOS-bases versions of Windows, namely Win9x, and possibly WinME, which *are* crufty.
"But I wish the Enlightenment people could've taken a hint when it comes to CPU-usage."
Enlightenment is meant to be graphics-intensive, visually stunning, and capable of looking like almost anything. This inevitably means that E is going to use more computing resources than, say, twm or fvwm or blackbox. From what I can tell from browsing the mailing lists for E, a lot of attention *is* paid to making as fast as it can be.
E, though, is definitely never going to be another FVWM or blackbox. It is a window manager for aesthetes with computing horsepower to spare.
One can use pdfTeX, which is a modified TeX that is designed to write PDF rather than DVI. There is also dvipdfm which creates a PDF file from a TeX DVI file. Others have already mentioned ps2pdf.
Slashdot Mirror
"If I'm not mistaken, you could run Gnome under FreeBSD with Linux compat"
Why would you want to? Linux compatibility is primarily useful for running closed-source apps built to run on Linux. GNOME can simply be compiled for FreeBSD by whoever maintains the FreeBSD packages for GNOME.
GNOME is supposed to be a Unix desktop, not just a Linux desktop, so portability across Unices would be a goal anyway. I doubt that KDE had much to do with it.
I don't think that *anyone* is going to get total Word compatibility as long as Microsoft has control over Word's file format. IMHO, what is really needed in the long run is not compatibility with Word, but a way to make the ubiquity of MS Office inevitable.
"How could anyone feel ripped off about a fake fan site?"
Because it *is* fake. It is a lie. It is misrepresentation. People do not like being lied to.
What the poster said was that Linux was useful *almost* at the moment it was posted, and the link to which you pointed actually confirms that. Let's see:
Linux 0.01: Uncompilable
Linux 0.02: Compilable but not very usable
Linux 0.03: Hey, pretty usable
Linux 0.10 (jump in version number) Starting to work pretty well
Linux 0.11: Now has a small following
Linux 0.12: Actually a pretty stable kernel
Linux 0.95 (jump in version number again): Good enough to have a 0.9x version number
All this occurred between July 3, 1991 and January 5, 1992, a space of about six months, so the first poster was actually pretty much correct.
AFAIK, an example of "deliberately obfuscated code" would be code that was preprocessed somehow to make it hard to understand, i.e. running the code through the C preprocessor.
"could someone pleaseg ive a decent explanation of why the Mozilla GUI is so sluggish?"
I think it's because 1) because the Mozilla builds are compiled with debugging info, which makes them slower and heavier, and 2) because "premature optimization is the root of all evil, and the Mozilla developers are probably avoiding optimizing Mozilla until they work out most of the bugs, so that the optimization itself doesn't introduce subtle bugs.
"Linux must have a personal dislike for me, since I can usually kill it pretty easily."
"I've had X applications totally lock up the system on many occasions."
Do you have a problem with Linux crashing on you *and* a problem with X locking up, or is it just X that's the problem. If Linux itself is crashing, then you probably have a hardware problem. If it's just X locking up, then, well, you're stuck.
"So you don't know if it is copyrighted until after you break in."
I think the idea is that to break in, you have to break the DMCA.
DMCA forbids circumventing access control schemes, encryption schemes, copy protection, and the like. The trouble with the DMCA is that for the most part, it doesn't take into account whether or not one may have a legitimate reason for breaking the encryption or copy control scheme; you are even forbidden to break an encryption scheme that keeps you from viewing a copy of data that you bought, paid for, and otherwise have the legal rights to. It is as if a law was passed forbidding people to break locks--even the lock to one's own house!
"Try KDE and you'll never look back"
Hardly. I have gone back and forth between KDE, GNOME, and assorted window managers more times than I can count. Not everyone is going to find KDE to be the be-all and end-all of desktops.
"while Nautilus is very cool, it's almost like they forgot about the issue of speed."
I believe a wise programmer whose name I forget said "Premature optimization is the root of all evil." The developers probably want to bang out the bugs before sizzling the code.
"I was trying to ask is whether, because of the 'linking to GLP'd libraries' issue, applications will need, in order to have first class support on either of the desktop environments -- that is, to be able to use their graphics toolkits, component technologies, etc. --, need to also be GLP'd or otherwise follow the licensing of the DE."
Short answer: no.
Long answer:
The libraries that a GNOME application links to are LGPL'd, not GPL'd, which means that proprietary applications can legally link to these libraries.
Developers of proprietary applications that link to Qt, including proprietary KDE applications, have to pay Trolltech to use Qt. Because of the dual license for the Qt Free Edition, Qt is in effect considered to be GPL'd when the software that links to it is GPL'd, or QPL'd when the software linking to it is under any other free license. The KDE libraries themselves are LGPL'd.
According to www.kdevelop.org, KDevelop supports creating GNOME applications. Maybe that's your :kick a** development tools for GNOME" right there.
"i can tell you that KDevelop does look about 10 times better than GEdit"
Apples and oranges comparison. Gedit was never mean to be an IDE, just a text editor.
Oh, boy. This is a question that could lead to a lot of flamage.
This is about the size of it:
1) The source code of an executable work, according to the GPL, includes the source code of all the work's modules, except for those modules that are normally distributed with the operating system on which the executable runs.
2) The source code of a work must be available *as a whole* under the terms of the GPL. That in effect means that the pieces of the source code of a work must either be available under the GPL, or a license whose terms are a subset of the GPL terms, i.e. the X license or the new BSD license.
3) If the licensing terms of a module of a GPL'd work is not a subset of the terms of the GPL, then the terms of the GPL are breeched, and the work cannot be distributed at all.
4) RMS and others consider libraries to be modules of the software that links to them, i.e. GTK+ is a module of the GIMP.
Point 4 was essentially the crux of the entire controversy. If Qt is considered a module of KDE, then its licensing terms must be the same or a subset of those of the GPL, else KDE cannot be legally distributed. Up until several months ago, the free edition of Qt was only under the QPL, whose terms were *not* a subset of the terms of the GPL. Those who considered Qt a module of KDE came to the conclusion that distributing KDE was illegal. Obviously, the KDE developers disagreed with this. Flamage and a great headache ensues.
Trolltech has since release the free version of Qt under a dual license: a choice of either the QPL or the GPL. This means that even if Qt is considered a module of KDE, KDE--or the vast majority of it--is in the clear, because Qt is now available under the GPL.
There was arguably some minor cleanup to do, according to RMS. There is a handful of third-party GPL'd code in KDE that was modified to be used with Qt, without the third-party author's express permission. If linking that third-party GPL'd code with Qt was illegal at the time that it was done, then those who modified said third-party code violated the GPL and forfeited their rights to those bits of third-party code. That little nit couldn't be fixed by any action of Trolltech, only by the authors of the third-party code regranting permission to use their code, which RMS correctly but impolitically referred to as "forgiveness." Another brief period of flamage ensued, mostly by those who misread "forgiveness" as meaning some sort of display of wailing and contrition. That flamage has pretty much died down.
That's the nutshell of the arduous story of KDE's licensing issues.
"I don't see the problem here."
The problem is that the "copy protection" thwarts both illegal copying and copying that falls under fair use. You don't have to believe that proprietary software is evil to find that disturbing.
"Fetchmail is supported on BSD, but NOT by the author."
Um, might that be because BSD ports are usually supported by someone other than the author of the software?
Why not just set it to "testing" or "unstable" instead?
"Or get FreeBSD and simply install KDE by typing 'cd /usr/ports/X11/kde-2.0.1; make install'"
Um, that's as silly as saying "Go get Debian, and type apt-get update; apt-get upgrade". The kind of folks who would feel the need for a KDE installer really wouldn't be installing another OS on a lark.
"I wouldn't call the Linux support in FreeBSD emulation (although I admittedly tend to use that word lacking a better one). FreeBSD simply implements the Linux ABI."
I know, but like you, I "admittedly tend to use that word lacking a better one". I've also seen the emulation at work, and found it uncanny. Quite a credit for both the FreeBSD developers, for making it work in the first place, and for the Linux developers, for using an open ABI that lets the "emulation" work so well. Kudos all around.
"And frankly, I don't think Oracle would refuse anyone to run their servers under FreeBSD."
I doubt that, too, though the previous poster made it appear that the Oracle developers did something that made running Oracle on FreeBSD problematic somehow. That's why I wondered what could be the matter with Oracle that could have thwarted the Linux "emulation".
"Lately though, we have been forced to adopt Linux simply because the latest Oracle & Java 1.3 environments are unavailable on FreeBSD."
You mean that the stuff in the FreeBSD handbook on get Oracle running on FreeBSD doesn't work anymore? What did Oracle do to thwart the Linux emulation? Hmm.
BTW, at freshports.org, there's a port of linux-jdk13. Maybe it'll do what you need it to do?
"even though I haven't had a problem with BSODs on a properly configured machine, and win2k doesn't seem to need to reboot."
Ah, you're using Win2k. Most Linux users who have had stability problems with Windows have had problems with the DOS-bases versions of Windows, namely Win9x, and possibly WinME, which *are* crufty.
"But I wish the Enlightenment people could've taken a hint when it comes to CPU-usage."
Enlightenment is meant to be graphics-intensive, visually stunning, and capable of looking like almost anything. This inevitably means that E is going to use more computing resources than, say, twm or fvwm or blackbox. From what I can tell from browsing the mailing lists for E, a lot of attention *is* paid to making as fast as it can be.
E, though, is definitely never going to be another FVWM or blackbox. It is a window manager for aesthetes with computing horsepower to spare.
One can use pdfTeX, which is a modified TeX that is designed to write PDF rather than DVI. There is also dvipdfm which creates a PDF file from a TeX DVI file. Others have already mentioned ps2pdf.
I myself have used dvipdfm and ps2pdf.