[Top][All Lists]

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

Re: [Evms] Questions about portability

From: Andrew Clausen
Subject: Re: [Evms] Questions about portability
Date: Mon, 13 Nov 2000 17:15:04 -0200

Christoph Hellwig wrote:
> 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 :)


(But, there are still your other complaints, hehe)

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


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

Why, BTW?

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

DOS/Windows.  But, your comment still stands (but, I'm interested in
insane computers ;-)

Anyway, my argument is a bit obtuse.  I won't bother persuing it.  hehe
> > 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.

It's VERY contained ugliness, but yes, I agree.

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

Obviously, the file system code is going to be shared between partition
and LVM environments, so the code is going to be there, but it doesn't
need to appear in the LVM interface.

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

My grandmother doesn't, hehe.

> The error might just not be an error,
> or I intended to see that error -

In which case, it should be possible to specify this (convieniently).
This would be a big debate, and I don't think this is the appropriate
place, hehe...

Maybe I should ask for address@hidden  :p

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

<vague statement>I guess it depends on the context</vague statement>

/me runs

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

So, I win?  :p

I guess not, because you'd rather print out the [translated] error
to stderr, and be done with it.  Not sure how this works for GUIs.  (log

Andrew Clausen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]