LWN: Comments on "ESR's goodbye note"

Do we need this crap on LWN?

bronson — Sat, 03 Mar 2007 06:26:59 +0000

Well, I blame CUPS for thinking to this day that "client-error-forbidden" is a perfectly adequate error message. The error messages that CUPS prints out have to be about the worst in the entire industry. The only solution is to turn on debugging and then dig through an 2 MB trace (that includes all web/CGI traffic too) trying to see what went wrong.

It's. an. utter. nightmare.

Sorry, that was theraputic. Clearly I still have a long way to go before I'm truly cured of my CUPS-induced trauma. :)

Do we need this crap on LWN?

emj — Sat, 03 Mar 2007 04:32:40 +0000

But the printer dialogs on Linux desktops sucks, maybe it isn't CUPS fault but blame has to be lain some where.

Try printing duplex on a Linux machine, from Acrobat Reader... ;-/

Travel rules

mikesalib — Thu, 01 Mar 2007 23:02:45 +0000

Actually, he is not clear with his rules at all. I once worked on a conference that invited him to speak (along with many others). Shortly before the conference started, he sent me an angry flame complaining about the fact that we had not set up the trip to his exacting specifications. He pointed to that same damn travel requirements document.

I checked my email and politely explained to him that he *never* *told* us about his requirements. Furthermore, none of the other 30 attendees were so demanding. He acted churlish, but showed up anyway.

Apparently, I erred in not reading everything on his website. Regardless of the rules, the arrogance and self importance of expecting everyone to know them is mind boggling.

apt in CentOS (was: integrity checking)

topher — Thu, 01 Mar 2007 04:24:06 +0000

Just a note, if you enable the CentOS Extras repository on a CentOS 4.x box, there is an apt package available. You can enable it, use yum to install it, and then use apt to manage your packages from then on.

Definitely worth it, IMO. ;-)

which package owns a file

rfunk — Tue, 27 Feb 2007 23:15:54 +0000

That's a generated file rather than one installed from a package. (The base-passwd
package generates it, but I realize your point is about how to get that information.)

The easiest way I know to get that sort of information is to grep the files
in /var/lib/dpkg/info/.

which package owns a file

cdmiller — Tue, 27 Feb 2007 23:00:41 +0000

Yeah but whats up with this?

dpkg -S /etc/passwd
dpkg: /etc/passwd not found.

Whereas:
rpm -qf /etc/passwd
setup-2.7.3-1mdv2007.0

dev => udev

bojan — Mon, 26 Feb 2007 04:27:18 +0000

> why you'd need to "clean out" /dev when moving to an udev-based system

Well, if you run "yum upgrade", it is a fact that that's is what's going to happen: upgrade to udev will remove dev, which will remove all entries in /dev.

As you explained, it is not necessarily what needs to happen - but it does by default. So, unless you're prepared for some creative surgery (as per you explanation), you will get screwed.

Coming back the original question of supported upgrades from CentOS 3 to 4 (or RHEL 3 to 4), it is obviuos why this is not a recommeded thing to do - people don't normally want to recommend a complicated and risky process that would in the end require a reboot anyway (new kernel). RHEL packages were designed to be upgraded using the upgrade process, not "yum upgrade" (remember: RHEL 3 and 4 don't even ship yum, it's a CentOS addition).

You can find some more info here (search for udev):

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manu...

Note how you have to be on 2.6 kernel before starting this. CentOS 3 (i.e. RHEL 3) is based on 2.4 kernel.

Instead, one cuts a small kickstart file, starts an upgrade and after some minutes has a fully upgraded system with far less risk of stuffing things up.

dev => udev

smurf — Sun, 25 Feb 2007 14:54:18 +0000

So please enlighten us poor souls who have *no*idea* why you'd need to "clean out" /dev when moving to an udev-based system. Why not leave the old package-supplying-/dev-nodes installed?

You can mount a tempfs onto /mnt/whatever, create the bare essential device nodes there, move-mount that to /dev, and start up udev. (In fact, this is how a udev-based system boots in the first place.)

Total downtime for programs attempting to open /dev/null (or whatever): Zero.

Afterwards, if you do want to remove the old /dev-supplying package, well ... RPM has a --justdb option.

Do we need this crap on LWN?

evgeny — Sun, 25 Feb 2007 14:01:29 +0000

OK, thanks for clarifications. I stand corrected.

> Connectiva ported apt-get to rpm and I prefer it over yum to administer the odd Redhat machine we have at work.

And so do I...

Do we need this crap on LWN?

rganesan — Sun, 25 Feb 2007 08:50:36 +0000

> Even if true (though I've yet to see anybody stating it on oath) this
> would be absolutely insufficient to justify its existence - given that
> apt-get existed prior to RPM emergence.

I am a Debian developer but I am responding in defence of RPM, go figure ;-). First, apt-get did not pre-date RPM. Second, apt-get cannot be directly compared to rpm. rpm package equivalent is a deb package and rpm binary equivalent is dpkg utility. apt-get operates at a level higher than dpkg and automatically handles dependencies among other things. Connectiva ported apt-get to rpm and I prefer it over yum to administer the odd Redhat machine we have at work.

As a format, there's not really much to choose between rpm and deb. They both work well. In fact, there is a consistency in rpm command line that I like better than dpkg (for e.g. dpkg --listfiles and dpkg --contents vs rpm -ql and rpm -qlp). I also like the fact that source rpms are also rpms.

Why redhat invented yum when apt-get was already out there is still a mystery to me. However, yum or apt-get is still not the real issue. Even debian apt-get has trouble mixing and matching many repositories. I have had trouble installing some packages from Ubuntu universe/multiverse because the packages in those repositories don't meet the high standards of the code. The real issue is the quality of the underlying packages and the number of available packages.

And _that_ gentlemen is where Debian really shines. Debian is extremely anal about getting even the most trivial details in a package right. If you make the smallest typo/grammar mistake in your package description you get a bug. If you get your dependencies wrong, or doesn't handle upgrades correctly that's a severe bug. It's this attention to detail and the availability of all the packages in the core that makes Debian a winner.

ANDing

man_ls — Sat, 24 Feb 2007 18:18:06 +0000

You mean, like saying this

The relationship between the Free Software movement and the Open Source movement is [...] (w)e disagree on the basic principles, but agree more or less on the practical recommendations. So we can and do work together on many specific projects. We don't think of the Open Source movement as an enemy. The enemy is proprietary software.

instead of this?

The culture of the project's core group has become steadily more unhealthy, more inward-looking, more insistent on narrow "free software" ideological purity, and more disconnected from the technical and evangelical challenges that must be met to make Linux a world-changing success that liberates a majority of computer users.

Take your pick.

ESR's goodbye note

job — Sat, 24 Feb 2007 15:52:08 +0000

It is, and that's the disturbing part the story.

That may have something to do with Raymond recently joining the Linspire board. Read this newsletter from a little more than a month ago, especially point number 10.

Unethical to say the least. Eric S. Raymond, ladies and gentlemen. It's a wonder he gets away with so much.

ESR's goodbye note

arcticwolf — Sat, 24 Feb 2007 13:57:19 +0000

From your above post:

'"iPod generation" is bunch of people who sold their freedom cheap. Why the hell free software guys should think about them at all - is beyond me.'

Pretty clear, if you ask me.

annoyances of building an RPM

zlynx — Sat, 24 Feb 2007 00:41:23 +0000

Perhaps I should have said that you can't do it as "Just a quick hack to fix the build, I don't have time to do it right."

If you are determined to evade a proper source package, you can of course.

Do we need this crap on LWN?

eklitzke — Fri, 23 Feb 2007 23:28:31 +0000

Normally this is used for things that aren't libraries. For example, you might want to have multiple kernels installed, multiple versions of MySQL, multiple versions of Python, etc. I think if you were careful you could do this with libraries as well, but I'm not sure how intelligent RPM would be wrt overwriting symlinks. As it stands, Debian based distributions include the package version as a component of the package name, to get around the limitation. This is why, for example, on Ubuntu there is currently a python2.4 and python2.5 package. In an RPM based distribution there would just be a bunch of python packages in the same repository, and by default the newest one is installed -- if you need an older version and it is in the repository, it can be pulled in by another package's dependencies, or you can specify the version you want to install at the command line. This is a useful feature, and there are yum extensions (e.g. installonlyn) that use it in interesting and creative ways.

Do we need this crap on LWN?

hummassa — Fri, 23 Feb 2007 14:46:08 +0000

> the CUPS rant had some tangible meat to it

No it did not.
It was the same problem -- the guy didn't want to use the right tool for
the job. In the case of CUPS, I have not encountered a printer that didn't
show up correctly in the "Printers" KDE control panel applet for a long
time. Plug it in, fire kcontrol, install the cups drivers, print away --
including network printers.
I am a Kubuntu-using guy, but ESR's rants are normally tangible-meat-free.
:-)

He, he

hummassa — Fri, 23 Feb 2007 14:38:22 +0000

s/OR/XOR :-)

Translations

dark — Fri, 23 Feb 2007 13:52:12 +0000

ESR's complaints about Fedora are a bit vague. Allow me to clarify them here.

* Chronic governance problems.
Translation: They refused to distribute non-free codecs.

* Persistent failure to maintain key repositories in a sane, consistent state from which upgrades might actually be possible.
Translation: Upgrade didn't work for me today. Then when I tried to force it, it broke.

* A murky, poorly-documented, over-complex submission process.
Translation: QA is a pain. They rejected my package.

* Allowing RPM development to drift and stagnate -- then adding another layer of complexity, bugs, and wretched performance with yum.
Translation: Upgrade didn't work for me today. Then when I tried to force it, it broke.

* Effectively abandoning the struggle for desktop market share.
Translation: They refused to distribute non-free codecs.

* Failure to address the problem of proprietary multimedia formats with any attitude other than blank denial.
Translation: They refused to distribute non-free codecs.

annoyances of building an RPM

khim — Fri, 23 Feb 2007 11:27:42 +0000

This mechanism can be easily circumvented (homework: find at least 5 ways to do so) and thus again we are returning back to policy.

Basically it's Windows approach: we'll forbid you to do this because you don't deserve to have control. Sad to have this misfeature in *nix tool...

ESR's goodbye note

khim — Fri, 23 Feb 2007 11:14:31 +0000

Shall we also ostracize everyone who has ever used a proprietary system? After all, only those who grew up with Linux, and have never used anything else, can truly be ideologically pure.

Huh ? Where have you got this idea ?

Don't abandon 'em. Educate 'em. Some of 'em might be smarter than you think.

This is the right idea.

I don't have a problem with a guys who own iPod. As long as they know that all problems in Linux<->iPod interaction are not Linux fault, but Apple's fault - they are not hopeless but... they are not part of "iPod generation"!

Do we need this crap on LWN?

drag — Fri, 23 Feb 2007 07:52:09 +0000

""Also: dpkg cannot install multiple versions of a package simultaneously. RPM can do that, portage can do that, I don't see why this huge feature has been neglected by the Debian community for years.""

I don't understand that and how that works.

In fact it caused major problems for me when I tried to use CentOS that I'd end up with multiple packages installed somehow with no easy way to get rid of them.

Say I have one program that depends on libfoo.3.2 and I have another program that depends on libfoo.3.5 with the libfoo project introducing incompatabilities in their lib files on minor numbers (As many projects do).

Does having multiple packages of libfoo installed automaticly make both programs work? I have no idea.

I mean I've been using Debian for years and I never ever had a desire to install two copies of the same program at the same time...

Do we need this crap on LWN?

mokki — Fri, 23 Feb 2007 07:11:33 +0000

Swapping of glibc at runtime works nicely on all distributions.

As I said the only time I (almost) hosed my system was when I installed a broken glibc. After that you can no longer start any programs and you have to hope you have enough of needed terminals/other programs open that still refer to the old working glibc to recover the situation. The worst thing is that with a broken glibc no distribution tools can install/restore you to safe state again.

fetchmail vulnerabilities in the last year or so

rfunk — Fri, 23 Feb 2007 06:52:25 +0000

This is getting ridiculous. I said one of two DoS and one encryption
issue, in the past year or so. You listed one encryption issue from
2006, two DoS from 2006, and a DoS from 2005. It's now 2007. By my
count the situation is exactly as I said, but if you want to include the
2005 DoS in there then you can have a cookie or whatever for counting
three DoS instead of 1-2.

Look, I couldn't care less if you prefer getmail over fetchmail. But if
you're going to push getmail or criticize fetchmail, please do it with
something approximating the truth. Fetchmail's post-ESR security record
of a handful of low-risk vulnerabilities is far better than your
characterization of "a fresh exploit every other week."

fetchmail vulnerabilities in the last year or so

DonDiego — Fri, 23 Feb 2007 06:32:50 +0000

Right on the fetchmail homepage I find not one or two but four advisories from the last year or so, all of which apply to 6.3.x:

CVE-2006-5974: Fetchmail was found to crash when refusing a message that was bound to be delivered by an MDA. This bug was introduced into fetchmail 6.3.5 and fixed in 6.3.6.

CVE-2006-5867: Fetchmail was found to omit TLS or send the password in clear text despite the configuration stating otherwise. This was a long-standing bug reported by Isaac Wilcox, fixed in fetchmail 6.3.6. There will be no 6.2.X releases to fix this bug in 6.2.X.

CVE-2006-0321: Fetchmail was found to crash after bouncing a message with bad addresses. This bug was introduced with fetchmail 6.3.0 and fixed in fetchmail 6.3.2.

CVE-2005-4348: Fetchmail was found to contain a bug (null pointer dereference) that can be exploited to a denial of service attack when fetchmail runs in multidrop mode. 6.2.5.5 and 6.3.1 have this bug fixed.

Re:

pjdc — Fri, 23 Feb 2007 06:24:27 +0000

But he just got rid of him!

fetchmail security

DonDiego — Fri, 23 Feb 2007 06:16:32 +0000

I'm apparently not making myself clear here .. I don't give a damn about new versions ever since I found a replacement that I consider superior in every respect (and no, I don't care about supporting obscure broken servers). I had grown discontent with the size of fetchmail and its man page for some time already. What then finally made me look for a replacement was fetchmail showing up on the security page every other week...

You may or may not have made fetchmail secure (BTW, ever tried fuzzing it?). If you did, congratulations. I'm quite confident you didn't reduce its size considerably, though.

fetchmail security

DonDiego — Fri, 23 Feb 2007 06:03:45 +0000

No. Although the examples are admittedly few there are securely designed and implemented programs that don't reveal vulnerabilities even under close scrutiny. vsftpd comes to mind.

ESR's goodbye note

njs — Fri, 23 Feb 2007 02:02:32 +0000

>"iPod generation" is bunch of people who sold their freedom cheap. Why the hell free software guys should think about them at all - is beyond me. If they sold their freedom for cheap once - why do you think they'll fight for it the next time ?

Shall we also ostracize everyone who has ever used a proprietary system? After all, only those who grew up with Linux, and have never used anything else, can truly be ideologically pure.

(This principle would, unfortunately, rather decapitate the free software movement. I don't think RMS even qualifies? He wasn't born believing in free software...)

Don't abandon 'em. Educate 'em. Some of 'em might be smarter than you think.

ESR's goodbye note

wlach — Fri, 23 Feb 2007 00:58:24 +0000

The Art of Unix Programming (2003) is actually quite good and well worth reading.

(speaking as someone who's not generally a fan of ESR)

Re:

eklitzke — Thu, 22 Feb 2007 21:05:22 +0000

You can have him!

Do we need this crap on LWN?

pipitas — Thu, 22 Feb 2007 20:45:42 +0000

Yes, I also remember his tirade directed against CUPS.

Our capable ESR did not realize at the time, that he used a frontend tool
to CUPS that was not part of CUPS itself. That frontend (called s.th.
like "rh-print-manager" or similar, can't remember exactly) was what made
his life so bad that he even quoted his Aunt Tillie... And that very
RedHat/Fedora frontend was the reason for most of the bad PR CUPS received
at the time (Native CUPS tools and its default configuration would have
handled easily the requirements ESR had for his home printing...).

But still, the criticism was taken up by Mike Sweet in a positive way, and
Mike introduced several changes and improvements into CUPS 1.2.x because
of that.

Which does not change my personal opinion about ESR being a guy who seems
to love publicity around his person more than anything else...

Do we need this crap on LWN?

eklitzke — Thu, 22 Feb 2007 20:40:41 +0000

FWIW...

The only problems I have had with RPM have been circular dependencies (this not recently). This can, of course, occur with dpkg as well -- it's a problem that is symptomatic of poor packaging, not the package manager. OTOH, I have had issues with dpkg on a number of occasions. In particular, dpkg is not as strict about making sure that everything is going to work, and at least twice I have had failed dist-upgrades that broke the system, because half way through the upgrade dpkg panicked somewhere and left my system half broken. RPM is pretty paranoid in its transaction checks, and will not put you in this position.

Also: dpkg cannot install multiple versions of a package simultaneously. RPM can do that, portage can do that, I don't see why this huge feature has been neglected by the Debian community for years.

A long time Fedora user, I have recently been using Ubuntu because of a few big packages not present in Fedora that would be too onerous to maintain myself. I have been pretty pleased so far, but I still am not impressed with dpkg, especially given the niceties of RPM (and yum).

Do we need this crap on LWN?

loening — Thu, 22 Feb 2007 20:15:36 +0000

Speaking of remote upgrades with RPM. I personally have done
RH8->RH9->FC1->FC2->FC3->FC4->FC5->FC6

On a workstation that sits 300 miles away from me that I haven't seen in years.

Do we need this crap on LWN?

bojan — Thu, 22 Feb 2007 20:07:21 +0000

> But rpm's approach to file updates (used to) prevent the update of base libraries from being achievable on running systems.

Going back to something like Red Hat Linux 7.2, this worked just fine. Upgraded glibc (remotely) many times. I honestly cannot remember before that...

Do we need this crap on LWN?

bojan — Thu, 22 Feb 2007 20:01:34 +0000

> Great, but not on a dedicated host 10,000 miles away.

You missed the unattended upgrade bit above. The one with kickstart.

Let me repeat again. This particular limitation (of not being able to upgrade CentOS 3 to CentOS 4 while running) has nothing to do with RPM. It has to do with the fact that CentOS 4 (i.e. RHEL4) uses udev and CentOS 3 (i.e. RHEL3) uses a dev package. When dev gets removed by upgrading to udev, your system is hosed (you have nothing left in /dev).

Otherwise, I've done plenty of hot upgrades by doing "yum upgrade" on many different versions of Fedora.

> which is the point that ESR seems to have finally stumbled upon in the head article

He stumbled upon his on inability to manage his own system and/or ask others how to do it.

"I don't know how, so it can't be done."

branden — Thu, 22 Feb 2007 18:22:42 +0000

JoeBuck, thanks, even if your subject line is a pretty flagrant distortion of my message. I did say, "if there is a way, my [...] co-workers have not shared it with me."

dpkg log

k8to — Thu, 22 Feb 2007 18:21:07 +0000

Buh, I didn't look at the criteria closely. I've often needed a log and found the 'most recent update' information was too lossy.

deb "wasn't already there" to be used.

evgeny — Thu, 22 Feb 2007 18:00:41 +0000

> So while technically Debian/dpkg was publically available before RHL/RPM, dpkg "wasn't already there" to be used when RHL1.0/RPP (and PMS) was released, nor while RPM was being developed.

I really don't know whether RPP should count (i.e., how sophisticated it was), especially given that RPM wasn't backward compatible to it (then you can also count the primitive package management system used by Debian in 1993 and still get a one year off).

Do we need this crap on LWN?

pizza — Thu, 22 Feb 2007 17:18:40 +0000

>> "RPM-based folks" are apparently missing out on a
>> lot of remote exploits and possible filesystem corruption!

>Some would argue it's not appropriate to have such file system checking
>built in to a package management system.

No; I was referring to the fact that you can't fsck a live filesystem, and that it's an unfortunate fact of life that filesystems are at best only as reliable as the disks they run on -- errors silently happen.

For me, periodic reboots serve two purposes -- Perform filesystem consistency checks, and install updated kernels (I am quite glad the 2.6.x.y series exists!)

It's more commonly known as scheduled preventative maintainence, and through the use of multiple physical systems, I avoid service downtime. (Even with virtualization, the host system needs occasional TLC too!)

> Dare I suggest that if you used a Debian based distro you could go live and stay live with less redundancy and pre-testing.

Been there, done that, been burnt by it. As I've alluded to many times in my posts here, it's the policies that you follow that ultimately matter. I discovered the hard way that using Debian didn't make things any simpler for me -- It just had a different set of quirks to watch out for.

Granted, this was a few years back, and Debian has addressed quite a few of the problems I had at the time... but as I've also said, if I don't see any tangible benefit to making a change, why bother?

ESR's goodbye note

khim — Thu, 22 Feb 2007 17:13:02 +0000

"iPod generation" is bunch of people who sold their freedom cheap. Why the hell free software guys should think about them at all - is beyond me. If they sold their freedom for cheap once - why do you think they'll fight for it the next time ?

Sure - if everyone in new generation will sell their freedom for cool iPod the free software will become extinct, but to try to go after iPod generation is wrong way to fight for freedom...