Porting to Kernellib?

[jandrieu]

Have you considered porting to the kernellib? Such as that maintained at https://github.com/ChatTheatre/kernellib ?

I'm working with the latest eOS codebase at https://github.com/ChatTheatre/eOS (in part because the DGD repo failed out of the gate). FWIW, this is a recently cleaned up effort to get a minimal DGD workable out of the box, from the people behind SkotOS.

I was able to use the DGD build from that with Gurbalib, but trying to add, for example, the ssh module from Dworkin: https://github.com/dworkin/lpcssh, which claims compatibility with kernellib (which Gurbalib doesn't use). FWIW, getting DGD building out of the box was problematic (I got it to build but the file hierarchy needed help).

Have you looked at kernellib at all? How crazy would it be to port the minimal Gurbalib library over to a kernellib base?

The essential problem with eOS is that it doesn't have enough in its minimal box. So, yes, you can run it out of the box, but all you get is an empty prompt. No rooms, no objects, no races/characters/etc. Gurbalib is totally awesome. It felt like a bare bones reality which was not only rewarding, it also gave a concrete example of how the kernel and other code fits together.

Even if kernellib sounds crazy, thanks so much for the work with Gurbalib. Getting it up and running helped a TON with understanding what is going on with the whole DGD architecture. Thanks!

[sirdude]

I haven't looked at eOS I will it sounds very interesting. Multiple times I attempted to cut down gurbalib to the bare minimum and then abandoned it for other stuff.

If you look at the TODO file I have it on my list to get ssh working, however I haven't spent any time on it, been working on other things. Porting the lpcssh stuff to gurbalib is probably simpler than trying to port gurbalib to the kernellib. They have basic design structures that don't really mesh well it would be a really complicated project to try and merge them.

gurbalib wasn't created by me I just cleaned it up so to speak and fleshed it out a little bit with the help of a bunch of other people. I don't think I want to work on porting it to kernellib at this point, I still have a lot of unfinished work on gurbalib to do and I would rather spend my time on that work.

Having said all of that, I'm really happy you enjoyed gurbalib and working with it. Let us know if you have any ideas how to make it better.

[jandrieu]

Cool. FWIW, I couldn't get the ssh working with eOS either.

FWIW, I was working with Phantasmal's kernel write up at https://github.com/noahgibbs/phantasmal/blob/master/website/DGD/Kernel/Modifying.base.html Which pretty much starts with the same thing the LPC SSH project does, namely, adding an object that gets invoked on sign-in, by editing or adding /usr/System/initd.c

Do you have an idea of where that would go in Gurbalib? If I can get the code invoked in the right place, I'm open to trying to make it work.

[sirdude]

I'm going to close this ticket and email you outside of github with some talk I had with others about this type of thing. We can continue the discussion there. :)

[shentino]

I'm about a half hour late here, but as successor maintainer of phantasmal, fork maintainer of my own branch of the kernel library, and contributor to the open version of SkotOS, I think I should chime in here.

I strongly advise against porting Gurba to the kernel library at this point barring some further planning, as, as it stands, the two codebases are incompatible architecturally.

@sirdude: Please CC me on said email discussion for this, I think I may be able to help with the discussion.

[jandrieu]

@shentino Thanks for the perspective. If porting the lib is too big of an ask, it might still be interesting to see if we can get the LPC SSH module working for Gurbalib.

[shentino]

I'm about a half hour late here, but as successor maintainer of phantasmal, fork maintainer of my own branch of the kernel library, and contributor to the open version of SkotOS, I think I should chime in here.

I strongly advise against porting Gurba to the kernel library at this point barring some further planning, as, as it stands, the two codebases are incompatible architecturally.

@sirdude: Please CC me on said email discussion for this, I think I may be able to help with the discussion.

To be fair, porting Gurba to the kernel library does have merit on its own, in my opinion, and I think that both subjectively as maintainer of the klib and objectively as a user and collaborator of Gurba.

That said, if such a thing were to happen the incompatibility would need to be addressed first.

[shentino]

@shentino Thanks for the perspective. If porting the lib is too big of an ask, it might still be interesting to see if we can get the LPC SSH module working for Gurbalib.

LPCSSH is architected to be on top of the klib, yes, I mean it is possible to port it with effort That said however I have objections to the package as it is, partly because it can hide output on login, such as the splash screen and what not and it's thus possible to interfere with I/O from the mud itself.