Umm, rpm has supported signed packages for quite some time now. Red Hat does sign all their packages using GPG. This is the signature information included with every official Red Hat update:
These packages are GPG signed by Red Hat, Inc. for security. Our key is available at:
I could make that list even longer with many more projects that Red Hat either funds, maintains, develops or contributes to, but I think I've already proven my point.
What I don't understand, if the original poster of this thread is correct, is why someone at said "client" doesn't just set up a single server (and a single license with RedHat), set up for free updates, then use that machine to update all the other machines on the network running a copy of RedHat (it isn't necessary for each machine to auto update - talk about a waste of bandwidth)? This shouldn't be that difficult to set up, and bypasses the monthly fee - right?
It would bypass it, and it would be perfectly ok as I understand it. But you have to consider that RHN is more than just doing a rpm -Fvh on every system - it lets you tailor the upgrades and upgrade policys for every machine, tell exactly what should be upgraded when there's upgrades and how and when, and what upgrades should be notified upon, etc. So you'd have to implement a "RHN" of your own on your local net to replace all of that functionality, even with that single master that uses RHN "for real".
Hey, I am all for RedHat to make money - and I agree that this is a value added service, and should be charged for. No problems here with that. But they better hope their normal business users are all dumb, or have incompetent admins (running Linux - hah - probably some MCSE who picked up a book on RedHat and now thinks he knows something - that or a management type trying to get ahead)...
Don't confuse convenience and simple economics with being dumb. For some companies it might be cheaper to use RHN than hire a code monkey to implement an equally competent update-distribution mechanism (yes, RHN is more than just the functionality of apt-get).
Most of the services that Red Hat offers can be had for free (in fact, all I know of). You can download the OS free of charge - but many people don't have the bandwidth/time/patience/burner or want the printed manuals/support. Consider this a similar thing - it's a ready-to-go update deployment/tracking system for those who need it and don't want to or have the time or resources to implement it on their own.
Installing a new version of glibc is a great deal more than just rpm -Uvh glibc-2.2.rpm. Loads of stuff depends on it and you're usually better off waiting for a new distro and patching any smaller holes while you're waiting.
That was a great deal more, was it?
My point is, upgrading the glibc on Red Hat 7 really isn't harder than that. Red Hat 7 was compiled against glibc 2.1.92, a prerelease of glibc 2.2, and thus everything is binary compatible with the final glibc 2.2. If you think you shouldn't upgrade your glibc, think again.
Unfortunately, rather than fixing the bugs and making GMC a truly slick GUI version of the awesome terminal mode file manager
Umm... even the author of gmc admitted widely that doing a file manager the way gmc was done (a hacky GUI interface to a CLI file manager) was a big mistake to begin with, and a shame for all the rest of Gnome as long as it wasn't replaced. The concept of having to map the operations in a GUI file manager to the workings of mc was less than fortunate.
So it wasn't really a question about "fixing bugs" in gmc (I don't know if you noticed it but gmc development has been dead for a long time), it was a question about replacing the broken design all together and start over with something new. Hence Nautilus.
If you were paying attention though, there was a peice of software that Bob never used when doing these three tasks. Gnome. That is, his desktop software. All he did was launch his wizz bang integrated application.
Not entirely true. Nautilus makes heavy use of the Bonobo component system, and also provides lots of pointers for viewing the files in alternate applications. In fact, there are rather few built-in viewers specific for Nautilus. All this makes a user use a good deal of "the rest of Gnome" even from inside Nautilus.
1.The debian policy, in my experience, produces better, more consistent packages.
Do you have examples? What exactly is better with the Debian packaging policy? Otherwise this is just trolling... you can't just expect anyone to listen to "uhm, yeah, the package policy is great because apt is great and apt is great because the policy is great because..." with no explainations, and expect anyone to take you seriously.
2.Due to this consistency, apt-get and so on are made possible.
How does a packaging policy make a technology possible? Please explain. Otherwise, I think common sense says it's the other way around.
I haven't tried the various tricks that are used to get apt-get working with rpm, but given my previous experience, I don't see them as being likely to work. I could be wrong here.
Again, please tell why. I think a lot of people agree with me that you build a policy around the technology used - because if the technology doesn't support the decisions you make in your policy, then what good is the policy? The technology is the foundation for all your policy work - it takes more time to change the technology than make a slight change in policy.
I assure you that I understand the difference between the two, but I am not convinced that you understand the link... make sense?
Yes, I understand the link, but not why you believe the relationship is reversed.
evidently I got a few things wrong there... However, the point I am making still stands. The point is that it's debian's policies that make the dpkg and apt-get system easier to use than the various rpm systems.
I don't agree with you on the point of ease-of-use. But even if we let that aside, you think it's Debians packaging policies that make Debian packages shine. I don't understand your point, in my experience rpms done by Red Hat are also excellently packaged, maybe even better.
If the same policies were strictly applied to rpms (as you claim SuSE does), then they would be as good (except that apt-get and dpkg rock:).
They are strictly applied. I still sense some confusion here. You have to be able to distinguish between the two different subjects:
Packaging technology used (rpm/deb/tgz)
Packaging policy (how the person building the packages does with naming, building and scripting of packages, macros used, etc.)
Each distribution has their own packaging policy. Debian has their own. Red Hat has their own. SuSE has their own. And so on. Just because Red Hat and SuSE share the package technology doesn't mean they share package policies. On the contrary.
A particular package technology does not enforce a particular packaging policy. You can use the same technology but have different views on how packages should be named, for example. Neither should a technology enforce a policy; policies are usually only a "political" decision and have not much to do with technology.
As for the technology, dpkg may have some interesting aspects. But as for Debians packaging policy, I don't think they are as good as you make them out to be. Debian naming OpenSSH packages "ssh" to make users confused what ssh is installed is just one example.
Still, the dominance of RedHat and the incompatibility between the RPM based distros doesn't bode well for rpm in my books.
So you're blaming differences in distributions on the package system used? Please explain, because I fail to understand the reasoning.
.. Was 'Red Carpet' ever made? It would have been easier to use apt, since it has been ported to rpm. Same goes for that KDE update thing, and all the other redundant tools. Or am I totally missing the point here?
is not actually the fact that apt-get is not comparable to RPM, but the fact that Debian has a strict policy on package dependencies.
Eh, so has every distro.
The main difficulty with porting apt-get to RPM (and in fact, the main difficulty with any automated system for RPM) is that there are no standards about how to make your rpms. You just do it whatever way you wnat.
So what you really say is that it's bad packaging. I would call that the packager's fault, and not blame rpm.
RedHat themselves don't conform to the LSB filesystem standard, which doesn't help.
This is where it gets really wrong. To start with, LSB is not a filesystem standard (LSB is not even completed yet!), FHS is (and is completed).
And yes, Red Hat 7 plays by the rules of the FHS very nicely.
IMHO, any packaging system must have complete and strict dependencies, and policies on these so that a package is not valid unless it's correct and pretty damned complete, and it must comply with the LSB as much as practicable.
I sense some confusion. A package shouldn't confirm to a filesystem standard. That's just plain illogical. You'll end up with hard-coded paths that are wrong on many systems. Instead, you should use rpm macros when packaging an rpm and specifying paths, macros that will make things go where they should on any rpm system. That makes stuff exactly as portable as you want.
Good packagers use macros, bad ones don't.
Debian does this, no RPM distros do.
Maybe because you're asking for the wrong thing?
Hence, Debian is easier to maintain.
Given the above, I don't understand this argument.
The only problem I see is people who cannot understand the difference between a problem with bad rpm packaging and a potential problem with rpm.
The next time I reinstall Linux I think I'll install Debian instead of RedHat. I've stuck with RH because of habit, but RH7 really convinced me to switch. kgcc, plus shipping a frickin SNAPSHOT of gcc - are they on crack? If you can't release something of good quality, don't do a release at all.
Shipping something of quality was exactly what they tried to do. The problem was that the gcc maintainers had not released anything for over a year. gcc 2.95.2 was broken with regards to lots of stuff, most notably C++ and Alpha stuff, for which many fixes had existed for a long time in cvs.
So what Red Hat did was to debug and polish a release snapshot with all these fixes, to ensure a quality compiler.
And with the 2.96-69 update, it's probably the best gcc compiler you can get.
Uh, that's not from some port scan, that's what the server says in it's headers. In this case, it was Apache compiled for Red Hat Linux by Red Hat, so the server version line says that, and the version is returned with each http request.
Try this:
$ telnet www.debianplanet.org 80 Trying 212.1.134.138...
Connected to www.debianplanet.org.
Escape character is '^]'. GET / HTTP/1.0<CR>
<CR>
HTTP/1.1 200 OK
Date: Fri, 16 Feb 2001 17:52:35 GMT
Server: Apache/1.3.14 (Unix) (Red-Hat/Linux) PHP/4.0.4
X-Powered-By: PHP/4.0.4
Connection: close
Content-Type: text/html
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head> ...
So unless they have installed a Red Hat 7 apache rpm package on Debian, thy're using Red Hat 7 (the php 4.0.4 stuff indicates Red Hat 7).
Then why do a custom install when you don't know what you are doing?
Installing a deamon will in almost all cases make it enabled too. If you want it installed and thus want to use it, you most certainly want it enabled too.
Bottom line: if you don't want it enabled, don't install it (which is exactly the point of the custom install; letting you define exactly what you want installed and enabled).
Red Hat 7 didn't install with everything enabled by default. If you install "Workstation", the default, almost nothing deamon-like is installed (and thus not enabled).
If you instead choose to do a "Server" install, lots of common server software will be installed, and thus enabled. But you have to manually make that choice (and ignore the warnings in the help text).
Chances are you did a server install when you would have been better off with the default workstation install.
So... you as a Linux-Company would do such a feat as translating an office suit to a yet unsupported language and NOT try to keep other commercial entities from making money of your precious work, at least for some time?
Yes. Not all companies are as greedy as SuSE and try to withhold stuff all the time.
Red Hat releases all its software as free software all the time, and of course competitors can get it and use it themselves (that's how Mandrake got started). But Red Hat doesn't think this is a problem, on the contrary (there was a interview with Bob Young a while ago where he was asked about this), it's part of the evolution of free software and benefits everyone. Mandrake can use Red Hat's improved software and Red Hat can use Mandrake's improved software.
This is a fundamental part of how free software works, and a part that SuSE seemingly doesn't understand.
to be pedantic i would like to point out that RedHat does have a priority ftp site (for customers paying support)
True.
where updated packages appear 1-2 weeks before the public ftp servers
Eh? Are you sure about that? I don't think that's true. The packages appear at the same time everywhere. If you experience a 1-2 week lag, it could be a problem with the syncing at the mirror you are using.
but this is a minor thing, and i agree that RedHat has a very good attitude:-)
Yes. Amazing how people don't care that much when a company like SuSE screws with licenses or withholds their downloads, but are scared to death with a company like Red Hat.
Although Red Hat is the opposite when it comes to this - the ISOs are downloadable right from the beginning, even before you can buy the package; everything Red Hat does is released under the GPL/LGPL, etc.
I think it's the companies that say they support free software and the free software movement, but on the same time are not afraid to stick a non-free license on what they do or withhold free versions, that one should be afraid of. Let's hope SuSE will get better in this aspect.
How about SUSE, Debian non-US/non-free neither of which should fall foul of US IP Law!
Eh... this is not about where the headquarters are located, it's about exporting/selling in a market where the product potentially infringes on patents. Those two can be very different.
Anyone care to post a list of all the other Linux Distributors who do not let themselves be subjected to US IP Law?
All other distributions are subject to US IP law when selling/exporting products to the US. Where the product was developed or where the headquarters are is not important, it's where the product is exported/sold.
This is one of the best reasons why Redhat!=Linux and perhaps the one that will see RedHat either leave the US or simply crumble.
I don't understand your point. Main Red Hat headquarters are indeed in the US, but there are offices in the UK, France, Germany, Italy, Spain, and Japan. There are Red Hat developers all over the world.
Where the head office is doesn't have the big effect you seem to think, IMHO. When the export of SSH still was restricted, Red Hat Germany provided those SSH RPM packages on ftp to anyone outside the US wanting those, just like other distributions did.
The vulnerabilities being exploited have been documented since at least Redhat 4 days.
That's an outright lie. Care to back it up with some proof? The wu-ftpd vulnerability used by these worms is with wu-ftpd versions prior to 2.6.0, and this vulnerability affected every single Linux distribution that included wu-ftpd (most do). Guess what? The hole was discovered, and wu-ftpd 2.6.0 released, after Red Hat 6.2 had been released for some time. An updated wu-ftpd 2.6.0 package was issued as a security fix for Red Hat 6.2 by Red Hat shortly thereafter.
Slashdot Mirror
These packages are GPG signed by Red Hat, Inc. for security. Our key is available at:
http://www.redhat.com/corp/contact.html
You can verify each package with the following command:
rpm --checksig
If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command:
rpm --checksig --nogpg
So it's not exactly a new idea :-)
I could make that list even longer with many more projects that Red Hat either funds, maintains, develops or contributes to, but I think I've already proven my point.
It would bypass it, and it would be perfectly ok as I understand it. But you have to consider that RHN is more than just doing a rpm -Fvh on every system - it lets you tailor the upgrades and upgrade policys for every machine, tell exactly what should be upgraded when there's upgrades and how and when, and what upgrades should be notified upon, etc.
So you'd have to implement a "RHN" of your own on your local net to replace all of that functionality, even with that single master that uses RHN "for real".
Hey, I am all for RedHat to make money - and I agree that this is a value added service, and should be charged for. No problems here with that. But they better hope their normal business users are all dumb, or have incompetent admins (running Linux - hah - probably some MCSE who picked up a book on RedHat and now thinks he knows something - that or a management type trying to get ahead)...
Don't confuse convenience and simple economics with being dumb. For some companies it might be cheaper to use RHN than hire a code monkey to implement an equally competent update-distribution mechanism (yes, RHN is more than just the functionality of apt-get).
Most of the services that Red Hat offers can be had for free (in fact, all I know of). You can download the OS free of charge - but many people don't have the bandwidth/time/patience/burner or want the printed manuals/support. Consider this a similar thing - it's a ready-to-go update deployment/tracking system for those who need it and don't want to or have the time or resources to implement it on their own.
The agent is GPL. If you don't trust the binary, use the source.
Or you could use Red Hat... ;-)
Umm... you're right, it's
rpm -Uvh glibc-2.2-12.i686.rpm glibc-common-2.2-12.i386.rpm nscd-2.2-12.i386.rpm
That was a great deal more, was it?
My point is, upgrading the glibc on Red Hat 7 really isn't harder than that. Red Hat 7 was compiled against glibc 2.1.92, a prerelease of glibc 2.2, and thus everything is binary compatible with the final glibc 2.2. If you think you shouldn't upgrade your glibc, think again.
Umm... even the author of gmc admitted widely that doing a file manager the way gmc was done (a hacky GUI interface to a CLI file manager) was a big mistake to begin with, and a shame for all the rest of Gnome as long as it wasn't replaced. The concept of having to map the operations in a GUI file manager to the workings of mc was less than fortunate.
So it wasn't really a question about "fixing bugs" in gmc (I don't know if you noticed it but gmc development has been dead for a long time), it was a question about replacing the broken design all together and start over with something new. Hence Nautilus.
Umm, no...
a mp3 player
It uses mpg123 for that. Nice, eh?
and more.
My point being that it re-uses a lot of code. So it's not so much of a "huge part of Gnome" as it is a "wide portal to Gnome".
Not entirely true. Nautilus makes heavy use of the Bonobo component system, and also provides lots of pointers for viewing the files in alternate applications. In fact, there are rather few built-in viewers specific for Nautilus. All this makes a user use a good deal of "the rest of Gnome" even from inside Nautilus.
Do you have examples? What exactly is better with the Debian packaging policy? Otherwise this is just trolling... you can't just expect anyone to listen to "uhm, yeah, the package policy is great because apt is great and apt is great because the policy is great because..." with no explainations, and expect anyone to take you seriously.
2.Due to this consistency, apt-get and so on are made possible.
How does a packaging policy make a technology possible? Please explain. Otherwise, I think common sense says it's the other way around.
I haven't tried the various tricks that are used to get apt-get working with rpm, but given my previous experience, I don't see them as being likely to work. I could be wrong here.
What isn't likely to work? Some people have already made it work for you.
ie, the policy enables the technology to work.
Again, please tell why. I think a lot of people agree with me that you build a policy around the technology used - because if the technology doesn't support the decisions you make in your policy, then what good is the policy? The technology is the foundation for all your policy work - it takes more time to change the technology than make a slight change in policy.
I assure you that I understand the difference between the two, but I am not convinced that you understand the link... make sense?
Yes, I understand the link, but not why you believe the relationship is reversed.
I don't agree with you on the point of ease-of-use. But even if we let that aside, you think it's Debians packaging policies that make Debian packages shine. I don't understand your point, in my experience rpms done by Red Hat are also excellently packaged, maybe even better.
If the same policies were strictly applied to rpms (as you claim SuSE does), then they would be as good (except that apt-get and dpkg rock :).
They are strictly applied. I still sense some confusion here. You have to be able to distinguish between the two different subjects:
Each distribution has their own packaging policy. Debian has their own. Red Hat has their own. SuSE has their own. And so on. Just because Red Hat and SuSE share the package technology doesn't mean they share package policies. On the contrary.
A particular package technology does not enforce a particular packaging policy. You can use the same technology but have different views on how packages should be named, for example. Neither should a technology enforce a policy; policies are usually only a "political" decision and have not much to do with technology.
As for the technology, dpkg may have some interesting aspects. But as for Debians packaging policy, I don't think they are as good as you make them out to be. Debian naming OpenSSH packages "ssh" to make users confused what ssh is installed is just one example.
Still, the dominance of RedHat and the incompatibility between the RPM based distros doesn't bode well for rpm in my books.
So you're blaming differences in distributions on the package system used? Please explain, because I fail to understand the reasoning.
Yes. Some people like GUI tools.
Eh, so has every distro.
The main difficulty with porting apt-get to RPM (and in fact, the main difficulty with any automated system for RPM) is that there are no standards about how to make your rpms. You just do it whatever way you wnat.
So what you really say is that it's bad packaging. I would call that the packager's fault, and not blame rpm.
RedHat themselves don't conform to the LSB filesystem standard, which doesn't help.
This is where it gets really wrong. To start with, LSB is not a filesystem standard (LSB is not even completed yet!), FHS is (and is completed).
And yes, Red Hat 7 plays by the rules of the FHS very nicely.
IMHO, any packaging system must have complete and strict dependencies, and policies on these so that a package is not valid unless it's correct and pretty damned complete, and it must comply with the LSB as much as practicable.
I sense some confusion. A package shouldn't confirm to a filesystem standard. That's just plain illogical. You'll end up with hard-coded paths that are wrong on many systems. Instead, you should use rpm macros when packaging an rpm and specifying paths, macros that will make things go where they should on any rpm system. That makes stuff exactly as portable as you want.
Good packagers use macros, bad ones don't.
Debian does this, no RPM distros do.
Maybe because you're asking for the wrong thing?
Hence, Debian is easier to maintain.
Given the above, I don't understand this argument.
The only problem I see is people who cannot understand the difference between a problem with bad rpm packaging and a potential problem with rpm.
Shipping something of quality was exactly what they tried to do. The problem was that the gcc maintainers had not released anything for over a year. gcc 2.95.2 was broken with regards to lots of stuff, most notably C++ and Alpha stuff, for which many fixes had existed for a long time in cvs.
So what Red Hat did was to debug and polish a release snapshot with all these fixes, to ensure a quality compiler.
And with the 2.96-69 update, it's probably the best gcc compiler you can get.
Incorrect. It's egcs 1.1.2.
Try this:
$ telnet www.debianplanet.org 80
Trying 212.1.134.138...
Connected to www.debianplanet.org.
Escape character is '^]'.
GET / HTTP/1.0<CR>
<CR>
HTTP/1.1 200 OK
Date: Fri, 16 Feb 2001 17:52:35 GMT
Server: Apache/1.3.14 (Unix) (Red-Hat/Linux)
PHP/4.0.4
X-Powered-By: PHP/4.0.4
Connection: close
Content-Type: text/html
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
...
<html>
<head>
So unless they have installed a Red Hat 7 apache rpm package on Debian, thy're using Red Hat 7 (the php 4.0.4 stuff indicates Red Hat 7).
Installing a deamon will in almost all cases make it enabled too. If you want it installed and thus want to use it, you most certainly want it enabled too.
Bottom line: if you don't want it enabled, don't install it (which is exactly the point of the custom install; letting you define exactly what you want installed and enabled).
If you instead choose to do a "Server" install, lots of common server software will be installed, and thus enabled. But you have to manually make that choice (and ignore the warnings in the help text).
Chances are you did a server install when you would have been better off with the default workstation install.
-rw-r--r-- 1 root root 1299736 dec 20 20:34 python2-devel-2.0-3.i386.rpm
Python 2 is in "Powertools" on Fisher.
Yes. Not all companies are as greedy as SuSE and try to withhold stuff all the time.
Red Hat releases all its software as free software all the time, and of course competitors can get it and use it themselves (that's how Mandrake got started). But Red Hat doesn't think this is a problem, on the contrary (there was a interview with Bob Young a while ago where he was asked about this), it's part of the evolution of free software and benefits everyone. Mandrake can use Red Hat's improved software and Red Hat can use Mandrake's improved software.
This is a fundamental part of how free software works, and a part that SuSE seemingly doesn't understand.
True.
where updated packages appear 1-2 weeks before the public ftp servers
Eh? Are you sure about that? I don't think that's true. The packages appear at the same time everywhere. If you experience a 1-2 week lag, it could be a problem with the syncing at the mirror you are using.
but this is a minor thing, and i agree that RedHat has a very good attitude :-)
I agree.
Although Red Hat is the opposite when it comes to this - the ISOs are downloadable right from the beginning, even before you can buy the package; everything Red Hat does is released under the GPL/LGPL, etc.
I think it's the companies that say they support free software and the free software movement, but on the same time are not afraid to stick a non-free license on what they do or withhold free versions, that one should be afraid of. Let's hope SuSE will get better in this aspect.
Eh... this is not about where the headquarters are located, it's about exporting/selling in a market where the product potentially infringes on patents. Those two can be very different.
Anyone care to post a list of all the other Linux Distributors who do not let themselves be subjected to US IP Law?
All other distributions are subject to US IP law when selling/exporting products to the US. Where the product was developed or where the headquarters are is not important, it's where the product is exported/sold.
This is one of the best reasons why Redhat!=Linux and perhaps the one that will see RedHat either leave the US or simply crumble.
I don't understand your point. Main Red Hat headquarters are indeed in the US, but there are offices in the UK, France, Germany, Italy, Spain, and Japan. There are Red Hat developers all over the world.
Where the head office is doesn't have the big effect you seem to think, IMHO. When the export of SSH still was restricted, Red Hat Germany provided those SSH RPM packages on ftp to anyone outside the US wanting those, just like other distributions did.
Now just make sure you all visited petition.eurolinux.org
I've done so, and Red Hat is there =)
It's spelled "Red Hat". Would you please care to explain why you write that name with a dollar sign?
That's an outright lie. Care to back it up with some proof?
The wu-ftpd vulnerability used by these worms is with wu-ftpd versions prior to 2.6.0, and this vulnerability affected every single Linux distribution that included wu-ftpd (most do). Guess what? The hole was discovered, and wu-ftpd 2.6.0 released, after Red Hat 6.2 had been released for some time. An updated wu-ftpd 2.6.0 package was issued as a security fix for Red Hat 6.2 by Red Hat shortly thereafter.
The LPRng problem was detected very shortly after Red Hat 7 was announced. A fix was released immediately.
That they have not been repaired and the packages update is as inexcusable as the assorted Microsoft vulnerabilities.
Please check your facts before spouting off such FUD and lies. Or maybe I just responded to a troll, posting at +2...