I know (I was just replying to someone saying make world was much better than the RPM system). I disagree about the dependency checking part though - stuff that is not part of the operating system (compiled by hand, "installed" by copying files from a different computer, or stuff from the ports collection in FreeBSD) can depend on a specific version of a library or such. make world isn't designed to address this sort of thing.
There's a bug in your HOWTO - it assumes you actually know people who might be interested and you can choose.;) There's no such thing as "free tours for female singles through the Red Hat development offices so we can talk to them"...;)
While I understand the advantages of updating the entire system, let's not ignore that there are some reasons for doing C libraries and all with the package manager as well...
make world on FreeBSD takes ages on a 486. rpm -U *libc* *kernel* is fast even there.
It's easier for end users who don't know anything about programming (believe me, some people ARE too stupid to do make world; make install. They're not too stupid to use kpackage).
Dependancy checking
Re:Some comments... (not supposed to be flamebait)
on
KDE Looks Ahead
·
· Score: 2
Kanossa: Speed is not the only reason to make the change. Stability is the other one. mico-c++ was never as stable as we'd need it. DCOP: It's basically a wrapper around libICE, which is a well known X11 standard that just didn't get as much attention as it should have, and it's entirely possible to build a wrapper that transfers requests from other systems to DCOP.
Re:KDE becomes more and more like closed software
on
KDE Looks Ahead
·
· Score: 2
KDE doesn't move away from standards without a good reason. CORBA is used less (NOT dropped) because it had severe speed, memory usage, and stability problems. Compare the CORBA version of koffice (which has been around for ages) with the 3 days old Kanossa based version and yoU'll see the difference.
Also, it is not impossible to write a CORBA wrapper for DCOP.
We have konqueror, which is based on kfm, and does pretty much the same things Mozilla does. I don't see a real need to integrate Mozilla - why have 2 things that do the same?
Re:What is the level of interoperability?
on
KDE Looks Ahead
·
· Score: 2
There's no problem exchanging files and such. The interoperability problems that are there are mostly because of the totally different nature of the libraries, therefore, you can't for example do Drag and Drop from a KDE application to a GNOME application or vice versa. But you can run GNOME programs on the KDE desktop and vice versa, that's not a problem.
WindowMaker is KDE compliant by the way - if you don't like KDE's window manager, don't use it. KDE gets along well with both WindowMaker and Enlightenment 0.16...
Can you tell me some more about those make errors? I can't reproduce them.
if Microsoft had spent this long releasing a long-awaited product, the release of a new beta would be an opportunity to mock them
Right - but in their betas, there's no real progress - W2000 beta 3 is not more reliable than beta 2 (it does fix some bugs - and introduces others to take their place). With the Mozilla builds, we at least see some progress.
The war is over
Not quite - it may be over in the Windoze world (for now - that doesn't mean it won't change!), but not in the rest of the world... And with Linux getting more important, products that are cross-platform are getting more important, and nobody sane would call Internet Exploiter cross-platform.
People WILL consider alternatives like Netscape or Opera if it means they can use it on every machine they're using, and not just the one running Windoze.
release browser components
Take a look at (for example) the KDE libraries: There's a HTML display widget, there are http handling classes, there's the beginning of Java support (in 2.0 CVS), and there's more.
Spend all your free time making a nice install, and new package manager that works great, and then make packages for every program 3 times (sparc alpha intel). Then when your done tell me, i'll come over and take it and put my name on it and sell it. Your hard work, my hard money.
No problem with that, if
you don't remove my name
you keep adding your own stuff and release it under the GPL or a similar license so I can use it in my version, too
you don't say "the original version sucks!!! Mine is the only way to go!" (This does not include listing your advantages, of course!)
So what's wrong with Red Hat? Don't say "managed to screw up" without giving even a hint of a reason. "It's the only Linux Distro that people compare to Microsoft products" is hardly a reason - the primary reason for this is that the bigger distributions are of course the first ones to get compared. Besides, not everything about Microsoft products is bad. If you say Windows sucks, I'm the first to agree. But that doesn't mean it doesn't have any features we should be (and already have been) taken over. The really bad things about most Microsoft products are their instability, bloat, lacking security, the concept of payware and closed-source, and the close-to-impossibility to get a bug fixed if you report it. Can you see any of those in RedHat 6.1? If so, let me know and I'll be glad to fix it for 6.2.
but mandrake just takes all the work adds kde and calls it their own
This was once true (if you don't count that the early Mandrake versions added some non-KDE packages such as licq, as well), but definitely is no longer the case.
By now, both distributions do their work - and copy over patches from the other, of course. There's nothing wrong with that, it's what free software is all about. (Yes, this does work both ways - it should be quite obvious that Mandrake inherited a lot of stuff from Red Hat, but also, any Red Hat 6.1 user who has used Mandrake before will already be familiar with some KDE customizations.)
Sure - edit/usr/lib/rpm/rpmrc to get the flags you need, then rpm --rebuild *.
If you want speed, you'll probably want to use gcc 2.95.1 or pgcc 1.1.3. gcc 2.95.1 has problems compiling some packages because it got stricter ANSI and also modified the asm() syntax a bit, and not everything got fixed yet. I'll put up an archive of gcc 2.95.x-related patches soon. (as soon as the admins give me the space I need, that is;) ).
What is the precise relationship between Mandrake and RedHat linux distributions these days?
They use the same basic tools, and are developing their distributions independantly.
Patches that make sense are usually taken over from one distribution to another (it's obvious that Mandrake is using a lot of Red Hat code from the way it started - now it works both ways. Look at the KDE packages from RH 6.1 to see an example of Red Hat making use of Mandrake code).
Slashdot Mirror
I know (I was just replying to someone saying make world was much better than the RPM system).
I disagree about the dependency checking part though - stuff that is not part of the operating system (compiled by hand, "installed" by copying files from a different computer, or stuff from the ports collection in FreeBSD) can depend on a specific version of a library or such. make world isn't designed to address this sort of thing.
It's not THAT complicated...
Actually I have an RPMified FreeBSD testbox. (not finished though - but I do have libc RPMs and such).
There's a bug in your HOWTO - it assumes you actually know people who might be interested and you can choose. ;) ;)
There's no such thing as "free tours for female singles through the Red Hat development offices so we can talk to them"...
rpm -U *libc* *kernel* is fast even there.
Kanossa: Speed is not the only reason to make the change. Stability is the other one. mico-c++ was never as stable as we'd need it.
DCOP: It's basically a wrapper around libICE, which is a well known X11 standard that just didn't get as much attention as it should have, and it's entirely possible to build a wrapper that transfers requests from other systems to DCOP.
KDE doesn't move away from standards without a good reason.
CORBA is used less (NOT dropped) because it had severe speed, memory usage, and stability problems.
Compare the CORBA version of koffice (which has been around for ages) with the 3 days old Kanossa based version and yoU'll see the difference.
Also, it is not impossible to write a CORBA wrapper for DCOP.
We have konqueror, which is based on kfm, and does
pretty much the same things Mozilla does.
I don't see a real need to integrate Mozilla - why have 2 things that do the same?
There's no problem exchanging files and such.
The interoperability problems that are there are mostly because of the totally different nature of the libraries, therefore, you can't for example do Drag and Drop from a KDE application to a GNOME application or vice versa.
But you can run GNOME programs on the KDE desktop and vice versa, that's not a problem.
WindowMaker is KDE compliant by the way - if you don't like KDE's window manager, don't use it.
KDE gets along well with both WindowMaker and Enlightenment 0.16...
Can you tell me some more about those make errors? I can't reproduce them.
if Microsoft had spent this long releasing a long-awaited product, the release of a new beta would be an opportunity to mock them
Right - but in their betas, there's no real progress - W2000 beta 3 is not more reliable than beta 2 (it does fix some bugs - and introduces others to take their place). With the Mozilla builds, we at least see some progress.
The war is over
Not quite - it may be over in the Windoze world (for now - that doesn't mean it won't change!), but not in the rest of the world...
And with Linux getting more important, products that are cross-platform are getting more important, and nobody sane would call Internet Exploiter cross-platform.
People WILL consider alternatives like Netscape or Opera if it means they can use it on every machine they're using, and not just the one running Windoze.
release browser components
Take a look at (for example) the KDE libraries: There's a HTML display widget, there are http handling classes, there's the beginning of Java support (in 2.0 CVS), and there's more.
And you even get a "sample" browser - konqueror.
Linux 2.3 *IS* frozen, and has been for
quite a while.
No problem with that, if
So what's wrong with Red Hat?
Don't say "managed to screw up" without giving even a hint of a reason.
"It's the only Linux Distro that people compare to Microsoft products" is hardly a reason - the primary reason for this is that the bigger distributions are of course the first ones to get compared.
Besides, not everything about Microsoft products is bad. If you say Windows sucks, I'm the first to agree. But that doesn't mean it doesn't have any features we should be (and already have been) taken over.
The really bad things about most Microsoft products are their instability, bloat, lacking security, the concept of payware and closed-source, and the close-to-impossibility to get a bug fixed if you report it.
Can you see any of those in RedHat 6.1? If so, let me know and I'll be glad to fix it for 6.2.
but mandrake just takes all the work adds kde and calls it their own
This was once true (if you don't count that the early Mandrake versions added some non-KDE packages such as licq, as well), but definitely is no longer the case.
By now, both distributions do their work - and copy over patches from the other, of course. There's nothing wrong with that, it's what free software is all about. (Yes, this does work both ways - it should be quite obvious that Mandrake inherited a lot of stuff from Red Hat, but also, any Red Hat 6.1 user who has used Mandrake before will already be familiar with some KDE customizations.)
Sure - edit /usr/lib/rpm/rpmrc to get the flags
;) ).
you need, then rpm --rebuild *.
If you want speed, you'll probably want to use gcc 2.95.1 or pgcc 1.1.3.
gcc 2.95.1 has problems compiling some packages because it got stricter ANSI and also modified the asm() syntax a bit, and not everything got fixed yet.
I'll put up an archive of gcc 2.95.x-related patches soon. (as soon as the admins give me the space I need, that is
What is the precise relationship between Mandrake and RedHat linux distributions these days?
They use the same basic tools, and are developing their distributions independantly.
Patches that make sense are usually taken over from one distribution to another (it's obvious that Mandrake is using a lot of Red Hat code from the way it started - now it works both ways. Look at the KDE packages from RH 6.1 to see an example of Red Hat making use of Mandrake code).