The term everybody, implies everybody, including authorities.
What Capt. Beyond is referring to is the way laws work in the US, as decided by the supreme court by many cases that laws must be enforced for everybody fairly. This means, you can't selectively pick and choose law, you must enforce it for all violators (when possible). As soon as you stop enforcing the law, it becomes invalid forever, unless it comes to a formal agreement of goverment to enforce it again.
The most famous example of it, is that according to the law books, one driving a motor vechicle in Vermont must have a person waving a red flag, out in front of the car, to warn people of a noisey vechicle coming, that could scare farm animals. Of course, the fact that it's not enforced, means that even if a police officer brought you in for violating this law, the courts would overturn the case, as it hasn't been enforced in almost 100 years.
Another case, is if you see people parking in a no-parking zone everyday (and don't get ticketed), but when you do, you get a ticketed, and can prove that normally people do this without getting ticketed, the courts will dismiss the case.
The division of powers works well in the United States. You claim they represent maintaining the status quo, I have to disgress. In the US, the goverment's sole purpose is protecting peoples freedoms, therefore ensuring the common good. Laws are designed to protect you from stomping on other peoples freedoms (like for example traffic laws, are designed to protect people from hurting others).
"The windows UI is the most extensible UI. You can change it, hook onto it, write plugins for it, and even write scripts for it with DHTML/Javascript. On windows, apps like ICQ and winzip can add to context menus for example - something no other GUI shell has done anywhere near as well."
Mac OS also has the applity for apps Context (Control-Click) Menus to the desktop, as of Mac OS 8.0. Stuffit Deluxe, for example does that. Via. the template feature in KDE 1 you can also add apps own context menus (although this is limited). KDE 2 has even better support for this.
Mac OS since System 5.0, has supported extensions, which can replace any part of System code or ROM loaded into memory with your own version. This is possible to a lesser extent under Linux with kernel modules. Not to mention that higher levels of Linux are totally modular, you can replace bits and parts of them at almost any level (assuming you have permission).
Mac OS uses extensions instead of plugins, see above. They are far more powerful (and potentially dangerous). KDE 2 supports many forms of plugins, including kicker plugins, kwin plugins, filters, and the list goes on...
Linux nor Mac OS can not run scripts in DHTML/Javascript except using a browser. This is a good security pratice, in my experience. Plus they have their own scripting languages, for Linux it's perl (using perl bindings) or bash (using stuff like kwmcom or dcop command line app for GUI stuff), in Mac OS it's AppleScript (which can also do gui stuff).
"generic SCSI - doesn't work on G4s, so no Scanner"
Generic SCSI should work on your machine. You will however need to recompile the kernel with the
aic7xxx kernel driver and the SCSI generic support. Some machines (namely older ones with mesh SCSI) still have problems with Linux trying to access scanners to fast (causing a SCSI Target Abort), enable debuging (see lists.linuxppc.org for info) or add some delay loops to the SCSI generic driver.
"smbfs - hard to find as a pre-compiled module, so no access to the NT Server directly"
Get off you butt and recompile the kernel with smbfs support. You really don't expect your distro's default kernel to come compiled with everything on by default?! This certainly works.
"no Appletalk client protocol AFAICT - so no accessing NT Appletask shares, or the other Macs directly"
Yes, there is afpfs which compiles on the PowerPC, and can mount almost all AppleShare over IP disks. However, AppleShare over Localtalk cables isn't supported (and it is being phased out by Apple and Microsoft too.).
The rest of your points are pretty much accurate. One thing, you may want to check out MOL again, as running it in the console has been accelerated lately. The only speed problems I have seen are related to video speed, producing video similar in speed to running Mac OS with Extensions loaded (therefore just basic video accel, nothing fast).
For offical stable releases, KDE almost always has KDE PowerPC RedHat packages at the time of the offical release. Debian, on the other hand -- well the packages alienate fairly well:)
Many PowerPC users use KDE, if you don't believe me, stop into irc.kde.org's KDE development channel - #kde, you will see several PowerPC Linux users.
Nobody is currently making up cvs-snapshots of KDE 2.0 right now, mainly because it takes alot of time and effort to do so, and nobody exactly wants to bother.
Don't worry, I can almost assure you that there will be PowerPC binaries on the offical day of the KDE 2.0 release.
Ian Gerser had made up ppc.rpm for 1.91 soon after the release, he never did get 1.92 up, but he may do 1.93 packages (I don't know).
At any rate, KDE 2.0 is near, doing beta snapshots all of the time is almost a waste of effort.
I think you are miss understanding the point of the GPL. You can design closed-source programs for free with GPL'd Qt Designer, but you must pay ("sponser Qt development") to use Qt for closed source programs.
The GPL only covers derived work from the program, not output of a program (according to RMS and others). Otherwise, everytime I used a GPL'd program to write a text file (like to write a book) I would be forced to GPL. That is so insane it would never happen. Of course a clarification would be nice, but almost every court would see it that way.
"Which is fine, until ms updates the appearance of the GUI, or some third party does it (and there are several who have - chroma, windowblinds). When this happens, Qt apps will stand out and probably look pretty ugly, compared to the rest of the system. Think of those boring grey stark bevels sitting inside something like Apple's Aqua, because it doesn't pick up on the *real* native appearance. Ugh. I'm all for fancy interfaces, but please: *consistent* fancy interfaces. Developers and toolkit vendors have to keep that in mind."
If you aren't using the OS's native toolkit, this will always be a problem. Many apps suffer from this program, and it's not just third party software. For example, Microsoft Office on Mac OS and Windows does not use native widgets on either platform for everything.There are countless other examples.
They seem to have invented there own for widgets specfically for the program where needed. This certianly does break WindowBlinds, Kaliedoscope, Color Themes, etc. That's why I avoid themes, and try to go with the native color. If figure that way it has been highly tested, and should be consistant (if the UI developer had half a brain).
Qt and KDE by far are the hardest working widget set/desktop when it comes to trying to match one widget set to another one. Qt apps on Windows, is very similar to the MFC widget set. The screenshots show this is also true on other platforms.
People ask, why don't you just use the native widget set in the first place for everything? That would certainly make everything very consistant. But it would limit the design of advanced features and ease of use, by limiting ideas to one company. Not to mention that often the native widget sets API is difficult to program for, or clumbsy.
Good cross theming as you pointed out, isn't perfect, but it's a good start.
KDE has excellent network transparency, just like the rest of UNIX. Some of the network features are somewhat obscure and not well advertised, but they work.
Examples:
* arts: Designed to work over a network
* kfiledialog: 2.0 version supports things like ftp and mail.
* kedit: As long as I have used it, it can email the currently openned text file to whoever you want (I use this alot for sending test pages to the imaclinux staff list).
* konqueror and kfm: http, ftp, besides the file protocol works. You can relatively add
* dcop/kparts works okay over an network, however it is probably better to use mico for this. mico is still supported by KDE 2, however none of the core apps require it anymore. dcop has the big advantage -- it's very simple and fast (which is good for networks).
I have tried GNOME 1.2, and my feeling were it was passable, but not particularly enjoyable. Then again, I am probably used to doing things the KDE way, and not the GNOME way.
FYI: I went Afterstep -> KDE -> GNOME -> KDE.
Here where my complaints about GNOME (probably partly my fault):
* gmc still sucks. It's gotten better, and more stable, however it has locked up my box hard a few times, it's icons are unprofessional and not eye pleasing. The second problem is a matter of taste. Forently, the GNOME team is addressing both of these problems with Natilus.
* panel's app menu is sluggish, no matter how I change the settings. The kpanel app menu is always fast for me. I think 24-bit color PNG mini images used in the menu are mainly to blame for this. I guess a faster machine might help, although I those mini icons, should probably be 8-bit xpm, which is much faster to load.
* panel is still unstable. I think this is due to the design of the way applets load, and the bonobo panel to applet communication bugs.
* I like to see more intergration between the wm and GNOME, and the same with the file manager.
* Also, I would like to see some scriptablity (like KDE has with kwmcom or dcop command line app).
* grdb doesn't work nearly as well as krdb. Mainly because grdb is based on an really old version of it.
* gdm needs a gui config app
* GNOME feels to unix-ey, and not very Mac-ey or
Window-ey. Part of this is in the design purposely, most of the GNOME creators are UNIX people, who are used to writing UNIX software in motif.
However these problems are relatively minor, they can easily be fixed. There are many excellent GNOME apps that I use everyday in KDE, such as X-Chat, GnomeToaster, gaim, xmms, etc.
While I like GNOME alot, it has many fundimental problems that KDE has addressed. Being able to run GNOME apps almost seemlessly in KDE 2.0, makes KDE very attractive to me, not to menition the numerious other benifits.
PS: I don't give a damn about whatever licensing shit. I just want to use the best. I'll leave licensing up to the lawyers.
Seriously, if you have a half decent computer, it should be plenty of RAM for running multiple widgets and libaries at the same time.
Especially, when an fast machine can have dual 1 ghz proccessors and 1024 meg or so RAM.
Heck, I am stuck with 32 megs of RAM + 64 megs of Swap, on a PowerMac 4400/200 (with a 603ev processor), and don't have any problem running (right now) KDE + Netscape + X-Chat + xmms + gnapster. It gets a bit slow from time to time, but it's really not bad most of the time.
Also, consider using a recent version of Linux 2.2, it has very good swap mangment.
However, note that the Microsoft Word file has much more useful data then that text file. The Microsoft Word file has:
* Almost(?) Unlimited Undo, Even After You Have Saved it, closed it, and reopened it again.
* Formatting. Although this doesn't account for all of it.
So what you have done is basically put two copies of python_bestiary in the document file. Of course, if you look around, by disabling some of the optional features (such as using fast save) you will greatly cut down in size.
Of course not to argue that MS Word shouldn't be compressing their files more, I imagine this will happen more in the future as PC's speed up, and Microsoft can slow down the program.
This is the truth. Helvetica (often 12-pt) is the default font. Helvetica was never meant for a screen font at all -- it was designed for printing headlines.
The standard console font is very nice for console work, but it's too big for X work, and doesn't scale down nicely.
For some reason, Chicago and Charcoal just don't feel right on X. This is probably because they were designed for other GUI's. A good font for X, would need to be bitmap (10, 12, 14 pt.), postscript, and probably truetype. Anti-aliasing would also help, Keith Packard of XFree is doing work on this, I have heard (doing rendering fast client side).
I have to agree it's time for a new X default non-monospaced font. Fixed in X is a pretty good monospaced font, but as it name implies, it's not at all scalable. Something existing just won't cut it -- even KDE's attempts at making a bolder default font (Helvetica Bold 10), seemed out of place.
"Kde 2.0 is already a year behind schedule. A whole year was lost messing with CORBA shit, but everybody seems to forget that. "
A year delay is pretty insignicant compared to the rest of the industry. Look at NT 5, Mac OS X and Windows 95, all released several years later then their orginal planned release date. Not to deny the fact that they have had great improvement over the past few years, as has KDE. KDE 2 beta3 in August 2000, versus an pre-Alpha snapshot one year ago is a totally different beast. KDE 2 today has many new features, it is faster, better designed, and just works better(TM)..
"Sadly, third party developers of Kde apps which work fine with Kde 1.1x have been unable to port their apps to Kde 2 because the base libraries kept changing from week to week or even from day to day. Hopefully there will now be binary and source stability in the infrastructure, but based on failure of Kde to deliver that stability despite promises to do so months ago I suspect that the infrastructure will keep changing in incompatible ways right up to the final release date."
This is true. KDE project clearly noted with these snapshots, that they were highly experimental, and were testing grounds for new technologies, not the actual release. Today, as of the feature freeze of two weeks ago, the API should be considered completely stable -- nothing is bound to change that would break apps for at least 3 or more years. Now is the time KDE app developer should be porting to KDE 2, before it was risky, as it was known that things were broken.
"Since Kde got motivated to actually start releasing 2.0 betas progress has been good. The current snapshots are very usable right now."
Yes, things have gotten alot better, now that they are actually working on a release. The technology and framework, and code was there, so now was the time for them to start focusing in on a release. I have to agree it's comming along nicely.
"However, everybody seems to forget that Kde is much more than what is in the official packages. There are literally hundreds of excellent Kde applications written by people who are not part of the Kde core development team."
Yes, I have to agree. The biggest examples are things like Quanta+, KVirc and KDevelop. However, I use many smaller ones quite often, like Kweather and KBill too. Now that the API is stable, hopefully developers will continue bringing these apps to the next generation of KDE.
"So much time has now gone by that it's a wonder these developers have not abndoned Kde and moved over to the Gnome camp where changes in the base libraries have been incremental and apps can also be incrementally upgraded to stay compatible."
You lost me there. Is this the GNOME that uses GTK+, the library that has had 3 source and binary incompatible stable or in the line to become stable releases in the past 3 years. KDE and Qt have only had 2. Break libraries and software from time to time is neccessary, unforently, progress, and stable design demand it. At least with OSS, the port is not too difficult in most cases.
"If Kde does not do more to make these independent developers feel more involved and appreciated (like providing decent descriptions and links to the application home pages and download sites from the official Kde site for heavens sake) Kde may lose these developers."
Have you ever looked at ftp.kde.org or even around at www.kde.org? On ftp.kde.org, I see lots of KDE apps that aren't included in the main KDE distro. Many quality ones too. devel-home.kde.org hosts several KDE application projects, some are not in the main KDE pacakges. Non-main KDE applications are frequently announced on kde-announce@lists.kde.org.
"Kde doesn't seem to care. It only seems to care about a few prima donna deveopers working on core components who have corporate sponsors. Certainly these hardworking and very talented people must be accomodated, but that is only part of the picture. "
That's not how KDE comes up with there main packages. They take the best, and put in there, even from the non-core developers. They send crap that doesn't work to kdenonbeta, and don't include it the packages -- even if it's from the core developers. If somebody writes enough good patches, or enough good software, they become a core developer. It's not an exclusive club that you make it sound.
"Kde seems to have forgotten what made its application framework so attractive to so many developers - a sense of participation. There now seems to be a sense of elitism or even exclusion, and a boys club mentality that will be Kde's downfall if a concious effort is made to keep it in check."
No, that's just wrong. I think you should refer to my above comment..
Disclamer: I am NOT a KDE developer, just an enthuist who enjoys working with K Desktop Enviroment Technologies. I believe they have worked hard to create an awsome desktop enviroment, one with exterme flexablity and usablity, in some respects far superiour to the commerical desktops. I am a long time Mac user, and enjoy working with high quality user interfaces that work for me. I have used Helix GNOME, WindowMaker, E and several other software pieces, however I still enjoy KDE the best.
Actually YDL and LinuxPPC (both based on RedHat) are more secure then x86 for several reasons.
- inetd.conf services are all commented out on install. The user must uncomment them to use them. That means the user knows he enabling something that could be insecure.
- PPC Specific Exploits are far and few between. The PowerPC is a more complex processor to write asm for, not to mention less popular. Who is going to write an exploit for PowerPC Linux -- when most people are running i386 linux.
- Yellow Dog Linux includes yup, which can be configured to run automatically from cron to download and install the latest security updates, similar to Debian.
- RedHat PowerPC Linux distros come out after the i386 ones, so they have time to spot and fix security problems before shipping.
- Both YDL and LinuxPPC have a good track record at letting people know about problems quickly. They have security related mailing lists.
And yes, Debian for the PowerPC certianly exists. I am running it now.:P And SuSE 6.4 also exists. Read some of the problems you might encounter on a below post.
I am using Debian/PowerPC right now. Yes, I like the package system, it works very good. The FHS is uses works pretty good. Advanced users may want to take a look.
However, Debian has many problems, (some of which are problems on the x86 too).
- There are few PowerPC/PowerMac specific stuff in Debian/PPC now. While more and more is being added, it's still not at the level of established PowerPC distros. Stuff like Mac-on-Linux (Run Mac OS on top of Linux), pmud (Powerbook Battery Control), pmacpow (turn your machine on and off a specific times), vmode (change resolution of FrameBuffer, some claim obsolete), Xpmac (an old, simple, few options but fast X Server), Netscape (the version they have is really old) etc.
- No KDE. I find KDE to be a fast and useful desktop enviroment. Yes, I have heard all of the licensing arguments people make, but most of those arguments are a load of bullcrap. I resent being told what is right and wrong for me. And there are other packages like KDE that won't include for similar reasons. The kde.tdyc.com powerpc.deb's are outdated and limited in what they have.
- Debian is behind on the PowerPC. All new software on the PowerPC comes out in RedHat-like.ppc.rpm, expecting to be installed on a RedHat-like system, with a FHS similar to RedHat. So you can install them on Debian using Alien, but it will put things in the wrong place, and sometimes mess up the configs.
- I have had problems with dpkg uninstalling the wrong versions of programs when I have multiple versions. Maybe it's just my luck.
- The installer is half-baked. Hey, I couldn't even get it to work right. Maybe it was just when I installed it last Spring -- it quite possibly has improved since then.
- apt-get is very cool stuff. I love that program. However, similar systems are being developed, such as yup. Still yup is very immature compared apt-get, it is rapidly improving.
For most people I would recommend (at the current time) to stay away from Debian. Unless you are familar with setting up lots of config files, and doing stuff by hand, Debian isn't the anwser. Debian/PPC is a sweet distro, but in it's current state it requires experience, and careful work on the installer to get it working nicely.
Of course I assume you could apply the same arguments to SuSE, as it has many of the same problems.
All in all, if you are the typical user, and want an install that works out of the box well, get Yellow Dog Linux.
Part of the problem is Altivec patch for GCC produces binary incompatible binaries (with older non-ativec machines). Also, to get the most out of Altivec, you have to call Altivec instructions, which if you don't #ifdef, you will create source that won't compile on normal GCC (and work on non-G4 machines).
Being an anonymous coward, I am sure this is probably a troll, but I'll bite for the hell of it.
"The root problem I think is so much differing hardware. Intel is usually pretty standard. PPC stuff ain't."
PowerPC hardware is actually alot more similar in config from model to model then x86 boxes. The difference in PowerPC proccessors is quite small, as is the hardware. There are only about half a dozen different video cards to worry about. SCSI, Floppy, USB, Serial, etc. are the pretty much the same on every Mac (although not all have those ports). The biggest difference now days between models is new world PCI vs. old world PCI vs. Nubus (which is only starting to be supported).
"There seems to be no central place to report bugs"
It depends on the software. Just like x86 Linux, there is not an universal place to report bugs. It really doesn't help to send a GNOME bug to the Linux PowerPC Kernel Team. For kernel bugs, try sending to linuxppc-dev@lists.linuxppc.org. For packaging bugs, send mail to the place that makes your distro. Questions and comments on LinuxPPC 2k can be posted to linuxppc-user@lists.linuxppc.org. Yellow Dog Linux, SuSE and Debian also have there own ways to get in contact with the packagers (and others).
"I've tried but it seems they just want to ship CDs not record problems."
This would be LinuxPPC, Inc. you are referring to? I have noticed they have a tendency to go with cool, easy to use, over stable and tested, but that's their choice. Other distros (like YDL, Debian and SuSE) are more stable and reliable.
"I'm quite happy to test stuff and see if I can isolate problems, but not if noone is interested in fixing these problems."
I highly doubt your comments and suggestions are falling on deaf ears, no matter how it appears. However note that many of the hackers are very busy, and may not have time to fix stuff right way. Of course if you have made up patches or clear fixes I am sure they would be much more likely to fix them.
"Documentation is worse than non-existent in that it's inaccurate."
This is certianly a problem, as PowerPC Linux is quickly improving, and the documentation is quickly lagging behind. However, excluding the boot process it's almost the same as x86 Linux. If you need post install help for YDL or LPPC, take a look at the RedHat manual, and on the web. For SuSE look at the SuSE documentation and others. There are also lots of Debian documentation.
"Getting hold of the latest source for a specific platform is next to impossible."
Especially nowdays, source tends work between archs without problems. Few Linux programs aren't source compatible with the PowerPC.
"In short it sounds like the Intel Linux of two or three years ago:-)"
- VirtualPC emulates x86 RedHat Linux, at a speed similar to a 66 Mhz 486 on most G3 machines. This means X Windows will be slow, as will many apps (like Netscape). This just doesn't compare to running Linux natively, which is far faster.
- Your running on top of Mac OS. If Mac OS crashes, you lose your Linux stuff. Debian GNU/Linux on my Mac only has downtime caused by me adding or changing hardware, power outages, and that rare time I have to use Mac OS.
- VirtualPC means you are sharing your RAM between Mac OS and Linux. This means you need lots of RAM, and you have to share it (Linux won't be able to use all your 512 Megs or whatever, Mac OS needs some of it).
- VirtualPC is too slow for a server or day to day use.
Good things about VirtualPC with Linux:
- Run Mac OS programs side by side with Linux programs. Actually, you can do this now with PowerPC Linux, thanks to Mac-on-Linux.
- It's preinstalled. No complex installation needed.
With PowerPC Linux if you mess up your configuration, all you have to do is get out your backup (you backup frequently right?!)
Part of the problem is Netscape 4.x is optimized for 603 proccessor, and not the 604/G3 that Internet Explorer is.
<p>Internet Explorer on a 603 is dog slow compared to Netscape Communicator. It's a case of optimization. If Netscape where to change it's compile flags and/or maybe it's compiler, Netscape would be alot faster on newer machines.
Linux supports existing Multiprocessor Macs fairly well. Of course, drivers for this machine won't be avalible right away, (doh!), but I am sure somebody will create them.
In KDE 2, the default Window Manager is kwin. Kwin is designed to be a fully themable and to be compliant with the Window Manager Spec 2.0 (which is to be used with GNOME 2.0). So hopefully in the future, it will be easily replacable with something like Sawmill.
Already, Enlightenment, BlackBox, and WindowMaker have optional compile in support for KDE 1.
For best results, you will still want to use kwin, since kwin is a KDE app, uses KDE themes, and feels very KDE like. Of course nobody is stopping people for writing another Window Manager that is a KDE app (using KDE like menus, themes, etc.). Kwin is slightly more memory efficent then kwm (which had a few bloat problems, IMHO), and supports theme plugins (which are extermely powerful).
That's Qt 1.x you are referring to. Qt 2.x offers very flexable and fast theming support, including gradients. It is the base of KDE theming support (which adds several other functions to theming). All I can say is KDE 2/Qt 2 widgit themes are impressive.
If you actually read the license you would have noticed that in a tie, the winner is always the KDE developers and never Troll Tech. For Troll Tech to win in a license dispute they must get a least 1 of the KDE developers on the team to agree with them.
Troll could not get away with half-hearted development. They must release a major release every tweleve months, and the two KDE representives most agree that it is a major release. Failure to do so, means the Qt license defaults to BSD licensing terms.
Why would Troll stop doing commerical development and continue free development? They wouldn't be making any money, they would quickly go under, and then they wouldn't be able to support Qt Free Edition, so therefore it would go BSD licensed.
The two members of the KDE project are elective representives, choosen by the KDE project as chairs to this committe. The same is true with the two Troll representives. It's a lifetime appointment, unless they retire or do something really bad, they will stay. That way, they are unlikely to be overly influenced by Troll or KDE. They also are not Troll Tech employees or consultants, they are KDE representives. And if you read the license, the worst they can vote on this license is to loosen the terms -- ie. that can't legally add new restrictions.
The people are Troll Tech like Open Source Software, and with the design of the QPL and KDE Free Qt Foundation they must continue to support open source software forever. Nobody is at Troll dislikes OSS -- if they did, why would they be working at a company that the majority of their product is OSS ?
And the last time I checked, their licenses are not legally flawed -- saying so would be going on no clear evidance -- pulling something out of your butt or out of somebodys elses butt.
<p>First off, GNOME is not GPL'd. GNOME libs for example are lgpl'd, as is gtk+, a few parts are BSD licensed. KDE isn't GPL'd either. kdelibs are lgpl'd just like GNOME. kdebase is mainly artistic licensed, although it contains some other licenses. koffice is completely artistic licensed. Other apps are under a variety of free licenses, from BSD to LGPL to GPL to QPL to Artistic. Just like GNOME.
<p>The 30 million dollar question comes down to -- what about those few pesky apps that are under the GPL?
<p>Well, some of the most active developers (like the author of ksysv) have changed there license (ksysv author added a gpl exception). But there are a few KDE apps that the authors have no current way to contact them (their email address are invalid) or they are no longer avalible (dead, moved away, etc.).
<p>What do we do with these programs? 1) Discard them? 2) Move them to kdenonbeta? 3) Change the license without the author's permission? Obviously, if you were one of those authors and had not been notified about one of the above happening, you would be likely pissed, to say the least. It's not fair to discard somebody's hardwork, just because there was a new licensing problem discovered.
<p>The KDE Qt Free Foundation are doing their best to resolve this matter, but it certainly isn't easy. No solution is ideal for either party.
Slashdot Mirror
The term everybody, implies everybody, including authorities.
What Capt. Beyond is referring to is the way laws work in the US, as decided by the supreme court by many cases that laws must be enforced for everybody fairly. This means, you can't selectively pick and choose law, you must enforce it for all violators (when possible). As soon as you stop enforcing the law, it becomes invalid forever, unless it comes to a formal agreement of goverment to enforce it again.
The most famous example of it, is that according to the law books, one driving a motor vechicle in Vermont must have a person waving a red flag, out in front of the car, to warn people of a noisey vechicle coming, that could scare farm animals. Of course, the fact that it's not enforced, means that even if a police officer brought you in for violating this law, the courts would overturn the case, as it hasn't been enforced in almost 100 years.
Another case, is if you see people parking in a no-parking zone everyday (and don't get ticketed), but when you do, you get a ticketed, and can prove that normally people do this without getting ticketed, the courts will dismiss the case.
The division of powers works well in the United States. You claim they represent maintaining the status quo, I have to disgress. In the US, the goverment's sole purpose is protecting peoples freedoms, therefore ensuring the common good. Laws are designed to protect you from stomping on other peoples freedoms (like for example traffic laws, are designed to protect people from hurting others).
"The windows UI is the most extensible UI. You can change it, hook onto it, write plugins for it, and even write scripts for it with DHTML/Javascript. On windows, apps like ICQ and winzip can add to context menus for example - something no other GUI shell has done anywhere near as well."
Mac OS also has the applity for apps Context (Control-Click) Menus to the desktop, as of Mac OS 8.0. Stuffit Deluxe, for example does that. Via. the template feature in KDE 1 you can also add apps own context menus (although this is limited). KDE 2 has even better support for this.
Mac OS since System 5.0, has supported extensions, which can replace any part of System code or ROM loaded into memory with your own version. This is possible to a lesser extent under Linux with kernel modules. Not to mention that higher levels of Linux are totally modular, you can replace bits and parts of them at almost any level (assuming you have permission).
Mac OS uses extensions instead of plugins, see above. They are far more powerful (and potentially dangerous). KDE 2 supports many forms of plugins, including kicker plugins, kwin plugins, filters, and the list goes on...
Linux nor Mac OS can not run scripts in DHTML/Javascript except using a browser. This is a good security pratice, in my experience. Plus they have their own scripting languages, for Linux it's perl (using perl bindings) or bash (using stuff like kwmcom or dcop command line app for GUI stuff), in Mac OS it's AppleScript (which can also do gui stuff).
"generic SCSI - doesn't work on G4s, so no Scanner"
Generic SCSI should work on your machine. You will however need to recompile the kernel with the aic7xxx kernel driver and the SCSI generic support. Some machines (namely older ones with mesh SCSI) still have problems with Linux trying to access scanners to fast (causing a SCSI Target Abort), enable debuging (see lists.linuxppc.org for info) or add some delay loops to the SCSI generic driver.
"smbfs - hard to find as a pre-compiled module, so no access to the NT Server directly"
Get off you butt and recompile the kernel with smbfs support. You really don't expect your distro's default kernel to come compiled with everything on by default?! This certainly works.
"no Appletalk client protocol AFAICT - so no accessing NT Appletask shares, or the other Macs directly"
Yes, there is afpfs which compiles on the PowerPC, and can mount almost all AppleShare over IP disks. However, AppleShare over Localtalk cables isn't supported (and it is being phased out by Apple and Microsoft too.).
The rest of your points are pretty much accurate. One thing, you may want to check out MOL again, as running it in the console has been accelerated lately. The only speed problems I have seen are related to video speed, producing video similar in speed to running Mac OS with Extensions loaded (therefore just basic video accel, nothing fast).
For offical stable releases, KDE almost always has KDE PowerPC RedHat packages at the time of the offical release. Debian, on the other hand -- well the packages alienate fairly well :)
Many PowerPC users use KDE, if you don't believe me, stop into irc.kde.org's KDE development channel - #kde, you will see several PowerPC Linux users.
Nobody is currently making up cvs-snapshots of KDE 2.0 right now, mainly because it takes alot of time and effort to do so, and nobody exactly wants to bother.
Don't worry, I can almost assure you that there will be PowerPC binaries on the offical day of the KDE 2.0 release.
Ian Gerser had made up ppc.rpm for 1.91 soon after the release, he never did get 1.92 up, but he may do 1.93 packages (I don't know).
At any rate, KDE 2.0 is near, doing beta snapshots all of the time is almost a waste of effort.
I think you are miss understanding the point of the GPL. You can design closed-source programs for free with GPL'd Qt Designer, but you must pay ("sponser Qt development") to use Qt for closed source programs.
The GPL only covers derived work from the program, not output of a program (according to RMS and others). Otherwise, everytime I used a GPL'd program to write a text file (like to write a book) I would be forced to GPL. That is so insane it would never happen. Of course a clarification would be nice, but almost every court would see it that way.
"Which is fine, until ms updates the appearance of the GUI, or some third party does it (and there are several who have - chroma, windowblinds). When this happens, Qt apps will stand out and probably look pretty ugly, compared to the rest of the system. Think of those boring grey stark bevels sitting inside something like Apple's Aqua, because it doesn't pick up on the *real* native appearance. Ugh. I'm all for fancy interfaces, but please: *consistent* fancy interfaces. Developers and toolkit vendors have to keep that in mind."
If you aren't using the OS's native toolkit, this will always be a problem. Many apps suffer from this program, and it's not just third party software. For example, Microsoft Office on Mac OS and Windows does not use native widgets on either platform for everything.There are countless other examples.
They seem to have invented there own for widgets specfically for the program where needed. This certianly does break WindowBlinds, Kaliedoscope, Color Themes, etc. That's why I avoid themes, and try to go with the native color. If figure that way it has been highly tested, and should be consistant (if the UI developer had half a brain).
Qt and KDE by far are the hardest working widget set/desktop when it comes to trying to match one widget set to another one. Qt apps on Windows, is very similar to the MFC widget set. The screenshots show this is also true on other platforms.
People ask, why don't you just use the native widget set in the first place for everything? That would certainly make everything very consistant. But it would limit the design of advanced features and ease of use, by limiting ideas to one company. Not to mention that often the native widget sets API is difficult to program for, or clumbsy.
Good cross theming as you pointed out, isn't perfect, but it's a good start.
Please explain to me how KDE is network hobbled?
KDE has excellent network transparency, just like the rest of UNIX. Some of the network features are somewhat obscure and not well advertised, but they work.
Examples:
* arts: Designed to work over a network
* kfiledialog: 2.0 version supports things like ftp and mail.
* kedit: As long as I have used it, it can email the currently openned text file to whoever you want (I use this alot for sending test pages to the imaclinux staff list).
* konqueror and kfm: http, ftp, besides the file protocol works. You can relatively add
* dcop/kparts works okay over an network, however it is probably better to use mico for this. mico is still supported by KDE 2, however none of the core apps require it anymore. dcop has the big advantage -- it's very simple and fast (which is good for networks).
I have tried GNOME 1.2, and my feeling were it was passable, but not particularly enjoyable. Then again, I am probably used to doing things the KDE way, and not the GNOME way.
FYI: I went Afterstep -> KDE -> GNOME -> KDE.
Here where my complaints about GNOME (probably partly my fault):
* gmc still sucks. It's gotten better, and more stable, however it has locked up my box hard a few times, it's icons are unprofessional and not eye pleasing. The second problem is a matter of taste. Forently, the GNOME team is addressing both of these problems with Natilus.
* panel's app menu is sluggish, no matter how I change the settings. The kpanel app menu is always fast for me. I think 24-bit color PNG mini images used in the menu are mainly to blame for this. I guess a faster machine might help, although I those mini icons, should probably be 8-bit xpm, which is much faster to load.
* panel is still unstable. I think this is due to the design of the way applets load, and the bonobo panel to applet communication bugs.
* I like to see more intergration between the wm and GNOME, and the same with the file manager.
* Also, I would like to see some scriptablity (like KDE has with kwmcom or dcop command line app).
* grdb doesn't work nearly as well as krdb. Mainly because grdb is based on an really old version of it.
* gdm needs a gui config app
* GNOME feels to unix-ey, and not very Mac-ey or
Window-ey. Part of this is in the design purposely, most of the GNOME creators are UNIX people, who are used to writing UNIX software in motif.
However these problems are relatively minor, they can easily be fixed. There are many excellent GNOME apps that I use everyday in KDE, such as X-Chat, GnomeToaster, gaim, xmms, etc.
While I like GNOME alot, it has many fundimental problems that KDE has addressed. Being able to run GNOME apps almost seemlessly in KDE 2.0, makes KDE very attractive to me, not to menition the numerious other benifits.
PS: I don't give a damn about whatever licensing shit. I just want to use the best. I'll leave licensing up to the lawyers.
Time to upgrade to at least 32 megs of RAM.
Seriously, if you have a half decent computer, it should be plenty of RAM for running multiple widgets and libaries at the same time.
Especially, when an fast machine can have dual 1 ghz proccessors and 1024 meg or so RAM.
Heck, I am stuck with 32 megs of RAM + 64 megs of Swap, on a PowerMac 4400/200 (with a 603ev processor), and don't have any problem running (right now) KDE + Netscape + X-Chat + xmms + gnapster. It gets a bit slow from time to time, but it's really not bad most of the time.
Also, consider using a recent version of Linux 2.2, it has very good swap mangment.
However, note that the Microsoft Word file has much more useful data then that text file. The Microsoft Word file has:
* Almost(?) Unlimited Undo, Even After You Have Saved it, closed it, and reopened it again.
* Formatting. Although this doesn't account for all of it.
So what you have done is basically put two copies of python_bestiary in the document file. Of course, if you look around, by disabling some of the optional features (such as using fast save) you will greatly cut down in size.
Of course not to argue that MS Word shouldn't be compressing their files more, I imagine this will happen more in the future as PC's speed up, and Microsoft can slow down the program.
This is the truth. Helvetica (often 12-pt) is the default font. Helvetica was never meant for a screen font at all -- it was designed for printing headlines.
The standard console font is very nice for console work, but it's too big for X work, and doesn't scale down nicely.
For some reason, Chicago and Charcoal just don't feel right on X. This is probably because they were designed for other GUI's. A good font for X, would need to be bitmap (10, 12, 14 pt.), postscript, and probably truetype. Anti-aliasing would also help, Keith Packard of XFree is doing work on this, I have heard (doing rendering fast client side).
I have to agree it's time for a new X default non-monospaced font. Fixed in X is a pretty good monospaced font, but as it name implies, it's not at all scalable. Something existing just won't cut it -- even KDE's attempts at making a bolder default font (Helvetica Bold 10), seemed out of place.
"Kde 2.0 is already a year behind schedule. A whole year was lost messing with CORBA shit, but everybody seems to forget that. "
A year delay is pretty insignicant compared to the rest of the industry. Look at NT 5, Mac OS X and Windows 95, all released several years later then their orginal planned release date. Not to deny the fact that they have had great improvement over the past few years, as has KDE. KDE 2 beta3 in August 2000, versus an pre-Alpha snapshot one year ago is a totally different beast. KDE 2 today has many new features, it is faster, better designed, and just works better(TM)..
"Sadly, third party developers of Kde apps which work fine with Kde 1.1x have been unable to port their apps to Kde 2 because the base libraries kept changing from week to week or even from day to day. Hopefully there will now be binary and source stability in the infrastructure, but based on failure of Kde to deliver that stability despite promises to do so months ago I suspect that the infrastructure will keep changing in incompatible ways right up to the final release date."
This is true. KDE project clearly noted with these snapshots, that they were highly experimental, and were testing grounds for new technologies, not the actual release. Today, as of the feature freeze of two weeks ago, the API should be considered completely stable -- nothing is bound to change that would break apps for at least 3 or more years. Now is the time KDE app developer should be porting to KDE 2, before it was risky, as it was known that things were broken.
"Since Kde got motivated to actually start releasing 2.0 betas progress has been good. The current snapshots are very usable right now."
Yes, things have gotten alot better, now that they are actually working on a release. The technology and framework, and code was there, so now was the time for them to start focusing in on a release. I have to agree it's comming along nicely.
"However, everybody seems to forget that Kde is much more than what is in the official packages. There are literally hundreds of excellent Kde applications written by people who are not part of the Kde core development team."
Yes, I have to agree. The biggest examples are things like Quanta+, KVirc and KDevelop. However, I use many smaller ones quite often, like Kweather and KBill too. Now that the API is stable, hopefully developers will continue bringing these apps to the next generation of KDE.
"So much time has now gone by that it's a wonder these developers have not abndoned Kde and moved over to the Gnome camp where changes in the base libraries have been incremental and apps can also be incrementally upgraded to stay compatible."
You lost me there. Is this the GNOME that uses GTK+, the library that has had 3 source and binary incompatible stable or in the line to become stable releases in the past 3 years. KDE and Qt have only had 2. Break libraries and software from time to time is neccessary, unforently, progress, and stable design demand it. At least with OSS, the port is not too difficult in most cases.
"If Kde does not do more to make these independent developers feel more involved and appreciated (like providing decent descriptions and links to the application home pages and download sites from the official Kde site for heavens sake) Kde may lose these developers."
Have you ever looked at ftp.kde.org or even around at www.kde.org? On ftp.kde.org, I see lots of KDE apps that aren't included in the main KDE distro. Many quality ones too. devel-home.kde.org hosts several KDE application projects, some are not in the main KDE pacakges. Non-main KDE applications are frequently announced on kde-announce@lists.kde.org.
"Kde doesn't seem to care. It only seems to care about a few prima donna deveopers working on core components who have corporate sponsors. Certainly these hardworking and very talented people must be accomodated, but that is only part of the picture. "
That's not how KDE comes up with there main packages. They take the best, and put in there, even from the non-core developers. They send crap that doesn't work to kdenonbeta, and don't include it the packages -- even if it's from the core developers. If somebody writes enough good patches, or enough good software, they become a core developer. It's not an exclusive club that you make it sound.
"Kde seems to have forgotten what made its application framework so attractive to so many developers - a sense of participation. There now seems to be a sense of elitism or even exclusion, and a boys club mentality that will be Kde's downfall if a concious effort is made to keep it in check."
No, that's just wrong. I think you should refer to my above comment..
Disclamer: I am NOT a KDE developer, just an enthuist who enjoys working with K Desktop Enviroment Technologies. I believe they have worked hard to create an awsome desktop enviroment, one with exterme flexablity and usablity, in some respects far superiour to the commerical desktops. I am a long time Mac user, and enjoy working with high quality user interfaces that work for me. I have used Helix GNOME, WindowMaker, E and several other software pieces, however I still enjoy KDE the best.
Thank You.
Actually YDL and LinuxPPC (both based on RedHat) are more secure then x86 for several reasons.
:P And SuSE 6.4 also exists. Read some of the problems you might encounter on a below post.
- inetd.conf services are all commented out on install. The user must uncomment them to use them. That means the user knows he enabling something that could be insecure.
- PPC Specific Exploits are far and few between. The PowerPC is a more complex processor to write asm for, not to mention less popular. Who is going to write an exploit for PowerPC Linux -- when most people are running i386 linux.
- Yellow Dog Linux includes yup, which can be configured to run automatically from cron to download and install the latest security updates, similar to Debian.
- RedHat PowerPC Linux distros come out after the i386 ones, so they have time to spot and fix security problems before shipping.
- Both YDL and LinuxPPC have a good track record at letting people know about problems quickly. They have security related mailing lists.
And yes, Debian for the PowerPC certianly exists. I am running it now.
I am using Debian/PowerPC right now. Yes, I like the package system, it works very good. The FHS is uses works pretty good. Advanced users may want to take a look.
.ppc.rpm, expecting to be installed on a RedHat-like system, with a FHS similar to RedHat. So you can install them on Debian using Alien, but it will put things in the wrong place, and sometimes mess up the configs.
However, Debian has many problems, (some of which are problems on the x86 too).
- There are few PowerPC/PowerMac specific stuff in Debian/PPC now. While more and more is being added, it's still not at the level of established PowerPC distros. Stuff like Mac-on-Linux (Run Mac OS on top of Linux), pmud (Powerbook Battery Control), pmacpow (turn your machine on and off a specific times), vmode (change resolution of FrameBuffer, some claim obsolete), Xpmac (an old, simple, few options but fast X Server), Netscape (the version they have is really old) etc.
- No KDE. I find KDE to be a fast and useful desktop enviroment. Yes, I have heard all of the licensing arguments people make, but most of those arguments are a load of bullcrap. I resent being told what is right and wrong for me. And there are other packages like KDE that won't include for similar reasons. The kde.tdyc.com powerpc.deb's are outdated and limited in what they have.
- Debian is behind on the PowerPC. All new software on the PowerPC comes out in RedHat-like
- I have had problems with dpkg uninstalling the wrong versions of programs when I have multiple versions. Maybe it's just my luck.
- The installer is half-baked. Hey, I couldn't even get it to work right. Maybe it was just when I installed it last Spring -- it quite possibly has improved since then.
- apt-get is very cool stuff. I love that program. However, similar systems are being developed, such as yup. Still yup is very immature compared apt-get, it is rapidly improving.
For most people I would recommend (at the current time) to stay away from Debian. Unless you are familar with setting up lots of config files, and doing stuff by hand, Debian isn't the anwser. Debian/PPC is a sweet distro, but in it's current state it requires experience, and careful work on the installer to get it working nicely.
Of course I assume you could apply the same arguments to SuSE, as it has many of the same problems.
All in all, if you are the typical user, and want an install that works out of the box well, get Yellow Dog Linux.
Part of the problem is Altivec patch for GCC produces binary incompatible binaries (with older non-ativec machines). Also, to get the most out of Altivec, you have to call Altivec instructions, which if you don't #ifdef, you will create source that won't compile on normal GCC (and work on non-G4 machines).
Altivec.org has both patches and rpms of patched gcc (and binutils too, I beleive). Also see the Yellow Dog Linux Devel Page, it has some altivec info.
Being an anonymous coward, I am sure this is probably a troll, but I'll bite for the hell of it.
:-)"
:)
"The root problem I think is so much differing hardware. Intel is usually pretty standard. PPC stuff ain't."
PowerPC hardware is actually alot more similar in config from model to model then x86 boxes. The difference in PowerPC proccessors is quite small, as is the hardware. There are only about half a dozen different video cards to worry about. SCSI, Floppy, USB, Serial, etc. are the pretty much the same on every Mac (although not all have those ports). The biggest difference now days between models is new world PCI vs. old world PCI vs. Nubus (which is only starting to be supported).
"There seems to be no central place to report bugs"
It depends on the software. Just like x86 Linux, there is not an universal place to report bugs. It really doesn't help to send a GNOME bug to the Linux PowerPC Kernel Team. For kernel bugs, try sending to linuxppc-dev@lists.linuxppc.org. For packaging bugs, send mail to the place that makes your distro. Questions and comments on LinuxPPC 2k can be posted to linuxppc-user@lists.linuxppc.org. Yellow Dog Linux, SuSE and Debian also have there own ways to get in contact with the packagers (and others).
"I've tried but it seems they just want to ship CDs not record problems."
This would be LinuxPPC, Inc. you are referring to? I have noticed they have a tendency to go with cool, easy to use, over stable and tested, but that's their choice. Other distros (like YDL, Debian and SuSE) are more stable and reliable.
"I'm quite happy to test stuff and see if I can isolate problems, but not if noone is interested in fixing these problems."
I highly doubt your comments and suggestions are falling on deaf ears, no matter how it appears. However note that many of the hackers are very busy, and may not have time to fix stuff right way. Of course if you have made up patches or clear fixes I am sure they would be much more likely to fix them.
"Documentation is worse than non-existent in that it's inaccurate."
This is certianly a problem, as PowerPC Linux is quickly improving, and the documentation is quickly lagging behind. However, excluding the boot process it's almost the same as x86 Linux. If you need post install help for YDL or LPPC, take a look at the RedHat manual, and on the web. For SuSE look at the SuSE documentation and others. There are also lots of Debian documentation.
"Getting hold of the latest source for a specific platform is next to impossible."
Especially nowdays, source tends work between archs without problems. Few Linux programs aren't source compatible with the PowerPC.
"In short it sounds like the Intel Linux of two or three years ago
Good way to end a flame (not, it gives it away
There are a few problems with that approach:
- VirtualPC emulates x86 RedHat Linux, at a speed similar to a 66 Mhz 486 on most G3 machines. This means X Windows will be slow, as will many apps (like Netscape). This just doesn't compare to running Linux natively, which is far faster.
- Your running on top of Mac OS. If Mac OS crashes, you lose your Linux stuff. Debian GNU/Linux on my Mac only has downtime caused by me adding or changing hardware, power outages, and that rare time I have to use Mac OS.
- VirtualPC means you are sharing your RAM between Mac OS and Linux. This means you need lots of RAM, and you have to share it (Linux won't be able to use all your 512 Megs or whatever, Mac OS needs some of it).
- VirtualPC is too slow for a server or day to day use.
Good things about VirtualPC with Linux:
- Run Mac OS programs side by side with Linux programs. Actually, you can do this now with PowerPC Linux, thanks to Mac-on-Linux.
- It's preinstalled. No complex installation needed.
With PowerPC Linux if you mess up your configuration, all you have to do is get out your backup (you backup frequently right?!)
Actually thats kind of backwards. Qt hired some of the KDE developers, because Qt liked there work, and wanted them to fully development.
No, what he means it you need KDE to be installed for this to work -- the code that converts the themes in kdelibs and not qt.
Theming should work fine in Qt only apps, assuming that they don't hard code colors and controls into them (like some Windows apps do).
Part of the problem is Netscape 4.x is optimized for 603 proccessor, and not the 604/G3 that Internet Explorer is.
<p>Internet Explorer on a 603 is dog slow compared to Netscape Communicator. It's a case of optimization. If Netscape where to change it's compile flags and/or maybe it's compiler, Netscape would be alot faster on newer machines.
Yes!
Linux supports existing Multiprocessor Macs fairly well. Of course, drivers for this machine won't be avalible right away, (doh!), but I am sure somebody will create them.
In KDE 2, the default Window Manager is kwin. Kwin is designed to be a fully themable and to be compliant with the Window Manager Spec 2.0 (which is to be used with GNOME 2.0). So hopefully in the future, it will be easily replacable with something like Sawmill.
Already, Enlightenment, BlackBox, and WindowMaker have optional compile in support for KDE 1.
For best results, you will still want to use kwin, since kwin is a KDE app, uses KDE themes, and feels very KDE like. Of course nobody is stopping people for writing another Window Manager that is a KDE app (using KDE like menus, themes, etc.). Kwin is slightly more memory efficent then kwm (which had a few bloat problems, IMHO), and supports theme plugins (which are extermely powerful).
That's Qt 1.x you are referring to. Qt 2.x offers very flexable and fast theming support, including gradients. It is the base of KDE theming support (which adds several other functions to theming). All I can say is KDE 2/Qt 2 widgit themes are impressive.
If you actually read the license you would have noticed that in a tie, the winner is always the KDE developers and never Troll Tech. For Troll Tech to win in a license dispute they must get a least 1 of the KDE developers on the team to agree with them.
Troll could not get away with half-hearted development. They must release a major release every tweleve months, and the two KDE representives most agree that it is a major release. Failure to do so, means the Qt license defaults to BSD licensing terms.
Why would Troll stop doing commerical development and continue free development? They wouldn't be making any money, they would quickly go under, and then they wouldn't be able to support Qt Free Edition, so therefore it would go BSD licensed.
The two members of the KDE project are elective representives, choosen by the KDE project as chairs to this committe. The same is true with the two Troll representives. It's a lifetime appointment, unless they retire or do something really bad, they will stay. That way, they are unlikely to be overly influenced by Troll or KDE. They also are not Troll Tech employees or consultants, they are KDE representives. And if you read the license, the worst they can vote on this license is to loosen the terms -- ie. that can't legally add new restrictions.
The people are Troll Tech like Open Source Software, and with the design of the QPL and KDE Free Qt Foundation they must continue to support open source software forever. Nobody is at Troll dislikes OSS -- if they did, why would they be working at a company that the majority of their product is OSS ?
And the last time I checked, their licenses are not legally flawed -- saying so would be going on no clear evidance -- pulling something out of your butt or out of somebodys elses butt.
Gosh. Can't people learn?
:)
<p>First off, GNOME is not GPL'd. GNOME libs for example are lgpl'd, as is gtk+, a few parts are BSD licensed. KDE isn't GPL'd either. kdelibs are lgpl'd just like GNOME. kdebase is mainly artistic licensed, although it contains some other licenses. koffice is completely artistic licensed. Other apps are under a variety of free licenses, from BSD to LGPL to GPL to QPL to Artistic. Just like GNOME.
<p>The 30 million dollar question comes down to -- what about those few pesky apps that are under the GPL?
<p>Well, some of the most active developers (like the author of ksysv) have changed there license (ksysv author added a gpl exception). But there are a few KDE apps that the authors have no current way to contact them (their email address are invalid) or they are no longer avalible (dead, moved away, etc.).
<p>What do we do with these programs? 1) Discard them? 2) Move them to kdenonbeta? 3) Change the license without the author's permission? Obviously, if you were one of those authors and had not been notified about one of the above happening, you would be likely pissed, to say the least. It's not fair to discard somebody's hardwork, just because there was a new licensing problem discovered.
<p>The KDE Qt Free Foundation are doing their best to resolve this matter, but it certainly isn't easy. No solution is ideal for either party.
<p>Lets all try to get along now