[rescue] moussh [was Transplanting a Sun Fire V210 motherboard - PSU requirements?`]

[Mouse]

>> (Avoiding OpenSSH was one of the motivations behind my writing
>> moussh, for exmaple.)
> How does moussh compare to other implementations?  Does it implement
> local echo? ;)

As in, line-at-a-time instead of character-at-a-time input?  No.  It
would be relatively easy to implement, though; I've added it to the
to-do list.

As for how it compares in other respects?  It's different.  It's got a
bunch of stuff I'm not aware of in any other implementation (though I
haven't looked much; another big part of the reason I did it was to
learn the protocol, for which using some other implementation is
useless).  And, of course, it's lacking in some respects as compared to
others.

Things I'm particularly proud of:

- Connection sharing that actually works well.
- A relatively powerful ocnfig-file language.
- Very flexible host-key management; in particular, if it sees a key it
   knows coming from a host it doesn't, it'll tell you about it.
- No non-PD code needed beyond libc (by default it uses libgmp for
   large-number arithmetic, but it does have a private implementation
   sufficient for its own purposes; I still use libgmp where I can
   because it's usually faster).
- An interactive interface to the authentication agent.
- The ability to use an arbitrary process's stdin/stdout as the server
   connection, rather than insisting on establishing a TCP connection.
- TCP forwarding that must work, or the client doesn't start.

I talked about it at BSDCan 2005, I think it was, and I think I listed
"completely independent codebase" and "under active development" on
both the "Advantages" and "Disadvantages" slides....

>> So far, my perception of OpenBSD has not been enough better than
>> NetBSD to override that.
> Well, it DOES derive from NetBSD.

I know.  I got involved with NetBSD just barely before...um, before the
split, shall we say.

>> What I'd _like_ to do is to head off in my own direction.  I'm not
>> sure what, and I'm not sure I'm capable, but I am sure it would be
>> interesting.
> Start with 4.3BSD as a base and modernise it from there. ;)

I would prefer to go in a different direction.  As useful as POSIX has
been, I think it's doing the computer world harm now, in that
something that doesn't at least mostly fit a POSIX framework more or
less can't be done.  For example, in 2002 I ran into an experimental
encrypted storage paradigm that had some interesting potential, but the
design was pretty much incompatible with the POSIX model.  Since I was
hired to build a glue layer to make it mountable as a filesystem under
NetBSD, this posed an interesting challenge - but it was an issue only
because of the POSIX paradigm's dominance.

So, yeah, I would start by questioning everything.  Processes.
Filesystems.  Sockets.  Do we need them?  What do they provide?  Are
there other ways to satisfy the same underlying desires?  Is a thing
satisfying multiple desires, and if so can we split it?  Do multiple
things satisfy the same desire, and if so can we merge them?

For example, filesystems as POSIX knows them satisfy two very distinct
desires: (1) storage that survives across reboot and power-off; (2)
organization of storage.  These are each pretty necessary, but there's
no reason they have to be addressed by the same subsystem.  (As a
simple counterexample, imagine a Lisp system in which (2) is addressed
by the usual Lisp-world mechanisms, but (1) is addressed by simply
marking some Lisp-world objects as nonvolatile.  Something like a
filesystem might be involved under the hood, or might not.

Something like processes with respect to threads of control are
probably necessary unless I can find a way to use a model of
computation that's not sequential imperative.  But it's entirely
possible that I can reduce or augment the list of state associated with
each thread of control.  Memory space.  Access rights (by which I mean
not only stuff like UID, but also stuff like file descriptors).
Working directory.  Do we need these?

What about UI paradigms?  There are a lot of those running around and
I'm wondering if I want to adopt and/or adapt them or try to invent
something new.

So far, I have a lot of questions and few answers.  But I want to
experiment more than build The Next Great OS.  If it turns out to be
useful, fine, but that's a distinctly secondary concern at this point.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B