[nSLUG] [OT] Looking for a DNS secondary partner

Daniel Morrison draker at gmail.com
Mon May 4 17:45:02 ADT 2009


2009/5/4 Ian Campbell <ian at slu.ms>:
> On Mon, May 04, 2009 at 03:17:08PM -0300, D G Teed wrote:
>> On Mon, May 4, 2009 at 2:51 PM, Ian Campbell <ian at slu.ms> wrote:
>> > On Mon, May 04, 2009 at 10:52:19AM -0300, D G Teed wrote:
>> I do think it is a professional failing.  yum is used in a professional
>> product or two, and given its critical role, I'd think they only allow
>> skilled coders to tackle its maintenance.
>
> Two words: debian openssl.

Two words do not a cogent argument make. What?

> Even OpenSSH has had its share of bugs. Mistakes happen, even for
> skilled coders.

Earlier you were saying that a high moral standard (e.g. not engaging
in murder) is not required to write good code. Now you're saying that
even good coders make mistakes. Conclusion: having low moral standards
does not exempt you from making mistakes, even if you're a good coder.
Am I following correctly? :)

> To be fair, from a developer's perspective a python backtrace is
> probably far more useful than "Error fooing Bar"

But it sucks from a user's point of view.

> I know nothing about your code, but I'm going to go out on a limb and
> say a backtrace would be more useful than a generic error message

You added the word 'generic'.

> there too. You may want to handle it more gracefully than yum does,
> but... yum doesn't need to keep running, it has the luxury of being
> able to exit abruptly if it wants.

yum dosomething withmypackage
[abrupt exit]

Oh great, now what?

Yum is production code used at the core of distributions' package
management. I don't think it has the luxury to break unexpectedly...
and yet it does.

> I guess I don't understand what your complaint is. Does yum blindly
> assume things without checking them (obviously bad), or is your
> complaint that it dumps an unfriendly-looking flood of messages on
> users when it fails?

It was stated that yum blindly assumes a file exists before attempting
to open it, and then crashes. That's what I remember reading earlier,
anyhow...

> > > What I never understood was why ext3 enjoys the popularity it does.
Stephen Gregory said:
> > Ext3 has stability and reliability. Two nice features when you are
> > dealing with data.

> XFS has been around almost as long as Ext2, performs better, and has
> other nice features not found in Ext2 (like safe online dump, online
> defrag, and a couple features like guaranteed IO rate that I don't
> think were ever ported to Linux... still, they exist.)

I remember trying to setup XFS on a RAID I was creating at home, back
when I still thought SCSI was cool (maybe 7-8 years ago). It was a
nightmare trying to understand the complex xfs tools, not to mention
getting xfs support properly compiled into the kernel. All kinds of
third-party patches.

Fundamentally, ext3 enjoys the popularity it does for the same reason
Windows, MSIE, and FAT32 do. Because they're the default. All Linux
kernels since forever supported ext2, and ext3 is backwards-compatible
with ext2. All distributions include the tools. You can boot any Linux
rescue disk from any distribution and it will be able to read your
partitions. There's drivers to read ext2 from Windows (and likely
other OSs) too.

Stability, reliability, availability. And the fact that it's the de
facto "Linux standard" means that it will still be supported tomorrow.
That's why it's popular.

ReiserFS was surrounded in controversy (due to Hans Reiser's ego) long
before he committed any well-publicized criminal acts. That's the main
reason I never got around to testing it. I got the impression that if
it broke, I could pay for commercial support, or risk a tongue-lashing
in some forum. Not so with ext2/3/4. I've met Stephen Tweedie and Ted
T'so, and they're nice guys! So I use ext3 and get warm fuzzies.
Simple.

-D.

PS: one can (and many have) said the same things about OpenBSD: safer
than Linux, better, etc. But people like Linus; he makes them feel
good. Not so for Theo.



More information about the nSLUG mailing list