Given ARM's repuation for low power chips... The cooling fan in the Netwinder is there for the sake of the HD, and if I am not mistaken, the support chipset puts out more heat than the chip itself -- and thats at 275Mhz
For the sake of a quick speed hack (i.e. make the overhead a little lighter compared to what was there previously), set HZ to some power of 2 (i.e. 128 or 1024) and use >>'s, 's and &'s rather than %'s. p.s. does anybody know how quickly the PII does mod's compared to adds, shifts and &'s?
As the title says, Jiffies go at 100Hz. This is the kernel scheduler frequency. (i.e the bit to the right of the #define HZ in linux/include/asm/param.h) For a 1Ghz machine, jiffies will run out at the same rate (so far as our time is concerned), but the tasking will seem ~10 times coarser to the applications. That said, if the machine is 1Ghz, the overhead of doing 64bit jiffies is minor (or zero if you have a 64bit processor)
Using old kernel config. file with new kernel?
on
Linux 2.2.4
·
· Score: 1
copy the old config file to/usr/src/linux/.config (replace/usr/src/linux with your linux source directory if different) and use make oldconfig
Kernel-of-the-week Club
on
Linux 2.2.4
·
· Score: 1
You don't have to -- as the saying goes...
if it ain't broke don't fix it.
Basically, if the new kernel adds little or nothing that you need, then don't bother with it. Personally, I'm waiting for reiserfs to make it into the kernel -- its stable, and I have been running it with 2.2.2acSomething for some time now (sine 2.2.2 came out)
p.s. anybody know how one persuades knfsd to do anything?
To make it blue screen... to run a GNOME applications, do (gnome-thingy || init 7) have runlevel 7 kill everything, print up the blue screen, and then halt the system. p.s. Windows is FAR more stable than GNOME -- and windows crashes a lot.
We really need the GCC maintainers to get the EGCS code merged into the GCC tree, and have 2.8 and 2.7 dropped. Too many source compatibility problems have been brought around by 2.7's lack of standards conformance and tolerance of illegal constructs (read Linux 2.0). Essentially, EGCS 1.1 should be called GCC 2.9, EGCS 1.1.2 --> GCC 2.9.2 etc.
One of the major problems with the current 2.2 kernels seem to occur when swap and ram get filled. Basically, take up all the ram, and all the swap, which the system will allow, and it will go swap-happy and hang whilst it swaps itself to death.
Basically, we need to look at the license provisions of previous licenses granted for software to use the CDDB database.
If you have a CDDB program, and a license to use the CDDB data without the terms prohibiting archiving, redistribution etc. then you could probably use the software, archive data and retransmit it to a new CD database.
In any case, what is needed is SWIFT action -- get a project underway, and get a simple format out of the door -- it needn;t make the service easy to use at first (give it a few weeks to sort that out -- it should allow users to submit CD details, and have an OpenContent license drawn up (or cloned) so that people know that their work wont be abused and exploited like escient are doing.)
Maybe someone could get Rob to host one temporarily bolted onto the side of slashdot, using a separate MySQL database? (i.e. http://cd.slashdot.org)
A CD database server placed here with an explanation as to why not to use CDDB should get a lot of attention in the FSC -- and that would make a very good start.
What is really needed now is to get the inter application and window communications standardised across KDE and GNOME.
While X11 based mechanisms can be used, they should not be mandatory -- the mechanism should be window system independant and allow window signals and windows to be manipulated by scripts, if given appropriate permissions.
Above all, being able to run a GNOME application under KDE and have it integrate with KDE, and a KDE application integrate with GNOME when run under GNOME should be considered a priority -- so that the KDE control panel will control both GNOME and KDE applications in a consistent useable way, and simliarly for the GNOME control panel.
Oh, and please please please... get rid of the old Windows.ini style file format for configuration -- something like an extended libPropList format would be better -- preferably something that could be mapped directly to XML RDF. This would allow for centralised, decentralised and distributed application configuration.
So far as I see it, yes the community is about freedom. Freedom to choose, and to make decisions about what is best for a particular situation, rather than what we are allowed do do by the license.
Part of the problem stems from the GPL being TOO strong -- rather than having the 'You can't...' problems of proprietary software, you've got to the other extreme -- 'You can't...' all over again.
(M$ software typically says that you can't run in on a non-M$ platform -- and GNU does little different -- you can't link to a non-GNU library unless GNU takes precidence in all licencing issues.)
While GPL is one of the thing that is designed to ensure Freedom, it is also one of the greatest threats to it -- you can have Freedom, so long as its 'this type' of freedom.
(Consider the parallel with -- 'you can run any legally purchased program, provided your OS is windows' -- the attitude that M$ wants to promote with windows (One this, one that, one the other))
Think about it, think some more, and when you're done stop and think. None of the freedom comes from blindly following ANY single book of rules -- you HAVE to think about what you're doing, what it represents, and what are the consequences. You HAVE to listen to others (yes, even RMS,ESR etc.) and consider other opinions. If you don't, then the only thing that you can really be sure of is that you are inevitably going to end up being wrong.
You could easily reverse the results by using a 9600bps modem for Windows 98 for which only Win3.1 drivers exist, and a 14.4 with drivers for both for the Windows 3.1 box.
The problem is not the slight difference in speed. It's that the modems are different, so the result is not truly objective.
Not a rebuttal, but points about both gmc and kfm
on
Gnome 0.99.7 released
·
· Score: 1
This is not a rebuttal, but an expansion on what has been said.
Limited configurability (why the fuck can't I get rid of the huge useless toolbar?) Grid limited icon placement, this is *ALSO* a limitation of kfm btw!
And FAR TOO MUCH CODE.
Ugly drag & drop properties, the drag representation could be made better (alpha channel? a la windoze?). How can I turn off the stupid Motif drop-fail-so-fly-back-to-drag-point crap?
They've got worse problems than that. I think that KDE might have solved this, but have any of you started a drag, and then switched window? Have any of you tried to cancel a drag? Have any of you had DnD'ing just crash the whole thing?
Crash prone, yeah, still beta.. Limited integration with the rest of GNOME (it would be nice if apps could use gmc for their file dialogs, with all the options. No need to reimplemnt stuff. This is the GNU Network Object Model Enviroment right???)
This is one of the BEST examples of the problems of code bloat -- how large is GMC???
p.s dont shout about its wondeful features...
VFS -- ftp, tar,... these should NOT be handled by GMC (they should be in a system library or a GNOME support library. (n.b. they ARE going this way) -- KDE still needs this to be done for KDE, however I would expect them to learn from the mistakes made with GMC.
Apps use GMC for file dialogs??? You're kidding right? Last time I checked, gnumeric (compiled under PGCC 1.1.1 on stampede with all optimisations enabled) was noticeably slower than M$ Excel 97 running under Wine from the files on my Windows box (mounted over NFS under linux from the VFAT drive...).
In short, gtk and gnome are SLOW. Using GMC instead of the GTK file boxes would make it interminably slow.
Still beta -- pre-1.0, like KDE should be considered alpha. 1.0 should be considered beta (KDE 1.1 is really the first proper release of KDE regardless of what may be said -- KDE 1.0 was as much a joke as GNOME 1.0 will probably turn out to be for release wuality software.
Not multi-threaded. Why not create a separate thread for the desktop?
For a more stupid problem with both KFM and GMC. Why require that there be a desktop where things can be dragged at all. I'd personally prefer a shelf, and dragging an object to a desktop opens the object in that desktop. So far as separate thread for desktop... How about a separate thread for each region (i.e. one for the whole window, one for the toolbars, one for the tree on the left, one for the file view window, a thread for each job given to GMC, i.e. copy or move, a thread for opening a ZIP file in the VFS.
Intelligent, unemotional discussion of KDE v Gnome
on
Gnome 0.99.7 released
·
· Score: 1
Although I fervently believe in choice when it comes to apps like wordprocessors, spreadsheets. etc. I strongly believe that the less technical end user should only have to "learn Linux" once. To the new non-technical user, the interace *is* the OS. I believe that for the good of Linux, only one interface should be dominant.
A different opinion. Linux should NOT have any graphical user interface by default. KDE and GNOME should do to Linux what NextStep/OpenStep did to Mach -- provide a consistent OS with a GUI that is based on Linux. What should be dropped is the 'it's all Linux' thing -- though that could be difficult. The 'it's all GNU' a la RMS should also be avoided.
Gnome seems to go for flashy and neat stuff.
That in itself is not the problem. The problem is that it goes for the flashy stuff at the expense of the simple stuff -- its in its feature bloat stage -- where new stuff is added at the expense of stability. However, I recall that KDE 1.0 wasn't exactly brilliant either, so we should give the GNOME guys the benifit of the doubt for now, and remember that having two heavily worked out avenues of exploration is better than one, since KDE and GNOME can and should copy ideas and try varaiatons on them (there's features of the GNOME panel that I like, and similarly for the KDE one)
KDE seems more professional.
Than what? GNOME is currently totally unprofessional, and nothing times anything is still nothing... arguably Windows 3.0 is more professional (still) than GNOME (though I do use both)
I have never been able to deal well with Enlightenment. It seems to give up functionality and ease of use in favor of a sort of bizzare flash. KWM seems (to me) very no nonsense, direct, intuitive, and functional.
Its still really in the early development brainstorm stage -- its just useable, and useful for people to play around with.
KDE's memory requirement is embarrasing. Nobody involved with KDE ever seems to even care about that. I *cannot* set up a low memory 486 system built out of "junk parts" for friends using KDE which is sad because those are the very friends that could benefit most from KDE! Memory usgage may be KDE's greatest weakness.
Expect this to get worse before it gets better. KDE needs to stress and use reusable components (far more then it already does anyhow). This should be done to the point that most applications can be easily scripted out of KDE. Memory efficiency comes from minimalism and reuse. So expect GNOME to have similar problems if it is not already
Using X11 in low memory is painful ( I know as an ex 8mb user). KDE and Gnome will suck on such systems, as will any large GUI program (netscape 4, StarOffice, WordPerfect, xdoom, xquake) KDE 1.1 is lighter in memory use.
Hopefully, a port to something like GGI could be done -- abandoning X for network graphics and using CORBA and reusable objects would be an interesting long term goal, and the Berlin project could be looked to for ideas to this if nothing else (else... read implementation)
Gnome has lower memory requirements by a long shot. As I understand it, ORBit is much more efficient than MICO and that MICO was originally written as an educational tool and nothing more. (Don't assume I know what I'm talking about here, about MICO. I just *heard* this. I don't know that for sure.)
The GNOME and KDE teams are NOT developing ORBS. Therefore it would be a good idea for them to settle on the same ORB and make their systems more interoperable. They should look at a larger number of ORBs, standardise on one, and possibly cannibalise others for the remaining parts if necessary (as a stop gap). Some examples of ORBs are
mico -- KDE uses it.
ORBit -- GNOME uses it.
omniORB2 -- apparently its fast, and anyhow, its GPL, so code can be shared between these.
TAO -- The ACE ORB (can't remember where to find it, so someone please add a link...
KDE 1.1 and 1.0 don't use corba, so Mico is not included. When it does, it will use Mico, for reasons of its maturity.
Should they tie themselves to one ORB. I don't have much experience of ORBs, so could someone explain the problems entailed with changing the ORB.
The memory comaparisons should be backed up by the output of ps or relevant utilities, compiling both with same compiler, optimisations etc.
Agreed. Though is should be given a more thorough analysis then just ps'ing it (for release candidate stuff).
I get the impression that the Gnome team has started at a lower level, building a foundation of ORBit, etc. which will pay off in the long run, whereas KDE picked available tools a jumped right into coding the GUI. This is not a criticism of KDE. If KDE were not here, we would not have anything finished and ready right now or over the last year or two and Linux/Unix would not be in as good a shape. (The two projects may be complememtary in that way.) I'm interested in (*constructive*) comments about the quality of the relative foundations.
Bear in mind that KDE can make use of GNOME components, so they should consider doing the higher level stuff. KDE and GNOME working together more is always a good thing...
Redhat always pushed the easyness of their distro. Not including KDE was a backwards step if that was their goal, and I'm now an ex Redhat...
I dumped RedHat for Stampede. The speed difference is huge, though debugging is more difficult. ld.so really needs to be modified to allow for the easy loading of a program with debugging libraries, without, or with a mix (i.e make a ldload command which allows you to specify how dynamic linking will be done) That said, Stampede installation is currently far from easy, and I haven't yet managed a proper install that I didn't have to clean up after. That said, its worth it for the speed increase compared to Slackware and relative cleanliness compared to RedHat. Is it me, or is RedHat really turning into the Microsoft/Windows of Linux?
mico is slow and bloated. It would be an idea for the KDe folks to carefully consider which ORB they use. It would be an idea to go for one written purely in C++, since this is their preferred language (it saves a lot of headaches to avoid going cross-language unless necessary, so the C++ to C-Library and other basic libraries should be the only case where this is done
(GNOME used to use it, but dumped it for this reason, and started ORBit).
p.s. anybody know what omniORB 2 is like? I hear that its fast and stable.
The KDE people need to draft some ammendments, call these the 'KDE Qt/GPL software ammendments' or somehting similar, and then allow people to say (This program may be distributed under the GPL, they following may also be applied by whoever distributes the program... (quote KDE stuff)).
Think about this a little, and bear in mind that the GPL only disallows additional restrictions, not additional permissions
Ubiquitous, enslaving, and conveniently incompatible with nearly everything else...
Unfortunately, this has to be said abou the GPL.
'It is perfectly acceptable to combine non-GPL and GPL software so long as the terms of both licenses allow the GPL to take precedence...'
One thing the Linux community stands for is FREEDOM OF CHOICE.
We can CHOOSE to run Linux instead of some Micro$hite Redmond 1984 rubbish.
We can CHOOSE whether to leave some feature in the kernel, or whether to remove it or rewrite it.
We can CHOOSE whether to upgrade to the latest version or NOT TO DO SO.
However, with the GPL, we have no choice whatsoever -- use ten lines of GPL code in our program and we have to make it GPL. Linking such a program to a non-GPL library and you cannot redistribute the result (unless you own the rights to the GPL code mentioned).
You can have any license you want, provided it's GPL
You can have any OS you want, provided it's Windows You can have any colour you want, provided it's black.
Its worth discussing this, since we may end one 'lack of choice' only to be trapped by another one
p.s. Take this a Devil's advocate statement, since I myself support GNU/Linux, but openly support the idea of more than one free software license.
Makes me wonder... (hardware bigotry follows...)
on
NYT covers WINE
·
· Score: 1
The funniest thing along those lines, which didn't happen to me, but to my (then) housemate, concerned a Quantum Fireball hard drive (the name's quite ironic). Basically, the main controller chip fused, turned into a short circuit, and started melting its way out of its casing (it was nearly there after 1second of this). Basically, we spent good hour or two going through the system working out where all the smoke came from:-).
I had a 160Mb quantum that was barely used, and died. Basically, dont buy maxtor, dont buy Quantum.
The one thing I like about zip disks is their robustness -- also the one thing why I wish those 120Mb 'superfloppy' things would go away.
I've only ever had one problem with a zip disk, and that's the inability to reformat them to the correct size when they've been incorrectly formatted (this due to the problems getting 'doze to correctly handle the internal zip drive)
Slashdot Mirror
How much is a decent BX motherboard, two 300A PPGA celerons and two of these adaptors?? Any prices yet??
Given ARM's repuation for low power chips... The cooling fan in the Netwinder is there for the sake of the HD, and if I am not mistaken, the support chipset puts out more heat than the chip itself -- and thats at 275Mhz
Or just that after all the opening and closing of the case, you'd lost the screws :-)
For the sake of a quick speed hack (i.e. make the overhead a little lighter compared to what was there previously), set HZ to some power of 2 (i.e. 128 or 1024) and use >>'s, 's and &'s rather than %'s. p.s. does anybody know how quickly the PII does mod's compared to adds, shifts and &'s?
As the title says, Jiffies go at 100Hz. This is the kernel scheduler frequency. (i.e the bit to the right of the #define HZ in linux/include/asm/param.h) For a 1Ghz machine, jiffies will run out at the same rate (so far as our time is concerned), but the tasking will seem ~10 times coarser to the applications. That said, if the machine is 1Ghz, the overhead of doing 64bit jiffies is minor (or zero if you have a 64bit processor)
copy the old config file to /usr/src/linux/.config (replace /usr/src/linux with your linux source directory if different) and use make oldconfig
You don't have to -- as the saying goes...
if it ain't broke don't fix it.
Basically, if the new kernel adds little or nothing that you need, then don't bother with it.
Personally, I'm waiting for reiserfs to make it into the kernel -- its stable, and I have been running it with 2.2.2acSomething for some time now (sine 2.2.2 came out)
p.s. anybody know how one persuades knfsd to do anything?
To make it blue screen... to run a GNOME applications, do (gnome-thingy || init 7) have runlevel 7 kill everything, print up the blue screen, and then halt the system. p.s. Windows is FAR more stable than GNOME -- and windows crashes a lot.
gnomecc fails to correctly swallow approx 2/3 of the preference windows. and yes -- gmc crashes far too much.
We really need the GCC maintainers to get the EGCS code merged into the GCC tree, and have 2.8 and 2.7 dropped. Too many source compatibility problems have been brought around by 2.7's lack of standards conformance and tolerance of illegal constructs (read Linux 2.0). Essentially, EGCS 1.1 should be called GCC 2.9, EGCS 1.1.2 --> GCC 2.9.2 etc.
One of the major problems with the current 2.2 kernels seem to occur when swap and ram get filled. Basically, take up all the ram, and all the swap, which the system will allow, and it will go swap-happy and hang whilst it swaps itself to death.
Heavy G++ compiles are a good way to cause this.
Basically, we need to look at the license provisions of previous licenses granted for software to use the CDDB database.
If you have a CDDB program, and a license to use
the CDDB data without the terms prohibiting archiving, redistribution etc. then you could probably use the software, archive data and retransmit it to a new CD database.
In any case, what is needed is SWIFT action -- get a project underway, and get a simple format out of the door -- it needn;t make the service easy to use at first (give it a few weeks to sort that out -- it should allow users to submit CD details, and have an OpenContent license drawn up (or cloned) so that people know that their work wont be abused and exploited like escient are doing.)
Maybe someone could get Rob to host one temporarily bolted onto the side of slashdot, using a separate MySQL database?
(i.e. http://cd.slashdot.org)
A CD database server placed here with an explanation as to why not to use CDDB should get a lot of attention in the FSC -- and that would make a very good start.
What is really needed now is to get the inter application and window communications standardised across KDE and GNOME.
.ini style file format for configuration -- something like an extended libPropList format would be better -- preferably something that could be mapped directly to XML RDF. This would allow for centralised, decentralised and distributed application configuration.
While X11 based mechanisms can be used, they should not be mandatory -- the mechanism should be window system independant and allow window signals and windows to be manipulated by scripts, if given appropriate permissions.
Above all, being able to run a GNOME application under KDE and have it integrate with KDE, and a KDE application integrate with GNOME when run under GNOME should be considered a priority -- so that the KDE control panel will control both GNOME and KDE applications in a consistent useable way, and simliarly for the GNOME control panel.
Oh, and please please please... get rid of the old Windows
OK, straight question --
The Id numbers on the CD's are unique right?
Why do we need to map them to some unique ID
number -- a database could easily use the ID
as a key.
So far as I see it, yes the community is about
freedom. Freedom to choose, and to make decisions
about what is best for a particular situation, rather than what we are allowed do do by the license.
Part of the problem stems from the GPL being TOO
strong -- rather than having the 'You can't...'
problems of proprietary software, you've got to
the other extreme -- 'You can't...' all over again.
(M$ software typically says that you can't run
in on a non-M$ platform -- and GNU does little
different -- you can't link to a non-GNU library
unless GNU takes precidence in all licencing issues.)
While GPL is one of the thing that is designed
to ensure Freedom, it is also one of the greatest
threats to it -- you can have Freedom, so long
as its 'this type' of freedom.
(Consider the parallel with -- 'you can run any
legally purchased program, provided your OS is
windows' -- the attitude that M$ wants to promote
with windows (One this, one that, one the other))
Think about it, think some more, and when
you're done stop and think. None of the freedom
comes from blindly following ANY single book of
rules -- you HAVE to think about what you're doing, what it represents, and what are the
consequences. You HAVE to listen to others (yes,
even RMS,ESR etc.) and consider other opinions.
If you don't, then the only thing that you can
really be sure of is that you are inevitably
going to end up being wrong.
You could easily reverse the results by using a 9600bps modem for Windows 98 for which only Win3.1 drivers exist, and a 14.4 with drivers for both for the Windows 3.1 box.
The problem is not the slight difference in speed. It's that the modems are different, so the result is not truly objective.
This is not a rebuttal, but an expansion on what
has been said.
And FAR TOO MUCH CODE.
They've got worse problems than that. I think that KDE might have solved this, but have any of you started a drag, and then switched window? Have any of you tried to cancel a drag? Have any of you had DnD'ing just crash the whole thing?
This is one of the BEST examples of the problems
of code bloat -- how large is GMC???
p.s dont shout about its wondeful features...
handled by GMC (they should be in a system
library or a GNOME support library. (n.b. they
ARE going this way) -- KDE still needs this to
be done for KDE, however I would expect them to
learn from the mistakes made with GMC.
all optimisations enabled) was noticeably slower
than M$ Excel 97 running under Wine from the
files on my Windows box (mounted over NFS under
linux from the VFAT drive...).
In short, gtk and gnome are SLOW. Using GMC instead of the GTK file boxes would make it interminably slow.
For a more stupid problem with both KFM and GMC. Why require that there be a desktop where things can be dragged at all. I'd personally prefer a shelf, and dragging an object to a desktop opens the object in that desktop.
So far as separate thread for desktop... How about a separate thread for each region (i.e. one for the whole window, one for the toolbars, one for the tree on the left, one for the file view window, a thread for each job given to GMC, i.e. copy or move, a thread for opening a ZIP file in the VFS.
Linux should NOT have any graphical user interface by default. KDE and GNOME should do to Linux what NextStep/OpenStep did to Mach -- provide a consistent OS with a GUI that is based on Linux. What should be dropped is the 'it's all Linux' thing -- though that could be difficult. The 'it's all GNU' a la RMS should also be avoided. That in itself is not the problem. The problem is that it goes for the flashy stuff at the expense of the simple stuff -- its in its feature bloat stage -- where new stuff is added at the expense of stability. However, I recall that KDE 1.0 wasn't exactly brilliant either, so we should give the GNOME guys the benifit of the doubt for now, and remember that having two heavily worked out avenues of exploration is better than one, since KDE and GNOME can and should copy ideas and try varaiatons on them (there's features of the GNOME panel that I like, and similarly for the KDE one) Than what? GNOME is currently totally unprofessional, and nothing times anything is still nothing... arguably Windows 3.0 is more professional (still) than GNOME (though I do use both) Its still really in the early development brainstorm stage -- its just useable, and useful for people to play around with. Expect this to get worse before it gets better. KDE needs to stress and use reusable components (far more then it already does anyhow). This should be done to the point that most applications can be easily scripted out of KDE.
Memory efficiency comes from minimalism and reuse. So expect GNOME to have similar problems if it is not already Hopefully, a port to something like GGI could be done -- abandoning X for network graphics and using CORBA and reusable objects would be an interesting long term goal, and the Berlin project could be looked to for ideas to this if nothing else (else... read implementation) The GNOME and KDE teams are NOT developing ORBS. Therefore it would be a good idea for them to settle on the same ORB and make their systems more interoperable. They should look at a larger number of ORBs, standardise on one, and possibly cannibalise others for the remaining parts if necessary (as a stop gap). Some examples of ORBs are
- mico -- KDE uses it.
- ORBit -- GNOME uses it.
- omniORB2 -- apparently its fast, and anyhow, its GPL, so code can be shared between these.
- TAO -- The ACE ORB (can't remember where to find it, so someone please add a link...
Should they tie themselves to one ORB. I don't have much experience of ORBs, so could someone explain the problems entailed with changing the ORB. Agreed. Though is should be given a more thorough analysis then just ps'ing it (for release candidate stuff). Bear in mind that KDE can make use of GNOME components, so they should consider doing the higher level stuff. KDE and GNOME working together more is always a good thing... I dumped RedHat for Stampede. The speed difference is huge, though debugging is more difficult. ld.so really needs to be modified to allow for the easy loading of a program with debugging libraries, without, or with a mix (i.e make a ldload command which allows you to specify how dynamic linking will be done) That said, Stampede installation is currently far from easy, and I haven't yet managed a proper install that I didn't have to clean up after. That said, its worth it for the speed increase compared to Slackware and relative cleanliness compared to RedHat.Is it me, or is RedHat really turning into the Microsoft/Windows of Linux?
mico is slow and bloated. It would be an idea for the KDe folks to carefully consider which ORB they use. It would be an idea to go for one written purely in C++, since this is their preferred language (it saves a lot of headaches to avoid going cross-language unless necessary, so the C++ to C-Library and other basic libraries should be the only case where this is done
(GNOME used to use it, but dumped it for this reason, and started ORBit).
p.s. anybody know what omniORB 2 is like? I hear that its fast and stable.
The KDE people need to draft some ammendments, call these the 'KDE Qt/GPL software ammendments' or somehting similar, and then allow people to
say (This program may be distributed under the GPL, they following may also be applied by whoever distributes the program... (quote KDE stuff)).
Think about this a little, and bear in mind
that the GPL only disallows additional restrictions, not additional permissions
Unfortunately, this has to be said abou the GPL.
One thing the Linux community stands for is FREEDOM OF CHOICE.
However, with the GPL, we have no choice whatsoever -- use ten lines of GPL code in our program and we have to make it GPL. Linking such a program to a non-GPL library and you cannot redistribute the result (unless you own the rights to the GPL code mentioned).
Its worth discussing this, since we may end one 'lack of choice' only to be trapped by another one
p.s. Take this a Devil's advocate statement, since I myself support GNU/Linux, but openly support the idea of more than one free software license.
The funniest thing along those lines, which didn't happen to me, but to my (then) housemate, concerned a Quantum Fireball hard drive (the name's quite ironic). Basically, the main controller chip fused, turned into a short circuit, and started melting its way out of its casing (it was nearly there after 1second of this). Basically, we spent good hour or two going through the system working out where all the smoke came from :-).
I had a 160Mb quantum that was barely used, and died. Basically, dont buy maxtor, dont buy Quantum.
And BACK UP OFTEN.
The one thing I like about zip disks is their robustness -- also the one thing why I wish those 120Mb 'superfloppy' things would go away.
I've only ever had one problem with a zip disk, and that's the inability to reformat them to the correct size when they've been incorrectly formatted (this due to the problems getting 'doze to correctly handle the internal zip drive)