Merge branch 'odin' of codeberg.org:jeang3nie/capsule into odin
This commit is contained in:
commit
29c136060d
3 changed files with 77 additions and 0 deletions
41
content/gemlog/neovim:_init.lua_from_scratch.gmi
Normal file
41
content/gemlog/neovim:_init.lua_from_scratch.gmi
Normal file
|
@ -0,0 +1,41 @@
|
||||||
|
Meta(
|
||||||
|
title: "Neovim: init.lua from scratch",
|
||||||
|
summary: Some("I tried my usual goto for bootstrapping my NeoVim config on FreeBSD only to find it broken"),
|
||||||
|
published: Some(Time(
|
||||||
|
year: 2023,
|
||||||
|
month: 6,
|
||||||
|
day: 19,
|
||||||
|
hour: 4,
|
||||||
|
minute: 34,
|
||||||
|
second: 31,
|
||||||
|
)),
|
||||||
|
tags: [
|
||||||
|
"neovim",
|
||||||
|
"vim",
|
||||||
|
"lua",
|
||||||
|
"compatability",
|
||||||
|
],
|
||||||
|
)
|
||||||
|
---
|
||||||
|
After chucking one of my only remaining Arch installations in favor of FreeBSD (now a dual boot with Void) I've been one by one massaging my dotfiles and fixing software compatibility issues to get my preferred environment up and running. Only yesterday I managed to get my multiplexer, Zellij, up and running by backporting a fix from upstream git to their current release. I've been having trouble getting my NeoVim config setup, in that it was reporting that it couldn't set up language servers, and last night after work I began investigating.
|
||||||
|
|
||||||
|
I've been using kickstart.nvim for a while as a jumping off point, as when I made the switch from an init.vim to init.lua I didn't really feel like starting from scratch. But what I found bothered me enough that I chucked it all. About four months ago they switched from the Vim package manager they had always used, Packer, to a new one called Lazy. I've never experienced issues with Packer, but if that was the only change and things were working I'd probably just roll with it. They also switched from just using the NeoVim official lsp support package to a new plugin called Mason which is supposed to make installing new language servers easier. Crap, here we go.
|
||||||
|
|
||||||
|
So Mason may or may not actually do what it says it does, ON LINUX. It doesn't even attempt to work on FreeBSD. Once it detects that you're running FreeBSD it exits with an 'Unsupported Platform' error message. I'm getting really tired of this crap. This is the sort of lazy programming that made me throw in the towel ten years ago and switch back to Linux, but I'm kinda pissed about it now and motivated to fix things where I can.
|
||||||
|
|
||||||
|
I consider this particular pattern of checking what OS you're running rather than checking for features to be lazy and stupid. There's a great article on exactly this sort of thing by the author of the hobby OS Sortix in relation to GNU Gnulib, where he argues to great effect that instead of checking for the platform one should be checking for features. He's 100% correct, but unfortunately in the real world programmers get lazy about this sort of thing and sometimes programming languages and frameworks are not your friend here.
|
||||||
|
|
||||||
|
Anyway, this is in my view another example of piling abstraction on top of abstraction, as Neovim comes out of the box with support for lsp servers and just needs to be properly configured in order to use them. As annoying as the extra layers are, I might have still taken the route of rolling back to an earlier version of Kickstart, except that when I looked at the git history there are literally no releases or even tags to roll back to. I decided in the end this is just not the sort of code I want running on my system if they take such a laissez-faire approach while moving at breakneck speed. So I set out to actually learn how to write an init.lua from scratch, with the hope that what I wound up with would be lighter, easier to maintain, easier to migrate to a new machine and better tailored to how I use my editor.
|
||||||
|
|
||||||
|
It turns out that this is not all that hard to do with a little patience and a lot of searching. Some parts of my config are of course still literal cut and paste from project pages for the plugins that I did keep. But I definitely have a better understanding of what's going on overall and there shouldn't be any surprises luring around to bite me later. Lua is such a simple language that if you have any programming experience you'll be off and running without ever having to read the docs, just by looking at code samples.
|
||||||
|
|
||||||
|
Right now I've got the plugins list pared down to the following:
|
||||||
|
* Packer for managing plugins
|
||||||
|
* nvim-lspconfig to manage lsp configuration
|
||||||
|
* telescope for quickly navigating between files in a project
|
||||||
|
* nvim-cmp for snippets and completions
|
||||||
|
* vim-fugitive for Git integration
|
||||||
|
|
||||||
|
I've gotten rid of all the TreeSitter highlighting, as I'm totally fine with Neovim's inbuilt syntax highlighting. Also gone are things like color themes and status line plugins. All told, while Kickstart gives you what they call a "minimal" starting point with a 515 line init.lua mine is currently at 168 lines. I may add a few more leader shortcuts, and possibly futz around with the default colors a bit, but I think I'm mostly done and happy with it.
|
||||||
|
|
||||||
|
One feature that I tried to retain is the ability to bootstrap itself just by dropping the init.lua into a new machine and running a couple of commands. The project page for Packer has a suggested function to add to init.lua which, if packer is not installed, shells out to git clone the repository into the correct location. It's a pretty small and easy to understand bit of code, just as it should be.
|
26
content/gemlog/re_richard_stallman.gmi
Normal file
26
content/gemlog/re_richard_stallman.gmi
Normal file
|
@ -0,0 +1,26 @@
|
||||||
|
Meta(
|
||||||
|
title: "Re: Richard Stallman",
|
||||||
|
summary: Some("I agree with Ploum\'s stance on Richard Stallman"),
|
||||||
|
published: Some(Time(
|
||||||
|
year: 2023,
|
||||||
|
month: 6,
|
||||||
|
day: 20,
|
||||||
|
hour: 10,
|
||||||
|
minute: 43,
|
||||||
|
second: 35,
|
||||||
|
)),
|
||||||
|
tags: [
|
||||||
|
"freesoftware",
|
||||||
|
],
|
||||||
|
)
|
||||||
|
---
|
||||||
|
After reading Ploum's recent post about how Richard Stallman was right all along, I have to say that I agree with his take. This is likely going to be short, because I don't have much to say beyond what he wrote.
|
||||||
|
=> gemini://ploum.net/2023-06-19-more-rms.gmi
|
||||||
|
|
||||||
|
This might seem odd coming from someone who just posted about how sick he was of Linux and was moving back to FreeBSD. If only all of my choices were easily explainable in life.
|
||||||
|
|
||||||
|
I've found myself as I get older actually becoming more "radicalized" than I was in my 20's and 30's. I definitely feel like society lost it's way a long time ago. One of the things that I like most about Ploum's post is that he recognizes the larger parallels between society's ills and free/libre vs proprietary software. Everywhere you look these days you see that what used to be held in common trust is being carved up and divided among those who don't really need any more.
|
||||||
|
|
||||||
|
What if, when a house became abandoned, rather than ownership reverting to a bank, it was held in common trust? What if an enterprising person who decided to fix that house up and live in it was just allowed to assume ownership of it? Why does this seem like a ridiculous concept? The bank has no use for houses. Banks don't need to go home after their long workday and play in the yard with their dog, people do. Wouldn't the world be such a better place if this sort of thing was encouraged? There would be less abandoned houses becoming a problem for their towns, homelessness would have an obvious solution and people might not be so willing to sell their precious time just so that they could have a basic human need (shelter).
|
||||||
|
|
||||||
|
Our society in general values ownership too highly. In the US where I'm from we are perhaps the worst. I like the idea of reverting "property" back to the commons more and more, whether that be intellectual property or even inheritance. Obviously, if someone is currently using a resource then that should be respected, but when they die, or if they abandon it's stewardship, then that thing should revert to the commons, to be held until someone else needs it. In the case of knowledge, the idea of property and ownership is outdated and dangerous and should probably not apply at all beyond attribution.
|
|
@ -19,12 +19,21 @@ Some shorter thoughts and updates that might not warrant a full gemlog entry. I'
|
||||||
=> .. Home
|
=> .. Home
|
||||||
## 2023-06-21 06:22 UTC
|
## 2023-06-21 06:22 UTC
|
||||||
I was up late tonight, so I did some work on the Filesystem storage backend for Dory. Mostly writing tests, which caught a few bugs, but also implementing some missing functionality.
|
I was up late tonight, so I did some work on the Filesystem storage backend for Dory. Mostly writing tests, which caught a few bugs, but also implementing some missing functionality.
|
||||||
|
## 2023-06-20 17:59 UTC
|
||||||
|
Just subbmitted a PR for the `sc` crate which gives the ability to make syscalls from Rust on NetBSD/x86_64. If accepted, maybe I'll see about adding other architectures on FreeBSD and NetBSD.
|
||||||
|
## 2023-06-18 02:56 UTC
|
||||||
|
I managed to get the latest git source of Zellij to compile and run on FreeBSD, so no more faffing about with Tmux. Hooray! The fix for Zellij will be in the next release apparently. I had to apply a patch from the port to the `wasmer-vm` crate, as they're making some erroneous assumptions about not being able to support x86_64 on FreeBSD.
|
||||||
|
## 2023-06-15 15:00 UTC
|
||||||
|
So apparently the terminal multiplexer I've grown accustomed to (Zellij) isn't working on FreeBSD right now. Trying out tmux. Hopefully my muscle memory doesn't get in the way too much.
|
||||||
|
|
||||||
## 2023-06-15 04:08 UTC
|
## 2023-06-15 04:08 UTC
|
||||||
I decided to install FreeBSD on actual hardware again and had some interesting complications. I had a full gemlog post ready to go about it actually, but one of the complications lead to some data loss, so I'll have to put it all back together again.
|
I decided to install FreeBSD on actual hardware again and had some interesting complications. I had a full gemlog post ready to go about it actually, but one of the complications lead to some data loss, so I'll have to put it all back together again.
|
||||||
|
|
||||||
In other news, I've been forgetting to git commit/push/pull when updating this tinylog and had to clean up a bad merge earlier. No posts should have been lost, which is the great thing about putting it all into VC, but obviously my workflow needs updated.
|
In other news, I've been forgetting to git commit/push/pull when updating this tinylog and had to clean up a bad merge earlier. No posts should have been lost, which is the great thing about putting it all into VC, but obviously my workflow needs updated.
|
||||||
|
|
||||||
## 2023-06-10 13:55 UTC
|
## 2023-06-10 13:55 UTC
|
||||||
The latest Dory commits center around an iso-8601 time implementation, which is the format that `timestamp` lines are supposed to use in messages. The spec is of course a little ambiguous, and iso8601 allows dates in one of three formats, with the further distinction that there is both a `basic` formatting and an `extended` formatting, where the difference is the appearance of separators between the fields. I've decided for expediency to only implement `calendar` style dates, which is the traditional yyyy-mm--dd format that we're all used to seeing.
|
The latest Dory commits center around an iso-8601 time implementation, which is the format that `timestamp` lines are supposed to use in messages. The spec is of course a little ambiguous, and iso8601 allows dates in one of three formats, with the further distinction that there is both a `basic` formatting and an `extended` formatting, where the difference is the appearance of separators between the fields. I've decided for expediency to only implement `calendar` style dates, which is the traditional yyyy-mm--dd format that we're all used to seeing.
|
||||||
|
|
||||||
## 2023-06-07 20:36 UTC
|
## 2023-06-07 20:36 UTC
|
||||||
Today, after finishing a blog post, I wrote a parser to convert a `&str` to the `Message` struct in Dory. I also added a lot more test coverage, which revealed a few issues to fix.
|
Today, after finishing a blog post, I wrote a parser to convert a `&str` to the `Message` struct in Dory. I also added a lot more test coverage, which revealed a few issues to fix.
|
||||||
## 2023-06-06 18:12 UTC
|
## 2023-06-06 18:12 UTC
|
||||||
|
@ -36,6 +45,7 @@ The `sendmsg` binary (using Dory as it's backend) is now able to send Misfin mai
|
||||||
Just finished hacking together a small binary that sends Misfin messages from the command line using Dory. Time to grab the reference implementation code and start testing.
|
Just finished hacking together a small binary that sends Misfin messages from the command line using Dory. Time to grab the reference implementation code and start testing.
|
||||||
|
|
||||||
As an aside, I was thinking that client certs in theory should make identity spoofing next to impossible. That might mean that Misfin clients could just directly shell out to a sendmail-esque binary such as this rather than logging in to a remote server and sending their messages from there. Basically how email was always supposed to work, before all of the spam mitigations broke the ability to deliver mail from unknown random IP addresses. I mean, where you actually send from shouldn't make a bit of difference so long as your certificate goes with you.
|
As an aside, I was thinking that client certs in theory should make identity spoofing next to impossible. That might mean that Misfin clients could just directly shell out to a sendmail-esque binary such as this rather than logging in to a remote server and sending their messages from there. Basically how email was always supposed to work, before all of the spam mitigations broke the ability to deliver mail from unknown random IP addresses. I mean, where you actually send from shouldn't make a bit of difference so long as your certificate goes with you.
|
||||||
|
|
||||||
## 2023-06-05 14:55 UTC
|
## 2023-06-05 14:55 UTC
|
||||||
Began a proof of concept binary project to test out sending Misfin mail using Dory. I should be able to commence testing for interop in the next couple of days. Watch this space for progress reports.
|
Began a proof of concept binary project to test out sending Misfin mail using Dory. I should be able to commence testing for interop in the next couple of days. Watch this space for progress reports.
|
||||||
## 2023-06-05 04:25 UTC
|
## 2023-06-05 04:25 UTC
|
||||||
|
|
Loading…
Add table
Reference in a new issue