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

Merge branch 'odin' of git.hitchhiker-linux.org:jeang3nie/capsule into odin

Browse source
This commit is contained in:
Nathan Fisher 2023-04-29 19:24:59 -04:00
commit c54e538385
7 changed files with 359 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

113
content/gemlog/daily_driving_void.gmi Normal file
View file

@ -0,0 +1,113 @@
Meta(
title: "Daily driving Void",
summary: Some("I\'ve switched from Arch to Void as my everyday OS and development platform"),
published: Some(Time(
year: 2023,
month: 4,
day: 7,
hour: 15,
minute: 25,
second: 17,
)),
tags: [
"Arch",
"Void",
"Linux",
"Distros",
],
)
---
I've had Void as a second boot option for months now, and before that I had a fairly long running VM. I've been interested in moving to Void for a while for a couple of reasons, but the biggest would be that I wanted a distro based on Musl libc.
I already made this particular jump on one machine, the Raspberry Pi 4 which runs this gemlog, my Gitea instance and an Apache server. It's been rock solid and I haven't had to do anything other than install updates since the first week I brought it up. I haven't had that kind of stability in a long time.
## Clearing some blockers
One of the things that had been holding me back for a while was that the versions of Gtk and LibAdwaita in the Void repositories were behind what I needed to compile some of my projects, namely Eva, Gfret and Vapad. I've been used to getting library updates on Arch very soon after they become available. That highlights one of the differences between the Arch and Void release models. Both are rolling, but Void is more "Rolling Stable" for lack of a better term. More on that below. Anyway, short of compiling libraries myself this one was beyond my control. In the future I'll hold off updating my code until the libraries are available on Void, which coincidentally matches up better with what a lot of the LTS distros are doing.
The other issue I was having it turns out was my own fault. It's no secret I do most of my coding these days in Rust, and it has definitely spoiled me in a lot of ways. The version of Rust in the Void repos was, up until last week, 1.64. There were a number of really cool features release in Rust 1.65 which I bought into right away. The biggest two were let..else and labeled blocks.
```
// old syntax
let thing = if let Some(t) = some_function_returning_option() {
t
} else {
return Err(NoThingError);
};
// with let..else
let Some(thing) = some_function_returning_option() else {
return Err(NoThingError);
};
```
The other feature, labeled blocks, is pretty much the same thing as Zig's named blocks, and it's a geat feature. It allows one to return early from a code block with a value, including breaking out of an outer loop in nested loops. The syntax is a little odd, but I've already used it in a couple of places.
```
let liff = 'outer: loop {
loop {
break 'outer 42;
}
}
```
Anyway, I really wanted those newer features and not having them was going to be a deal breaker for me. Ordinarily I'd be using Rust from the official installer, rustup, but I was getting weird random issues every time I tried using the toolchain provided that way. I thought it had something to do with Musl, and that the Void devs had found a workaround. Turns out it was just me not realizing that I had previously installed Rust via the distro packages and had neglected to remove the `rust-std` package. Doh.
Note that about the same time I fixed that issue, the distro packages were updated. But I'm sticking with the rustup toolchain because the distro packages are missing rustfmt and clippy, which are too nice to not use.
## Rolling release vs rolling stable
This seems like a subtle distinction, but in practice is has some noticable effects. In Arch, every package gets updated as soon after a new stable version is released as it can be packaged and tested. This includes libraries and kernels. This is rolling release.
In Void, those libraries don't get updates beyond path releases until the applications that are using them require the new versions. Void also uses the most recent LTS series kernel. This leads to less churn overall, while still having the benefit of a system that never has to be reinstalled or go through an upgrade from one OS version to another.
This leads to some interesting contradictions. On Arch, I had gtk-4.10 for months, while all of the Gnome applications that were installed only needed gtk-4.8. But when Gnome43 came out, it took almost two months for the dev team to build, test and release it. Void, on the other hand, waited until the desktop was being updated and updated all of the libraries at the same time. So when Gnome44 came out last week Void got a large influx of updates and the entire desktop was available within days. It's probably not as well tested as Arch, but considering the manpower constraints how could it be?
> Note: Fedora and Ubuntu both time their releases to occur shortly after Gnome major releases, so when the next major version of those distros ship it can take advantage of what is at the time the latest version. So the way Void works is actually pretty similar, except no need to download an iso and upgrade from one distro release to another or to change repositories.
At any rate, I really rather like this "Rolling Stable" approach. It definitely calmed things down when it came to running the OS as a server, and it seems to work out nicely on the desktop as well.
## Some interesting things I've encountered in Musl
As most OSS these days is written for Linux, and the vast majority of distros ship Glibc rather than Musl, it's only natural that some differences would be noticable, particularly if like me you tend to experiment and write a fair bit of low level code. Just this morning, I was working on bringing up an aarch64 cross compiler toolchain (as per the instructions in my post about building cross compilers) and Binutils failed to build. The offending code was in the `gprofng` module, where it was looking at the members of the `sigevent` structure individually, and expecting one to be there that does not exist in Musl. Rather than investigate and patch I just disabled gprofng via the configure script. Luckily that was a thing that I could do. This sort of thing is not always the case.
Another difference I encountered when writing some code which read usernames and validated passwords using the libc `pw` and `spw` structs. My original pass at this (using unsafe Rust) compiled and ran fine with Glibc. With Musl, it compiled and errored at runtime because some of the data I was trying to read was a null pointer (I did at least have proper error handling and null checks in the code). Anyway the reason it was happening was that Musl re-uses the same memory address for each subsequent construction of `pw`. When I looked at the POSIX spec, sure enough it said that some Libc implementations do this and it is fine. There were two possible solutions. One was to copy the bytes from that memory location into an owned piece of memory. The other method was to move all of the logic using the data in the first `pw` instance to before the creation of the second `pw` instance. The second method, requiring one less allocation, is what I used. This is a pretty nice demonstration of the sort of trouble you can get into when writing `unsafe` Rust, but because the language has trained me to account for all code paths instead of just the happy path it was a pretty easy diagnosis and fix.
That's two examples of the sort of things I've encountered in Musl, and I think they're pretty indicative of the sort of subtle differences one might encounter. That is to say, you're only going to encounter them if you're poking at the system. The average person really isn't going to notice any difference whatsoever because everything pretty much just works. A look at the relative sizes of tthe code is enlightening.
```
# Musl, according to Tokei
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
GNU Style Assembly 312 7938 7165 256 517
Autoconf 35 6624 236 6273 115
C 1583 65083 50968 7551 6564
C Header 668 40754 35683 301 4770
Makefile 12 314 201 34 79
Shell 4 925 638 172 115
===============================================================================
Total 2614 121638 94891 14587 12160
===============================================================================
# Glibc
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
GNU Style Assembly 2345 463470 328440 93738 41292
Autoconf 94 112969 112642 182 145
C 10186 1015110 708606 209622 96882
C Header 3341 416395 304183 79574 32638
C++ 35 2447 1660 525 262
Happy 1 387 330 0 57
JSON 2 100 100 0 0
LD Script 3 25 7 17 1
Makefile 202 21349 15600 2869 2880
Module-Definition 21 2958 2759 0 199
Perl 3 864 635 142 87
Python 68 18705 14720 2383 1602
Shell 83 8713 6102 1671 940
TeX 1 11672 7162 3697 813
Plain Text 8 63381 0 63159 222
===============================================================================
Total 16393 2138545 1502946 457579 178020
===============================================================================
```
I've compiled both Musl and Glibc numerous times while playing around with HitchHiker. Glibc takes a solid 15 minutes start to finish, while Musl is done in around a minute or less. Also, why do I want or need both Perl and Python in a Libc distribution? They might not be available (much less wanted) while bootstrapping a system from source.
The coding *style* is also enlightening. Drew Devault did a great writeup on one of his investigations into why a certain piece of code segfaulted with Glibc and not with Musl.
> Maybe, just maybe, the behavior of this function should not depend on five macros, whether or not you’re using a C++ compiler, the endianness of your machine, a look-up table, thread-local storage, and two pointer dereferences.
=> https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html Drew Devault: A tale of two libcs
Anyway, even though I'm not writing much C these days it cannot be denied that C is the foundation upon which Linux (and most other modern software) is built. So for a long time I've really wanted to switch to a distro that uses what I firmly believe is a better Libc implementation. Void scratches that itch quite nicely. Bonus points because it uses Runit for Init, and I'm a big fan of service supervision suites like Runit and S6.

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

@ -0,0 +1,52 @@
Meta(
title: "Hitchhiker Linux: an origin story",
summary: Some("I once accidentally built a Linux distro. A few years later, I did it again on purpose"),
published: Some(Time(
year: 2022,
month: 9,
day: 14,
hour: 17,
minute: 34,
second: 7,
)),
tags: [
"linux",
"software",
],
)
---
Once upon a time, about 2011 to be a little more precise, live was not going my way. My marriage had blown up, my kids were strangers to me and I found myself rather on the far side of sanity. This is not in fact the worst thing that can happen to a man of course because I was still breathing. But I found myself at that time without a job, without a car, and without much in the way of motivation.
One gets bored after a time and finds a way to pass the time. I had left the vast majority of my earthly possessions behind in a storage unit and had at that time no computer. I missed it, however, and found a discarded carcass that I deceided to bring back to life (as one does) with a hard drive but no operating system. Having been a full time Linux and FreeBSD user previously, I wanted a Linux installation. This might be a good time to point out that I also had no internet connection, which combined with not having and operating system to begin with puts a damper on installing Linux. Among what meager possessions I did have with me, however, was an old briefcase with a 512MB pendrive and a CD tucked into a pocket, upon which was written a version of Puppy Linux.
So armed, I started making trips to the local public library in order to use their internet connection and began stuffing as many Slackware packages as possible onto my little 512MB pendrive. I would arrive on foot after a four mile walk (did I mention that I was at the time in the middle of nowhere?), ask to use a computer, and just load it up. So armed, I booted up the computer carcass with the trusty old Puppy Linux CD, formatted the disks to the then shiny ext3 filesystem and extracted each Slackware package individually onto the drive, examining the post install scripts to see if anything further needed done and manually running any needed commands. It took about two weeks to get a full graphical environment this way. And you thought that you had it bad installing from floppy....but I digress.
## The Star Wars connection
Several years prior to this I was at a midnight showing for Revenge of the Sith. Being a huge nerd I showed up early, with all of the other huge nerds. Having the better part of an hour to pass until the movie started I had brought along reading material, in this case a training manual for Red Hat Linux. Being among other fellow nerds it should perhaps not come as a surprise but the enormous bearded guy seated next to me was a Linux enthusiast and wasted no time in telling me that Red Hat was a waste of time. He also just so happened to have a full printed copy of the Linux From Scratch book in his car, which he proceeded to retrieve as a gift for his new friend. We enjoyed the movie and went our separate ways, and after glancing at the book I was intrigued but somewhat intimidated.
Fast forward to my shiny new Slackware installation with it's oh so compelling Fluxbox desktop. I figured in for a penny, what the hell. And so I began making more trips to the library and downloaded the current version of the book along with the required source packages and tarballs. Having nothing if not time on my hands I fired through the book in a day, and then began on Beyond Linux From Scratch. I caught the bug, and was having fun. So much fun that I decided that I would automate everything.
## Enter HitchHiker Linux Mark I
The resulting build system was pretty cool I thought. It wrapped most of the build using a master Makefile and a number of included .mk files such that you could build everything just by entering the source directory and typing `make buildworld`, just like on FreeBSD. Sure, it was kind of brittle, but it worked, and it was way faster than manually typing all of the commands. I even began work on a ports tree, which could quickly get a LAMP server up and running along with a host of other console base utilities. It developed to about the halfway point to a working graphical environment and then stalled, as I had to resume normal life with a job and adult responsibilities again. I saved the work in Git and figured on picking it back up at some later time.
## The SystemD resolvconf incident
It was not long after that when I encountered Arch Linux and began using it in favor of Slackware as my daily driver. It was great in that once configured it just kept running without ever needing a reinstall. I still use Arch on several computers, but there are still a few things that annoy me about Arch. One of them is SystemD. I know that's not an Arch specific thing, and I do see and admit some of the benefits that SystemD brought to the Linux desktop and server. That said, SystemD gave me the impetus to resurrect Hitchhiker. Upon setting up a new system (a Raspberry Pi) with a static IP I began encountering issues with the network. I've been doing this for years, and after double checking I was sure that I had dome it all correctly. But some programs would fail to resolve dns, and some had intermittent issues. When I did finally track the issue down it was due to resolv.conf no longer being the two line file that I had placed there to designate my chosen dns servers, but a symlink to a systemd controlled monstrosity that had replaced my own configuration. I was pissed. Not only does SystemD think that it should have control over this file, it thinks that a convoluted setup involving dnssec should be default. I happen to disagree. My long experience has been that two lines naming a primary and secondary server are ALL. THAT. YOU. EVER. NEED.
Nor was this an isolated thing. I've found that in it's default configuration, SystemD is just way too opinionated. The defaults work great for most people, but the moment that you want to do anything even remotely advanced it throuws up strange roadblocks. After looking around at the various other distros that used a different init system I was unsatisfied. I've since discovered Void Linux, which is excellent, but again I digress.
## HitchHiker Mark II
Thinking that my code was safe turned out to be a mistake. I had chosen Google Code as a platform to keep the original build system while I went off to live my life, back at the time when Google's slogan had been "Do no Evil". While I knew that things had changed in the interim, I was annoyed to discover that my code was all gone. Every project that I had entrusted to Google Code was just gone without a trace. Oh well, I remembered how I had done it once, so I knew how to do it again. More to the point, I knew what didn't work as well as I intended and had a good idea how to fix it.
I went a lot further this time. Linux From Scratch builds a temporary toolchain and environment, chroots into it and uses those tools to build the final system. This is kind of ugly to automate. HitchHiker instead creates a sysroot compiler and then builds the entire base system without having to chroot into it. A number of packages had to be patched. The benefit is that cross compilation is also possible. The system can build from just about any Linux distribution with a functional and relatively modern C compiler, on any architecture, for a number of architectures. It's tested to build correctly for x86_64, x86, aarch64, armv7, and riscv64.
Being a fan of the BSD's I ported a lot of the userland over to Linux. Some came from the Outils project and was ported from OpenBSD already. Some Linux specific utilities came from suckless, and I wrote a fair bit of others in C myself. You get lksh as /bin/sh (the Posix compatible version of the MirBSD Korn shell) and Zsh as a user shell. There are two editors, ee which comes from FreeBSD and heirloom Ex/Vi. So I'm typing this right now using a descendent of the original Unix Vi written by Bill Joy. For a time I was using The One True Awk, but had to replace it with Gawk as there were compatability issues when compiling a lot of third party software. The idea is to have a smallish base system which includes just enough operating system to bootstrap itself from source, upon which you can build whatever you want. The base system has a lot of C code imported directly into it, as is done for BSD, but tracks certain major pieces such as Gcc and Glibc and keeps them up to date. Third party packages are provided via NetBSD pkgsrc. I'm running the Mate desktop right now, with the option of Xfce and a long list of small Window Managers as optional.
Installation is pretty manual. You have to start from a working Linux environment, either making a dual boot or using a live image. You make your partitions, mount them and extract the tarball for the root filesystem. Then either add a Grub configuration entry (for a dual boot) or else install grub. You'll have to edit some config files in /etc and chroot into the system to set a root password. Init is via S6. Once installed, I'm going to be providing a tarball with a bootstrapped version of pkgsrc so that you can just install binary packages using the pkgin package manager from NetBSD. Pkgin works pretty much the same as Apt from a user perspective, so it's not going to seem too foreign for most users. Down the road HitchHiker is going to have it's own ports tree, as there's a lot of stuff that is Linux specific and not included in pkgsrc. I have some of the infrastructure in place for it, but it's not ready for public consumption yet.
I'm also working on a handbook that will guide users through installation and various configuration tasks like setting up the network, and working with the S6 init and supervision suite. It's partway done, but not gauranteed accurate yet as the system keeps evolving.
## When?
I'll be officially putting up the binaries for x86_64 sometime this quarter, followed at some later date with aarch64. I'm looking to get my hands on the next StarV board, after which I'll make it available on RiscV as well. 32-bit can be built for but I'm not going to compile packages for it myself. The source is already available and quite liberally licensed as BeerWare, with third party sources retaining their original licensing of course.
=> https://hitchhiker-linux.org HitchHiker Linux homepage
=> https://git.hitchhiker-linux.org Hitchhiker Linux git repository

40
content/gemlog/is_gemini_boring_and_is_that_even_bad.gmi Normal file
View file

@ -0,0 +1,40 @@
Meta(
title: "Is Gemini boring and is that even bad?",
summary: None,
published: Some(Time(
year: 2023,
month: 4,
day: 11,
hour: 4,
minute: 6,
second: 31,
)),
tags: [
"gemini",
"tech",
"writing",
],
)
---
I'm sure you've all seen the thread so I won't re-hash. But I disagree with the fundamental premise on several grounds.
* There is actually a pretty wide variety of content here
* Even if the subject matter is weighted towards tech, I don't see that as bad. Or boring.
* On a less rational note, it bothers me to see someone I've come to appreciate and respect in distress.
Ok, so gemini is largely dominated by technically minded people and a lot of their posts are technically oriented. I can't argue with that. But there really is other stuff here. I've seen it. Once in a while, I've posted it. But I think that a common belief that sets the average long term Gemini resident apart from the average technically oriented person is some combination of the beliefs that small can be beautiful, sustainability is important, uncontrolled growth is bad, and slow thoughtful communication via longer form writing is preferable to jingoism and sound bytes. I consider myself to be a thoughtful person, someone who tries to find a balanced point of view. That said, I've been challenged and called out here when my thinking wasn't truly acknowledging the depth of certain subjects, and I'm better for it. Gemini tends to collect people who want to not only express things on a little deeper level, but those who are ok with having their views challenged so that they can learn and grow. Some of those interactions have been in the many Re: threads, while some have been in email comments. What they all have in common is that they feel more meaningful than anything I've found on the world wide web in a very long time.
Even when tech is the subject, I find the sort of technologies and computing that are discussed here to be more interesting than what gets written about elsewhere. On any given day Antenna probably has someone talking about Forth, installing OpenBSD, explaining the `Pledge` system call, or giving an update on their massive web crawler which is designed to rank individual and personal sites above corporate trash. Go back to the web (even the better parts such as Fedi) and most of the talk is centered around how bad crypto/llm/next_fad is. I am fascinated reading about someone's ground up Forth implementation. I already know llm's are being put to bad use, and frankly -that- is boring.
But in the end, there's an old piece of advice that is always good advice. Be the change that you want in the world. So if you want to have more varied subject matter on Gemini, a good start is to begin creating it.
### So what's going on in my world?
Well my truck finally got to the point a few weeks ago that I can't justify keeping it on the read until it's had some real work done on it. I've been taking the bus to work in the afternoon. Unfortunately, in the US public transportation tends to suck, and in smaller cities or towns it's really hit or miss whether it exists at all. In our town the bus doesn't run on Sundays and the last route runs an hour and a half before the end of my work shift. So I'm stuck walking home five miles. It isn't as bad as it might sound to some. I really needed the exercise, for one, and I'm down ten pounds so far.
Spring is definitely here in the last couple of weeks, and tomorrow morning on my day off I'll be tuning up the lawn mower and installing a dog run rather than being inside typing on my laptop. My dog, Spock, has been going really stir crazy this winter. He wants to be outside running and playing and hunting smaller (and sometimes larger) animals. I'm going to try to get out and get both our lawn and the neighbor's lawn done before he has a chance. The guy just turned 71, literally a few days after my own father did, and since my dad is too far away for me to watch out for I'm going to do what I can for my neighbor as a proxy.
Most of my coding projects have slowed down due to the extra time I'm taking walking everywhere. I've caught up on a lot of podcasts and a few audiobooks. Almost done with "John Dies at the End" and I'm planning to start "Dungeon Crawler Carl" after that. But I do have a few things brewing, and have chipped away slowly at some of the longer running projects. HitchHiker is getting it's own package manager that has a few novel ideas. But I won't go too far into that just now because I want to get a bit more of it working before I talk about it much.
I suppose the biggest thing coming down the pike, and I can get away with saying this here because my partner is never going to read it, is that I've picked out an engagement ring. We've been together seven years now, and living together for six of those years. It's time. My daughter is actually nagging me about it because I'm pretty sure she likes my SO more than she likes me and wants it to be official. Anyway, she (my SO, not my daughter) is really into astronomy and follows the goings on with Nasa, the ISS and even Mars weather. So the ring is platinum, inlaid with meteor.
Anyway, I guess I figured there was something in that original post about Gemini being so tech centric. Even if I spent the first half of this post arguing the fact. It definitely could have been presented more delicately, but I'm OK with being challenged. So I figured I'd wind the post down by writing on a more personal note to change things up a bit. Like I said, be the change you want to see.

49
content/gemlog/migrating_to_sway.gmi Normal file
View file

@ -0,0 +1,49 @@
Meta(
title: "Migrating to Sway",
summary: Some("Testing out Sway since I\'ve essentially been using XFwm as a tiling WM for a while anyway"),
published: Some(Time(
year: 2023,
month: 4,
day: 12,
hour: 14,
minute: 45,
second: 5,
)),
tags: [
"sway",
"wayland",
"linux",
],
)
---
Someone posted recently saying that they'd heard a rumor that there wasn't enough technical content in Gemini. Here's another contribution to that sphere..
I am definitely a minimalist when it comes to computing, and a bit of a "power user" (as much as I hate that designation, I guess it fits), but I've been hesitant to jump on the tiling WM train despite recognizing the benefits of that workflow. I think the reason has mostly been that I just couldn't be bothered to learn a bunch of new keyboard shortcuts. But that's frankly not much of an excuse since Sway is ultimately configurable however you like it.
I did play around for a while with dwm back when it first came on the scene years ago. I liked it, but not all of the shortcuts made sense to me and I didn't feel like having them compiled into the binary was in fact a great way to go, because for one thing you have to update sometimes, and for another thing that would require maintaining my own config.h file to use on each machine I run. I'd much rather just put a dotfile in place than a custom compiled binary for every machine. Anyway, I didn't end up making it my daily driver. At the time I was using PekWM, which I still have fond memories of. For those who don't know what PekWM is, it's a stacking X11 WM with tabbing built in. Basically you can drag one window onto another and the two windows will be joined as one, with a tab for each in the titlebar to select which one gets displayed. It came with no panel, and I didn't use one. All I had was a right click menu. But after playing with dwm, I did adopt dmenu as my application launcher.
PekWM, however, is among a long list of X11 window managers that has fallen into disuse and is not being actively maintained. I set up a very highly customized OpenBox and used that for a while, going so far as adding my own custom shortcuts for simple tiling layouts (I still liked the concept). But when I replaced my old desktop machine with a Raspberry PI for a home server and a laptop for hacking, my OpenBox setup was relegated to the PI and I settled into using XFCE for a number of years.
My XFCE setup has evolved over time, first losing the bottom panel, then shrinking the top panel, then acquiring a custom theme with very slim titlebars. I added a lot of my keyboard shortcuts for tiling, but mostly just used fullscreen windows and workspaces. I started Zterm as a simple way to have Vim and a terminal open at the same time. Then switched to NeoVim, and used to built in terminal for a while. Then I discovered Zellij (which I've been using on XFCE up until this week) which is a cool terminal multiplexer in the vein of GNU screen or Tmux. And then, realizing that I've been essentially using XFCE as a tiling WM for a while anyway, I decided to just bite the bullet and try out Sway. It's been about 48hrs now, and I think I'm hooked.
### My configuration
I'm not really doing anything fancy in my configuration. I've got the titlebars cut right down to about a 3-4mm strip and the included status bar set to autohide. I really don't like giving up screen real estate. I'm using Wofi as a launcher, although I may switch to bemenu because it's simpler. I haven't decided yet. I've changed the keybindings to match what I've grown used to over the years. Super + 1 switches you to desktop 1, Super + 2 to #2 and so forth, while Super +F1 moves the focused window to desktop 1 and so on. I don't like the defaults where you're expected to hold Super + Ctrl at the same time. Makes my fingers hurt.
The little things that took a little digging to configure right were things like making sure that I had an ssh-agent up and running on login and investigating why neither Thunderbird nor Firefox would open from Wofi (but they will from bemenu or a terminal). I gave up on that last one because I don't use Firefox on the daily, I use Qutebrowser, and I put in a shortcut to start Thunderbird using Super + M just like I had in XFCE.
It's funny, but using it pretty much doesn't feel any different. I've got even more screen real estate, which is good on my backup laptop which only goes to 1080 resolution, and even less distractions than before. The last thing I think I need to figure out is how to exit without using the touchpad, as the exit keycombo brings up the "swaynag" program, and you have to actually click a button to tell it that yes, you really want to leave. That's kind of an odd default I would say, considering how keyboard driven the rest of the desktop is.
### Gnome really pisses me off
I've been on a quest for screen real estate for years now. I remember vividly when GTK+ moved from the 2.0 series to the 3.0 series that pretty muich every widget took up oodles of space compared with the old version. I used to have a pretty highly customized gtkrc file and gtk.css to try to cut a lot of that down, but honestly I'm tired of fucking around with it. I'm only bringing it up because of the stark contrast after a couple of days using Sway. I really, really want to like Gnome. I like the simplicity, and I do think that it's an attractive overall design. But what I want out of it is a nice simple way to may all of the hugh ui elements shrink down to the smallest possible size so that I have room to display a couple files side by side with a terminal underneath to check if my code is still compiling. Sway makes that really, really easy in comparison. It's definitely not pretty though. But I mostly don't care about that.
### No more terminal multiplexer (probably)
I've felt no real need for anything like a terrminal emulator with split panes or a terminal multiplexer these past couple days, as the compositor just does it for me. It's also nice to be able to quickly fullscreen one window, then shrinkn it back down with a keypress. So Zellij might be relegated to remote only use when I log into the server for maintenance.
### Getting NeoVim to use the system clipboard
This is something that has always annoyed me about Vim. Vim has it's own clipboard implementation that doesn't, by default, integrate with the system clipboard. It's part of why I just used the builtin terminal for a while. Anyway, it was probably always fixable, but I didn't take the time to dive into it until earlier this week. And since I'm on NeoVim now, and using an `init.lua` for configuration rather than `init.vim`, here's my little lua snippet.
```
-- Integrate with system clipboard
vim.keymap.set('v', '<C-c>', '"+y')
vim.keymap.set('n', '<C-v>', '"+p')
```
This doesn't interfere with the use of the builtin cut buffers, but it enables me to put a visual selection into the system clipboard with the expected Ctrl-c shortcut, and to paste from the system clipboard into an editor buffer using Ctrl-v. Note that the latter requires being in 'Normal' mode. If I'm in 'Insert' mode then it's the same shortcut used to paste into my terminal, or Ctrl-Shift-V.

75
content/gemlog/re_facilitating_posting.gmi Normal file
View file

@ -0,0 +1,75 @@
Meta(
title: "Re: Facilitating Posting",
summary: Some("Me, the peanut gallery, just adding to the discussion"),
published: Some(Time(
year: 2023,
month: 4,
day: 12,
hour: 20,
minute: 6,
second: 18,
)),
tags: [
"gemini",
"zond",
"make",
"scp",
"git",
"php",
"permissions",
],
)
---
=> gemini://senders.io/gemlog/2023-04-11-facilitating-posting.gmi Original
=> gemini://tobykurien.com/replies/2023-04-11-re-facilitating-posting.gmi Reply
I'm sure a lot of the capsules here have started out as totally hand written and managed, while slowly adding more automation as time goes by. My own capsule falls into that category as well. Currently I've got it down to two commands (plus the actual writing).
```
zond post "Title of Post" init -ept tag1,tag2,tag3 -s "A summarry of the post"
make
```
My capsule generator, Zond, has added a few small but useful enhancements over time. The -e flag tells it to open the newly created file in my editor, while the -p flag tells it to go ahead and mark the file as published after closing the editor (which just involves turning the "published" field on the metadata struct from None to Some(datetime)). I'm not saying it's for everyone, but it definitely suits the way that I work.
The second command just runs the default target of the Makefile sitting in my capsule's source directory, which does the following:
* calls `zond build`
* scp's all of the generated files to the server
* publishes the atom feed to Antenna using `openssl s_client`
* calls `git add .`, `git commit` and `git push` to check the source into my gitea instance and a mirror on Codeberg
For those with less git-fu (a lot of folks came of age after git became synonymous with GitHub so they don't know the command line) you can add as many push url's as possible. It's easy enough I find myself scratching my head when folks ask how to mirror a repository or migrate away from GitHub.
```
git remote set-url --push origin <first url>
git remote set-url --push --add <second-url>
```
> Since the server ran under a different user, I had multiple commands to copy, change ownership, etc. which also required typing in my sudo password multiple times. I thus enabled passwordless sudo, which is a terrible idea and gave me a reason to find a better way.
That reminds me of the terrible advice I've often seen for php web applications, where the web server needs write permissions to some directory, but the user wants to be able to upload changes via ftp or whatnot. No? Before your time again? Well anyway, lots of folks always loved to recomment just doing a `chmod -R 777` on the directory.
If you ask me, that's a great argument for static sites. The server for this capsule runs as one user, with read only permissions on the directory where the files reside. My own user actually owns the files, so I can just scp them as myself.
It also reminds me of my earlier post about sudo. The fact that sudo is seen as a nag, and gives one the option of turning off the nagging by enabling passwordless sudo, does in itself seem like it's encouraging insecure configuration. At least to me it does. Just an aside though.
> And that's it! it's wonderful (I have to type my ssh key passphrase a few times - but that's w.e). I'll likely get this running on my writing PC too!
The ssh-agent is your friend. You can put the following in your shell startup file (.bashrc or .zshrc).
```
eval $(ssh-agent)
```
Note: this will only work for the current shell. If you're running X11, you can add to ~/.xprofile:
```
if [ -z ${SSH_AUTH_SOCK+x} ]
then eval $(ssh-agent)
fi
```
This checks if you have the SSH_AUTH_SOCK set, and if not then it starts up ssh-agent as part of the Xorg startup process and adds the socket path to the environment. Wayland is a bit trickier. I've settled on using gnome-keyring since I keep Gnome installed for testing some of the graphical programs I've written. So in my .zshrc I have the following:
```
# if running X then we start ssh_agent from .xprofile, but if we're on Gnome and
# Wayland we need to use the Gnome keyring ssh agent
if [ ${XDG_SESSION_DESKTOP} = "gnome" ] || [ ${DESKTOP_SESSION} = "sway" ] && [ ${XDG_SESSION_TYPE} = "wayland" ]
then export SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
fi
```
Then it's just a matter of making sure that gnome-keyring-daemon is running after login. For Sway, I simply include `exec gnome-keyring-daemon` to my ~/.config/sway/config` file.
Any way that you do it, assuming the ssh-agent is running and the socket path is in your environment correctly, then you can just type `ssh-add` to unlock the keys and they'll stay unlocked for the lifetime of your login. Don't want to leave your keys unlocked if you step away from your desk? Run `ssh-add -d` to remove keys.

1
tags.lock Normal file
View file

@ -0,0 +1 @@
5413

29
tags.temp Normal file
View file

@ -0,0 +1,29 @@
!_TAG_FILE_FORMAT 2 /extended format; --format=1 will not append ;" to lines/
!_TAG_FILE_SORTED 1 /0=unsorted, 1=sorted, 2=foldcase/
!_TAG_OUTPUT_EXCMD mixed /number, pattern, mixed, or combineV2/
!_TAG_OUTPUT_FILESEP slash /slash or backslash/
!_TAG_OUTPUT_MODE u-ctags /u-ctags or e-ctags/
!_TAG_PATTERN_LENGTH_LIMIT 96 /0 for no limit/
!_TAG_PROC_CWD /home/nate/src/gemini.hitchhiker-linux.org/ //
!_TAG_PROGRAM_AUTHOR Universal Ctags Team //
!_TAG_PROGRAM_NAME Universal Ctags /Derived from Exuberant Ctags/
!_TAG_PROGRAM_URL https://ctags.io/ /official site/
!_TAG_PROGRAM_VERSION 5.9.0 //
Creative Commons Attribution-ShareAlike 4.0 International Public License LICENSE.md /^## Creative Commons Attribution-ShareAlike 4.0 International Public License$/;" s
Section 1 =E2=80=93 Definitions. LICENSE.md /^### Section 1 =E2=80=93 Definitions.$/;" S section:Creative Commons Attribution-ShareAlike 4.0 International Public License
Section 2 =E2=80=93 Scope. LICENSE.md /^### Section 2 =E2=80=93 Scope.$/;" S section:Creative Commons Attribution-ShareAlike 4.0 International Public License
Section 3 =E2=80=93 License Conditions. LICENSE.md /^### Section 3 =E2=80=93 License Conditions.$/;" S section:Creative Commons Attribution-ShareAlike 4.0 International Public License
Section 4 =E2=80=93 Sui Generis Database Rights. LICENSE.md /^### Section 4 =E2=80=93 Sui Generis Database Rights.$/;" S section:Creative Commons Attribution-ShareAlike 4.0 International Public License
Section 5 =E2=80=93 Disclaimer of Warranties and Limitation of Liabilit= LICENSE.md /^### Section 5 =E2=80=93 Disclaimer of Warranties and Limitation of Liabilit=$/;" S section:Creative Commons Attribution-ShareAlike 4.0 International Public License
Section 6 =E2=80=93 Term and Termination. LICENSE.md /^### Section 6 =E2=80=93 Term and Termination.$/;" S section:Creative Commons Attribution-ShareAlike 4.0 International Public License
Section 7 =E2=80=93 Other Terms and Conditions. LICENSE.md /^### Section 7 =E2=80=93 Other Terms and Conditions.$/;" S section:Creative Commons Attribution-ShareAlike 4.0 International Public License
Section 8 =E2=80=93 Interpretation. LICENSE.md /^### Section 8 =E2=80=93 Interpretation.$/;" S section:Creative Commons Attribution-ShareAlike 4.0 International Public License
Using Creative Commons Public Licenses LICENSE.md /^### Using Creative Commons Public Licenses$/;" S
all Makefile /^all: build upload publish commit$/;" t
build Makefile /^build:$/;" t
clean Makefile /^clean:$/;" t
commit Makefile /^commit:$/;" t
nsc32fe56d0101 public/gemlog/atom.xml /^<feed xmlns="http:\/\/www.w3.org\/2005\/Atom" xml:base="gemini:\/\/gemini.hitchhiker-linux.org">$/;" n uri:http://www.w3.org/2005/Atom
publish Makefile /^publish:$/;" t
submit_url Makefile /^submit_url = gemini:\/\/warmedal.se\/~antenna\/submit?gemini%3A%2F%2Fgemini.hitchhiker-linux.org/;" m
upload Makefile /^upload: build$/;" t