Subject: RE: uvm_fault panic on 4.0_BETA2/amd64
To: Joerg Sonnenberger <joerg@britannica.bec.de>
From: De Zeurkous <zeurkous@nichten.info>
List: tech-kern
Date: 06/22/2007 15:09:34
Haai,

On Fri, June 22, 2007 14:55, Joerg Sonnenberger wrote:
> On Fri, Jun 22, 2007 at 02:35:08PM -0000, De Zeurkous wrote:
>>>[snip]
>>
>> I'm not talking about financial incentives (yuck). I'm talking about
>> reputation.
>
> AFAIK exactly one person is fixing bugs in LFS right now. He has made a
> lot of progress over the last two years in that area. Saying that
> "it will never be stable" is attacking the reputation of exactly that
> person for no good reason. That's why I complain about the tone of that
> message.

If I had the responsibility of lifting a brick of 128 kilograms 2 meters
into the air, and I'd barely get it 2 cm, does that damage my reputation,
or should I get more people (or a tool, for that matter) in to help me
finish the job?

>
>> That doesn't matter for my point. There have been tons of people
>> complaining about LFS and /nobody/ seems to do anything about it in a
>> reasonable timeframe; I've seen lots of issues that could be solved by a
>> few hours of hard work (rm -rf /usr/{,pkg/}games if you can't do that).
>
> Are you sure many of the issues are that easy? It is not so much the
> complexity of LFS alone, but the interaction of the code base with UFS
> and UVM. That is far from trivial. I don't know what Konrad is normally
> doing, so I have no idea whether or not he could do that.

I will certainly admit that I don't have a good grasp of the kernel
internals right now. However, with the appropriate rest (2 months of tape
monkey work (C) a budget cut /ain't/ funny) I can surely get a very good
idea of it after two months on-and-off studying.

Besides, filesystem code interacting directly with the VM system? That's
totally unnecessary, although some care is obviously needed in the case of
using swap files.

>
> I found that opinion about NetBSD to be popular and unjustified.

Hm, I was not even aware of this. It was an independent conclusion.

> NetBSD
> has gotten a lot better over the last two years and seen many important
> new features.

But still, there isn't a Plan 69(TM). While a load of improvements
continue to be made, there isn't anything more than a rough direction to
take the project in. We need a vision of a future operating system to
evolve into.

My personal favorite is to acknowledge Plan 9 won't work since it's too
low-level, and instead build a mid-level system upon (and in some cases,
such as the kernel, integrated with) NetBSD. I'm working on a flow-based
execution environment for the high-level stuff.

>
>> When things get tight, don't just hold on and see where the ride will
>> take
>> you. /Act/, even if it means making sacrifices.
>
> I'm often working the larger part of my day on NetBSD and pkgsrc, so I
> feel a bit more personally involved with comments like that :-)

Heh :)

Baai,

De Zeurkous
-----------

Friggin' Machines!

>
> Joerg
>