1. That depends on you demands. Sure, it's not as tested as RHEL or Debian stable, but it doesn't crash every 5 minutes either. In fact, I've yet to see Fedora crash.
2. FUD. It's impossible to choose a default install that every single person in the world is completely satisfied with. You need to learn how to uninstall things.
3. So, having GUI tools for 50% of the tasks is worse than having no tools at all? That's just dumb...and even if you think so, uninstall or do not use the GUI tools!
4. Huh? Fedora Core + Extras has around 3000 packages. How many are there in Debian stable? More importantly, how many do you need? And btw, did you not just say that Fedora was bad because of "extra cruft"?
5. That is not a bad thing. Nobody is forcing you to upgrade, just because there's a new version available (see 6).
6. That is the only valid argument, and the only reason to upgrade. There is however a community project called Fedora Legacy (www.fedoralegacy.org) that provides security updates for EOL'ed Fedora/Red Hat products.
7. Well, it's doable with apt or yum, but it's not the supported or recommended way. You need to reboot your Debian servers on upgrade as well, to switch kernels.
As someone else pointed out, MS prices do not include support. Moreover, when you buy from Red Hat, you don't buy RHEL 3 - you buy RHEL. That means that upgrades are free as long as you are subscribed. You may upgrade as often, or as rarely, as you like. A new version of RHEL is released about every 18 months.
The flickering is due to the fact that QT is not double-buffered. There are, AFAIK, tricks to make applications/widgets double-buffered, but it's not toolkit-wide. Gtk is, however.
There is a speed vs. eyecandy/usability tradeoff involved.
Hrm, I think some of the information about RPM needs to be clarified.
1) RPMs are distributed as upstream source + any number of patches. That's equivalent.
2) RPM calculates dependencies by looking at what libraries are linked to by any of the files in that package. You never specify a dependency on say, "gtk2", that is done by RPM. Except for the case when a program calls an external binary, such as k3b depends on cdrecord.
3) RPM has everything but suggests and recommends.
4) Not sure what you mean there, but I think it's about packaging different versions of the same library to be installed in parallell, like qt-2.3.1-1 and qt3-3.1.1-1? Debian does that too, I don't know what's automated in that process however.
5) RPM has pre, post, preun and postun scriptlets. Those are simply short shell scripts that are run at install/uninstall. How is that any different?
6) RPM has a policy of never asking any questions during install. IIRC you can set the ask-questions-level to "never" in Debian, which would be equivalent. Nice thing to have though.
7) RPM has Provides:
8) Well...you need rpm, rpm-build and popt. Maybe not as standard as ar/tar/gz, but by no means impossible.
9) Logging is possible on the dependency manager level (yum/apt/up2date etc). I don't see why you'd need additional logging at the lower package manager level.
That should make the list a bit shorter. I'd agree that DEBs are a bit more feature-rich, mainly because of the configuration abilities and suggests/recommends stuff, but the difference is not that big.
The main advantage of Debian packages is not in the file format, but in the fact that there are basically no 3:rd party packages. They are all in (one of ) the main Debian repository(-ies), and are therefore compatible. What do you think would happen if there were to appear 10 dpkg-based distros, with package names and packaging guidelines each slightly different from each other, and from Debian?
For Fedora Core users, the Nvidia graphics driver is already packaged, and soon ATI's driver will be too. Installation is one command:
yum install nvidia-glx (or fglrx)
That's it. No configuration, no compilation, nothing. You don't even have to reboot. Even easier than Windows. The drivers are provided by the Livna.org repository (http://rpm.livna.org).
Progress on the ATI driver can be monitored here:
http://bugzilla.livna.org/show_bug.cgi?id=211
As of right now, the published version of the Nvidia driver is 1.0.6106, with 6111 coming out shortly.
Some of the improvments made by the livna re-packaging can be read about here:
http://rpm.livna.org/livna-switcher.html
The same applies to the ATI driver.
Note: an ATI employee (M Tippett) has been heavily involved in the packaging process, which shows real committment from ATI's side. Nvidia has not even bothered to answer a request to put a link on their driver download page to rpm.livna.org.
"Additionally HP-UX, Linux, NetApp NetCache, Solaris and recent releases of FreeBSD cycle back to zero after 497 days, exactly as if the machine had been rebooted at that precise point. Thus it is not possible to see a HP-UX, Linux or Solaris system with an uptime measurement above 497 days."
http://uptime.netcraft.com/up/accuracy.html#whic ho s
Holy Dogshit! So there really are people around that haven't heard about automatic dependency resolvers such as apt, yum, up2date, yast, urpmi or portage...even more amazing is that can be moderated insightful.
Actually, Apache is already included in WS.
According to this (all the way down), you get Apache, NFS and Samba in WS 3.0. You need ES or AS if you need the following servers:
Now, before everyone goes "I knew it! ext3 sux!!!!111!!1", remember that the default mode for ext3 is ordered, and not journal. Compare the numbers for ext3_ordered and ext3_writeback with reiser/xfs/jfs, and you'll see that ext3 is very very close in most cases.
Andrej Gromyko (former Soviet Union Sect. of State) wrote in his autobiography about Mao Tse Tung's plan to destroy the capitalist forces sometime in the 60's or 70's. It went something like this: first, China would invade Taiwan. This would make US/Nato respond by taking back Taiwan, and move onto the Chinese mainland, where the Chinese forces would fall back to the Gobi desert. Meanwhile, the Soviet Union would be passive, and even a little pro-American. Then, when least expected, the Soviet Union would launch a nuclear attack on the Nato forces in the Gobi desert, destroying them. Mao estimated about 200 million dead chinese, which was an acceptable price to pay...
In Debian, you have the file format.deb, low-level package tool dpkg, and high-level package tool apt. In Red Hat, you have the file format.rpm, low-level package tool rpm, and high-level package tool up2date (or apt, which is available for RH and various other rpm based distros). In Mandrake, you have the file format.rpm, low-level package tool rpm, and high-level package tool urpmi.
Do not compare apt with rpm. Saying "apt is better than rpm" is like saying "2 meters is more than 2 minutes". It doesn't make sense. ___
Here we go again...
If you think that having no package manager, or having a very simple package manager, is better than rpm or dpkg you are simply wrong. Let me tell you why:
Dependencies are there for a reason. Just because you can install kdebase.tgz without having qt installed, doesn't mean it will run. Too obvious example? Well, name all libs that you need in order to run Galeon? Or what libs you need to update to what versions if you want to upgrade Galeon from 1.2 to 1.4?
The metadata (dependencies) that come with rpm/dpkg also makes it possible to write and use tools as apt/urpmi/up2date, to automatically download and install software with a single command.
Everything that you can do with a.tgz package, you can do with rpm/dpkg. Everything that you can do with a source tarball, you can do with a.src.rpm/dpkg_equiv., with the possible additional (small) overhead of editing a spec file. End of story.
No/primitive package management is simply a subset of rpm/dpkg. Here's how to downgrade rpm to the equivalent of Slack's pkg manager:
echo "alias rpm='rpm --nodeps --force $*'" >>/root/.bashrc
There, no dependency checking.
RedHat, Mandrake and SuSE are all installable "across the net with a single floppy". And they all have apt or equivalent tools included. That's what you will learn by not using Debian exclusively.
Red Hat compiles their packages with -mcpu=i686, which means that they are optimized for i686 but still runs on i386 (with -march=i686, the binary won't run on anything lower than i386). Important packages, such as kernel and glibc are compiled with the -march option, that is if you install it on a Pentium, you get the i586 rpm and so on.
If you want to, you can always rebuild the source rpms for packages like X or GTK or whatever, and use the "--target " switch to rpmbuild. That will optimize for your architecture. Look at/usr/lib/rpm/rpmrc for details on compiler flags.
How do they force you? Just find the config file, edit it in your favourite text editor, save it and restart whatever program you wanted to customize. You don't even have to install the gui tools.
This is a widespread misconception - that Galeon is much much "lighter" than Mozilla. On my system (RH7.2, p3/866 512M) Mozilla uses 19M of RAM, and Galeon 17M immediatley after startup and loading www.gnome.org. All according to top. Startup time doesn't differ much either, rendering speed almost identical (as it should be). The only thing is that on slow machines (less than 500 MHz), menus and such - the chrome - on Mozilla is noticably slower than the GTK interface on Galeon. On my machine though, I can't tell the difference.
AND bear in mind that XUL is a very complex peice of software that brings something new to software development. It is not bloat. Also, it is nowhere nere as fast in Linux as in Windows, due to (i guess) more optimization in the Windows specific parts.
Recent packages. Also, quite a lot of experimental performance-enhancing patches in their kernel tree (preemptible, low-latency scheduler and probably more that I don't know about). And yes, you may install the vanilla kernel if you like. It's just a matter of "emerge gentoo-sources" or "emerge vanilla-sources".
Re:I like Slackware -- Who Decides Dependency?
on
Is RPM Doomed?
·
· Score: 1
That's a interesting point - however, dependencies are closely linked to what features are compiled into a program. Let's say you want to package Nautilus: it's possible to disable mozilla support at compile-time, removing the need for mozilla to be installed. But then you remove an important part of functionality. Or, you could try to split the package into speperate pieces where that is possible (nautilus/nautilus-mozilla or mozilla/mozilla-mailnews/mozilla-irc etc), but that won't always work either.
It's always a tradeoff, and there's always someone who isn't satisfied. Say you put everything realted to Gnome in one package - very easy to install, and probably doesn't have a lot of external dependencies except obvious ones like X and glibc. But then someone shouts "Bloat!", because he or she doesn't want to have Evolution installed jut to run Xchat. On the other hand, if you look at Gnome now, it's at least 10 different packages on top of X that you need to install (and run) Xchat. Which is better?
I short, it's impossible to please everyone at the same time. If you're not satisfied with the way someone else has done the job for you, do it yourself.
Re:I like Slackware's .tgz
on
Is RPM Doomed?
·
· Score: 1
Well, what do you think the dependencies are for? They are packages (programs/libraries) that you need in order to use whatever you're trying to install. That's just it. You can't drop dependency checking and then think you can install (and actually use), say, Mozilla without installing X.
From what I've read here on/., 99% of all people who say "Package mangement is bad" simply do not know how to use it - rpm, dpkg/apt or what-have-you.
Btw, if you by "cicular dependencies" mean that "rpm A requires rpm B" and vice versa - rpm handles that quite nicely (and I'm sure dpkg does too) if you issue "rpm -Uvh A B".
Slashdot Mirror
YouDothemath
Oh, man...
1. That depends on you demands. Sure, it's not as tested as RHEL or Debian stable, but it doesn't crash every 5 minutes either. In fact, I've yet to see Fedora crash.
2. FUD. It's impossible to choose a default install that every single person in the world is completely satisfied with. You need to learn how to uninstall things.
3. So, having GUI tools for 50% of the tasks is worse than having no tools at all? That's just dumb...and even if you think so, uninstall or do not use the GUI tools!
4. Huh? Fedora Core + Extras has around 3000 packages. How many are there in Debian stable? More importantly, how many do you need? And btw, did you not just say that Fedora was bad because of "extra cruft"?
5. That is not a bad thing. Nobody is forcing you to upgrade, just because there's a new version available (see 6).
6. That is the only valid argument, and the only reason to upgrade. There is however a community project called Fedora Legacy (www.fedoralegacy.org) that provides security updates for EOL'ed Fedora/Red Hat products.
7. Well, it's doable with apt or yum, but it's not the supported or recommended way. You need to reboot your Debian servers on upgrade as well, to switch kernels.
As someone else pointed out, MS prices do not include support. Moreover, when you buy from Red Hat, you don't buy RHEL 3 - you buy RHEL. That means that upgrades are free as long as you are subscribed. You may upgrade as often, or as rarely, as you like. A new version of RHEL is released about every 18 months.
If it makes you feel any better, I see it too :-)
The flickering is due to the fact that QT is not double-buffered. There are, AFAIK, tricks to make applications/widgets double-buffered, but it's not toolkit-wide. Gtk is, however.
There is a speed vs. eyecandy/usability tradeoff involved.
Hrm, I think some of the information about RPM needs to be clarified.
1) RPMs are distributed as upstream source + any number of patches. That's equivalent.
2) RPM calculates dependencies by looking at what libraries are linked to by any of the files in that package. You never specify a dependency on say, "gtk2", that is done by RPM. Except for the case when a program calls an external binary, such as k3b depends on cdrecord.
3) RPM has everything but suggests and recommends.
4) Not sure what you mean there, but I think it's about packaging different versions of the same library to be installed in parallell, like qt-2.3.1-1 and qt3-3.1.1-1? Debian does that too, I don't know what's automated in that process however.
5) RPM has pre, post, preun and postun scriptlets. Those are simply short shell scripts that are run at install/uninstall. How is that any different?
6) RPM has a policy of never asking any questions during install. IIRC you can set the ask-questions-level to "never" in Debian, which would be equivalent. Nice thing to have though.
7) RPM has Provides:
8) Well...you need rpm, rpm-build and popt. Maybe not as standard as ar/tar/gz, but by no means impossible.
9) Logging is possible on the dependency manager level (yum/apt/up2date etc). I don't see why you'd need additional logging at the lower package manager level.
That should make the list a bit shorter. I'd agree that DEBs are a bit more feature-rich, mainly because of the configuration abilities and suggests/recommends stuff, but the difference is not that big.
The main advantage of Debian packages is not in the file format, but in the fact that there are basically no 3:rd party packages. They are all in (one of ) the main Debian repository(-ies), and are therefore compatible. What do you think would happen if there were to appear 10 dpkg-based distros, with package names and packaging guidelines each slightly different from each other, and from Debian?
For Fedora Core users, the Nvidia graphics driver is already packaged, and soon ATI's driver will be too. Installation is one command:
/Peter Backlund
yum install nvidia-glx (or fglrx)
That's it. No configuration, no compilation, nothing. You don't even have to reboot. Even easier than Windows. The drivers are provided by the Livna.org repository (http://rpm.livna.org).
Progress on the ATI driver can be monitored here:
http://bugzilla.livna.org/show_bug.cgi?id=211
As of right now, the published version of the Nvidia driver is 1.0.6106, with 6111 coming out shortly.
Some of the improvments made by the livna re-packaging can be read about here:
http://rpm.livna.org/livna-switcher.html
The same applies to the ATI driver.
Note: an ATI employee (M Tippett) has been heavily involved in the packaging process, which shows real committment from ATI's side. Nvidia has not even bothered to answer a request to put a link on their driver download page to rpm.livna.org.
Get the facts:
c ho s
"Additionally HP-UX, Linux, NetApp NetCache, Solaris and recent releases of FreeBSD cycle back to zero after 497 days, exactly as if the machine had been rebooted at that precise point. Thus it is not possible to see a HP-UX, Linux or Solaris system with an uptime measurement above 497 days."
http://uptime.netcraft.com/up/accuracy.html#whi
No, they are 4294967296 times better.
Holy Dogshit! So there really are people around that haven't heard about automatic dependency resolvers such as apt, yum, up2date, yast, urpmi or portage...even more amazing is that can be moderated insightful.
I saw an ad where a company was looking for someone with experince in "J2EE (Java to Enterprise Edition)". How reassuring does that sound...
Actually, Apache is already included in WS. According to this (all the way down), you get Apache, NFS and Samba in WS 3.0. You need ES or AS if you need the following servers:
amanda-server, arptables_jf, bind, caching-nameserver, dhcp, freeradius, inews, inn, krb5-server, netdump-server, openldap-servers, pxe, quagga, radvd, rarpd, redhat-config-bind, redhat-config-netboot, tftp-server, tux, vsftpd, ypserv.
That being said, I'm sure it's very, very easy to grab the dhcp SRPM from ftp, rpm --rebuild and install.
Now, before everyone goes "I knew it! ext3 sux!!!!111!!1", remember that the default mode for ext3 is ordered, and not journal. Compare the numbers for ext3_ordered and ext3_writeback with reiser/xfs/jfs, and you'll see that ext3 is very very close in most cases.
Andrej Gromyko (former Soviet Union Sect. of State) wrote in his autobiography about Mao Tse Tung's plan to destroy the capitalist forces sometime in the 60's or 70's. It went something like this: first, China would invade Taiwan. This would make US/Nato respond by taking back Taiwan, and move onto the Chinese mainland, where the Chinese forces would fall back to the Gobi desert. Meanwhile, the Soviet Union would be passive, and even a little pro-American. Then, when least expected, the Soviet Union would launch a nuclear attack on the Nato forces in the Gobi desert, destroying them. Mao estimated about 200 million dead chinese, which was an acceptable price to pay...
Wrong, wrong, wrong.
.deb, low-level package tool dpkg, and high-level package tool apt. .rpm, low-level package tool rpm, and high-level package tool up2date (or apt, which is available for RH and various other rpm based distros). .rpm, low-level package tool rpm, and high-level package tool urpmi.
In Debian, you have the file format
In Red Hat, you have the file format
In Mandrake, you have the file format
Do not compare apt with rpm. Saying "apt is better than rpm" is like saying "2 meters is more than 2 minutes". It doesn't make sense.
___
Here we go again... If you think that having no package manager, or having a very simple package manager, is better than rpm or dpkg you are simply wrong. Let me tell you why:
.tgz package, you can do with rpm/dpkg. Everything that you can do with a source tarball, you can do with a .src.rpm/dpkg_equiv., with the possible additional (small) overhead of editing a spec file. End of story. /root/.bashrc
Dependencies are there for a reason. Just because you can install kdebase.tgz without having qt installed, doesn't mean it will run. Too obvious example? Well, name all libs that you need in order to run Galeon? Or what libs you need to update to what versions if you want to upgrade Galeon from 1.2 to 1.4?
The metadata (dependencies) that come with rpm/dpkg also makes it possible to write and use tools as apt/urpmi/up2date, to automatically download and install software with a single command.
Everything that you can do with a
No/primitive package management is simply a subset of rpm/dpkg. Here's how to downgrade rpm to the equivalent of Slack's pkg manager:
echo "alias rpm='rpm --nodeps --force $*'" >>
There, no dependency checking.
RedHat, Mandrake and SuSE are all installable "across the net with a single floppy". And they all have apt or equivalent tools included. That's what you will learn by not using Debian exclusively.
Bte, Red Hat manages package dependencies. You are simply ignorant.
Red Hat compiles their packages with -mcpu=i686, which means that they are optimized for i686 but still runs on i386 (with -march=i686, the binary won't run on anything lower than i386). Important packages, such as kernel and glibc are compiled with the -march option, that is if you install it on a Pentium, you get the i586 rpm and so on.
/usr/lib/rpm/rpmrc for details on compiler flags.
If you want to, you can always rebuild the source rpms for packages like X or GTK or whatever, and use the "--target " switch to rpmbuild. That will optimize for your architecture. Look at
...if you want to try it out yourself. I'm downloading RH 8 isos as I type.
ftp://mir1.ovh.net
How do they force you? Just find the config file, edit it in your favourite text editor, save it and restart whatever program you wanted to customize. You don't even have to install the gui tools.
We'll conquer the desktop together, one user at a time if need be," enthused Shawn Gordon, President of theKompany.
I'm pretty sure he said 'konquer the desktop'.
This is a widespread misconception - that Galeon is much much "lighter" than Mozilla. On my system (RH7.2, p3/866 512M) Mozilla uses 19M of RAM, and Galeon 17M immediatley after startup and loading www.gnome.org. All according to top. Startup time doesn't differ much either, rendering speed almost identical (as it should be). The only thing is that on slow machines (less than 500 MHz), menus and such - the chrome - on Mozilla is noticably slower than the GTK interface on Galeon. On my machine though, I can't tell the difference.
AND bear in mind that XUL is a very complex peice of software that brings something new to software development. It is not bloat. Also, it is nowhere nere as fast in Linux as in Windows, due to (i guess) more optimization in the Windows specific parts.
Recent packages. Also, quite a lot of experimental performance-enhancing patches in their kernel tree (preemptible, low-latency scheduler and probably more that I don't know about). And yes, you may install the vanilla kernel if you like. It's just a matter of "emerge gentoo-sources" or "emerge vanilla-sources".
That's a interesting point - however, dependencies are closely linked to what features are compiled into a program. Let's say you want to package Nautilus: it's possible to disable mozilla support at compile-time, removing the need for mozilla to be installed. But then you remove an important part of functionality. Or, you could try to split the package into speperate pieces where that is possible (nautilus/nautilus-mozilla or mozilla/mozilla-mailnews/mozilla-irc etc), but that won't always work either.
It's always a tradeoff, and there's always someone who isn't satisfied. Say you put everything realted to Gnome in one package - very easy to install, and probably doesn't have a lot of external dependencies except obvious ones like X and glibc. But then someone shouts "Bloat!", because he or she doesn't want to have Evolution installed jut to run Xchat. On the other hand, if you look at Gnome now, it's at least 10 different packages on top of X that you need to install (and run) Xchat. Which is better?
I short, it's impossible to please everyone at the same time. If you're not satisfied with the way someone else has done the job for you, do it yourself.
Well, what do you think the dependencies are for? They are packages (programs/libraries) that you need in order to use whatever you're trying to install. That's just it. You can't drop dependency checking and then think you can install (and actually use), say, Mozilla without installing X. /., 99% of all people who say "Package mangement is bad" simply do not know how to use it - rpm, dpkg/apt or what-have-you.
From what I've read here on
Btw, if you by "cicular dependencies" mean that "rpm A requires rpm B" and vice versa - rpm handles that quite nicely (and I'm sure dpkg does too) if you issue "rpm -Uvh A B".