Re: [Evms] Questions about portability

[Christoph Hellwig]

On Mon, Nov 13, 2000 at 04:15:55PM -0200, Andrew Clausen wrote:
> The full library isn't bloated, because you only need the modules
> you want.  There may be slightly more bloat for the "core" library,
> but there's likely to be more code-reuse, so if there are many
> modules (that you want simultaneously), then there is less bloat
> in total.

Ok, now I need only a simple 'program' interface to each module and
I would be happy :)

> 
> >   - it's more UNIXish (and I _really_ like the UNIX way of doing things)
> 
> I'm not convinced here.  Say, compare this to something like the
> standard ftp client.  Should it have separate binaries for "ls",
> "get", "mget", etc?  Why doesn't it?  (because ftp runs on a
> connection?)

Because they are not separate things.  The ftp 'commands' are mostly
send over a tcp connection and executed by the server.
On the other hand lots of ftp daemons use a separate 'ls' binary...

> Could similar arguments be made about this stuff?  (the programs
> aren't really independent - it doesn't make sense (in MOST cases) to
> run these programs on their own?)

No.  I often run e.g. lvextend on my own.  And usually you can resize
filesystem on they're own as long as the block device container is large
enough. (Ok, as spotted before DOS might have problems with that, but
DOS is not considered to be installed on a sane computer ;)).

> Yes, but file systems and partition table code are in completely
> separate modules.  Actually, the way libparted deals with this is
> quite ugly, IMHO.  File systems need to know about all partition
> tables (rather than the other way around, which is The Right Thing)
> We need to do it like this, just because of the fat16/32 issue.

Ugg. That's realy ugly.
I don't know sane filesystems (e.g. ext2) and sane partitioning schemes
(e.g. LVM) should know of each other...
And I'm interested in LVM and not all that DOS legacy crap.
You want it in parted - but I don't want to see such things in a LVM
enviroment.

> Which is often very frustrating.  It's often very difficult to discover
> what the error was, and often, you can do intelligent recovery...
> 
> Eg: Unix handles running out of HD space VERY badly.  X usually crashes,
> and goes into a cycle of crash, attempt restart, crash...
> 
> Users tend to have to LOOK for the problem (i.e. the cause), rather than
> have it presented to them.  (This is true for basically all software,
> not just Unix.  At least with Unix, it's usually possible to find the
> problem...!)

I must say that I like that behaviour.  The error might just not be an error,
or I intended to see that error - now I will get a simple notice on stderr
and it is done.  Sure I would really like to see foorecover tools for
everything, too - but Windowsish <Ok> <Cancel> <Retry> <Make me mad> dialogs
are horryble to me.

> But, how do you present the error message to the user?  (With the
> appropriate options, etc.)  You want to do this in the native language,
> right?

Actually I wouldn't - but lots of others would...

        Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.