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

[Cory Smelosky]

On 27 Feb 2013, at 17:32, Mouse <mouse at Rodents-Montreal.ORG> wrote:

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

Nice.

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

I wonder if I could get it to build on 4.3BSD. ;)

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

POSIX is a rather nonstandard standard. ;)

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

I'd also question "everything as a file" and "everything is a stream of
bytes".  Implement proper message busses, and nonblocking queues.  Take a hint
or two from VMS with regards to filesystem.

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

Hmmm.  A dedicated subsystem to fulfil each part of a filesystem could
increase interoperability.

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

Working directory?  Not really necessary.  It think it helps with knowing
where you currently are in the hierarchy though.  However, that ceases to be
an issue if you redesign the hierarchy.

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

Please kill X.  It is time for it to die.  A standard graphics subsystem that
all drivers hook in to would be nice as well.  It would cause less issues and
incompatibilities (nvidia rendering fonts differently than amd on linux is an
example of this issue)

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

I find just planning on fascinating.  I'm unable to implement my own due to
lack of knowledge.

>
> /~\ 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
> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue