Restarting My Blog

It has been quite a while since I last posted here. I went through a period where I did all of my writing on [gemini](https://gemini.circumlunar.space/), and then in the fall of 2023 I started working towards a degree in Computer Science that took up the majority of my time (in conjunction with still working full-time).

Rust Criticism - from a Rustacean

I've been using Rust for a little over three years now and I absolutely love it. Rust makes good on a lot of it's promises. Rust makes highly reliable software, makes concurrency and parrallel code much easier to reason about, and will make you a better programmer even on those occasions that you write some code in another language. I could continue heaping praise.

Rust Build Systems

There was a recent [post](https://coaxion.net/blog/2023/04/building-a-gstreamer-plugin-in-rust-with-meson-instead-of-cargo/) that was linked to in This Week in Rust that delves into some experiments with building Rust code via Meson rather than Cargo. Meson is, for those who don't know, the officially blessed build system for Gnome which is written and configured in Python.

Jah Rule

Security is a multi-faceted subject in computing, and even amongst those who use Unix in one form or another there are disagreements about how best to handle various aspects of system administration. In today's blog post I'm going to be talking about the subject of controlled priviledge escalation, and in particular the presence of suid binaries on your system.

Leveraging Trait Objects

Making a multi-call binary is a neat way of sharing code between a number of small programs. Perhaps the most famous example is [Busybox](https://busybox.net) but there are others such as Dropbear (an ssh client and server) or BeastieBox. I once even wrote a multi-call shell script, which sourced a different file full of functions depending on the name it was called as. Today's project is inspired heavily by BusyBox but is written in Rust and has a somewhat more limited scope.

Another Rust Parser

Parsing text input is a common programming task. If you intend to write any kind of software, you are eventually going to be writing some sort of low level parser, because you just can't always count on having a library ready made for the task. For today's post, I'm going to take some lessons learned in writing the gemtext parser for [GemView](https://codeberg.org/jeang3nie/gemview), a few things you're likely to encounter a lot in C code, and write another parser in Rust.

Introducing Oxterm

Zterm has been one of my larger projects and by my reckoning fairly successful in it's original goals. I've enjoyed the project immensely, and learned a great deal along the way. However, writing an end user application in a pre-1.0 language while simultaneously working on the language bindings for the toolkit being used has presented some challenges, to say the least.

Rewriting Gemview's Gemtext Parser Part 2

In my last [post](../rewriting-gemtext-parser) I described the reasons behind and implementation of the new Gemtext parser for GemView. In the summary, I pointed out a few areas of "low hanging fruit" which might make for some nice improvements over both the old parser and the new in it's then state.

Rewriting Gemview's Gemtext Parser

When I first began the GemView project, I had chosen to use an external crate to handle most gemini related tasks, such as connecting to the server, retreiving documents, and parsing gemtext. GemView would only really have to handle rendering the parsed GemText. Or so I thought.

April Update

I've been quite busy code wise lately but haven't made time to post anything. Almost all of the recent work has been on Rust projects, and while I haven't abandoned Zterm, I'm becoming more and more drawn to the Rust ecosystem. It's just that good.

Handling Unsupported Protocols in Gemview

[GemView](https://codeberg.org/jeang3nie/gemview) is meant to be a generic and reusable Gemini browser widget, while [Eva](https://codeberg.org/jeang3nie/eva) is the browser built to leverage it. GemView can already handle surfing around geminispace using the gemini protocol, but you never really know what types of links are going to be found in Geminispace.

April Update

There's been a slow but steady march of progress on these two projects over the past week, and I think it's now at the point where I could say that Eva is, while still a wip, somewhat useful.

Gemini Browser Widget

The [gemini](https://gemini.circumlunar.space) protocol is a simple, text oriented internet communication protocol. I don't want to go into too much detail about what Gemini is, I'll leave that to the reader to research if interested. This post is about a new project to create a freestanding gemini browser widget for gtk4, much like webkit2gtk is for the web, and a simple, nice browser which leverages it.

The Case for a Modern Language

There is a difference of opinion among many programmers regarding the idea of replacing **C**, either in newly wrritten code or else altogether. I find myself coming down on the side that it makes little sense to try to replace a legacy codebase, and still find **C** useful in some contexts (particularly in the realm of microcontrollers). That said I think a strong case can be made for using one of the several more modern languages that have sprung up in the systems programming space, at least for newly written code.

Gfret 2.0 and Beyond

Here we are 2 patch releases in and I never did finish documenting the release of **gfret** or the finishing of the work. I'm going to keep this post brief and just summarize where the project stands and where it's heading.

Gfret Gtk4 Port Part 4

I took some time away from coding entirely over the past several months for various reasons including, but not limited to, a bout with Covid and it's after effects, spending more time with family, and a general burnout feeling.

Gfret Gtk4 Port Part 3

Earlier in the week, the preferences were brought back without too much trouble. I've taken some time to do a bit of extra work to the public API of the backend crate, `fretboard_layout`. Rather than storing colors as a string, we now save the individual RGBA channel values, and can do so using u8 or f64 storage types.

Gfret Gtk4 Port Part 2

## Current status At the moment the gtk4 port has acheived basic functionality in terms of being able to save the svg to disk and display the current filename and saved status in the window title. Templates are currently disabled, as are preferences. In summary, there's a few things left to get back feature parity with the Gtk3 version.

Gfret Gtk4 Port Part 1

Gfret was written originally as a CLI based program, later expanded with a gui which was originally in PyQT calling the Rust binary to do it's work, which I then changed to PyGtk due to some issues I was having with scaling the preview image in Qt. Eventually the scaling was solved and for a time, the program had both Gtk and Qt based gui's.