jeang3nie/capsule
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Catch up on gemlog posts

Browse source
This commit is contained in:
Nathan Fisher 2022-11-09 12:02:48 -05:00
parent 36903a0a1e
commit 596eb75995
11 changed files with 406 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
content/gemlog/a_fun_little_bug_hunt.gmi Normal file
View file

@ -0,0 +1,33 @@
Meta(
title: "A fun little bug hunt",
summary: Some("A pull request leads to a bug hunt, leading to my waxing philosophical"),
published: Some(Time(
year: 2022,
month: 10,
day: 28,
hour: 4,
minute: 50,
second: 45,
)),
tags: [
"software",
"bugs",
"memory",
],
)
---
I've been getting occasional pull requests from a Russian gentleman on my Vapad text editor. Not only has he provided Russian translations for the application and kept them up to date, but he has been helping with features as well. This has been a nice change from my usual workflow, as most of my projects are fairly special insterest and don't often get contributions more than just the very occasional drive by. Alex (my contributor) laid the groundwork for moving Vapad to using Libadwaita originally, and added the initial support for in application messaging using the Adwaita Toast system. Most recently, he sent me a pull request which replaced a few instances of the GtkMessageDialog widget with it's Adwaita equivalent, which helps keep things a little bit more visually consistent.
Pulling the changes into my local copy for testing, the code immediately compiled without errors and ran as expected, with one small hiccup. Vapad knows whether the current document has been changed since it was last saved, or, in the instance of a new file, if it has had any typing occur since the new buffer was opened and not been saved. If you press the tab's close button, ask to close the tab via keyboard shortcut, or close the window it pops up a message dialog asking you if you would like to save the file. This is the before mentioned Adw.MessageDialog. Everything was still functioning after the change, but if the tab being closed was the last tab in a window then I was getting a sementation fault. I never had when using the Gtk.MessageDialog. Weird. I needed to investigate.
Looking at the docs, the Adwaita version of this widget automatically closes when it receives a response (when the user presses the Ok or Cancel button). The Gtk+ version of the dialog had to be closed manually. Since the calls to the dialog's `.close ()` method were still in place, I suspected use after free. I took the calls to `close ()` out, and everything still worked, including the segfault. Interesting.
Attempting to run Valgrind was not fruitful. Valgrind wanted debug symbols for Glibc. I didn't feel like trying to figure out how to get them on Arch. So I just started trying to reason about what the code was doing, because it's not overly complex.
It turns out, the new code was not the problem. It just revealed a bug that I had written myself but which was masked by the old message dialog's behavior. See, the FileSaver object for a GtkSourceBuffer saves the buffer contents asynchronously. The call to it's `begin` method takes an optional argument for a callback to be executed once the file save action has completed. In this case, the callback being run updates a boolean flag on Vapad's `Tab` object which indicates whether the file has any changes sinc ethe last save. When it ran on the last tab in a window, the window was already closed and the application terminated by the time the filesystem reported the file was saved. The reason it wasn't showing up as a bug before is that the message dialog (remember the message dialog?) had to be manually closed, which it was, after the call to the save method. And the message dialog was holding it's parent window open until it was itself closed, which ate up enough cycles that unless you had a really slow filesystem it was unlikely that you'd ever see the bug. That's the difference. The new dialog closed, then ran it's callback, where the old dialog ran it's callback, which closed the dialog as it's last instruction.
A classic race condition, basically.
The fix wasn't all that difficult. A new method was created for the `Tab` object, `save_file_on_close`, which does exactly what the `save_file` method does, with the exception that the `FileSaver` does not run a callback when it completes. This is the version that runs when closing a tab, if you answer affirmatively to save the file.
It got me thinking about memory access, and programming languages. Vapad is written in Vala, which compiles to C and is basically just a layer of indirection above C itself. I do a lot of programming in Rust and love it for a lot of reasons, but I've never really given a ton of thought to the memory safety aspects as there is so much more to recommend it as a language. I'm usually more excited about algabraic data types and generics, and the awesome compiler messages and documentation. But Rust's borrow checker would have caught this sort of bug before it ever had a chance to display a symptom. I've seen it do it. And while I still think Vala is a great language for the domain of Gtk+ application programming, I'm even more sold on Rust after this little bug hunt. I know for a fact that I coded a program with a memory access bug. I wonder how many more I have coded in the past without realizing it?

34
content/gemlog/fedi_server_update.gmi Normal file
View file

@ -0,0 +1,34 @@
Meta(
title: "Fedi Server Update",
summary: Some("There has been some good feedback on one of my recent posts"),
published: Some(Time(
year: 2022,
month: 11,
day: 9,
hour: 17,
minute: 2,
second: 20,
)),
tags: [
"fediverse",
"feedback",
"golang",
"gotosocial",
"pleroma",
"mastodon",
],
)
---
I have gotten some good feedback on my post about recent happenings in the Fediverse, and wanted to update on my current thinking in regards to setting up a Fedi server.
=> gemini://gemini.hitchhiker-linux.org/gemlog/the_twitter_invasion.gmi The Twitter invasion
It has been suggested that Pleroma has some image issues due to many of it's instances being lax on moderation or just not sharing the values that most of the FediVerse seem to have in common. I should also note that what I have read about Pleroma vs Mastodon performance is that Pleroma loses it's edge as the scale increases. I'm still evaluating Pleroma and have a test account on a certain instance, which I'm fairly positive about so far, but I am still looking at other alternatives as well.
Another suggestion that I received was to look at Bonfire, which is also written in Elixr and is currently in Alpha stage. I have checked it out and while the basics seem to be there and the interface looks nice, I'm getting the impression based on the behavior I'm seeing so far that the timelines aren't being fetched asynchronously. When you click on the button for the local timeline you get a nice binfire animation that displays for at least a few seconds before any posts appear. The project may have promise, but I think the UX is currently lacking and this lagginess in display is probably going to be offputting for a lot of people. Bonfire does have some features that seem quite nice that allow you to limit a post to a certain group of people, just this instance, only certain instances etc. I do like that.
=> https://github.com/bonfire-networks/bonfire-app Bonfire code repo
The one I'm a bit more excited about is GoToSocial. I've heard the name but silly me, I didn't realize what it was until a certain person mentioned it and I looked it up. This one is a backend only, so a frontend must be provided, but it is known to work with Pinafore on the web and Tusky on mobile. It's also written in Go and so potentially might be able to wring out a lot better performance once it's past it's current Alpha state. Beta is expected to be reached around the middle of next year at the current development pace. Like Bonfire there are features which allow some more granularity on how public your posts are, which is another plus.
=> https://github.com/superseriousbusiness/gotosocial GoToSocial code repo
=> https://pinafore.social/ Pinafore homepage
As I stated earlier, I'm still evaluating software options. However I'm planning on moving forward at some point - and probably sooner than later.

52
content/gemlog/moving_day_is_over.gmi Normal file
View file

@ -0,0 +1,52 @@
Meta(
title: "Moving Day is Over",
summary: Some("Adventurers in DIY, and my brothers in law are good people"),
published: Some(Time(
year: 2022,
month: 10,
day: 21,
hour: 0,
minute: 48,
second: 6,
)),
tags: [
"moving",
"towing",
"vehicles",
],
)
---
As I noted in my previous post, we are currently in the process of downsizing our living space so as to save for a house. My daughter has been moved out for two years now and not only do we not need quite so much space, the rent was a huge stretch. The new house is quite a bit smaller but it should be perfectly adequate for our needs, including occasional visits from my adult children who live out of state (one is an artist living in Rhode Island and one is a sophomore CS student in Maine).
We're pretty thrifty people, and generally won't pay someone else to do a job that we could conceivably do ourselves. So no moving company for us. In fact, not moving van either. My SO drives an SUV and I drive a pickup truck (I know, how American, but we're also rural and it makes sense for our lifestyle) so we've just been running loads out every day before work all month long. We had some larger furniture as wel as a piano, however, and also wanted to time it so that we could get all of the beds, the washer and dryer, and the home network all moved on the same day. The network wound up being a two day affair, as I'll explain below.
Anyway, Chrystal's brothers had our backs. Kenny came through with a moving dolly for the appliances, some extra ratchet straps and some extra muscle when it came time to move the piano. Her brother Ritchie offered the use of his flatbed trailer. So we were set to go Wednesday.
In addition to my hosting several public services my stepson does his schooling online, so it was important to have as short a disruption as possible. Our local ISP was actually pretty accomodating. They had the connection live at the new house as soon as it was shut off at the old house. So far so good.
I picked the trailer up Tuesday night, and that's when the fun began. Ritchie hasn't actually used this trailer himself in quite some time, so he neglected to renew the plates this year. Back in May, to be exact. So I was going to be pulling a rather large commercially registered trailer with the registration lapsed by five months. Mice had chewed the wiring earlier this year, and the third brother, Brian, said he fixed it when he used the trailer to move his toolbox (he's an officially retired master mechanic). Well, the brake lights and turn signals were working just fine, but no running lights. Brian apparently only pulled it during the day. I, on the other hand, was pulling it from Ritchie's house to our old house ate 8pm, in the dark, in sloppy rain conditions, without running lights. So doubly illegal. I was shitting my pants the entire drive, but really had no choice. I texted my long time friend Tony to fill him in on the situation and he immediately perked up.."Oh, hang on I'm listening. This sounds like the beginning of a great Nathan story!". He and our other friends apparently started a pool about whether I was going to make it through the next couple of days without police involvement.
The ride home actually went off without incident. My sphincter is, however, still clenched.
### We can get a load run over before Kenny comes to move the piano, right?
Yeah. Kenny was to meet us at 4:30 to move the piano, followed by our weekly family dinner at their dad's place. I figured we could run two loads in one day then. We'd get the appliances and most of the furniture over there ourselves in the morning, leaving only the piano and sofa for the afternoon. Loading up went fine. Fine, that is, if you enjoy about 40 farenheit and a steady drizzle. We had to tarp everything as we loaded. And of course I don't actually own any tarps. But hey, we had a bunch of used garden plastic from our makeshift greenhouse, so we just repruposed it.
Unloading started out all right, but went straight to hell when we got to the appliances. Laundry hookups in the new house are in the basement. This house was built circa 1940. Some people will already have some inkling of what I was now up against. The side door of the house opens up to a small landing, with three steps up into the kitchen stright in from the door, and a short narrow stairway to the left going down to the basement. The landing is approximately the exact size of our washing machine. Meaning I could get the washer in over the step onto the landing using the appliance dolly and then promptly had to remove the machine from the dolly, set the dolly in the kitchen, turn the machine (by lifting it by myself high enough to clear the first step up to the kitchen) and then attempt to get it back onto the dolly after sliding the machine halfway off the landing while Chrystal held it to keep it from tipping.
### Remember when I said the staircase going down was narrow?
Next problem. Those steps going down to the basement were pretty much the same width as the washing machine. With the railing the starcase is about three inches too narrow. So we had to take the railing off. And I left my power tools at the old house. Chrystal, who was trapped in the basement while I performed the previous manouvers, had to unscrew all nine mounting screws using a screwdriver. Being an old house, not every screw matches. True to form, 7 of the 9 screws were a sensible 2" length, with two random replacements that were both heavier gauge and also 5" long. She has arthritis in her hands, too. Not great. But it did get done.
We thought we were now good to go..
The clothes dryer is the same profile as the washing machine. Since the railing was already off we figured we'd be OK. We would have been, if it weren't for the outlet pipe sticking out from the back. After muscling it into place and discovering it wouldn't go down the steps I then had to muscle it back out of the house and chop a quarter inch off of the outlet pipe with an angle grinder, which luckily HAD already been moved. Got it into the basement, and then I promptly realized that we have a four prong plug on this dryer while the outlet in the basement is the old style three prong. GREAT! i'm sure I have a spare dryer pigtail in a box somewhere from when we move the previous time, but I just really wasn't in the mood at this point. And besides, it was now about ten past four, and time to go meet Kenny to move the piano.
The piano move went off without a hitch, other than the fact that we were moving a piano with two guys. That's two less than I'd like to have ideally, and I'm about twice the age that anyone should attempt this sort of thing at anyway. All I can say is that it hurts. Seriously, folks, that was horrific. Luckily family dinner was a much needed pizza and fried chicken. We all pigged out, had a short nap and then went back to the new house to spend our first night there as a family. I figured I'd try to get the network up before bed.
### The landlord has side cutters and knows how to use them.
So as a last insult before bed, I traced the wire coming in from the wall into a heating duct which I knew opened up to a register in the living room, right where all of the elctronics were set to go. Coming back up from the basement, I looked in the register and found the wire. With the connector cut off. F.U.C.K. I also discovered that the third switch by the front door, for which which we had yet to discover it's purpose, turns the outlet I was planning to plug ALL of the networking equipment into on and off. Great, so I'll be taping that outlet in the on position. Don't want to be shutting off the router and modem when groping in the dark for a light switch.
Anyway, getting the network back up last night was not to be. I do own a cable crimper, but it was in my toolbox back at the old house, which I wasn't planning to move until today, after the contractor was due to install the garage door. So first thing this morning we went to Lowe's, picked up some connectors and another crimper, and then came back to set all of it up. On the plus side, I like the new style compression connectors and tool. It's a vast improvement over the old crimp on coax connectors.
Just as I was finished setting up all of the hardware, we noticed that our ISP had dropped off a modem for us after we had informed them that we had our own and just needed the service transferred. Reminding me that, of course, you just can't trust those assholes.
So yeah, it's been fun.

19
content/gemlog/planned_outage.gmi Normal file
View file

@ -0,0 +1,19 @@
Meta(
title: "Planned Outage",
summary: None,
published: Some(Time(
year: 2022,
month: 10,
day: 17,
hour: 22,
minute: 9,
second: 3,
)),
tags: [
"life",
],
)
---
We're currently in the process of moving into another house. This capsule will be unavailable either over Gemini of Spartan for an undetermined period of time later this week, along with Finger service and the HitchHiker Linux https site and git repository.
This has been a long slog. All month long we've been packing boxes and loading both vehicles in the morning, dropping things off a load at a time before going in to work full time. Once it's over I don't plan to do much physical activity until spring.

60
content/gemlog/re_dependencies.gmi Normal file
View file

@ -0,0 +1,60 @@
Meta(
title: "Re: dependencies",
summary: Some("Some thoughts regarding system vs language package managers"),
published: Some(Time(
year: 2022,
month: 10,
day: 29,
hour: 3,
minute: 13,
second: 25,
)),
tags: [
"software",
"package-managers",
"dependencies",
],
)
---
Idiomrottning has a great article on software dependencies.
=> gemini://idiomdrottning.org/dependencies Dependencies
> 1. There are dependencies that are gratuitous and unnecessary.
> 2. There are dependencies that make your code significantly more readable and comfy.
>
> That second fact, to me, suggests that a hardline NIH approach is not the right path forward. That first fact suggests that pruning our deps a little bit is possible and probably good, but we are gonna need a good way to handle dependencies regardless. The “zero deps” approach is something I’m not a fan of, just as little as those unweildy, over-dependent trees.
I think this part is pretty easy to agree upon. And people mostly have come to understand this over time, as dependencies in C and C++ became quite unwieldy for a very long time, leading to an almost universal adoption of language level package managers amongst the last few generations of programming languages. While there are definite concerns with the implementation and security implications of many of these systems, on the whole I believe it has meant a great leap forward.
My experience is largely around Cargo, having written much more Rust in the past few years than anything else. But I am sure that much opf what I'm going to say will also apply more or less to `go get`, or `npm`, or whatever your language of choice happens to be using. Even Fortran has `fpm` now.
As an aside, she links to a great talk given in Milan by the creator of Zig, Andrew Kelley. I watched that talk on YouTube just a few days ago. Well worth checking out. But I digress from my digression. Zig, being at a pre-1.0 stage currently, still has no official language level package manager, although Mr. Kelley has stated clearly that he intends to build one with the community around the time of the 1.0 release of the language. Filling the void in the interim we have a few community sponsored projects, of which the two with the most traction are `Gyro` and `Zigmod`. I've tried both, and they both work great. Of the two, I prefer Zigmod and think it has some novel features that I'd like to see make it into the "official" zig codebase eventually.
Now, what I really want to address is the friction between distro and package maintainers versus language level package managers. I'm going to lump BSD in with the linux distros here because they also have to package this software, and their choices are relevant to the discussion. First I would say that the situation at Debian is untenable and their policies need to change. Said policies and tooling evolved around the C language and have not kept with the times.
Then there's the totally almost hands off approach taken by Arch (and yes, I do use Arch). Arch just builds the software in the way that the upstream recommends. They rely on using the most up to date stable releases to keep the system secure, in the hope that the upstreams will handle their own shit. As a software developer, I rather like this approach. But I also recognize the desire of many for more formal verification, as well as the fact that a large number of project will allow their code to go stale, particularly in regard to dependencies.
I use NetBSD's pkgsrc for packages in my little distro, HitchHiker. Pkgsrc takes a bit of a middle ground approach, at least when building Rust projects. Whereas normally you build a Rust project just by typing `cargo build` and let it download and verify dependencies itself, pkgsrc downloads all of the crates that a Rust package requires and verifies the checksums before running Cargo, passing command line switches to tell Cargo where to find the crates. I believe that FreeBSD does something similar. I'm not sure what this is actually accomplishing myself, apart from adding quite a bit to the workload of the package maintainers and the ridiculous size of the checksum files that have to be included in the pkgsrc tree. It's also quite a bit slower than Cargo. It would be one thing if they were attempting to have only one blessed version of a particular dependency in the entire distribution, like Debian does, but that is not what they are doing. They're just adding work and fighting the tool to make it work the way they wish that it worked.
Some proposed solutions from the original link I posted earlier:
> 1. Every module has at least two versions: latest-uploaded and latest-vetted. By default, you get the latest-vetted. This goes especially for recursive dependency resolution. You can pin to older versions (if so, we need some sorta in-app CVE alert system) and you can, with enough hoops, get newer, unvetted versions.
> 2. The modules hook into the distros’ normal package managers. So you can apt-remove and dpkg -L and so on.
> 3. And, when it’s time for the distro to package an app, the distro can bring in and pin vetted versions of the dependencies (again, that means some sorta built in CVE alerter is needed) and bless those versions officially.
There's some good sense here. I would love to see the Cargo developers reach out to distro maintainers and work out a system together. I also don't think that's going to happen in the near future. In the meantime, there are things that developers can and should do.
* Keep on top of updating your dependencies.
* Use any auditing tools at your disposal.
* Use good sense about when and where you take a dependency.
In the Rust ecosystem, there are a few nice Cargo plugins that can help with the first two. I started using `cargo audit` a while back in my projects. It provides alerts if your dependencies are out of date, unmaintained, or have any CVE's filed against them, including transitive deps. I have made it a habit to run it before tagging any release. I'm not a big fan of CI builds unless you are part of a large organization, but it can work nicely in a CI context as well.
I'm also in favor of changing the way publishing happens. For Rust and crates.io, currently the only requirement to publish to crates.io is a Github account. I have an account, grudgingly, partly for this reason. But that is an incredibly low bar for entry. I would like to see some form of formal review process, if only for the initial upload of a crate, to ensure that it is legitimate and not malware. I'd also like to see a very strict, one strike and you're banned for life, anti-malware policy in place. Others have also proposed adding a group of vetted core packages which extend the std library in useful and common ways, and I also think that this is a good idea.
Short of all of that, as a developer there are certain metrics that can be helpful to sort through crates.io to find the (hopefully) better packages. Number of downloads is a starting point, as it shows how commonly used a library is. I also like to look at release history to see how often something is updated. Both of these can be misleading, however. Just because a piece of software is often used doesn't automatically make it the best fit for your application. And to the second metric, after a project has attained a certain level of maturity, it is often feature complete and releases can and should slow down. So in addition to those metrics I also like to look at a crates dependents and it's dependencies. Looking at the former will give you some idea of the sort of projects which are using a crate, which can be either a big confidence booster or quite the opposite, if it is largely unused. The latter is important, as it will give you at least part of the picture of how large your dependency graph might get from adding this one package.
### This is not a simple issue, folks
There are those who are absolutely against language level package managers. The common argument is that your system package manager is the only tool that should be used to solve the problems that the likes of Cargo and NPM were designed to solve, but this is disingenuous at best. I'm looking at you, Drew Devault. In reality, if you look at most large C++ projects you will find dozens of sub-projects which are all vendored code. Due to the thrown together nature of this ecosystem, these dependencies are often incredibly difficult to update, and this code winds up becoming extremely stale. This is the garbage that might be available as a shared library on your distribution, but because distributions are shipping wildly varied versions of it, the software vendor just ships a specific version of the code and compiles it in statically in order to avoid a massive kludge of ifdefs and other preprocessor abuse. Some libraries which have been available for a long time have managed to avoid this by providing a consistent interface over the years, but they are probably the exception at this point. The reality is that your distro's package manager never has and never will know anything about this pinned code. Nobody is really managing it, because there's no tools that were designed TO manage it. That's what a language level package manager was designed to avoid, and they do their job well. And frankly most of the people who shout this argument the loudest know this and just happen to leave it out of their arguments.
On the flip side, it's way too easy to have a dependency graph explode just by adding a few packages. And it's pretty much impossible to audit all of that code yourself, so there is most definitely a problem.
I don't claim to have all of the answers. But I do think that there needs to be a more healthy and productive discussion, with less finger pointing and a lot better listening on all sides.

50
content/gemlog/re_handling_optional_values_in_rust_macro_rules.gmi Normal file
View file

@ -0,0 +1,50 @@
Meta(
title: "Re: Handling Optional Values in Rust macro_rules",
summary: Some("I love Rust, buuuttt...."),
published: Some(Time(
year: 2022,
month: 11,
day: 9,
hour: 3,
minute: 27,
second: 39,
)),
tags: [
"rust",
"zig",
"programming",
],
)
---
An interesting post on implementing Rust macros:
=> gemini://hoseki.iensu.me/posts/handling-optionals-in-rust-macro-rules.gmi
I love Rust, but there are certain things which I don't feel it does very well. One thing that I think was a mistake in C was the entire preprocessor, and most especially macros. I'm not exactly a fan of macros in Rust, either. I think this posts central premise is a good example where I can demonstrate a language which has a better solution.
The original post involves implementing some Rust code which can convert optional enum values to strings, and vice versa. I'm going to briefly show the same sort of thing in Zig, which has great compile time reflection.
```
const std = @import("std");
const meta = std.meta;
pub enum MyEnum = {
typeOne,
typeTwo,
typeThree,
pub fn tryToString(self: ?MyEnum) ?[]const u8 {
if (self) |s| {
return meta.tagName(s);
} else return null;
}
pub fn tryFromString(str: ?[]const u8) ?MyEnum {
if (str) |s| {
return meta.stringToEnum(MyEnum, s);
} else return null;
}
};
```
And thats it. The entire `meta` namespace is part of the standard library in Zig and deals with these sorts of compile time scenarios, allowing you to do a lot of conditional things based on what the compiler knows about the types at compile time. It was quite surprising to me to see just how much meta programming can be done with this system, and it makes me hate macros even more than before. Why have a separate sub-language for meta-programming? Zig shows that it's pretty much unneccessary. \Rantmode_off
That said, I tend to prefer Rust overall for real world use these days...

29
content/gemlog/re_mayan_and_gemini_priests.gmi Normal file
View file

@ -0,0 +1,29 @@
Meta(
title: "Re: Mayan and Gemini priests",
summary: Some("Gatekeeping is a dirty word"),
published: Some(Time(
year: 2022,
month: 11,
day: 2,
hour: 18,
minute: 50,
second: 38,
)),
tags: [
"gemini",
"gatekeeping",
],
)
---
In response to Szczezuja's post comparing the Gemini community to Mayan priests.
=> gemini://szczezuja.flounder.online/gemlog/2022-10-30-Mayan-and-Gemini-priests.gmi
I ordinarily try to steer clear of posting about Gemini itself. I do tend to post a good bit about the pieces of software that I've authored around Gemini, but those posts aren't really about Gemini itself but rather my hobby of writing software. But this idea that Gemini is an elite community of tech nerds that keeps people out by having a high barrier to entry bothers me, big time. In fact, just the word "gatekeeping" is a trigger word for me these days, much in the same way as the term "woke" is when it comes to social issues. Both terms are thrown around as a pejorative and source of ridicule. Both terms also are applied far too broadly. Of course, I'd rather that they weren't used as a pejorative to begin with, but the actual level of human decency or, correspondingly, technical awareness in the context of gatekeepking that can trigger their use is ridiculously low.
I'm not the first to reply to this post of course. But I'm going to start under the assumption that people are referring to not just browsing Gemini, which is ridiculously easy, but publishing on Gemini. That is, I'm giving the benefit of the doubt here that people aren't being -that- silly about it, because there are very good clients available for all platforms now and installation is generally point and click in a lot of cases (or swipe and touch on mobile).
Now, a lot of us on Gemini have written our own tooling around publishing and serving our content. I've written Zond, my capsule generator, and Agis, a Spartan server. If writing your own tooling was a requirement to join the discussion then maybe there would be some gatekeeping, but the vast majority of software written around the protocol is open source and freely available. I can only speak for myself, but I actually went to pains to try and keep my own projects as cross platform as possible, and while I can't gaurantee it to be the case I'm pretty sure that Zond and Agis would both compile and run on MacOS and Windows, not just Linux and BSD. I can't gaurantee it because I don't use those platforms so I can't test on them.
But all of that is besides the point, really, because there are a number of places that you can get free hosting for your capsule. In the case that you have someone else host your account, then I really don't see the problem. I could probably teach my aging parents how to write gemtext because it's so simple, and there are plenty of graphical tools that could be used to copy files to a server using sftp or scp. You basically need a text editor and a file manager that is network aware, which is frankly most of them. If you go with the tinylog format (which a number of people seem to be quite happy with) then the entire thing is in one file. Honestly the Unix command line isn't even really required.
I'm totally willing to help anyone who wants to publish to Gemini, by the way. Shoot me an email using the "Contact" link at the bottom of the page and I'll set you up with a subdomain on hitchhiker-linux.org, a limited shell account and even provide some technical help within reason. And I'm sure that I'm not the only person in Gemini space who would make such an offer.

23
content/gemlog/settling_in_to_the_new_house.gmi Normal file
View file

@ -0,0 +1,23 @@
Meta(
title: "Settling in to the new house",
summary: Some("After the move and resting up a bit, we\'re starting to settle in nicely"),
published: Some(Time(
year: 2022,
month: 11,
day: 1,
hour: 21,
minute: 35,
second: 57,
)),
tags: [
"homelife",
"cooking",
"diy",
],
)
---
It's pretty early in the morning for me as I write this, having grown accustomed to afternoon shift over the past five years. I've been up since about 7:30 local time sipping coffee, slicing vegetables and listening to a nice Jazz session featuring Danny Gatton and a young Joshua Redman. I've just finished filling the crocpot with Roma tomatoes, sweet yellow onion, green bell pepper and three varieties of beans. Browning some ground beef to add and in about 8 hours we'll be eating bowls of chili on a fall day.
We finished the mad rush to clean out the old house a week ago today and have been resting up and working on some small domestic projects. While I love our old home, we were overextended and it's truly liberating to not have that financial burden over our heads anymore. It's also nice to have trees. The big draw of the old house was a huge, almost two acre back yard which was wide open and facing directly south, along with our neighbor in that direction being a farm. So we caught every sunset in spectacular glory. The drawback was that the wind beat down with gale force at times. Now we're technically "in town", but right on the outskirts and close to the river. And the back yard is lined with trees including a giant Oak towards the back side. I missed that.
Today's agenda is a bit relaxed. Our basement is partially finished, ad we're turning the finished half into a bedroom for when my daughter comes to visit from Rhode Island or my son from college in Maine. There is a gap in one of the walls and part of the ceiling where some plumbing comes through. Looks like there was a bulkhead there at one time but it got torn out for whatever reason. I'll be headed to the lumberyard in a bit to get some dimesional lumber and framing it back in today. Other than that, it's just going to be a catch up day for domestic chores like laundry and dishes.

39
content/gemlog/the_twitter_invasion.gmi Normal file
View file

@ -0,0 +1,39 @@
Meta(
title: "The Twitter invasion",
summary: Some("The massive influx of people leaving Twitter is straining the Fediverse"),
published: Some(Time(
year: 2022,
month: 11,
day: 8,
hour: 16,
minute: 0,
second: 10,
)),
tags: [
"fediverse",
"social-media",
],
)
---
I'm sure we're all aware by now that not everyone is happy about Elon Musk owning Twitter. For those of us on the Fediverse we had the pleasure this week of having a lot of our instances overrun by a huge influx of new accounts. It seems that someone, actually a number of someones, suggested that Mastodon is a great place to move to from Twitter, and the people came. The instance where my account lives saw a doubling of accounts in about two days, before the admin prudently shut down new registrations.
The problem is, as quickly as our admin acted, he probably wasn't quick enough. That second day of the mass influx the server was obviously under a torture test and the hardware must have been running literally flat out to keep up with demand, a task that it was very much failing at as posts on everyone's timeline were running six to eight hours behind. More, in the case of federated content. And our instance was only one of the many that was having issues, with some of them being hit much harder.
Now, as a Geminaut, I'm used to back and forth communication taking a slower pace. I'm actually really cool with that aspect of what's going on, and I'm ok with the influx of people for the most part. I do worry that a lot of them are going to quickly discover that Mastodon is most definitely -not- Twitter and become disenchanted before they realize that it is, in fact, it's own pretty awesome thing. I am not even going to attempt to point out to most of the newcomers that what they're referring to as Mastodon isn't even really Mastodon, it's a Mastodon clinet and server with your timeline having content from the wider Fediverse as well. It's, you know, not worth the aggrevation right now. And in a way, that might be a good thing in the short term because we need a bit of time to let the network recover and to rebalance things a little bit. Some servers might need to upgrade some hardware, some connections might need upgraded. But we likely need to have more instances available to meet the demand, and we also might need to encourage some of those who signed up recently to move to a less crowded instance.
To that end, I'm considering bringing up an instance myself. Probably using recycled hardware, and serving a relatively modest number of users, but still useful to get people connected. More on that in a minute.
## Mastodon (the software) has a performance problem
It's actually kind of horrifying to me to think about what would happen if the Fediverse were to attempt to accommodate a user base rivaling Twitter if they were all using Mastodon. Speaking from an energy usage standpoint this would be a catastrophe. It's not just a matter of sending toots, boosting toots, replying to them, and favoriting them. Every time a user takes one of those actions it then gets federated to the rest of the network. This can exponentially increase the computational demands as the network grows. This is bad. We need this software to be extremely efficient. Right now, it isn't. The fact that so many instances came grinding almost to a halt this week illustrates that point pretty clearly.
Mastodon, which is probably the fastest growing part of the fediverse and is taking the brunt of the exodus from Twitter, is written largely in Ruby on Rails on the backend. If you look at energy consumption for programming languages, without even looking at the implementation, Ruby sits just above Python in energy efficiency. If you look at the link below this paragraph you'll see that we're talking almost 70 times the energy used compared with C. The frontend is largely written in Javascript, which while not great is a significant improvement over Ruby at using around 4.5 times the energy of C. Remember that these figures are just a baseline.
=> https://thenewstack.io/which-programming-languages-use-the-least-electricity/
Long story short, I started looking for alternatives. I was hoping to find something implemented in Go or possibly Rust, but no dice so far. There was a project called Rustodon, but it appears to have stalled out a couple of years ago before reaching full usability. The best option currently for a modest instance appears to be Pleroma, which is written in Elixr. Pleroma is said to run quite happily on a Raspberry Pi 4 for a modest number of users and seems to support everything that I actually care about in Mastodon. It's what I plan to bring up once I get some more hardware set up for it. But that's a short term sort of move, really.
What I want to see as a mid term solution is a piece of software that implements the ActivityPub protocol written in a fully compiled language such as Rust or Go, which emphasizes performance. What I think is a better solution long term might be a rethinking of the protocol itself to move the task of federation from the server to the client. Right now federation happens as messages passed from server to server. Peer to peer would make for a more distributed network, lower the computing resources required to run an instance, and probably make the network more resiliant to massive influxes of people like we saw this week. In fact, massive influxes of people actually improve a peer to peer network. Now understand that I'm not talking blockchain here. In fact I don't really have a clear idea of an architecture. But I'm not sure we can achieve a fully decenttralized network at massive scale if we're relying on the servers to pass all of the messages, at least not without melting down hardware in the process.
## This all makes me even happier with Gemini
All of this makes me appreciate the simplicity and efficiency of my Gemini workflow all the more. This capsule is hosted on a Raspberry Pi 4 over both Gemini and Spartan using Agate and Agis respectively. The same SBC also serves as a Finger server using Toe, runs a Gitea instance and the HitchHiker Linux website over Apache. Nothing in my capsule or the HitchHiker website is generated on the server at runtime, rather both sites are static pages.All of this makes me appreciate the simplicity and efficiency of my Gemini workflow all the more. This capsule is hosted on a Raspberry Pi 4 over both Gemini and Spartan using Agate and Agis respectively. The same SBC also serves as a Finger server using Toe, runs a Gitea instance and the HitchHiker Linux website over Apache. Nothing in my capsule or the HitchHiker website is generated on the server at runtime, rather both sites are static pages.All of this makes me appreciate the simplicity and efficiency of my Gemini workflow all the more. This capsule is hosted on a Raspberry Pi 4 over both Gemini and Spartan using Agate and Agis respectively. The same SBC also serves as a Finger server using Toe, runs a Gitea instance and the HitchHiker Linux website over Apache. Nothing in my capsule or the HitchHiker website is generated on the server at runtime, rather both sites are static pages.
As I mentioned before, I'm happy with the slower feedback loop that Gemini provides. I'm also happy with the likely smaller audience. I think it's good to step away from that instant feedback loop that social media provides. Gemini also gives you a chance to be a little more contemplative and just write for the joy of wrriting. There are so few distractions when it's just you and a text editor. It's a workflow that is so much more suited to thoughtful writing than evtering text into a small box in a browser page. In the browser, you have so many other things in your field of view, and the text box itself is usually pretty small. Add to that the fact that on a service like Mastodon or Twitter there's a character limit. I've actually never seen the appeal of that concept. I make use of it to increase my networking and to announce software releases of my various projects, but I really dislike turning communication into short soundbites.

33
content/gemlog/thoughts_on_workflows_and_graphical_tools.gmi Normal file
View file

@ -0,0 +1,33 @@
Meta(
title: "Thoughts on workflows and graphical tools",
summary: Some("What I want instead of an IDE"),
published: Some(Time(
year: 2022,
month: 10,
day: 9,
hour: 22,
minute: 53,
second: 44,
)),
tags: [
"software",
"workflow",
],
)
---
I've had a sort of rough sketch of an application in my mind that continues popping up every once in a while. The idea isn't yet fully formed, but it's a very persistent idea.
Those who have been around in the Unix world for more than a few years no doubt remember when Konqueror was the default filemanager/webbrowser/documentviewer in KDE. I've often wondered why they got away from this concept. I imagine the scope of the project was probably a bit unwieldy to be sure, but I still fondly remember it. Some things that I thought were cool and useful:
* You could not only open different sorts of things in different tabs, you could also split panes.
* You could open a directory with a filemanager tab, and split the view with a terminal emulator on the bottom open to the same directory.
* That last one also worked on remote filesystems.
Another program I have a fondness for is Geany, the nice little is it an IDE or just a fancy text editor. I like that even though it's not a full blown IDE, you have a terminal attached to the window. Seems obvious that when you're writing code you want a terminal always at the ready. I get that most IDE's have this functionality and then some, but I never cared for a full IDE, and Geany was the first text editor I encountered with an attached terminal.
Anyway, I've played around with terminals that have split panes and tabs. I've played around with writing a graphical text editor. I've messed around with browsers some as well. And when you're developing software, it seems that you always want quick access to all three. Your documentation is most likely going to be viewed in a browser, you're writing your code in a text editor, and you run commands in a terminal. It's easy to find a combination of terminal emulator and text editor, and Konqueror used to allow you to have a terminal and a browser open in the same window. As far as I know, however, nobody has ever tried to combine all three...
So yeah, the idea keeps pestering me. I have my desktop set up to where I usually have a terminal open on virtual desktop 1 and a browser open on virtual desktop 2. But how about an IDE like program that can, say, build the documentation for your project and open it in a browser tab? Or maybe I want a browser view open to some docs on one side of the screen and an editor on the other side. Maybe split the side with the editor so the bottom half is a terminal.
Even better would be a somewhat open architecture that provides different views and/or editors as plugins that you can stuff into whatever tab or view you want.
I realize a lot of this can be achieved with a tiling WindowManager. But I like the idea of a single program that provides more uniform keyboard shortcuts and conventions. Gtk+ already has a terminal widget in VTE, a really self contained browser widget in WebKitGtk+, and some really powerful editing features in SourceView. It's probably going to keep on nagging me...

34
content/gemlog/updating_gtk_applications.gmi Normal file
View file

@ -0,0 +1,34 @@
Meta(
title: "Updating Gtk applications",
summary: Some("Catching up to the Gnome 43 release cycle"),
published: Some(Time(
year: 2022,
month: 10,
day: 24,
hour: 23,
minute: 4,
second: 57,
)),
tags: [
"software",
"gtk",
"rust",
"gnome",
],
)
---
I've been patiently waiting for Gnome 43 to land in Arch Linux since it was release now over a month ago. I finally got tired of waiting yesterday and installed some alpha packages via a third party repository. I have to say, I'm a bit disgusted to have to do this to get current software on Arch. I've never had to do this sort of hacky thing before, and I don't like doing it. My strong preference is to only have the default repositories in my repo list. But I digress.
Now, Gnome is not my daily driver desktop environment. I keep it installed for testing and development, while running Xfce on a daily basis. But I have a number of applications that I have written and maintain which use the Gtk toolkit. For some years now, Gtk+ has been more and more tied to Gnome and is in fact hosted on the Gnome Gitlab instance. So it's a good idea in my case to pay attention to where this code is headed. I've also begun porting a couple of my applications to target Gnome more specifically by using LibAdwaita and loosely following the Gnome HIG. More often than not I have found that this makes for a nice interface, and such applications are still useful outside of Gnome.
Anyway, yesterday was the day. I pulled the trigger in the morning and on my lunch break last night started working on beating Gfret into shape. Gfret had been using a git checkout of the libadwaita-rs crate, and thus depended on git checkouts of Gtk+, Gdk, Glib and on down the stack. Those crates all officially saw new releases last week, so now was a perfect time to update.
The new crates came with some tweaks to the interface that were all pretty well documented in the release notes and everything went smooth. The "next" branch of Gfret was merged last night and is the new "HEAD". So Gfret-3.0 will be released sometime in the next week or two, as soon as I have time to type up release notes.
Another application, the Vapad text editor, actually had a PR which did some of the work that I wanted to do to it. It's nice when someone else does a bit of the lifting. I'm not used to it in my own projects, most of which have scratched a more personal itch. Anyway, Vapad's "About" window is now using the AdwAboutWindow widget rather than the old style GtkAboutDialog. He also updated the Russian translations while at it.
I have some plans for Vapad, at least for it's next release. Right now, it uses the GtkNotebook container widget to provide it's tabbed interface. I plan to switch that to the AdwTabView and then incorporate the upcoming TabOverview and Tabbutton widgets which will release with Gnome 44 to give it an adaptive interface, which will work better on devices such as the PinePhone or PineTab. But I will probably do a release in the meantime for this cycle.
Incidentally, the Eva small web browser is probably going to get some similar treatment down the road. A number of things that I learned while writing Vapad have lead me to ideas for improving the interface.
That's all for now. Happy hacking everyone.