Warning: there may be occasional oddness due to css and blog edits. **KNOWN ISSUE: possible hidden text**

Sunday, August 28, 2022

Never far from FreeBSD

Although it may seem that I have taken a vacation from FreeBSD, what I did do is more of a break from doing NEW things and thus didn't feel it worth reporting on the "SSDD repeat" it may have been.

One of the last new things I did relating to FreeBSD is creating the concept of 'FreeBSD Games Directory' which I did not myself promote but did make accessible to the public.  BSD Now somehow discovered it and mentioned the nascent project on one of their episodes.  Progress on it has been somewhat slow and it is presently kind of on a back burner.  What I have decided is that I will evolve it into a more proper database format thing which will output an easily consumable html format file.  Both varieties will be available but the barrier to use will be particularly low as it will only necessitate a browser and the more recent output.

This brings us to my other new project, which, if you've looked at the FreeBSD group on Gab, you'd know is my attempt to port dbeaver to FreeBSD.  This is mostly accomplished except that due to the way that it builds and it may be a maven build system default, each build even if the source is unchanged will receive a timestamp in each filename built.  This is completely useless for FreeBSD ports as we expect reproducibility in our pkg-plist file.  I have not yet discovered a sure way to disable the timestamp, nor have I figured out a workaround.  dbeaver is listed in the wanted ports wiki page.

So then, because dbeaver is what I hope to use, as a smaller database manipulation tool than something like open- or libre- office, and dbeaver on FreeBSD is stalled, therefore the games directory as I reimagined it is presently stalled as well.

Prior to playing with dbeaver porting, I had discovered a dependency of godot, libthorvg, and that it could be built fairly easily for FreeBSD.  I created an unofficial port for it, and even gave some feedback to upstream for correcting a few issues with building on FreeBSD.  It is among the six unofficial ports that I maintain now, dbeaver as incomplete is not among them yet.

Since all of that, which occurred some time ago, I have been continuing to play minetest on the NodeCore game servers.  I recently now officially have a consumer of the unofficial minetest-dev port I maintain which is cool, I know that it works nicely for me but it is good to hear that someone else succeeds with it on FreeBSD also.  Another player on one of the servers asked if I would test some software he was helping develop (gpusph: The world's first CUDA implementation of Weakly-Compressible Smoothed Particle Hydrodynamics) and when I followed the instructions he gave for building and testing, it worked fine for me.  This is good news overall, the code includes checks for FreeBSD in the build, which is always cool to see.

One of the NodeCore server admins chose to switch the texture from plain vanilla (included with the game install) to something else for whatever reason.  This felt a bit jarring for me and I didn't really like the appearance change to the game there.  I decided to solve the issue for myself if I could.  I knew that I could use a local texture pack to override whatever is on a server as its default, so I set myself to task.  First, I needed to find the vanilla textures which was relatively easy as I did have NodeCore Alpha installed for other testing and experimentation in singleplayer mode.  I did a search for all of the files in any directory named textures then copied them into a new directory.  The new directory needed a few more things added to complete its creation as a "new" texture pack.  I chose the name everywheres_nc and made a texture_pack.conf file by revising another I already had close at hand.  What began as a way to get vanilla textures back for myself and provide them to others via github became a way to make a few subtle changes.  First I corrected the texture of a rake to fit the components used to create it, three tines instead of four, this became two different designs.  The first design has a definite pitchfork style to it, the second was my initial idea of being rather triangular.  Both options are in the texture pack and will need to be renamed to the vanilla name for the item.  The next change is to a flower that I like least of all the vanilla flower shapes.  This was another mild change, simply shifting the colored portion of the flower up one pixel and leaving the one pixel space vacant in the greenery secondary part of the texture.  The plan for this texture pack, first, make any other adjustments to what is available strictly for NodeCore and its mods, and then expand to override the textures of regular minetest and its mods.  As some things do not have anything at all close to NodeCore, I am not yet sure if I will nodecorify those textures or do something else.  I like the super-polished look of the high DPI mesecon nodes because it is high tech and looks right for those in my opinion, so that is one option.  I'll have to experiment a bit to decide.

Along with my plan to have a nicely searchable database of games available for FreeBSD via ports, which includes screenshots and additional information to facilitate deciding whether to install or try a game or not, I am also hoping to help get more games and game engines ported to FreeBSD.  I would hope that my efforts lead to others creating official ports even if they are based upon upstream releases instead of upstream repo commits.  Even if this does not happen, I intend to continue to provide my own repo for each unofficial port which does track the upstream repo commit and following my philosophy of exposing all the applicable options for building and configuring a port for FreeBSD.  I have put some effort into various potential future unofficial ports the same way as those I've done already.  Besides a general theme of games, I wish to maintain a more 'bleeding edge' upstream commit tracked version of many different programs that I often use, so you might note feh and fvwm among my repos on github.  Firefox seems to be getting more bloated and has some undesirable default features, so that is on my "eventually to do" list, but there is also Librewolf which is a project which already modifies a Firefox build to adjust some things, and I have begun attempting to port it.  Librewolf is very linux centric with how things are done, so it will be a bit of effort to get things 'converted' to FreeBSD methodology.

We use FreeBSD and we may accomplish things, though we might not make mention of them.  Sometimes we are surprised to be recognized for our efforts even when they're incomplete and in a very work-in-progress condition but possibly this would lead to other contributions to it.  Simply using FreeBSD often leads to learning more things about the OS or small steps toward various ways of giving back.  Learning and exploration is on-going, we can each report on our progress or accomplishments, offer tips and techniques, give back to the the rest of FreeBSD in any small way, help new users and others who may struggle by our posted essays.  Our choice is FreeBSD for our reasons and if we didn't enjoy it we would switch to something else.  We're out here doing, even when we say nothing about our progress, speaking of it doesn't necessarily make it occur but it can be a record and inspire or teach others.

Frequently viewed this week