BO actually COULD serve a legitimate purpose, but rootkits really don't.
They can, actually. Picture a newbie wannabe-sysadmin (say, someone who wants to run a webserver for his personal stuff over his new DSL or cable connection). He can install that Linux CD he found in some magazine, then download a rootkit to check if there are any well-known leaks in his newly set up server without necessarily having to understand anything the rootkit does, or having to browse a list of exploits manually (which may fail even if someone bothers to do it - a newbie won't necessarily know that BIND is the DNS server (after all the binary is called named), so (s)he may skip BIND errata right away).
So that's how the history books are being rewritten now
Not quite - it's been that way. Ok, not everyone backed Harmony (the free Qt rewrite), but it did get to a point where it was nearly usable.
KDE never switched over to it simply because it wasn't completed (and eventually discontinued when Qt was open sourced).
How about not basing it on a proprietary toolkit in the first place
KDE didn't start as a "Hey, my OS lacks a decent interface for beginners, let's write one!" project, but as a "I've had a look at Qt, it seems to be possible to do this quickly..." project.
There was no specific plan or development group involved.
Besides, waiting for a decent free toolkit would have delayed the process for quite a while. Or can you name a usable toolkit that existed at that time?
IMO, making use of a proprietary library is OK if it's a temporary thing. Especially when that library is semi-open (you could always port it to your favorite OS and stuff).
The KDE project was dead meat with the original Qt license
If that is so, please explain why Caldera and Corel didn't include Gnome even when Qt was not fully open source. There must have been at least a number of people who disagree with you. (I agree with you though, unless we can assume Harmony would have been finished in Qt's license hadn't changed (and I think so)).
So you are ok with all libraries used in Linux being GPL?
If you have the option to buy different licensing at a reasonable price, yes. I don't see a problem with everyone having to contribute - if someone doesn't want to release his code, have them contribute in other ways.
While they may look at it as one, it isn't - KDE has many more lines of code than Qt.
[Possibility of TrollTech doing Microsoft-like games to prevent competition]
Even if they wanted to do that, they couldn't - how do you hide this sort of thing in GPL code?
Somebody WOULD patch it out and, if necessary, fork the product. If nobody else did, I would.
So how would you change it when the free replacement isn't ready yet?
and eventually had to be forced into changes
Umm... By who? Nobody forced Trolltech to GPL Qt, yet they did.
TrollTech extracts a developer tax on KDE apps
on proprietary KDE apps, that is. And that's fair - what's the problem?
Everyone can contribute - if someone decides not to contribute with his code, why shouldn't he be forced to contribute by paying the people who work on the library?
People writing proprietary software do it for the money. There's no reason they shouldn't share their profit with those who made it possible.
You probably didn't follow KDE development at that time closely enough.
Many KDE developers have always had a problem with the Qt 1.x license, to the point of starting the Harmony project, which was basically a free rewrite of Qt. The project was dumped after TrollTech's announcement that Qt would fall under the BSD license if they stopped developing it (meaning no new release in 6 months), and that Qt 2.0 would be truly Open Source.
The KDE people -ARE- happy inserting proprietary technology into the fundamental infrastucture
Not true (at least not anymore). Even for Qt 1.x, a free replacement was underway.
Wine is an emulator. It just provides winelib, which is an API wrapper. To use winelib rather than wine, you have to recompile, which is something some companies still won't do.
And winelib still isn't as fast as "really" native code - since it's an API wrapper, a lot of structures etc. winelib has to handle are all but optimal for typical Linux usage.
Not quite. RPM has a couple of advantages over debs, as well. Take a look at package building, for example. At least IMO, writing an RPM spec file is much quicker than writing all the files for a debian package. (Actually, the package manager was one of the main reasons why I based my own distribution on Red Hat Linux rather than Debian, which was long before I joined Red Hat.)
Yes, apt-get is nice (and has been ported to work with rpm).
In the long run, I think the best solution is to create a new package manager with the advantages of both systems (hard to do, though, since they follow very different philosophies on some things). It should have a unified package format, but also handle both "old" RPMs and "old".debs.
Get rid of all your spam while making a lot of money! For only $9999.99, you will receive the ultimate brochure on avoiding unsolicited commercial e-mail and unsolicited ads on slashdot! Call 1-900-SPM-HOAX to order the ultimate brochure about anti-spam videos! Forward this ultimate offer to everyone you know, preferably even people you don't know! Free bulk mailing software for this purpose is available right here.
Umm... PLEASE get your facts straight...
WM3M will of course be built with not just QT and GTK, but also Motif, Xaw, FLTK, FOX, wxWindows, winelib and MFC using winelib - it will be interoperable with really everything, and use up just 3 TB of RAM!
What's the error message you get when building the kernel? Did you make mrproper first (read the manual)? What's the bug report number of this problem? We can't fix problems we aren't aware of. (And compiling the kernel definitely works for me).
The services being turned off is intentional for security reasons (read the manual).
Run ntsysv, or "chkconfig ftpd on", "chkconfig telnet on",...
Also, make sure the firewall settings aren't preventing accesses to the services you want to run (read the manual).
They do have a responsibility, and their parents are to blame partially.
However, it's not all - like it or not, this type of conditioning is part of it.
I think games like Doom, Quake and all are harmless if they're played by the right people, but they definitely can get people on the wrong track. If you grow up thinking that shooting people is fun, you're much more likely to try it in the real world.
Are the makers of those games directly responsible? I think no. But those who market them to kids share the guilt.
We have both of those, by the way. In a Red Hat Linux
7.1 or sufficiently similar system, look at
kontrol-panel (in kdeadmin) for a centralized
configuration tool for everything - for an easy
to use web editor with php support and all, look
at Quanta...
The bigger problem is that people aren't aware of those tools. *nix still has the reputation of being hard to use, even though both KDE and GNOME beat Windows.
While Debian is definitely a nice distribution and certainly has some advantages and deserves mentioning and all, please don't spread FUD about Red Hat (or other distributions).
We don't waste all our time looking at stock tickers (actually I have no clue what our current stock price is), and I dare say that redhat-watch-list, redhat-list and all are just as good as their Debian equivalents. I haven't seen any mention of stock on the lists.
Similarily, please provide constructive criticism. Let me know why you claim ISDN didn't work rather than just stating it didn't work. We have isdn-config in 7.0, internet-config in 7.1 - did they give you an error message? Didn't you find them? What's the problem?
It's hard to fix "x doesn't work" if it works perfectly for all of us.
We're building the kernel module actually, so you can use it on filesystems you create after the installation.
That doesn't make it stable though.
Yes, it works well under normal circumstances.
But as soon as something odd happens, it breaks badly.
There are still some known cases of ReiserFS causing filesystem corruption under high load, and its userland recovery tools aren't ready for prime time.
Try recovering from a hardware defect (or a simulated one, try dd if=/dev/random of=/dev/hda offset=something count=10) with ReiserFS, try again with ext2. Notice the difference?
I have no doubt that ReiserFS will eventually get there, but it has quite a way to go before it's really stable for production use.
I don't have Quake 3, but some of the open source 3D games we're shipping in Powertools (Chromium etc.) are working nicely on my Matrox G400 with hardware acceleration enabled.
Most of the ancient documentation still applies, since most of the changes were internal (the database format has changed, we're now using db3 instead of db1, stuff like that).
AFAIK our docs people are currently working on updated documentation.
3 possible fixes, but you probably won't like any of them:
Get more RAM
Install 6.0, then update all packages using rpm -Fvh
Boot from a rescue CD, format your filesystem manually, mkdir -p/mnt/whatever/var/lib/rpm; rpm --initdb; rpm -ivh -r/mnt/whatever the packages you need
Anaconda (the installer we've used since 6.1) has a lot of advantages, but its dependency on python and other stuff comes at a price, it's currently quite a memory hog.
That said, I'm running 7.1 on my router (an ancient K5-100 w/ 32 MB RAM) without problems, installed using method #2.
No, because even on cards that support it well, Antialiasing can cause some problems and should be disabled by default.
Right now, Xrender is known to choose very poor replacements for bitmapped fonts (that can't be antialiased).
Xrender is pretty much a work in progress. We'll enable it by default when we think it's ready.
(Ok, since I (mostly) control the KDE and Qt packages, make that "when I think it's ready" Send bribery in cash^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hgood arguments my way.;) ).
I'll forward your request to our installer people - can't promise anything though.
Just bootdisks won't do, though - unless I'm badly mistaken, the tools handling filesystem creation and stuff are in the second stage image, meaning you won't get around without modified ISOs.
Thanks for your comment - we always welcome constructive feedback.
For your points:
journaling file system: We aren't waiting for ext3 specifically (though we still think it'll be the first stable jfs), we're waiting for any stable jfs. Unlike what you claim, our kernel people have found that ReiserFS isn't ready yet, it still caused heavy filesystem corruption under heavy load tests, and its userland recovery tools don't do much beyond a journal replay. Try to simulate a media defect (e.g. dd if=/dev/random of=/dev/hda offset=something count=3) and try to recover from that. With ext2/ext3, you'll lose some data, but a lot of stuff will remain intact. With ReiserFS, you can lose much more.
Yes, it's getting better and I have no doubt it'll be ready for prime time some time soon, but it's not there yet.
desktop market I presonally agree pretty much, however, Openoffice is nowhere near ready (have you ever tried selling someone a full-fledged office suite that can't print?), and it'll take quite some work to convince everyone that Linux is ready to replace Windows on the desktop.
I think that, at least if you use KDE and install Wine from powertools, you already get a very nice desktop OS, but unfortunately I don't make those decisions.
inetd: It's not that easy for practical purposes. Manipulating the inetd.conf file when you install packages that need to be launched from (x)inetd always has to be some crude hack. xinetd's feature of including all files in a specific directory is very useful there. We could provide an inetd package, but it would be pretty much unsupported because our official packages don't touch inetd.conf. I think it's not worth the trouble.
Are you aware of the fact that you can just run inetdconvert to translate inetd.conf files to xinetd format?
rpm: I think the rpm + up2date combo has all the features you need. If you think there's something we need to add, please let me know.
inputrc: We've had a couple of people complaining about the change, but we've had many more people writing in to let us know we finally got it right. I think this has to be a local configuration thing.
korn shell: I must admit I've never used any shells but bash and zsh. What exactly are the things you're missing in bash? Is the korn shell under an open source license?
requiring several compilers: Yes, this was unfortunate... Related to a relatively tight schedule and the fact that we couldn't know too far in advance whether kernel 2.4 would be ready in time for the 7.0 release, so we basically had to prepare for both cases. (The need for kgcc was purely because of kernel 2.2.x bugs). I don't think this will happen again.
Kernel mixing:Yes, this was a relatively crude hack. Nevertheless, it was the best option we had: With kernel 2.4 not ready for the release, but expected to ship shortly after, we wanted to have a release that will work well if you just update to kernel 2.4 (which we almost achieved). Compiling everything with 2.2 headers in place means it won't be able to use 2.4 specific features even if you install kernel 2.4 -- something we wanted to avoid. And yes, we did (do?) really plan to give people a kernel version upgrade for the 7.0 release, we just expected 2.4 to be ready earlier. Our kernel people say the version we're shipping in 7.1 (meaning 2.4.2+our patches) is the first really usable version of kernel 2.4, because it's the first one that doesn't cause filesystem corruption under heavy load. I don't know if the plan to release a 2.4 update for 7.0 is still current, now that we know 7.1 and a stable 2.4 kernel are appearing at the same time.
Besides, we aren't worrying about Mandrake or Suse - actually we're quite glad they're around. If they play fair [If anyone at Suse is reading this: Please start by putting yast under a reasonable license. Thanks.], everything they do is nice work for us, and we don't even need to pay them for it.;)
Slashdot Mirror
BO actually COULD serve a legitimate purpose, but rootkits really don't.
They can, actually. Picture a newbie wannabe-sysadmin (say, someone who wants to run a webserver for his personal stuff over his new DSL or cable connection). He can install that Linux CD he found in some magazine, then download a rootkit to check if there are any well-known leaks in his newly set up server without necessarily having to understand anything the rootkit does, or having to browse a list of exploits manually (which may fail even if someone bothers to do it - a newbie won't necessarily know that BIND is the DNS server (after all the binary is called named), so (s)he may skip BIND errata right away).
So that's how the history books are being rewritten now
Not quite - it's been that way. Ok, not everyone backed Harmony (the free Qt rewrite), but it did get to a point where it was nearly usable.
KDE never switched over to it simply because it wasn't completed (and eventually discontinued when Qt was open sourced).
How about not basing it on a proprietary toolkit in the first place
KDE didn't start as a "Hey, my OS lacks a decent interface for beginners, let's write one!" project, but as a "I've had a look at Qt, it seems to be possible to do this quickly..." project.
There was no specific plan or development group involved.
Besides, waiting for a decent free toolkit would have delayed the process for quite a while. Or can you name a usable toolkit that existed at that time?
IMO, making use of a proprietary library is OK if it's a temporary thing. Especially when that library is semi-open (you could always port it to your favorite OS and stuff).
The KDE project was dead meat with the original Qt license
If that is so, please explain why Caldera and Corel didn't include Gnome even when Qt was not fully open source. There must have been at least a number of people who disagree with you. (I agree with you though, unless we can assume Harmony would have been finished in Qt's license hadn't changed (and I think so)).
So you are ok with all libraries used in Linux being GPL?
If you have the option to buy different licensing at a reasonable price, yes. I don't see a problem with everyone having to contribute - if someone doesn't want to release his code, have them contribute in other ways.
KDE is a DEMO for TrollTech
While they may look at it as one, it isn't - KDE has many more lines of code than Qt.
[Possibility of TrollTech doing Microsoft-like games to prevent competition]
Even if they wanted to do that, they couldn't - how do you hide this sort of thing in GPL code?
Somebody WOULD patch it out and, if necessary, fork the product. If nobody else did, I would.
It's also pretty much a C vs. C++ thing - most people who prefer Gnome also hate C++.
Coincidentally, many Americans I know hate C++, while many Europeans I know like it.
They built their project on a proprietary library
While writing a free replacement
they were told about it, refused to change it
So how would you change it when the free replacement isn't ready yet?
and eventually had to be forced into changes
Umm... By who? Nobody forced Trolltech to GPL Qt, yet they did.
TrollTech extracts a developer tax on KDE apps
on proprietary KDE apps, that is. And that's fair - what's the problem?
Everyone can contribute - if someone decides not to contribute with his code, why shouldn't he be forced to contribute by paying the people who work on the library?
People writing proprietary software do it for the money. There's no reason they shouldn't share their profit with those who made it possible.
You probably didn't follow KDE development at that time closely enough.
Many KDE developers have always had a problem with the Qt 1.x license, to the point of starting the Harmony project, which was basically a free rewrite of Qt. The project was dumped after TrollTech's announcement that Qt would fall under the BSD license if they stopped developing it (meaning no new release in 6 months), and that Qt 2.0 would be truly Open Source.
The KDE people -ARE- happy inserting proprietary technology into the fundamental infrastucture
Not true (at least not anymore). Even for Qt 1.x, a free replacement was underway.
Wine is an emulator. It just provides winelib, which is an API wrapper. To use winelib rather than wine, you have to recompile, which is something some companies still won't do.
And winelib still isn't as fast as "really" native code - since it's an API wrapper, a lot of structures etc. winelib has to handle are all but optimal for typical Linux usage.
Not quite. RPM has a couple of advantages over debs, as well. Take a look at package building, for example. At least IMO, writing an RPM spec file is much quicker than writing all the files for a debian package. (Actually, the package manager was one of the main reasons why I based my own distribution on Red Hat Linux rather than Debian, which was long before I joined Red Hat.)
.debs.
Yes, apt-get is nice (and has been ported to work with rpm).
In the long run, I think the best solution is to create a new package manager with the advantages of both systems (hard to do, though, since they follow very different philosophies on some things). It should have a unified package format, but also handle both "old" RPMs and "old"
They didn't even pay him for it -- renaming their "in dos" Operating system to " W in do W s" in his honor was sufficient.
Get rid of all your spam while making a lot of money! For only $9999.99, you will receive the ultimate brochure on avoiding unsolicited commercial e-mail and unsolicited ads on slashdot! Call 1-900-SPM-HOAX to order the ultimate brochure about anti-spam videos! Forward this ultimate offer to everyone you know, preferably even people you don't know! Free bulk mailing software for this purpose is available right here.
Don't miss this incredible opportunity!
Umm... PLEASE get your facts straight...
WM3M will of course be built with not just QT and GTK, but also Motif, Xaw, FLTK, FOX, wxWindows, winelib and MFC using winelib - it will be interoperable with really everything, and use up just 3 TB of RAM!
What's the error message you get when building the kernel? Did you make mrproper first (read the manual)? What's the bug report number of this problem? We can't fix problems we aren't aware of. (And compiling the kernel definitely works for me).
...
The services being turned off is intentional for security reasons (read the manual).
Run ntsysv, or "chkconfig ftpd on", "chkconfig telnet on",
Also, make sure the firewall settings aren't preventing accesses to the services you want to run (read the manual).
So you probably have some broken BIOS that tells the kernel it has only 32 MB RAM.
What's the bug report number for this? Oh, there is none.
Users who complain, but don't report bugs to us continue to not impress me.
They do have a responsibility, and their parents are to blame partially.
However, it's not all - like it or not, this type of conditioning is part of it.
I think games like Doom, Quake and all are harmless if they're played by the right people, but they definitely can get people on the wrong track. If you grow up thinking that shooting people is fun, you're much more likely to try it in the real world.
Are the makers of those games directly responsible? I think no. But those who market them to kids share the guilt.
We have both of those, by the way. In a Red Hat Linux 7.1 or sufficiently similar system, look at kontrol-panel (in kdeadmin) for a centralized configuration tool for everything - for an easy to use web editor with php support and all, look at Quanta... The bigger problem is that people aren't aware of those tools. *nix still has the reputation of being hard to use, even though both KDE and GNOME beat Windows.
While Debian is definitely a nice distribution and certainly has some advantages and deserves mentioning and all, please don't spread FUD about Red Hat (or other distributions).
We don't waste all our time looking at stock tickers (actually I have no clue what our current stock price is), and I dare say that redhat-watch-list, redhat-list and all are just as good as their Debian equivalents. I haven't seen any mention of stock on the lists.
Similarily, please provide constructive criticism. Let me know why you claim ISDN didn't work rather than just stating it didn't work. We have isdn-config in 7.0, internet-config in 7.1 - did they give you an error message? Didn't you find them? What's the problem?
It's hard to fix "x doesn't work" if it works perfectly for all of us.
7.1 supports them. Getting a DSL or cable connection up is as easy as calling "internet-config" and filling out a form.
AFAIK we aren't providing support for it at installation time ATM, so you can't run a network install over DSL.
We're building the kernel module actually, so you can use it on filesystems you create after the installation.
That doesn't make it stable though.
Yes, it works well under normal circumstances.
But as soon as something odd happens, it breaks badly.
There are still some known cases of ReiserFS causing filesystem corruption under high load, and its userland recovery tools aren't ready for prime time.
Try recovering from a hardware defect (or a simulated one, try dd if=/dev/random of=/dev/hda offset=something count=10) with ReiserFS, try again with ext2. Notice the difference?
I have no doubt that ReiserFS will eventually get there, but it has quite a way to go before it's really stable for production use.
I don't have Quake 3, but some of the open source 3D games we're shipping in Powertools (Chromium etc.) are working nicely on my Matrox G400 with hardware acceleration enabled.
Most of the ancient documentation still applies, since most of the changes were internal (the database format has changed, we're now using db3 instead of db1, stuff like that).
AFAIK our docs people are currently working on updated documentation.
Anaconda (the installer we've used since 6.1) has a lot of advantages, but its dependency on python and other stuff comes at a price, it's currently quite a memory hog.
That said, I'm running 7.1 on my router (an ancient K5-100 w/ 32 MB RAM) without problems, installed using method #2.
No, because even on cards that support it well, Antialiasing can cause some problems and should be disabled by default.
;) ).
Right now, Xrender is known to choose very poor replacements for bitmapped fonts (that can't be antialiased).
Xrender is pretty much a work in progress. We'll enable it by default when we think it's ready.
(Ok, since I (mostly) control the KDE and Qt packages, make that "when I think it's ready" Send bribery in cash^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hgood arguments my way.
Because it's not really stable yet.
I'll forward your request to our installer people - can't promise anything though.
Just bootdisks won't do, though - unless I'm badly mistaken, the tools handling filesystem creation and stuff are in the second stage image, meaning you won't get around without modified ISOs.
For your points:
Yes, it's getting better and I have no doubt it'll be ready for prime time some time soon, but it's not there yet.
I think that, at least if you use KDE and install Wine from powertools, you already get a very nice desktop OS, but unfortunately I don't make those decisions.
Are you aware of the fact that you can just run inetdconvert to translate inetd.conf files to xinetd format?
Besides, we aren't worrying about Mandrake or Suse - actually we're quite glad they're around. If they play fair [If anyone at Suse is reading this: Please start by putting yast under a reasonable license. Thanks.], everything they do is nice work for us, and we don't even need to pay them for it.