[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: join us!



On Sun, 17 Sep 2000, Kurt Seifried wrote:

> > 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.

Kurt, how am I wrong?  Can you tell me _who_ built that package?  Yes,
Redhat has a bugtracking system, but not individual accountablity.
When I installed a Debian package, I know exactly _who_ put that code into
my system.

> 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.

Relocation is only one example.  Using the wrong user, the wrong variable,
not using some debian-ish ideals (like a fixed pager, instead of Debian's
alternative option), etc.  Basically, the Debian patch can be as simple as
a quick build script, to faily complex.  It depends on the package.

Reading the packing manual and the policy would be a good exercise for
someone who want to know more.

> 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.

http://security.debian.org OR http://www.debian.org/security has a
complete list archive for debian-security.  Every single announcement on
that list says things like "A fixed version".  If you can't figure out
that the changelog is the place to look for notice of what changed....

> > 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?

http://www.debian.org/social_contract for a start, then headover to
http://www.debian.org/devel and look at all of the links like the Policy
Manual, the Packaging Manual, the New Maintainer's Guide, the Developer's
reference.  Debian is extremely well documented, and moreso, if you find a
error, or inconsistency, file a bugreport against it. Everything in
Debian, from the software to the website to the manuals to the mailing
lists to the ftp site to the organization itself has a bug tracking system
entry.

> > 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.

2.2 took a long time... nobody argues with that.  The sheer size of Debian
is forcing a change in how things are done.  But you can't compare apples
to oranges.  Slink, for all of it's age, upgrades very smoothly to Potato.  
Try to upgrade Redhat 5.2 to 6.2... good luck.

as for RH 7.0 beta, we have Woody, and it's FAR more usable than RH 7.0
beta... and we support it very well.  You won't get an 'it's beta, wait
for the final version' from Debian.

> > 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.

If you have a _production_ machine; I don't care if it's NT, Linux, or
something else; you do not want to alter that machine too heavily.  
Installing an NT service pack is a nightmare and is known to break many
things.  Installed a new version to fix an bug/hole might be fine, and
then again, it might alter the program subtly.  In 90% of the cases, you
might not notice anything.  But if they altered a command syntax, suddenly
a script breaks some place.  A log file location.  Something else.  This
happens, and it's downtime, and more fixing.  With Debian, anyone who uses
'stable' is guaranteed that Debian will _NOT_ break things.  It is
__Stable__.

> > 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.

Who is then?  As a whole, if you measured who releases first, I'd bet
Debian is most of the time.  If I'm wrong, please document that. I seem to
recall a comparision sometime ago and Debian _was_ the fastest.

Seth




Reply to: