Slashdot Mirror
RPM Package Manager
Things have changed quite a bit since we last posted about the state of Linux Package Management. Over the few months ago, we saw the Connectiva release, which was a RPM front-end to apt-get [?] . Now, for those of you running RH6.x, there are a new program called Aduva Manager. It's kinda like using apt-get update/apt-get dist-upgrade, but checks dependecies and such for RH6.x based systems. They've got screenshots as well as a FAQ/download site. It's designed more for new users, but it looks like a step in the right direction for RPM.
It's been my humble opinion that packaging managers are good for "users" of OS's I just started using debian on my workstations after a co-worker showed me the ease of applying new dependancies. However without getting into a distro jihad here, I still say that for the tried-and-true, the only REAL way to understand and comprehend services on a production box, you really need to compile the source yourself.
How else are you going to be able to troubleshoot or modify any tweaks/perks/or problems that may occur.
Or take for example the debian debacle of a couple weeks ago. I did an upgrade then an install of a couple things only to find out that X was going to crap the bed on me... If I had been less lazy (yes I know that goes against EVERY netadmin's fibre) and had compiled the programs myself I could have saved a couple hours of time in the long run.
But as far as getting *nix out to the masses I applaud RH and Debian for attempting to ease the installation of software for new users.
-- Life: Hate the Game... Love the cereal
--
Care about electronic freedom? Consider donating to the EFF!
...these organic GUIs. Why do we need to have widgets that look like automobile clay models or stuff you'd find if you slit open your guts? What's wrong with good old 3D widgets, which took us like 10 years to get to?
- Linux is in a constant state of change.
A slick program like this takes many man hours to develop. Due to the constant changes done to Linux, developers not only have to do all the effort involved with developing their program, but also have to expend a lot of effort keeping track of every single change to the Linux distributions thrown their way.There is a lot of excitement in the Linux community about getting the latest distribution of (Debian/RedHat/SuSE/Slackware/whatever). This excitement oftentimes results in neglect of older, oftentimes more stable releases of Linux systems.
To RedHat's credit, RedHat still supports releases as far back as RH5.2, in the sense they still releases security upgrades for RH5.2. About a year ago, RedHat silently stopped releasing security upgrades for RH4.2. Since I still run a RH5.2 server (too far away and too mission-critical for me to conveniently upgrade), I dread the day no more security patches are made available for RH5.2.
I know that the people at Linux Weekly News have been making somewhat of a stink over the fact that Debian announced that they would not make available security patches for 2.1 bugs immediately after releasing Debian 2.2.
Anyway, the point being: The "latest and greatest" is not always the best solution.
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
That's not humorous at all. Please make way with your parody on such sensitive issues.
-root is lord.
This has been bugging me lately and you are near and the first one I saw this morning but Where does this idea that Debian is hard to install come from and really how long do you spend installing a system. Now granted before 2.2 maybe it was kind of hard because you had to go to dselect to do it. But the 2.2 install is cake. I will give a walkthrough. Boot, tell it what keyboard you want to use, partition, set up your swap partition, mount the rest of your partitions, install the kernel, choose modules (drivers) for your hardware, install the base system, set up networking and time, install lilo, reboot, give it a root password and make another user, choose simple and choose the tasks you want to install, pay a little attention to what packages are installed by default note any you would like to get rid of, let it install what it needs to, answer some basic config questions if not sure the defaults are really sensible, apt-get remove anything you don't want (I just hate XDM) apt-get install anything you want (Netscape and Mozilla are both good) Run xf86config (If this is hard for you maybe you really should be running RH)and you are done. Now really what was so hard about that? Could somebody please tell me just what is so hard about installing Debian?
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
Please do not reply to the idiot. Giving him/her/it* attention will only make it worse. Just adjust your threshold.
* Underline appropriate option. Multiple options may be valid.
People replying to my sig annoy me. That's why I change it all the time.
Besides, anybody who says that compiling their own source automatically makes them better understand their machine must not ever execute those "make install" scripts. If an automated process puts 100 files across 12 directories on your machine, and you tell me you can keep track of them all in your head for 100 software packages, I don't believe you.
www.HearMySoulSpeak.com
My pet peeve is the silly hierarchical package display. You have to figure out exactly where in the hierarchy the developer chose to stick the silly thing. Often a package can logically go in one of several places, and it seems that almost as often, yet a different place was chosen.
I like xrpm, which gives a flat view of installed packages or rpms in a directory. A long list, but no hiding in odd mislabeled corners.
Unfortunately, my RH 6.2 has 'aged' too much. I'm seeing too many things that pretty much require me to turn it into RH 7 with prerequisites, so I may as well take the faster route. Then get the updates on, etc.
RPM is handy for a user, as opposed to a developer. Though I try to understand more of the nuts and bolts of what's happening, my computer is more of a tool than a programming machine.
The living have better things to do than to continue hating the dead.
Warning, I am a debian user.
I don't think that redhat will ever give an automated-updating package manager their full support. It's a pain to get all of the little dependencies for RPM(this depends on that, which depends on those 8 packages, two of which require a new version of pacakge q), which helps them sell cds.
This is not at troll, but honestly, redhat has to sell cds, and I belive they have held back support for automatically updating package managers because they would rather have their users go out and buy redhat cds.
Now Eazel and I belive helixcode are gearing up to offer subscription(money)-based automatic system updaters, and I remember hearing something similar from redhat at one point. But I doubt they will ever support one for free. It's a sad fact that often technology advances are held back because a company needs to make money.
An interesting thing to try would be to make it so you could do bug-fixing upgrades (1.0 to 1.1) but not feature upgrades (1.0 to 2.0). And in order for that upgrade you would have to be running the new version of Redhat. "6.0 lets you upgrade from 1.0 to 1.1, but to get the added functionality of 2.0 you need to buy version 7!".
RPM is not at all outdated. .deb packages have a lot of things that are an advantage and a disadvantage at the same time, such as the post-install configuration. We don't want this type of stuff because it makes installation unnecessarily complicated.
The only real advantage of debs compared to rpms is apt-get, which has now been implemented for rpms as well. So why switch to anything else?
This message is provided under the terms outlined at http://www.bero.org/terms.html
How is .deb better then .rpm?
Apt-get.
Cleaner dependencies.
More package maintainers.
More packages in the standard tree - fewer compiled by other people who are not part of the distribution.
More testing.
Debconf.
No backward compatibility break between rpm-3 and rpm-4 for debs.
Nuff said.
Those screenshots are terrible. I hope that's a GTK theme or something, because I'd hate to have THAT on my desktop. I'm probably wrong. It's probably all hard-coded ugliness. Or even worse, they went ahead and wrote a whole theming engine for their one app while Qt or GTK already have the ability to make your desktop as ugly as you want.
I thought web sites were supposed to look more like applications in order to be more usable, not the other way around.
Who designs this crap?
I've talked with Aduva people a while ago, their plans are to add support for 7 in a while.
As for "silently" dropping 4.2, it's not really true. We have always supported the end-of-line releases for the last 2 major versions, meaning 4.2 was dropped when 7 was released, 5.2 will (unless our policy changes) be dropped when 8 will be released. I'm quite sure this information is publically available somewhere.
This message is provided under the terms outlined at http://www.bero.org/terms.html
The first thing I thought when I looked at the screenshots was "Looks like Lotus Notes 5.0. Ugh." The program sounds cool in concept, but I wish they'd stick to GTK so the program looks like everthing else on my desktop (except Netscape and Emacs.)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
i guess "rpm" now means "redundant package manager".
--
Did anybody see the licensing on this? Read on...
12. Access to the ADUVA Server
Aduva provides at present free of charge access to the ADUVA Server and to the
ADUVA KNOWLEDGE BASE. Aduva may charge in the future for access to the ADUVA
Server and/or the ADUVA KNOWLEDGE BASE. The information and/or any other data
received from the ADUVA Server is the sole property of Aduva and is protected
by copyright and other rights.
I wonder if they have a privacy policy...
--
Give a man a match, you keep him warm for an evening.
Give a man a match, you keep him warm for an evening.
Light him on fire, he's warm for the rest of his life
Unfortunately, all the Linux package managers (apt/dpkg, rpm, etc) lack one vital feature that all the big guys (IBM, Sun, HP) have included for years - the ability to install, but not commit a package.
One of the things "enterprise" Unices have is the ability to upgrade a package, while the system backs up your old package. If the package upgrade breaks something, it's simple to roll back to the prior state. If everything goes OK, it can be run through it's paces for a while, and then eventually "committed", whereby the old information is deleted.
Until some flavor of Linux adds this to their package management, Linux WILL NEVER be able to take over the corporate world (yeah, there's a lot of other things it needs to, like 32-bit UIDs and a journaling filesystem, but at least they're on their way).
Received the following:
:-)
Date: Wed, 27 Dec 2000 22:31:05 +0200
From: Ury Segal
To: egon@tuininga.org
Subject: Aduva Manager Privecy issue
[ The following text is in the "windows-1255" character set. ]
[ Your display is set for the "ISO-8859-1" character set. ]
[ Some characters may be displayed incorrectly. ]
Hi!
I am Ury Segal from Aduva.
I just wanted to say, in advance to the answers to your question you'll
probably get tomorrow ( It's 22:27 here ), that your privacy is kept, and
Aduva Manager does not send the inventory of your computer to our
servers. All we have is your IP ( and what you asked to download -
but that's just any FTP site can do. )
We are making the sources ready for GPL, and then you'll be able
to check my claim, but till then - you can either sniff the packets and
see for yourself, or just believe me
(The stream is SSLed, but it's sniffable if you are
on one end )
--
Ury Segal
Aduva INC
Phone: +972-3-7534300
Fax: +972-3-7534343
--
Give a man a match, you keep him warm for an evening.
Give a man a match, you keep him warm for an evening.
Light him on fire, he's warm for the rest of his life
This program is just one of many coming out lately that does the same error as Microsoft: Merging functionality and user interface. A package tool should consist of either one (or both) of a) a library b) a command line tool. Merging UI and functionality makes it very hard to change the UI (bringing it to a web-based administration, automation, etc) in the future, if needed.
Unfourtunately, this have been done a lot lately, mainly by KDE developers (No offense, you make a really good GUI, and some really nice functionalities, but could you please separate the two?):
* KMail have functionality to download mails and filter mails to different mailboxes (It should have used fetchmail and procmail for that, and provided only a graphical configuration tool for those two backends).
* QT contains both basic datastructures (Linked lists, hash-tables, etc) and GUI widgets (Buttons, listboxes, etc). In GNOME, those two parts are separated in Gtk+ (GUI widgets) and glib (basic datastructures).
* KDE contains a virtual filesystem that enables the user to transparently use files on remote sites using any KDE application. This functionality should have been in the operating system filesystem layer (There are several projects to achive this (portable): Podfuk, Alex, etc) VirtualFS), since as it is now, only KDE applications benefit. Here I might add that GNOME are unfourtunately heading for the same, developing the gnome-vfs (which stems from the Midnight Commander VFS).
--The knowledge that you are an idiot, is what distinguishes you from one.
This 'Aduva system' stinks of a pay-for-play service of some kind....
What is the Aduva business-model? What are they planning on doing to feed themselves? Does anyone know?
There seems to be some confusions as to what a "package manager" really is. This isn't an 'RPM front-end to apt-get" as Hemos put it. This is a port of apt to support RPM's as a package format. Debian packaging is done through 'deb' packages, which are almost identical to RPM's in form and functionality. Both have evolved to be very good package building, deployment, and retraction tools for software.
What this, Helix-Update, Eazel Services, apt, and up2date really do is function as package distribution channels. They resolve dependencies, check package location/availability against host-side maintained repositories and download the appropriate packages, once all the dependencies are figured out and resolved. They do not install the packages -- the package manager (RPM, dpkg) does this part. (Well, technically they can, but this would be through either re-writing, or linking to the library form of the package manager.)
While noone can argue that Debian had this capability first, and probably (currently) does it best due to having time to mature, it's natural that this capability will come to other distros and package formats precisely because it works so well.
Cheers,
Ken Crandall
It will be skinnable in newer versions
I really hope that by "skinnable" you mean that it will use the widget set that your window manager & desktop environment provides, or at the very least provide that as an option.
That last thing in the world we need are 500 "desktop-ready" applications, each with their own skin format. I already use four different applications that have separate theme formats: XMMS, Nautilus, Mozilla and gkrellm. Combined with GTK and Sawmill, that's 6 different theme formats I have to keep track of. (Well, that's kind of a lie; I have Mozilla installed so I can use Galeon...)
I don't need a themeable package manager, ICQ client, mailreader, image editor, web server, and SETI@Home client. Desktop environments provide those widget sets for a reason...
Jay (=
Hey, I got Debian 2.2r1 to install on my 68040 based Mac Centris 660AV, so I'm not saying it's impossible. I've just never had it EVER go as it was 'supposed to'... I've had problems with installing the X Server (in the 2.0 release that I was playing with, the console would cease to respond when working with the X servers and i'd have to manually kill-9 it and try again), I've had problems with dselect, with applications seg faulting on good hardware, and with certain pieces of hardware that worked back in Slackware on the 2.0.0 kernel not work in Debian 2.2r2. Maybe this is being picky, but lots of stuff just gets on my nerves.
Yes, RedHat, SuSE, Mandrake, etc are easy to install, very easy, like i can put the disk in, boot, select the shiny red button for 'install' (figuratively speaking) and it'll set all the defaults and select all the basic, normal packages. I don't have to do much. Sometimes, like with that Mac, I don't mind a challenge, but when it's just giving me a headache because I want to be able to play sounds or talk to my NIC, it's quite annoying.
Just my two cents worth...
"Titanic was 3hr and 17min long. They could have lost 3hr and 17min from that."
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
>>>if you cannot figure out a few simple commands, maybe you shouldn't be using
>>>Linux in the first place !!! Its not for joe average, its for people who like to get under the hood and tinker around.
I disagree... It may have been that way before, but more and more windows users are moving to linux, probably just because of the hype so they are curious. But the easier it is for any user to install and maintain packages, the more users will stay with linux. Sure sometimes its a good idea to compile the sources, but if there's already a package out there, it's just a waste of time. Ideally, no user should ever have to compile the sources- just have it there in case they want it. The thing that is keeping that from happening is the lack of a standard packaging system. RPM works fine, but I really like the apt-get feature of debs. But now that apt is being ported to rpm, then I think I'll just stick with rpm. In the meantime, whoever makes package management easier has got my support.
But on a side note, I think the interface for this piece of software is ugly and is poor UI design. I personally cant wait for RedCarpet from Helix to be available - that looks like the best bet right now for package management.
-Brandon
As I said in another post - the GUI will be skinnable and you will have the option to use the Aduva Manager with a standard GUI.
Hetz (Heunique)
The strict policy for Red Hat RPMs (and those of any other RPM based distribution I'm familiar with) is not to demand user interaction in %post, %pre and the likes. debs have a very different philosophy there (or at least used to, haven't checked out the latest Debian yet). We generally use %pre and %post to autogenerate stuff, not to prompt users.
This message is provided under the terms outlined at http://www.bero.org/terms.html
Because it's more profitable. How's that you ask? RPM is a for-profit company that relies on you buying new releases of their distro for profit while debian, on the other hand, is not.
If one could apt-get distupgrade a Redhat box ad infinitum you could buy their distro once and upgrade from that point forward. Debian is a non-profit organization and does not worry about cashing in on the next point release. Debian users upgraded from 2.1 to 2.2 by issuing a simple command. Redhat users sometimes have to deal with dependency problems if they want to upgrade a package and you can imagine what could happen with hundreds of packages.
Redhat benefits when people buy their distro. They might benefit if they could provide an apt-get frontend with a subscription based service. Although I would love to see an apt-get front end thats free to all, I bet the suits at Redhat corp won't let this happen. I could be wrong, but I think the use of a tool like apt-get and especially doing a distupgrade on a Redhat box is about profit and nothing more.
2.You may install the program yourself, but you must do so in accordance with Aduva's instructions. The Program is licensed, not sold. This license does not confer you title or ownership in the Program. The Program is not subject to any General Public License and is in whole or part the proprietary property of Aduva. You are specifically prohibited from reverse engineering the Program.
7.Confidentiality. All elements of the Program, the servers it attaches to, the manner of operation thereof, the code thereof and the information relating thereto are considered confidential information and you agree to maintain such information absolutely confidential and not to disclose such information to any third party whatsoever without first obtaining Aduva's prior written consent.
More (including a nasty termination clause) can be found on http://www.aduva.com/mason/new/licenses.html
I just downloaded it and tried it on a machine which I did not touch since I installed Redhat 6.2 on it (it sits here as a printer server), and here is what the program did:
1. compiled and added sound support for my ES1371 (I didn't know that I have sound card onboard, heh)
2. Upgraded my Netscape to 4.76 - security update (thats nice!)
3. updated my gtk
Then I selected the kernel and clicked Upgrade Now - and it downloaded and compiled kernel 2.2.17 quite nicely..
Overall - I really like the program - I just really hope that they'll replace the BUTT UGLY GUI and add the option to let me resize the window (it looks very small on EXCEED on my NT when I'm running 1600x1280)
Good work Aduva!
YoGi
Most of the content in Conectiva's site is in http://distro.conectiva.com.br, including news, projects, updates, security annoucements and a webcam.
For example, building packages depending on obsolete packages, or packages conflicting with the distro's official packages, is a good way to break apt-get in both Debian and Conectiva.
Given that they say they are going to GPL it, if they are not currently linking to a GPL component, they aren't doing anything wrong.
Not that I am sure the business model makes much sense. There are too many people willing to give away what they are seeking to sell.
Thanks
Bruce
Bruce Perens.
Why do so few people use src.rpm?
I love src.rpm packages for simple reasons, they make instalation and removal a cinch, but at the same time they have all the advantages of source.
I can recompile with opt flags, change install paths, apply custom patchs, and build myself a nice reusable rpm file for later use.
For all the people who complain about package systems "robbing me of control" try using src.rpm packages more often, there easy to use, flexable, and give you a nice clean souce tarballs that you can tweak to your hearts content.
Well, technically RPM will automatically deinstall any obsoleted packages on an upgrade, and so you'll also need to grab those as well, but this doesn't happen to often. Besides, you can always do:
rpm -q -a | sort >before
rpm -UvhF *.rpm
rpm -q -a | sort >after
It shouldn't be too hard to put together a wrapper for RPM that does that, and then reinstall all the older packages if you want to back out.
---
Apt-get.
Which is an update program, and not a package program. Mandrake has MandrakeUpdate (along with stable and cooker sources), and I'm sure most other rpm based distros have similar tools.
BUT - this has squat to do with .deb versus .rpm.
Cleaner dependencies.
Is that a function of the format or the package maintainers?
More package maintainers. .deb file format versus .rpm.
Again, has nothing to do with
More packages in the standard tree - fewer compiled by other people who are not part of the distribution.
Again, squat to do with deb versus rpm. And for that matter, Mandrake's Cooker has most of what I want, being an open submission of Mandrake rpms.
More testing.
Hunh? I'm not sure what that means, but I don't think you're referring to rpm versus deb as packages.
Debconf.
Okay now THATs more like it - can a somewhat less zealot debian user explain debconf? I'm seriously interested in deb versus rpm (Corel's distro for a two month period was as close as I got to debian).
No backward compatibility break between rpm-3 and rpm-4 for debs.
Bzzzt. Thank you for playing. It works fine on my system.
Nuff said.
Not only did you manage to sidestep the direct question (rpm versus deb as packages, leaving package managers/updaters out of the scope of the discussion), you merely named a whole bunch of utilities that would only be recognizable to debian users, who, presumably, would not need the information.
Any debian AND rpm user out there care to take a crack at explaining the difference and pros and cons between the package formats?
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
RPM == Red Hat Package Manager
:-) You could make a system (now :-) as easy to use, and as coherent, and as logically laid out, package-wise, as Debian and use RPM. Hell, now, you can even use apt-get with this mythical RPM-based system.
Seriously, the reason Debian doesn't use RPM is because R=="Red Hat" IMHO. That's the vibe I get from some folks who're involved in Debian. "Ick, that's a RH thing," I've heard more than once.
Stating on Slashdot that I like cheese since 1997.
Helix Code is working on such a program that they call IIIRC a meta theming engine. It currently has support for Gtk, Sawfish and XMMMS but it should be very modular.
Monkey sense
SuSE for a long time has had the ability to do updates off the web. You run YaST and tell it your installation medium is an FTP server and then tell it you want to update your existing setup. You can go through and install new apps or just update stuff you already have. It's worked pretty well for me and I've had the same system since version 6.1. Things I would like to see added to this are XML package descriptors vis a vis HelixCode, and support for HTTP updates in addition to FTP. YaST2 does all the stuff YaST does but with a friedlier X interface. I also want GNOME and KDE pluggins for YaST2 that will run in their respective trays and keep me up to date on package updates are up on servers.
I'm a loner Dottie, a Rebel.
Apt-get.
Which is an update program, and not a package program. Mandrake has MandrakeUpdate (along with stable and cooker sources), and I'm sure most other rpm based distros have similar tools.
Ever tried to use those tools ??
You are right though - this is not strictly a deb vs rpm issue.
More packages in the standard tree - fewer compiled by other people who are not part of the distribution.
Again, squat to do with deb versus rpm. And for that matter, Mandrake's Cooker has most of what I want, being an open submission of Mandrake rpms.
Actually this has a ton to do with reliability. The entire point of having a distribution is that they will ensure that packaging is reliable and consistent. When third party vendors start offering Redhat RPMs, or Mandrake RPMs, or you start using contrib RPMs, package dependencies get less consistent, and the machine is just not as clean.
I get everything I need at debian.org in woody non-us and non-free, all packaged by debian maintainers.
Debconf.
Okay now THATs more like it
Debconf is a little scripting conf that allows packages to pop up questions in console windows during the package installation that ask you if you would like to clobber your existing configuration files with new ones or not. The default is always do not clobber. Or, a package can pop up a reminder about a configuration issue associated with a package, and either show or do not show the reminder in the future. Lastly, they have help hints if you cannot resolve a dependency that tell you what to do !! These have helped me a few times.
Oh, oh, and it should also have an MP3 player, because they can always do it better anyway. And a file manager. And a plug-in architecture, so I can expand it into an entire OS if I so choose.
- wonder if they have a privacy policy... They have one, find it here: http://aduva.com/mason/new/privacy.html
--------------------------------
The up2date service has been changed, and no longer uses that directory - it's now a part of Red Hat Network. I like the new program better - I never liked the old one, so I didn't use it much. The new version works nicely, and I use it on my private machines.
Red Hat (and almost all the other distributions) use RPM because it works well and is a better and more flexible package format than deb. You're probably confusing "rpm being superior to deb" (package format) with "apt is cool" (distribution of packages)
RPMs, in contrast to .deb, has cryptographically signed packages (and has had so for ages), flexible and reproducible building method (look at a spec file, they really tell you how to build a package), separated patches(I've seen people claim than .deb can do this, but as long as the packages distributed with Debian don't seem to do this I'll believe that as an urban legend). Take a look at a SRPM and a Debian source package - there's really no competition.
Just run "up2date -u", and it will update your system from the command line.
It can be configured with up2date-config, so if you just want to download the packages or mark certain packages to be skipped you can easily do that as well.
Actually this has a ton to do with reliability. The entire point of having a distribution is that they will ensure that packaging is reliable and consistent. When third party vendors start offering Redhat RPMs, or Mandrake RPMs, or you start using contrib RPMs, package dependencies get less consistent, and the machine is just not as clean. I get everything I need at debian.org in woody non-us and non-free, all packaged by debian maintainers.
.deb/.rpm battle ended a long, long time ago. RPM won. How many people do you see coming out with .debs of their software? Sure, they *exist*...but at a 1:20 ratio to RPM producers.
Really? Mmm... Do you also purchase only Microsoft software, avoiding those nasty "other" vendors that prevent you from having a "reliable and consistent" experience? Because you could replace "Debian" with "Microsoft" there and have a sentence that could come from any number of idiot NT admins that I've run into.
Point well taken, but the environment is completely different. Everything I need under linux is free (as in speech), and can be packaged by a single party. And the single party is not a vendor with a monetary incentive to lock me in, but a collaboration of hundreds of volunteers.
There is nothing preventing RedHat from packaging everything that is packaged as RPMs for RedHat from third party vendors. The packaging basically consists of taking the installation files, and wrapping them together, setting sane dependencies, and pre/post install/uninstall scripts where appropriate.
Put another way, in a Microsoft world one of the single largest sources of OS trouble is third party software clobbering system dlls. If Microsoft could package that software properly, Windows would work much better. Of course, in a Windows world the third party software is actually competition, so this would never work.
In free software the third party software is a welcome addition to strengthen the distro. See the difference yet ??
The
This may surprise you, but Debian as a distribution is still growing rapidly. And the net number of people converting from RPM based systems to deb based systems is substantial.
But that is beside the point. Debian will continue. Its volunteer packaging force is growing rapidly, as is its user and testing base. There is no monetary bottom line affecting the distribution - only the joy of having free software that works the way it should. As long as the packagers keep packaging, the distro will continue. As long as the userbase keeps expanding, it will grow stronger and stronger.
No backward compatibility break between rpm-3 and rpm-4 for debs. :-)
/tmp clean on every boot. And /var/run.
.spec, rpm -bb .spec), you get to manually enter stupid info that could be auto-detected 99% of the time. Lovely.
/usr/X11R6/bin/Xfree86 instead of /usr/X11R6/bin/X, and the new config file is /etc/X11/XF86Config-4. The new install doesn't conflict with the old one that way (since 4.0 currently doesn't work for a lot of people).
.rpm-.deb issue. This is a distribution issue. If you're claiming that .debs inherently get more testing than .rpms, than I claim that you're full of it. To be fair, if you're slamming RH 7.0, you're on target.
Not an issue for at least RH and, presumably, other RPM-based distros (though I don't know, so I can't swear to it). RH just runs out and makes an rpm-4 compatible version of rpm that runs on old distros. Easy. Fun. Besides, presumably all the reinstalls you've had to do when the unstable Debian tree breaks your system add up to at least some form of "upgrade", hence lack of backward compatibility?
If you don't want to have to fuss with it, simply use the stable tree - that is what it is there for.
If you don't mind the occasional manual futzing with your box, the Debian unstable tree is for you.
And if you want a real pain in the ass, use a RedHat *.0 release. Totally unstable compared to Debian unstable. And RedHat calls it a production release.
Don't get me wrong - I administer RH and Debian boxes. I find I spend much less time screwing with the Debian boxes, and the initscripts and cron jobs (slocate, man) do more intelligent things. Like, for example, wiping
Basically, I tried Debian as an experiment. It was slink, and a royal pain to install (potato is supposed to be much easier). Then it was a pain to get everything the way I liked it, as I didn't know much of apt and dpkg. Then, I used the box. And over a few months, I realized the Debian box was running more smoothly, and upgrading more easily, than the Redhat box. And this is mainly due to clean packaging and apt and debconf.
From Debconf's own description: "It's a way to get rid of all those annoying questions Debian packages often ask when they are installed; or a way to present them to the user via a varierty of UI's.". Gee. That's just swell. Instead of auto-detecting things like most RPMs do (following a Red Hat convention) and then letting you customize things if you want something special (rpm -i blah.src.rpm, edit
Really, it does things like
1) install XFree 4.0
2) Prompt you whether you want to make XFree 4.0 the default
3) Remind you that Debian XFree 4.0 uses the binary
4) Ask if you want to autoconfigure XF86COnfig-4 or use the existing version.
So you can see, you have multiple options, all of which any reasonable user might choose. With redhat you only get a broken system until you can hack up a new config file.
And for another example, for gdm, the debconf entry asks if you want to keep or overwrite the gdm.conf file.
More testing.
Again, not a
Really, this is critical. Debian packages get a little testing by the maintainers, and sometimes others who download them from a web page. Then, they get placed in unstable. Thousands upon thousands download unstable (since apt works so well), and an open bug reporting system checks all the bugs. The package is changed again and again until it is assumed everyone in stable can use the package without issue. Then it is moved to stable.
Redhat is trying something similar with rawhide, but it gets a few orders of magnitude less testers.