Re: join us!
> If someone found a seemingly 'old' version in Red Hat 6.2, writing to
> support@redhat.com might or might not yield a result. You aren't sure who
> at Redhat is responsible for that given piece of software. In Debian,
> that is _never_ true. If I find a bug in the X server, I know that I can
> either file a bugreport or write directly to Branden, who maintains it,
> and often a response is immediate. Debian is the only distribution that
> can say this: you know the exact person who claims responsiblity for any
> given item.
Uhhh... no you are wrong.
[seifried@chaser seifried]$ rpm -qi usermode
Name : usermode Relocations: (not relocateable)
Version : 1.26 Vendor: Red Hat, Inc.
Release : 3 Build Date: Wed 12 Jul 2000
10:46:28 PM MDT
Install date: Wed 13 Sep 2000 07:03:57 PM MDT Build Host:
porky.devel.redhat.com
Group : Applications/System Source RPM:
usermode-1.26-3.src.rpm
Size : 141926 License: GPL
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
So you go to http://bugzilla.redhat.com/bugzilla, submit a bug report and 9
times out of ten get an email from someone at redhat in a day or so.
> It's not about duplicating effort at all. Clearly, you haven't been
> exposed to the 'Debian' way at all. Debian is very picky about doing
> things the 'right' way. Since we can't insist that all authors make
> their software do things the 'right' way, since we have the code, we patch
> it and release the diff, which brings the code to Debian specs. For
> instance, the policy manual clearly says what can and can't go where.
> Nothing in /usr/local, for instance. If an author wrote the software to
> install in /usr/local, we _must_ patch the software to put it into the
> 'right' place. You might argue about the duplication of effort, but I
> always know where the documentation, the binary, the libraries, etc, all
> are in any Debian packed piece of software. And there are lots of other
> less clear examples that can be made.
But quite often the author does do things the "right" way. As for relocating
software I fail to see what that has to do with anything.
> True. And Debian hasn't been blind: the major criticism is still 'this
> stuff is old' because everyone else rushes stuff out the door except
> Debian. Package pools will fix that, and it's already in the planning...
> I'm going to guess that Debian 3.0 will implement pools in some fashion,
> and that will make more up-to-date software releases.
Being to fast can be bad, being to slow is also bad. Users still do not
demand security, look at my weekly Linux digest, it's often 50k+.
> > So I'd definitely encourage you to tell people up front that you
> > backport selected improvements, seeking to produce the most stable
> > packages possible.
>
> This should be said clearer, I think the whole thing with Kurt proves
> that.
So far no-one has been able to point me to a Debian webpage regarding
security/updates that has the word "changelog" on it. a good place might be
/security/ or to make a page describing how you handle software updates.
> Hehehe. Gee, you really don't know Debian at all, do you? Before you
> write long critics, you should do your homework. All of this exists.
> Go to the website and take a look. It's well written and succinct, but
> you haven't read it yourself.
URL please?
> No, Debian doesn't. It's a volunteer effort, and there are _always_ never
> enough people to do all the jobs. Slink wasn't broken, it just aged
> badly compared to other distributions because they upgraded. Compare
> Slink a Redhat 5.2 or a Caldera 1.3 and you see how well done Slink
> was. Comparing Slink to Mandrake 7.0 isn't at all evenly matched.
Red Hat 4.2 also "aged badly"... as for comparing it to redhat 5.2.... will
6.2 has been out for quite a long time, well before 2.2. heck Red Hat 7.0
beta was out before Debian 2.2.
> The patches they release will apply cleanly, because they will take the
> time and effort. Red Hat, Mandrake and everyone else take the easy
> road: They just package the new version most of the time and recommend
> everyone upgrade. They don't take responsiblity, they shift it
> upstream. "Oops, that might break your system, but it's not our fault,
> they released a new version". Debian avoids this consistently.
I haven't really found this to be a problem, and I've been using redhat
since ... 3.0.3? As for not taking responsibility... I find that claim
rather lame.
> Debian's bug reporting is impartial. It's 100% open and mostly archived.
> Anyone can submit a bug report, and you can always see the history, the
> age, etc. Debian's release of security fixes is usually at the bleeding
> edge. Often Debian's release is days ahead of the other distributions,
> and keep in mind, our people don't get paid to do this.
Uhhhhhhh I take issue with this. I write a weekly Linux digest, have for
several months, Debian is not the fastest.
-Kurt
Reply to: