[mod] Minetest Systemd (API) [minetest_systemd]

[Piezo_]

Hello!

I know I usually tend to have a bit more humor when I release a mod, but this isn't so much of a tangible feature-packed mod as it is an attempt to create a tool to make modding easier for myself and others in the future.

------------------------------------
Questions you may have:
-------------------------------------

WTF is this?

I'm glad you asked (even though you didn't, but someone always does). This will eventually be a collection of essential tools, centralized (yes, I'm actually doing this. No, I'm not sorry) into one mod, as well as a framework for dynamically reloading changes in the internal code of mods that support that. Features will also be added as solutions to any problems that are persistent in multiple mods, and frequent compatibility issues.

some_mod already does minetestd.some_functionality better!

Tell me, and I'll remove my duplicate code, but only if some_mod isn't obscure and/or terribly written, and I have reason to believe my version is rendered pointless for all practical uses by its existence.

What kind of stuff will you add to this?

Any kind of tools that would be useful to people trying to assemble a modpack, subgame, or server that they want to be able to update in real-time.

Why GPLv3+?

Because it does make a difference. Allowing proprietary software to take advantage of your contribution to libre software is almost as bad as making proprietary software yourself, in this society.

--------------------------------------------------------------
Features
--------------------------------------------------------------

For a list of features, see the Readme file in the Notabug.org repo.

After the forums went down and had to be rolled back, all of the update changelogs were lost (fortunately, all of my mods are linked, not attached, so the updates themselves remain)

Download
License: GPLv3+

[Mantar]

Systemd for Minetest? Alright! Is it going to be badly programmed and prone to obscure errors, too? :D I can't wait for the massive ~1% performance increase (margin of error: 1%) we'll get from converting Minetest's logs into a compressed binary file that you have to analyze with special tools!

[Piezo_]

Systemd for Minetest? Alright! Is it going to be badly programmed and prone to obscure errors, too? :D I can't wait for the massive ~1% performance increase (margin of error: 1%) we'll get from converting Minetest's logs into a compressed binary file that you have to analyze with special tools!

No, it's just going to be that one annoyingly centralized core tool that tons of mods start to depend on, and may be somewhat bloated.

[Mantar]

No

That's gonna make Poettering feel bad, like you're making fun of him.

Hey, maybe it'll make him rage quit and then when he's gone, other devs can fix the worst of systemd's faults, like what happened when he left pulseaudio? That's brilliant! I fully support this mod, then.

[Glory!]

inb4 MTG includes minetest_systemd sooner than the blink of an eye.
/me shrivers in disgust and fear.
Also, be sure to mount /var and /lib read-write, maybe even /sys/efivars! Someone somewhere might need to restart the computer or install a library while the game is running. ;)

[Byakuren]

I think another criterion should be added: the functionality should be something that doesn't belong in the engine.

[Piezo_]

inb4 MTG includes minetest_systemd sooner than the blink of an eye.
/me shrivers in disgust and fear.
Also, be sure to mount /var and /lib read-write, maybe even /sys/efivars! Someone somewhere might need to restart the computer or install a library while the game is running. ;)

Jokes aside, I am actually going to add a way for mods to "reload" themselves mid-game, and implement a command for server admins to dynamically reload, start and stop individual mods as services (obviously, things like registered nodes and such will not be covered by the scope of this), meaning that some internal code functionality of mods could possibly be changed without having to restart a server.

[sofar]

You probably should choose the AGPL-3.0-or-later instead of the GPL-3.0. This prevents people from taking your code, modifying it and deploying the modifications a server without being required to give the changes they made under the AGPL-3.0-or-later license back to users of that server. If you stick with GPL-3.0, you can't enforce this.

But, honestly, Minetest Game already mostly is this. If you're planning to make something that kind of functions in the same way (never a real game, always needed) then I'd myself pick a better name. Not because I don't appreciate the joke (I get it, I contributed code to the systemd project myself) but naming OSS projects "ironically" has bad side effects (for instance, you may actually have people that are mistaken about what it does or make derogatory comments, and attract trolls. Before you know it someone may just make a suckless mod that is a fork of Minetest Game without any changes.)

Personally, I'd really wish people stopped making "collections" of support mods. I started minetest-mods so that they can be maintained as individual components and not necessarily be all interdependent, which is the whole problem of Minetest Game. You're effectively choosing to design this with the exact same design mistake at the core. I'd strongly urge you to consider instead just making individual support mods and maintain them and post them to the ContentDB, but hey, maybe I'm wrong here.

[Piezo_]

You probably should choose the AGPL-3.0-or-later instead of the GPL-3.0. This prevents people from taking your code, modifying it and deploying the modifications a server without being required to give the changes they made under the AGPL-3.0-or-later license back to users of that server. If you stick with GPL-3.0, you can't enforce this.

This is concerning, but since I've already published this as GPLv3+, I can't add the AGPL's restrictions...

But, honestly, Minetest Game already mostly is this. If you're planning to make something that kind of functions in the same way (never a real game, always needed) then I'd myself pick a better name. Not because I don't appreciate the joke (I get it, I contributed code to the systemd project myself) but naming OSS projects "ironically" has bad side effects (for instance, you may actually have people ththe codeat are mistaken about what it does or make derogatory comments, and attract trolls. Before you know it someone may just make a suckless mod that is a fork of Minetest Game without any changes.)

The name is only semi-ironic, as it will eventually provide start/stop/reloadable "services" that allow server owners and mod developers to change parts of their mods' code without having to restart their server, similar to systemd's "services". I may well change the name, though (minetestd used to be the name, as you could probably tell from the API, but I felt it was too similar to just straight up "minetest" that it would cause confusion)

Personally, I'd really wish people stopped making "collections" of support mods. I started minetest-mods so that they can be maintained as individual components and not necessarily be all interdependent, which is the whole problem of Minetest Game. You're effectively choosing to design this with the exact same design mistake at the core. I'd strongly urge you to consider instead just making individual support mods and maintain them and post them to the ContentDB, but hey, maybe I'm wrong here.

My philosophy on this is that all of these features being present together means that mod developers will have access to useful tools that are already designed to be 100% compatible with each other, with no redundancy, and without having to hunt them and all of their dependencies down one-by-one.

[sofar]

You probably should choose the AGPL-3.0-or-later instead of the GPL-3.0. This prevents people from taking your code, modifying it and deploying the modifications a server without being required to give the changes they made under the AGPL-3.0-or-later license back to users of that server. If you stick with GPL-3.0, you can't enforce this.

This is concerning, but since I've already published this as GPLv3+, I can't add the AGPL's restrictions...

Nonsense. You can relicense it as long as either:

1. You wrote all the code yourself

or

2. You asked all the people who contributed code if they agree on relicensing, and they said yes (in writing, preferably).

[sofar]

The name is only semi-ironic, as it will eventually provide start/stop/reloadable "services" that allow server owners and mod developers to change parts of their mods' code without having to restart their server, similar to systemd's "services". I may well change the name, though (minetestd used to be the name, as you could probably tell from the API, but I felt it was too similar to just straight up "minetest" that it would cause confusion)

This is exactly the type of stuff you shouldn't group with other mods.

(in systemd's case, things are vastly different, and the argument makes little sense, since you can't really have a normal working Linux system that is actually functional unless you do a bunch of other things too, but let's deviate too much from the topic ;))

[sofar]

My philosophy on this is that all of these features being present together means that mod developers will have access to useful tools that are already designed to be 100% compatible with each other, with no redundancy, and without having to hunt them and all of their dependencies down one-by-one.

You're not making a game. You're making a bunch of support modules. Game developers want to shop components and leave out stuff they do not understand. And someone will want to modify one part to do something different and then they are forced to fork 20 mods at once to modify one.

[Piezo_]

If all this ultimately becomes is an API that's only used by my mods, and a few daring server admins or modpack-makers, that's fine by me, and it's what I was expecting, honestly. If it does become widespread to the point where people want it to change, I'll listen, and if I can't meet demands, I'll probably hand over development to someone who can.

And maybe I'm making a mistake by proposing a systemd-like API, but honestly, I'm just making it as a multi-tool to make mod development and mod-conflict-resolution easier for myself, on my server.

[sofar]

And maybe I'm making a mistake by proposing a systemd-like API, but honestly, I'm just making it as a multi-tool to make mod development and mod-conflict-resolution easier for myself.

Yes, please feel free to experiment and do what you feel is best yourself. It's not like you couldn't split up the code later, and developing features in tandem can accelerate things significantly. I'm certainly interesting in what you intend to do about reloading.

[GreenXenith]

I'm certainly interesting in what you intend to do about reloading.

I'm personally a bit scared. There are numerous issues, even if it is possible to get working. Mods depend on loading behaviour, it's not something that can really be changed without breaking a ton of things.
Not saying I don't want to see this, it's the main thing I'm interested in about this mod so far :P but I do think you will encounter a lot of issues.

[Piezo_]

And maybe I'm making a mistake by proposing a systemd-like API, but honestly, I'm just making it as a multi-tool to make mod development and mod-conflict-resolution easier for myself.

Yes, please feel free to experiment and do what you feel is best yourself. It's not like you couldn't split up the code later, and developing features in tandem can accelerate things significantly. I'm certainly interesting in what you intend to do about reloading.

Be curious no more, for reloading has just been implemented!

PlayerCTL can be reloaded!

minetestd.math can be reloaded!

minetestd itself can be reloaded!

EVERYTHING CAN BE RELOADED! AHAHAHAHA!!!

Actually, in order to be reloadable, a mod has to register a service, and make some code structure changes to support reloading, as you can see, and you won't be dynamically registering and unregistering nodes, or anything like that. However, the current implementation has been tested to the best of my ability to mess things up (which is pretty high), and it holds strong!

Nobody will blame you if you don't make your mod reloadable, though. Honestly, I wouldn't turn a mod into a service unless there was an advantage to doing so. (In other words, don't expect Mese Portals to suddenly be registering a service).

[rubenwardy]

According to the mod code, the name for this mod should be minetestd not minetest_systemd

[Linuxdirk]

Systemd for Minetest? Alright! Is it going to be badly programmed and prone to obscure errors, too? :D

[sofar]

https://i.imgur.com/DgOiDXo.png

Alright, seriously, can we keep the trolling to the offtopic section perhaps?

[Piezo_]

According to the mod code, the name for this mod should be minetestd not minetest_systemd

I felt the name was too similar to minetest itself, so I changed it before I uploaded. Also, I'd already written the internal code, and I didn't want to make it longer, because people might have to type it out a lot.

On a somewhat unrelated note, I've noticed from experience that breaking up a mod's init.lua to support reloading often leads to confusing code. In the future, I'm going to recommend people keep their init.lua separate (although you'd probably still want to call minetestd.register_service in init.lua), and use (modpath)/services/(service).lua to hold the code used/reloaded by the service(s) you register.

[rubenwardy]

You shouldn't write to any globals which don't match your mod name. So you should either:

• Rename the table to minetest_systemd
• Change modname to minetestd. You can then change the topic title to this:
  

  Code: Select all

  [Mod] Minetest Systemd (API) [minetestd]

This is mostly my OCD for consistency getting the better of me. I'd still heavily recommend it for consistency reasons :)

[Mantar]

What trolling? Linuxdirk only posted a silly image, I seriously doubt anyone's going to get mad about it. (Unless Lennart Poettering hangs out here) At worst, it's off topic.

[Piezo_]

You shouldn't write to any globals which don't match your mod name. So you should either:

• Rename the table to minetest_systemd
• Change modname to minetestd. You can then change the topic title to this:
  

  Code: Select all

  [Mod] Minetest Systemd (API) [minetestd]

This is mostly my OCD for consistency getting the better of me. I'd still heavily recommend it for consistency reasons :)

I might do the second, but there are several of my mods (and modified versions of oxygenerators and witchcraft) on my server (which isn't public yet) that I'd have to update, so it would take a while. Then, I would push the changes to all of my own mods all at once.

I'm still concerned about the name minetestd being too close to minetest, though. If you think that won't be an issue, I'll go ahead and rename it to minetestd.

EDIT: Since it seems to be impossible to change the name of a repository on notabug.org, I am even less willing to rename the project, as it's too much hassle.

[Glory!]

You can manually sift through the code and CTRL+R it. It takes a bit of time but it does get the job done. Also, please, make this a modpack and not one giant integated bloat monolithic mod. Many of the proposed features can be broken into smaller mods, like mathf and collisionf.

What trolling? Linuxdirk only posted a silly image, I seriously doubt anyone's going to get mad about it. (Unless Lennart Poettering hangs out here) At worst, it's off topic.

It's banter regarding something only related by name so it's still quite offtopic in my opinion.

[Piezo_]

Update:

• Fixed data breaking after a reload with playerctl
• Added tool in "extras" to quickly parse chatcommand args
• core is now an active service. Disabling it quietly prevents all active services' global steps from being executed.