Nemin's Blog

Solar power

2026-04-11T10:38:00Z

1. The plan
2. Parts of a solar setup
3. My particular setup
4. The initial results
- 4.1. Shortcomings of the RIVER 3
5. A hasty, but needed upgrade
- 5.1. Shortcomings of the Anker SOLIX
6. Conclusion

I've been long fascinated by the concept of solar power. The idea of putting some weird blue plate in your garden or on your rooftop and getting free electricity sounds almost like a joke and yet, not only is it serious, it's a reasonably cheap project to accomplish as long as your requirements aren't super high.

That being said, I had a slight apprehension to messing with solar. Well, not even necessarily strictly with solar, rather with anything electric. My late grandfather was an electric engineer and he used to tinker on a small couple-dozen watts panel as part of his many retirement projects. I don't remember the exact details because I was very young, but I recall seeing a bunch of huge boxes and incomprehensible cabling, which put the subconscious idea into my mind that this is far too complicated for someone without a proper education in the field.

However, fate would see to it that just a couple of days before I started writing this post, nearly fifteen years after I was first enamoured with photovoltaics, I was reading the excellent LOW-TECH MAGAZINE's About the Solar Powered Website article, which details how they managed to wire up a self-sufficient Raspberry Pi(-like) based system as their server, which could, technically, run out of power if the weather was unkind.

What struck me as somewhat shocking is that the setup itself didn't seem all that complicated. Yes, there were several parts, including stuff whose purpose I wasn't aware of yet, but as a whole it seemed remarkably approachable.

This ultimately led me to the Youtube channel Footprint Hero, which features a guy called Alex Beale, whose entire shtick is to make easy to understand videos about solar power and how a complete beginner could start utilizing it themselves.

I was so impressed by how turn-key the entire process seemed based on his videos, that I became convinced that I want to try this stuff.

Disclaimer: I am a programmer by trade, not an electrician. While I have a generally decent understanding of software, hardware is a whole another beast and I am by all means pretty much a complete beginner. I tried to ensure my post contains correct information, but I cannot claim that I haven't made any mistakes in this post.

Please keep this in mind while reading and do your own research! It's well worth it, solar is a hella cool topic. Also corrections are very welcome in comments, if you find this post on social media.

1. The plan

Still, before jumping into doing things, one needs a reasonable target to aim for. Obviously, I wasn't going to just start filling my roof with panels and running my entire home off solar. Such a project would cost many thousands of euros, which I simply don't have, would require hiring a bunch of engineers and workers, and finally it likely wouldn't even pay for itself in a reasonable amount of time due to the solar-unfriendly laws in my country.¹

So, I decided to aim quite a bit lower. I have previously bought myself a plug-in watt-meter, mostly just out of curiosity to see how much power the different devices in my room use. The most interesting finding was when I noticed that my PC rarely seems to use more than 150-200W and, when I'm not using it for any strenuous tasks, it usually dips even lower into the 90-110W territory.

There is a law in place that mandates that below a certain threshold households pay a discounted price for electricity. We happen to be usually below this line, but sometimes things don't work out quite how we hoped and the meter creeps up slightly above the threshold. When this happens, the bill is suddenly a lot higher than it should be.

I figured, hey, if we only just go slightly higher every once in a while, perhaps by taking my PC out of the equation we could ensure we only ever stay in the discounted range.

The jury is still out to see whether my theory works in practice, but this was enough of an excuse for me to start looking into buying the necessary things to build a small system.

2. Parts of a solar setup

If you already understand how PV works, feel free to skip this part, I just want to get everyone up to speed first. To run a tiny solar system, one needs the following parts at the very least:

A battery: Stores excess energy in the form of chemical energy. Nowadays batteries are usually made from Lithium-ion salts and range from a couple hundred up to thousands of watt-hours worth of capacity.
An inverter: As solar panels generate direct current, while most appliances use alternating current, you need a so-called inverter which can turn one into the other.²

Figure 1: Schematic of an inverter. Notice how the path of electricity keeps turning around (i.e. inverting) with every switch. By C J Cowie - Own work, CC BY-SA 3.0.

Inverters use a set of transistor-pairs, which can be switched on and off extremely fast. By flipping between these at twice the speed of the intended frequency of the grid (50Hz in the US, 60Hz in th EU), the current is forced to rapidly switch directions, thus inducing an alternating wave, i.e. AC electricity.

Sadly this process is not 100% efficient. Generally inverter efficiency ranges between 85-95%, which means the true, useful capacity of your battery can easily be 15% less than stated in the specs.
A solar panel: Stars of the show. Generates electricity based on more or less the same principle as LEDs just in the opposite way. Did you know that you can actually use LEDs as an ad-hoc light sensor? I found it a pretty cool piece of trivia.

Photons radiated from the sun knock electrons free, which do a lap around the circuit the panel is wired into. This is usable electricity.
MPPT: Also known as a "Maximum Power Point Tracker". It is a small device that connects to both your battery and your solar panel and can, as the name implies, track the panel's maximum power point.

The maximum power point is the intersection of the ideal amount of voltage and current with regards to the solar panel's "Fill factor" (which basically quantifies the panel's quality) that provides the highest amount of usable power.

In an ideal world, where the panel is always in constant sunlight and isn't affected by temperature, this device would not be needed, as with those parameters frozen, the panel would generate a practically constant voltage and current (without regards to degradation, which would slowly worsen the output over the course of a couple decades).

However, realistically this is never the case. As seen on the graph below, the hotter a panel gets, the less voltage it's able to generate (see also the section on NMOT):

Figure 2: The current-voltage curve of my particular panel. At 50˚C it provides nearly 6V less voltage, than at 0˚C. Taken from the reference sheet.

What's worse the output also varies massively by how much of the panel is shaded. If you only used the raw output of a solar panel you'd find that even if only one or two of its cells were shaded, you would not only lose, say, 5-10% of your expected power, but up to a quarter of even half of it.

This is because the cells on a panel are wired in a shape kind of like a "string" or "pipe" and even a single shaded cell can act as a blockage in this "pipe", because not only do they not generate current, they also act as resistors and thus allow very little current to flow through them.

To prevent completely choking the circuit, modern panels have so-called bypass diodes built in, which allow going around entire rows of cells in case one of them becomes shaded.

While this allows for the rest of the panel to operate unhindered (and the shaded cell won't become damaged from the huge amounts of current trying to flow through), it also means that a single shaded cell can knock out at minimum an entire row, but with cheaper panels (which don't use nearly as many diodes) easily a third of the panel and thus drop the voltage considerably.

Figure 3: Power/Voltage curve of a solar system, with both shaded and unshaded curves. By Staberder - Own work, CC BY-SA 4.0.

MPPTs exploit Ohm's law. By utilizing a DC-DC converter, it can freely vary the apparent resistance (and thus the amount of voltage) of the system and, per the aforementioned law, a change in voltage will induce a change in current as well. By careful modification of these values, the MPPT ensures that the panel is always operating at the exact voltage that generates the greatest power and thus delivers the highest wattage based on the current conditions.

And as an added bonus, MPPTs can even account for things like the composition of your battery and make sure it only ever charges with safe parameters of input, as certain materials require vastly different "charge profiles" (i.e. mix of voltage and current) to operate safely.
Cabling and adapters: Solar panels generally use MC4 connectors. These are deep plugs, which slot tightly into each other, providing a good amount of insulation against water and dust as these panels and cables are expected to be exposed to the weather all year long.

However, power stations (see below) generally do not come with MC4 plugs. Rather they are most often equipped with XT60 connectors. These are easiest to recognise by their unique shape and yellow / orange coloration. From what I understand, these were originally made to connect car parts, but I couldn't really find any good sources on them.

Generally (unless you're doing things fully DIY, in which case you don't need this explanation in the first place) you will likely need an MC4-XT60 adapter and these are usually not part of the package. Some solar panels do come with them, but you're largely expected to pick them up yourself. From what I've found, they are surprisingly expensive.
Power station: If you don't want to DIY everything, you can also get a power station, which will serve as your battery, inverter, and MPPT at the same time.

On one hand going this route is much easier as you get a complete device that you just have to plug in and use. It is also far safer for a beginner, because you don't have to measure things out and make sure everything is properly grounded, insulated, and well integrated. Finally, you also get a warranty and even a couple of shiny toys in the form of a companion app that can allow you to monitor and manipulate the station from afar. This is the option I ultimately went with.

On the other hand, it's usually more expensive to buy a complete solution compared to building one from parts. I've seen videos where people mentioned that they can easily get double or nearly triple the capacity from building their batteries from scratch for the same price as a pre-built station would cost. You also learn a lot more this way and can swap out any parts if you want to upgrade, which is not something a complete station can usually accommodate.

3. My particular setup

With the basics out of the way, here's an itemized list of everything I've bought for this "experiment" / pet project along with my comments and reasoning for them. The list will start of small and get extended as new parts are introduced.

3.1. Power station

Item	Price (HUF)	Price (EUR)³
EcoFlow RIVER 3 Plus	107380	275
Sum	107380	275

My first purchase was an EcoFlow RIVER 3 Plus (which I'll refer to as "RIVER 3" for the rest of the post as it's a mouthful). This is a surprisingly cheap power station, that can consume 220W of solar power, which pretty much the highest I found in this price category. There are stations that can be charged with 300W or even as high as 1000W, but seeing how my PC rarely goes above 200W, I figured 220W should be plenty for the time being.

Note from the future: As it later turns out, it wasn't quite enough.

I'll touch on the "why" later, but first I'd still like to make it clear that I think the RIVER 3 is an excellent product if you don't have major capacity needs (you only really need an uninterruptible power supply or want to run minor appliances in places where you have no access to electricity) or if you are able to get good solar coverage for most of your day.

It's small, cheap, and has a quite impressive phone application with a lot of useful data and controls. Furthermore it's easily lightweight enough to carry around even in a backpack if you happen to need much more power than a powerbank could provide.

3.2. Solar panel

Table 1: Adding in my initial choice of panel.
Item	Price (HUF)	Price (EUR)³
EcoFlow RIVER 3 Plus	107380	275
220W Solar Panel	46790	120
Sum	154170	395

I was originally going for a 220W panel by VOLT Polska, since it felt logical that I should match my expected wattage to my power station's. I also liked, that the panel itself is relatively "small" (147x67 centimetres). The price itself was good too, at only around 120€, so I placed an order and started waiting.

However, not a whole day has passed and I quickly realized I may have been a bit too hasty. The more I continued to read about the topic, the more it seemed like it may not be such a good idea to perfectly match the two ratings, because you only really get 4-6 hours of max power. Which means the moment those ideal conditions pass, there is nothing guaranteeing my panel's output could keep up with the PC's requirements.

Figure 4: My current solar-setup. The panel stands on stacked bricks, with a piece of cardboard taking the brunt of its weight, so that the cables are unburdened.

Instead, I learned what one should do is to "overpanel". What this means is to find a panel (or multiple) whose voltage (and preferably current too) is within the limits and its wattage above the power station's maximum, so that even if the panel is operating only at a fraction of of its full strength, you're still getting as much power as your station can take.⁴

I am lucky enough to live in a home with a relatively large garden, so I had enough space for a much larger panel than I was originally going to go with. This is good news for my budget, because solar panels tend to have an inverse relation between size and price. This only makes sense: The more panels you can place in the same area, the more power you can generate.

Table 2: Swapping for the panel I ultimately went with.
Item	Price (HUF)	Price (EUR)³
EcoFlow RIVER 3 Plus	107380	275
410W Solar Panel	24999	64
Sum	132379	339

Because of this I was able to find a panel from RISEN Energy that is rated for a whopping 410W and which costs only half the price of the previous one at 64€. Excellent deal in almost all aspects, with the only ugly detail being that this panel is a monster in terms of size: 176x110 centimetres. A simple napkin-calculation tells me that it's almost 1.2m² bigger than the old candidate.

I'm not a big car guy in any meanings of the words, so I only drive an old 20+ years old Ford Fiesta. It's a tiny car, but I figured I don't need no shipping for my panel, "I'll just put the panel in the trunk and drive it home!" Yeah… A tip for future generations: A 2003 Ford Fiesta cannot accommodate a solar panel of this size.

Don't ask me how I learned.

3.3. Cabling

Item	Price (HUF)	Price (EUR)³
EcoFlow RIVER 3 Plus	107380	275
410W Solar Panel	24999	64
MC4-XT60i adaptor	9489	24
Sum	141868	363

I also found out that the RIVER 3 does not come with a solar cable, which was a little frustrating to learn, but I quickly found a store where such an adaptor is sold. It came in three different lengths, 2.5m, 3.5m, and 5m.

I ultimately picked the smallest, 2.5m one. Anything over that would've been overkill, since I was going to place the solar panel right next to my window anyway, which is right next to where I intended to store the battery.

Item	Price (HUF)	Price (EUR)³
EcoFlow RIVER 3 Plus	107380	275
410W Solar Panel	24999	64
MC4-XT60i adaptor	9489	24
MC4 "Super-Flat" cord	8080	21
Sum	149948	384

I also ended up buying a so-called "Super-Flat" cable, which allows you to run it under either a door or (as in my case) through a window-frame without needing to cut a hole.

Figure 5: The cable slips under the window's insulating foam, allowing for the window itself to stay closed.

It was a bit annoying to dish out another 20€ or so, but I figured if this whole thing doesn't pan out, I'd be left with a hole on my window-frame, which (even if small) would likely negatively affect the comfort of my room.

4. The initial results

It was late in the afternoon when I finally received all the necessary parts. I was very eager to try things out, but when we plugged everything in and I excitedly checked the RIVER 3's display, I was a little horrified to find that the panel (which, to remind you, was supposedly able to output 410W in ideal conditions) was only giving me a measly five watts. What's worse, I also saw some weird discoloration on the solar cells and the protective cardboard cover that the panel came in had a footprint on it, so I immediately started thinking of the worst. Not to mention how I'd get the panel back to the store.

Still, we figured it'd be worth waiting at least till the next day to see if the low power is just caused by the lethargic weather or if we really received a malfunctioning panel.

The night passed and during the next morning, to my great relief and joy, I saw that the station was charging at 30W and the amount was rapidly climbing in tandem with the sun. I messed with the panel's position and angle a little and soon enough (around 10-11AM) I started getting a constant 220W, the maximum the RIVER 3 is capable of receiving.

Figure 6: The RIVER 3 in operation at peak performance.

I waited until the power station was fully charged and then disconnected my PC and monitor from the grid and switched them over to the battery.

At first the PC didn't boot. Even after I pressed the button a couple of times, it seemed completely dead. This was a bit puzzling, but then I realized I just needed to turn on the station's "X-Boost" mode (which allows power surges of up to 1200W) and suddenly it sprang into life without issue.

My assumption is that during boot the PC draws in way more electricity and (without the special mode enabled) the resulting load may have been so large, that the power station thought it's an electric fault and blocked it with surge protection.

Table 3: My best-effort measurements over a day of (early spring) use.
Weather condition	Time of day	Minimum wattage	Maximum wattage
Direct, strong sunlight	9AM - 14PM	190	220
Early afternoon	14PM - 15PM	30	60
Cloudy / indirect sunlight	16PM - 17PM	15	40
Minimal sunlight / after sundown	17PM - 9AM	0	5

4.1. Shortcomings of the RIVER 3

Here's the list of negatives I've experienced using the RIVER 3:

While the mobile app of the RIVER 3 is far superior to the replacement I went with, I really don't like that it is an always online IoT device.

I'm not super paranoid or anything, nor do I necessarily think that someone could hack the home network through a power station, but it's still not really nice that it's always out there listening.

In an ideal world you'd have a physical switch whether you want IoT capabilities or not (the replacement has this) and pairing should work without any online account necessary, with purely local authentication (think the LED screen showing a code that you need to enter on your phone or similar).
Charging with 220W proved to be not nearly enough. While I do get many generally sunny hours, the panel is only in direct sunlight for a fraction of these.

Therefore, because only these hours provide the maximum power the panel is capable of, I am forced to utilize this period to get as much energy as I can. And the fact that my station "artificially" caps my panel at pretty much half it should be capable of kinda sucks and severely limits my daily net wattage.
But even if it was capable of collecting more from the panel the biggest bottleneck of this setup was the size of the battery inside the RIVER 3.

Much of the 220W was wasted at peak hours as the station was already fully charged and, once the low-light hours arrived, the battery's 268Wh worth of capacity could only power my PC for just about two hours.

Now, this didn't mean I was out of luck in the afternoon, because the RIVER 3 comes with a feature that allows the user to set a certain percentage below which the station switches over to mains. I set this to 30% capacity, to ensure whatever happens I still have some power left.

The rub was, however, that with this setup I wasn't fully "sun-sufficient".

5. A hasty, but needed upgrade

This didn't sit too well with me. The idea that I'd pretty much just waste a large share of the power I generate because the battery was too small felt like a half-victory at best and an annoying complete failure to accomplish my original goal at worst.

I quickly looked up how much it'd cost to get an expansion battery for the RIVER 3, but what I found to my horror is that it'd actually cost more than the base device itself. It goes without saying, that it would have also provided an almost 3x increase to my max stored wattage (bringing it from 268Wh to 840Wh), but at that point it genuinely felt like it'd make sense to simply look for a device that can both store more power and take more input from my panel at the same time.

Figure 7: The Anker SOLIX C1000 sitting on a tiny chair. It provides power to two PCs at the same time.

And, if I wanted to be that, there was little better choice (with my budget and circumstances anyway) than the Anker SOLIX C1000, which is a beast on a whole another level. Not only is its capacity near five times the RIVER 3's (meaning the Anker outdoes it even with the extension battery's additional storage), but it can also be charged with up to 600W of solar.

Obviously it's also quite a bit more expensive (costing about 2.5x the price of the RIVER 3), but at this point, I was pretty much all-in:

Table 4: Swapped the old station to the new one. Ouch.
Item	Price (HUF)	Price (EUR)³
Anker SOLIX C1000	240000	615
410W Solar Panel	24999	64
MC4-XT60i adaptor	9489	24
MC4 "Super-Flat" cord	8080	21
Sum	282568	724

Sadly this does mean I almost doubled my initial budget, but 725€ is still not exactly a major expense compared to a proper solar setup.

However, the changes are immediately obvious and almost all positive. Due to the size of the new battery, I'm able to run not only my own but also my partner's PC and by the station's own measurements, both should be good for nearly the whole day without accounting for the solar input.

Table 5: Results with the Anker SOLIX C1000
Weather condition	Time of day	Minimum wattage	Maximum wattage
Dawn	6AM - 7AM	50	100
Early morning	7AM - 8AM	150	180
Peak sunlight hours	9AM - 14PM	200	350
Afternoon / Past peak hours	14PM - 18PM	40	100
Minimal sunlight / after sundown	18PM - 6AM	0	10

A quick note about my results: Look, this is the n=1 measurement of a single guy living in Budapest, taking random samples of his solar setup in a single season and in a very short time period.

Please do not use these numbers to guesstimate your expected production / setup needs. Solar depends on a ton of variables, including sunny hours, placement of your panels, temperature, latitude, materials used, length of your cabling, quality of your inverter, etc.

My experiences might give you an alright idea what to expect, if you live in similar conditions, but that's about it. If you get a hankering for that sweet free electricity, please spend your first week just reading up on stuff (including laws) before jumping in. In the best case, you just gave yourself a huge head start, in the worst case you spared yourself a lot of headache and several hundred euros.

As for the solar, at the time of writing I was able to get a consistent 300W and above through the sunny hours, which is a night-and-day change compared to the 180W averages I've had with the RIVER 3. While it is still not quite the 410W you see on the tin, I'm not disappointed. As it turns out manufacturers generally provide two different metrics:

Output at Standard Test Conditions (or STC): Basically ideal, lab-made conditions where the panel can deliver as much power as it's able. Think measuring what power is generated when a very bright light is aimed dead-on a reasonably cold panel.

STC serves as a good measurement at the maximum possible output you can expect (this can be handy to pick the right wires and safety mechanisms) and it is the one number you'll definitely see on all solar panels, no matter their manufacturer or place of origin. However, it does not necessarily give a realistic idea about the panel's general performance.
Output at Nominal Module Operating Temperature (or NMOT): What STC fails to account for is that the output of solar panels has an inverse relationship with their temperature.

This means the hotter your panel gets (and it will get hotter, after all, the sun is shining on it all day long), the less power you'll be able to harvest.

Solar.com found that for every degree Celsius above 25˚C, your panel's efficiency will drop by around 0.3-0.5%. Which means on a hot summer, where your panel might heat up to about 35˚C, you can expect a 3-5% drop in efficiency. Considering most panels generally operate between 20-25% efficiency, this drop can be significant.

NMOT is the temperature which your panel is expected to reach under the conditions of 20˚C ambient temperature, slight wind, and 800W/m² irradiance. In my panel's case, this is 44˚C and the manufacturer reports a 0.34% drop in power per degree. Therefore, if I understand things correctly, I can expect a (44-25) * 0.34% ≈ 6.5% drop in efficiency at peak temperature.

By RISEN's own reckoning this means the panel will provide in general about 310W if I both get a ton of sunlight and high temperatures. Indeed, while I was able to get higher wattage already (even hitting higher than 410W for very brief periods), my general sustained peak wattage does seem to be around 325-350W.

Beyond the station itself, the package also came with a parallel-connection MC4 cable, so if I ever want to upgrade my setup by buying a second panel, that's one less item on the list. It's by no means a must-have nor is it nearly the most expensive part, but it's a nice gesture from the company, especially compared to the RIVER 3's bare-bones accessories.

In terms of non-solar charging, the station is able to be charged by a whopping 1000W using a wall socket (1300W if you enable "UltraFast charging", though the manufacturer warns against using it too much as it can harm the battery in the long run), which is a lot more than the RIVER 3's 600W and would charge a completely drained battery in practically an hour (and a bit, due to inefficiencies), which is excellent for its relatively large capacity.

I still intend to stick with solar-only (this was the main reason I switched in the first place), but if I'm ever in a pinch, this kind of charging speed could give me a serious second wind.

5.1. Shortcomings of the Anker SOLIX

This is, however, where the panel's not insignificant list of negatives start too:

You cannot set min-max values for the battery. These are a set of percentages below which the station automatically shuts its outputs down and above which it'll refuse to charge.

People usually set these to 20% and 80%, which give you ample usage, while also serving a dual purpose: The limit allows some leeway in case you are caught with your pants down in a blackout. Even if you were using your battery, you still have 20-30% to keep your machines on for a little while. The other reason is to protect the Lithium-ion cells, as both completely discharging them or filling them to full causes excessive wear.

Anker claims, that the second part is a non-issue, as the battery they use doesn't suffer from such limitations. However, if you happen to use your battery constantly like I do, you have to make sure yourself there's always enough juice in it in case a blackout hits. It's not a complete deal-breaker, but it's a bit of a shame.
You also cannot set the same "only charge from AC if the battery dips below X%" logic as with the RIVER 3.

I've seen posts that this was introduced in the Gen 2 version of the SOLIX C1000, but that's not the one I have and while they're similarly priced, I'm not too keen on sending yet another station back, paying even more, and then waiting for a new one to ship.

Not to mention the Gen 2 is also not expandable like the Gen 1 is, which would currently not be an issue, but if I ever want to upgrade, I would like to have the option.
The phone app's metrics are not nearly as informative. The RIVER 3 counted how many watt-hours you've used and how much you've charged back by type of input, which was perfect for my purposes of seeing how much electricity I can use without relying on the grid. Its charts were also a lot longer and higher-resolution, while the Anker's feels more like an afterthought / gadget to gawk at instead of something you could seriously keep an eye on.

In general, the app is a bit unreliable. The battery's status (percent charged and current input/output) updates slowly and gives no indication that the data you see is outdated. I've had instances where the app said the battery was around 80% charged, while the box itself said 95%. Similarly, the reported charge speeds can vary a lot too. It can take 5-10 seconds for the box to transmit new data and update to the real values, so I tend to just check the box itself.

I also had a couple weird disconnection issues, where I had to reset the box completely and delete then reconnect from the phone app to properly establish a connection between the two again.
The fan of the box is somewhat louder, especially when you hit peak solar hours and get performance above 300W. I wouldn't necessarily call it annoying (I don't even hear it in headphones), but if you need a quiet accumulator, because you either cannot bear a constant fan noise or your work requires silence, the RIVER 3 wins by a long shot.
The box is also large and heavy. Which is not really a surprise, nor is a fair comparison, considering the difference in capacity, but it's still worth emphasizing.

You can throw the RIVER 3 on your desk and it'll not take too much space, nor is it terribly heavy (at 4.5kgs). You absolutely cannot do the same with the SOLIX, as it's nearly 13kgs heavy and also the size of two shoe boxes on top of each other.

I'd still ultimately classify it well within "easy to carry around" compared to even larger stations, but it definitely requires far more planning where to place it compared to the RIVER 3.
Finally, the box tries to be very smart about the power it wastes, so whenever you're not using one of the ports, be it input or output, it automatically closes them down.⁵

This sounds great on paper, but during late dusk and early daybreak the panel has juuust enough sunlight to fluctuate between 0 and 1W. The station, being ever so diligent, switches its input port on and off whenever it perceives that electricity starts or stops flowing. And since these ports are isolated using relays which make an audible metallic pop with every actuation, you get about 20 minutes of rhythmic clicking which is both very grating in general and loud enough to wake me whenever I forget to pull the cord.⁶

Apparently this is known and "expected" behaviour. I intend to fix it by purchasing a circuit breaker (which will also serve as a convenient fuse to protect the battery) and just turn it off at night and thus prevent these blips, but I really wish this was as convenient as with the RIVER 3 which just completely avoids the issue by not reacting to such low inputs.

6. Conclusion

And yet, despite all these issues, I still think I made the right choice and, if my rough calculations are correct, I'll be able to save around 60-80kWh a month by driving the two PCs by solar.

Now, 60-80kWh might not be a life-changing amount, but considering that building and owning this project gave me a lot of joy and atop that it's paying for itself (even if extremely slowly) I think it was more than worth it.

Another interesting side-effect is that I'm feeling a lot more conscious about my PC usage. Now, I'm not expecting some miracle here, where I'll reconnect with nature and barely if ever turn on my PC, I am fairly dependent on my computer. But turning electricity from something you don't ever think about into something that I have a nominally "finite" supply of gives me at least some pause before turning it on and incentivizes me to take longer breaks to allow for the battery to charge more / faster.

Finally, I learned a lot about electricity while working on this post and project. While I did have physics classes both in middle school and university (also an actual electrics class in the latter), the materials there sadly mostly entered in one ear and left through the other. I don't think it was the fault of my teachers, more me being a bit too checked out to care. Now that I'm learning at my own leisure and interest, I find things are sticking a lot better and I'm building intuition for things I kinda-sorta understood on a surface-level before, but never to the extent to really comprehend what's going on. Physics is actually really cool!

Take care and thanks for reading!

Footnotes:

While the power company is obligated by law to buy your excess solar power, they only pay about 5 HUF / kWh. At the time of writing that is just barely above a single euro cent.

Assuming it'd cost about 10.000€ for a complete solar setup for a home (there are grants you can apply for, but for the sake of simplicity, let's ignore those) and about 40 kWh / day excess, it'd take you 68 years to make that money back without accounting for your power bill.

And if you do account for that (our household generally pays about 310-350€ a year for electricity) it'd still take 30 years to make your money back. Which far less terrible, but is still a far cry from the US's 5-10 years.

And if you're curious how to turn AC back into DC, look no further than FULL BRIDGE RECTIFIERS.

Assuming 390:1 HUFEUR exchange rate.

⁴

Every article about overpaneling will stress this and so will I:

It is generally okay to go over the current limit, because (besides malfunctions) your power station will only ever pull as much as it's able to and the rest is just wasted. Do consider fuses though, they're far easier and cheaper to replace in case of an issue.

It is NOT okay to go over the voltage limit. If current is "pull", voltage is "push" and it will push as hard as it can. Meaning at best you'll blow your station's internals and waste a bunch of money, at worst you'll burn down your home. Electronics are not a toy.

⁵

More specifically input ports are opened and close automatically always, while output ports are fully manual by default, but you can set up either one-time "shut it off after X hours" or general "shut it off after X minutes/hours of inactivity" timers for them.

⁶

Despite my annoyance, I'm more than glad that this feature exists, even if I think it could be implemented in a smarter way.

Solar panels can technically cause "backflow", meaning electricity flows backwards and is wasted through the panel in the form of heat and (invisible) light. By physically severing the connection, such issues are avoided.

I just wish they implemented some sort of exponential retry. I.e. if you freshly plug in something, it immediately latches and tries to start charging. If it finds power, then that's that. If it doesn't, it retries a second later, then two seconds later, then four, etc. until it reaches some sane upper limit or the user manually pulls out and reconnects the cable.

This would ultimately still allow patchy inputs, still protect against backflow and would solve the constant annoying popping.

Be aware of your Locale

2026-03-14T15:00:00Z

1. The problem
2. The solution

I happened to have reinstalled my PC recently. While I have set things up to pretty much out of the box, I have left one glaring omission which came back to haunt me (for a single afternoon or two, after which I've devised and quickly deployed a fix).

1. The problem

Note: This post will follow mostly the same path I took to investigate. Except a couple dead ends before I "figure out" the solution.

I was writing my previous article about getting LASIK, when I suddenly noticed all the Euro signs in the article were replaced with "???". This perturbed me quite a bit, chiefly because I would've found it really unbelievable to think that even a simple SSG like Haunt would not handle special characters properly.

And yet "that's exactly what happened" (obviously not, but bear with me for a moment): The encoding of the source code was correct. The parsed SXML was correct. The final HTML was not correct.

Now, I'm not exactly privy to the inner workings of Haunt. I have dabbled in its source, mostly to figure out defaults, but I haven't really dug deep. Because of that, I only had vague ideas where to start looking.

Based on the documentation for Readers, I knew whichever format you use originally, Haunt will first parse it into SXML and then render that SXML into HTML and write it onto the disk.

My first assumption was that it must have been one of the extensions I used. Ox-html stable IDs didn't touch the parsed output in the slightest and is so simple, that I figured it's unlikely it could be the cause.

I'm also using Jakob L. Kreuze's Org-mode reader for Haunt, which is quite a bit larger and more complex. But, after adding a debug print line and checking the output, the generated SXML was fine.

Okay, so the extensions are fine. Then it must be Haunt. By grepping the source code for sxml, I found a file called html.scm, that contains the following:

(define* (sxml->html tree #:optional (port (current-output-port)))
"Write the serialized HTML form of @var{tree} to @var{port}."
(define (write-escaped-string str)
  (define (escape ch)
    (case ch
      ((#\") (put-string port "&quot;"))
      ((#\&) (put-string port "&amp;"))
      ((#\<) (put-string port "&lt;"))
      ((#\>) (put-string port "&gt;"))
      (else (put-char port ch))))
  (string-for-each escape str))

;; <... The rest elided because it's not relevant ...>

Well, that was easy, right? The code just isn't escaping "€" right. Except, no, that explanation doesn't track in the slightest due to the else clause of that function. Haunt only escapes these four special cases, everything else is passed through as-is.

At this point I figured, well, I might as well try out this function. I fired up Geiser, Emacs's integrated Scheme REPL. Because I'm also using direnv and its accompanying extension for Emacs emacs-direnv, it automatically picked up the right version of Guile and also the right environment variables for me to be able to import Haunt's modules from the .envrc file found in the root of my site repository.

As my first attempt, I called the function with a very simple SXML tree:

scheme@(guile-user)> (use-modules (haunt html))
scheme@(guile-user)> (sxml->html-string '(html "€"))
$6 = "<html>\ufffd\ufffd\ufffd</html>"
scheme@(guile-user)>

It sure seems like sxml->html¹ is the problem, huh? Let's simplify it even further:

scheme@(guile-user)> (sxml->html-string "€")
$7 = "\ufffd\ufffd\ufffd"

With a sudden stroke of inspiration, I figured what if we drop sxml->html?

scheme@(guile-user)> "€"
$8 = "\ufffd\ufffd\ufffd"

A-ha! So the problem is in-fact Guile, not Haunt. On one hand, this was good, because I could rule out an entire project. On the other hand, now I fell into the even bigger bog of figuring what Guile was doing wrong.

One thing that struck me as odd is that not only were the files written to the disk off, I also noticed that the little arrows Haunt usually prints when copying files were also replaced by question marks.

Listing 1: An example of the little arrow.

copy assets/imgs/2026-03-10-lasik/drops.avif → /assets/imgs/2026-03-10-lasik/drops.avif

This already made me have a hunch, but the Unicode code-point \ufffd was also a glowing hint what was going. This character is called the Replacement Character, because it is what UTF-8 rendering software show when the character-code cannot be properly decoded.

Okay, so not even the terminal is able to encode things. Since I'm using Alacritty at the moment, which is a very modern terminal emulator, it not supporting something as basic as a Euro-sign was impossible.

2. The solution

And that was when I finally realized the issue: My locale was busted.

If you're using a mainstream distro (and haven't done anything overly fancy), you might not even know what a Locale is. In a nutshell, it's a set of rules that defines how locale-aware applications format things that differ on a language-by-language basis. Examples include dates (YYYY-MM-DD or DD-MM-YYYY?), fractions (1.5 or 1,5?), money, etc.

All of these rules are stored in locale files, which usually come pre-generated with your distro. However, if you happen to be using Arch (or one of its derivatives), you have to manually specify which locales you intend to use and then generate them, before they become usable.

If you forget to do this (like I have), your system will fall back to the "C/POSIX Locale". Here's a great quote I found on Stack Exchange to explain what it does (emphasis mine):

Stéphane Chazelas: The C locale is a special locale that is meant to be the simplest locale. You could also say that while the other locales are for humans, the C locale is for computers.

In the C locale, characters are single bytes, the charset is ASCII (well, is not required to, but in practice will be in the systems most of us will ever get to use), […] and things like currency symbols are not defined.

This explained everything. Now I only had to figure out how to fix it.

What followed was a long (and ultimately pointless) goose-chase, where I first checked how Guile handles locales, then how to make sure the locale is actually loaded, making sure my terminal was set to (what I thought was) the right LANG value, etc.

Nothing seemed to help, when I realized I haven't checked the most obvious thing: What language/region is set in KDE. I opened the settings, went to the right category, and I found it's set to British English, or en_GB.UTF-8.²

I did indeed want my PC to be using an English locale, but I only had en_US.UTF-8 and hu_HU.UTF-8 (my native language) enabled in my locale.gen file. Somehow, I completely failed to enable en_GB.UTF-8!

With some shaking of my head, I changed my locale to en_US.UTF-8, rebooted my PC, regenerated my site, and guess what, everything was working nicely.

Moral of the story? If your applications are behaving in silly ways when it comes to Unicode, your first assumption should probably not be that they're faulty, but that there is probably a misconfiguration somewhere along the chain.

I also must emphasise the boon that is FOSS again. Had Haunt and Guile been closed source programs, I probably would have had a far rougher adventure figuring out what's set badly… or I would have had to abandon using them in the first place.

Thanks for reading!

Footnotes:

sxml->html-string is basically just a wrapper around sxml->html, whose only purpose is to tie the output port to stdout.

I am genuinely unsure how this blunder slipped through. I'm fairly sure I set the right language in the installer (I'm using CachyOS, which comes with a graphical installer), but surely it's not the machine that made a mistake.

I got LASIK Surgery

2026-03-13T14:27:00Z

1. The issue that broke the camel's back
2. The breakthrough
3. Pre-op tests
4. The day of the operation
5. The day after
- 5.1. Checkup
6. Day 3
7. Day 4
8. Day 5 and Conclusion

I didn't exactly win the genetic lottery when it comes to vision. Both my parents wear thick glasses, my late grandparents were short-sighted too, and a lot of my relatives don't see super well either.

So it wasn't too much of a surprise to anyone, when I started watching TV from maybe a meter from the screen, that I most likely will need glasses too. I don't exactly remember my original prescription, but based the fact that I had to sit this close to see clearly means it probably was several dioptres from the get go.

Over the years my issues compounded. My myopia got worse, I was also diagnosed with astigmatism, and eventually also with strabismus divergens.¹ All of these were things glasses could mitigate and, for around 18 years of my life, that was fine by me.

However, by the time I was in my mid-twenties my eyesight worsened to -7.5 / -6.75 dioptres, with -0.75 cylinders on each eye. In practical terms, this meant that I was able to see clearly about 20 centimetres in front of me, after which the world quickly blurred into vague shapes and difficult to discern blobs. My glasses too grew thicker and thicker, my last pair having lenses that were easily almost a centimetre thick.²

Even this would've been fine, if not for…

1. The issue that broke the camel's back

Figure 1: Simulation of what I've seen. This effect is a type of Chromatic aberration.

I'm a frontend developer by trade. Not exactly a graphics designer, mind you, I still pretty much just bash rocks together until they look nice enough, but visuals are still part of my job.

Well imagine my shock when, during some project I'm not even wholly remembering anymore, I noticed that all the red and blue text on my site were a tiny bit misaligned. Not horribly so, a millimetre or two at most, but enough to bother me. What's worse, no matter how much I scoured my code, I couldn't find a reason for this discrepancy.

While different fonts can wildly differ with the same settings due to their inherent line-heights and such, the same font randomly floating higher or lower due to a colour difference sounded plain silly.

So silly in fact, that I started to see if I could find any other places where this happened. It happened on every other site I checked.

And, what's worse, nobody else I asked could see it!

I realized with some horror, that this was not an issue with CSS, nor even with my PC. The problem was with my vision.

I was a little devastated and a bit scared too. Bad eyesight is one thing. Sure, stuff is blurry and hard to make out, but reality is still reality. But having things move in impossible ways? That's a whole another ballpark and one I was not happy to be a member of.

And sure, we're talking about millimetres, but that's millimetres too much. I mentioned this to my local optometrist, but they couldn't really figure out anything, largely due to their lack of tools. I was running out of ideas when I noticed that if I take my glasses off, I could no longer see this issue.³

My feelings were twofold: On one hand, massive relief. "Thank goodness, it's not my eyes." On the other hand, I also felt a sense of disappointment and worry. Glasses were no longer wholly-reliable tools. From now on, they'd be their own potential cause of issues.

There were, of course, a couple of options to resolve this problem, such as:

Get glasses with thinner lenses: Prohibitively expensive. A set of good, mid-range glasses cost about 400€ where I live. This means a decent frame, moderately thinned lenses, maybe even a protective coating. Nothing fancy, but it also won't snap off your face at the worst moment.

"Good" glasses in comparison can easily cost 600 to 800€. Technically, I could afford this, having a programmer's salary helps a lot, but it just feels a bit too much for a device you most likely need to replace in 1-2 years anyway.⁴
Contact lenses: I'll be honest, I was never too good with touching my eyes. I hate eye-drops and I instinctively shut my eyes real tight whenever anything gets close to them. This, along with the fact that contacts aren't exactly the safest option long-term and the recurring cost kept me away.

I know normal contact lenses aren't that expensive, but because of how, erm, 'special' my eyes were, I couldn't just get off the shelf ones. They gave me a quote when I asked and said it'd be about 100€ / month for my supply, with no real option to involve social insurance.

Considering it would've cost me nearly 1200€ a year to get a pack of tiny disks to splat on my eyes, I was not rushing to get them.
Laser eye surgery: If you've read the title and description of this post, you already know this was my ultimate choice, but it wasn't one I've made easily.

This is partly my fault for not informing myself better earlier, partly my environment's, but I used to believe LASIK was still a much more primitive procedure than what they actually do today. My only second-hand experience was my grandfather, who underwent cataract surgery (which isn't even the same thing!), so I thought LASIK was all about doctors hacking and slashing your eyes until they can correct your vision.

Also, as is the common thing with all of these options, splurging around 2000€ isn't exactly something one does willy-nilly. Especially when the average person here makes about 1300€ post-taxes.

2. The breakthrough

For a while, I learned to live with this issue, always being slightly bothered by it, but never to the amount that I wanted a solution now.

That is, until I was doomscrolling on YouTube one night and I saw a video about LASIK. I'm not even sure why I got a recommendation like that. I don't tend to watch medical videos much (well, except for good old Dr. Bernard at ChubbyEmu) and especially not eyesight related stuff, but one way or another the algorithm figured it might be something I'd be interested in and morbid curiosity got the better of me.

The realisation was a little shocking, but I found out that not only is the operation a lot less gruesome than I thought, I was also not nearly as grossed out as I thought I'd be.

This sent me down a path of research:

I read a ton of posts on /r/lasik and (beyond a couple of bad cases) people were raving about the life-changing effect this operation had on them. I read a couple of medical journal summaries,⁵ watched videos of doctors talking about the procedure and read their comment sections. I also talked with some friends and colleagues who opted to do LASIK and they all sounded very enthused.

I also visited the "other side" to get a better picture, so I went to /r/lasiksupport, which is a subreddit dedicated to people who had problems with their eyes after undergoing the procedure. I admit, much of what I read there was daunting, but the sub also had an air of fanaticism around it, with people calling the surgery "mutilating your most delicate organ" and the doctors who do such procedures "butchers".

It's not that I want to dismiss anyone who had bad experiences. I'm sure many of the people writing there are genuinely distraught. My heart goes out to them and I hope their problems can eventually be fixed. I also don't believe LASIK is 100% safe, there is no such thing as surgery without possible complications.

However, what I read everywhere else simply did not add up with what I read on the sub. If LASIK truly was this horrifically dangerous and unpredictable thing, then surely it wouldn't have FDA or EU approval. I also read that there are a lot of lawyers and grifters that blew the rare unfortunate cases out of proportion and turned what started as healthy scepticism into straight up FUD for profits' sake, so I figured I can't really get an unbiased view of the potential dangers from non-professionals.

After a week or so of reading/watching/discussing the topic, I felt convinced enough to want to give this whole thing a shot. I started looking up prices and ultimately settled on a local clinic that seemed both "affordable"⁶ and quite reputable, as they claim to have completed 150 thousand successful operations and whom had a lot of positive reviews on Google Maps.

They also had a promotion that promised to forego the price of post-op consultation and even provide you with a reasonably priced set of sunglasses (a must, as UV rays can revert the improvement for the first three-six months), so I felt like it's now or never.⁷

3. Pre-op tests

I registered on the clinic's site and the next day I got a call back from them. I dictated in my dioptres and cylinder values, that I don't suffer from high blood pressure or diabetes, and that I'd like an appointment as soon as possible. They offered one two weeks from the time of the call. This matched what their website claimed (they explain due to the popularity of the clinic, it's unlikely that you can get an appointment with less than two weeks wait time), so I happily accepted.

As the nurses and the doctor explained, due to my severely bad eyesight, I had to undergo a "pre-candidacy" test. Meaning they needed to see whether it's even theoretically possible for me to undergo this surgery, so that nobody's time is wasted with the more involved tests in case it turns out my eyes aren't compatible.

Thankfully I passed this with flying colours. Hell, the doctor even remarked that my eyes are unusually thick. This is not really relevant in most areas of life, but for LASIK it's a huge benefit, because people with too thin corneas can only do a subset (or even none) of the surgeries.

There was, however, one issue and a big one at that. The doctor said that while LASIK can treat myopia and astigmatism quite well, it is completely ineffective when it comes to strabismus. She explained that while my glasses seemingly "fix" the condition, I still have what's called "hidden strabismus".

What this means is that even if it's not visible to the untrained eye, my eyes still slightly point in different directions and that, even if they make my other problems go away, it's simply caused by a different issue (a weakness of the eye muscles). She also said, because I wasn't treated for it when I was little,⁸ she cannot guarantee that I won't start seeing double once my glasses are off. Which is not only annoying, but also a source of migraine-like headaches as the brain is unable to properly comprehend the signals the eyes are sending to it.

Before I could go on to the actual in-depth eligibility test, I was asked to seek out a specialist that could inform me better about my chances and what to do in case my strabismus becomes permanent. I was lucky to be able to book an appointment for the very same day through my company's health insurance provider, so I didn't even have to pay for the examination.

The optometrist informed me that it is her belief, that since I can see fine with glasses, my strabismus issues should also be minimized if I undergo LASIK.

She also told me I'm lacking depth perception. This took me by some surprise, because it never really caused any issues and I always just assumed I had it, but apparently I don't. I asked whether this would affect me in any shape or form, she said if it didn't bother me so far, the LASIK won't affect it one way or another.

Having my worries assuaged, I applied to the second set of tests and got another appointment for next week.

The days ticked by in anticipation. While my initial results were promising, they were not enough to decisively say if I'm eligible or not. I had neither the resigned relief of knowing I stand no chance, nor the joy of knowing for sure that I am in fact able to partake.

Finally the day came and I went to the clinic to be subjected to a regimen of tests, some familiar, some completely new. They measured my glasses, my eyesight, the pressure in my eyes,⁹ and did some fancy 3D scans using machines that looked straight out of some tacky sci-fi show.

After all this was done, they applied pupil-dilating eye drops and re-did all of the tests as before. I must say, I never expected these drops to be this bad. I quite literally felt like the doctor splashed acid in my eyes. It stung and burned and I had to clutch the hem of my shirt to maintain my composure.

But at least it was done fast. And the result? Based on my measurements alone, I was in fact eligible to all potential eye surgeries: PRK, FEMTO-LASIK, and SMILE!

However, before I could get any choice paralysis, the doctor quickly ruled out PRK, saying with dioptres this high, it is unlikely that PRK could give me 100% eyesight.

We then also ruled out SMILE. Though it is technically more modern than FEMTO-LASIK, I was told that those who undergo SMILE treatment can no longer have corrective surgery in the future if their eyesight regresses and the procedure doesn't really provide anything over normal LASIK in my case.

While I do hope I won't need to ever get my eyes operated again, I don't want to risk going back to glasses in case the worst comes to pass, so I chose FEMTO-LASIK.

The doctor suggested clinic's robot-assisted version, which works by pretty much "sliding onto your eyes", compared to the traditional version, where a vacuum-ring is used to keep the eye taut. This variant is slightly more expensive, but comes with two great benefits:

One, your eyes won't get bruised, which is a common side-effect of the vacuum-rings. This is both quite ugly and I've read some previous reports where people claimed it caused them discomfort both during and after the surgery.
Two, as I mentioned earlier, my eyes instinctively shut really hard when I feel something approaching them. This can potentially dislodge the vacuum-ring, which can cause side-effects or the failure of the surgery.

With the plan worked out, I got my final appointment for the surgery set to a week from my visit. I was ordered to get a special kind of eye drops that promote tear generation and start using it three times a day for three days before the operation to make sure my eyes are lubricated enough to work on safely.

4. The day of the operation

I arrived early in the morning a bit nervous, but just as excited. My paperwork was taken, I had to read a legal disclaimer, where the clinic informed me of all the wonderful ways things could go wrong. It wasn't exactly a pleasant list and I do find it a bit grim, that you only get this paper when you're 95% of the way there already.

Obviously, it's done so that most people will say "screw it" and proceed, but if I were making the rules, I'd force companies to put this disclaimer front and centre. Informed consent should involve enough time and a neutral environment to make your choice.

Four signatures later, I was taken for another set of tests. The nurse explained that they work only with fresh measurements in case something happened between my last visit and now.

As iffy as I found the waiver above, in this aspect I'm very glad things work this way. While it might seem a bit tedious to have your tests taken three times, in my opinion it's better to do it more times and end up not using some of the measurements, than doing it less and ending up relying on out of date stuff.

This surgery is meant to last a lifetime (or at the very least quite a few years), so that half hour spent to make sure things are still valid and correct is well-worth it.

Figure 2: The glasses I chose.

I was asked to visit the clinic's glasses shop and select a pair of sunglasses for myself. The selection was a bit mediocre, I must admit. Most of the glasses looked plain silly and of the few that actually looked my style were almost all too small to cover my eyes adequately. Ultimately, I settled on a simple, black, medium-thick set of glasses. I'm not head over heels about it, but it's fine.

Next I was given a small Xanax pill, which helps both lower anxiety and also relaxes the eye muscles. I tend to shake my legs when I'm nervous and I was surprised to notice that, after at most five minutes, I calmed down enough to have my legs stop shaking. Soon they said it's time and I headed to the final waiting room, right outside the surgical theatre.

4.1. The moments before the operation

The nurse there gave me some plastic bags to cover my shoes, requested that I deposit all my belongings in a nearby box, put a surgical gown and hair cover on me, and then finally I was asked to sit in a large chair. There she administered numbing drops, then artificial tears, then washed the area with iodine solution to disinfect it. The numbing drops were horrible. They stung quite a bit (though thankfully not nearly as much as the pupil-dilating ones did) and I felt a sensation that I can only describe as my eyelids "wrinkling up". I'm sure no such thing actually happened, but that's just how it felt like.

Afterwards, I had to wait around 15 minutes for the surgeon to arrive. When that happened, I was given one final set of numbing drops and was ushered in to the surgery room.

I'd love to detail what I saw, but the reality of the situation is that I didn't see too much. The room itself was kept very dim, I was a little out of it from the Xanax, and I also wasn't seeing too well due to no longer having my glasses on and because of the numbing drops.

All I know is that I had to lay down on a big machine, surrounded by a bunch of people, then a nearby assistant helped prop my legs up with a triangular pillow.

4.2. The operation

Once I was settled on the bed, I was ordered to close my eyes and I heard something sliding in front of me. Someone taped down my right eye and I was told to stare intensely into the light above me. It was a small green light very out of focus. The machine slid closer and suddenly the light became very clear. A moment later I heard a screech of sorts and it looked like someone flashed a camera in my eye.

This was only an illusion. What really happened was the creation of the so-called "flap". An extremely fast laser activated and carved a small "lid" into my cornea. This "lid" is then used by the surgeon to protect the area underneath after it was operated on.

I was told to close my eyes, the tape was removed and then placed on my other eye and the process was repeated. Another "camera flash" later, I was told to close my eyes again and I was slid under another machine. One of the nurses placed a kind of "bag" over my head, which concealed my entire face, except for the single eye that was currently operated on. I figure it was to protect my head so that the laser could not affect anything but where it was intended to go.

I was asked to open my eye again and stare into another green light. What I saw was very unusual and my words fail to capture it correctly.

It was as if the lamp was under foamy water, which stirred and bubbled. In reality this was the laser ablating my cornea and reshaping it to be able to focus correctly. I felt a tiny bit of pressure, but no pain. Honestly, it was kind of mesmerizing and, despite all my initial worries, I was not afraid in the slightest. I also smelled hints of burning hair, which is not surprising considering our nails, hair, and corneas are made up of the same material.

The only negative part was the surgeon. She was very condescending and a bit rude, and she kept yanking my head around. I get that it is probably very stressful to operate on someone, but I am at the end of the day a paying customer, who is dazed and restrained, there is little point in using any kind of coercion when I was trying to cooperate already.

4.3. The moments after the operation

A few seconds later my other eye was also subjected to the procedure and we were done. Somebody grabbed my hand and guided me out to the waiting room, where I was sat in another chair.

The same nurse who gave me the drops appeared and removed my hair cover before giving me a glass of water, which I gladly gulped down. I had to spend around 45 minutes in that chair afterwards, giving myself eye-drops every fifteen minutes.

It must have looked very funny from the outside, but I kept staring at my hands. While my vision was still quite a bit blurry, I was shocked at how good I could see already. I was seeing details on my hands and in the room I couldn't with my glasses when I arrived.¹⁰

One thing I didn't anticipate, but ended up being quite annoying is that my nose started running real bad. I am not one to get too snotty usually, but after the operation I'm pretty sure I went through a pack of tissues in the first ten minutes. The nurse reassured me that this is perfectly normal and a common side effect of the eye (and thus the tear ducts) being messed with.

Aside from the nurse and me, there was also another patient in the room, who went in (and thus came out) right after me. We chatted a little to pass the time, he seemed just as elated as I was and mentioned not feeling anything at all. Lucky guy.

After the 45 minutes were up I was led into a side room, where a doctor checked me quickly. This was done with a very bright lamp, which was quite uncomfortable, but thankfully also very brief. I was told everything looks alright and that was that.

Once this was all done, I was allowed to go out to the reception. I was given a couple of instructions and a prescription, and I was asked to pay. Once we were done, I relinquished my glasses,¹¹ and with the help of my partner, made my way home.

4.4. At home

It was a little rough. I had to use artificial tears every fifteen minutes and also every hour anti-inflammatory steroid drops. Oddly enough my left eye was completely fine from the get go. It didn't hurt or itch or anything. My right one, however, was another story. There were three different kinds of sensations I felt. First it was the kind of itch you feel when your eyes are irritated by onions. Then it was as if an eyelash got into my eye. Then finally that too dissipated and I felt as if there was sand or grit in my eye.

I was told that my eyes would be vulnerable to bright lights for the first day, so I spent most of the rest of the day in a darkened room in my sunglasses, which made things a lot more bearable. Beyond the discomfort of the drops and the slight pain, I was remarkably fine. By the early afternoon I was even able to start using my PC,¹² though my vision tended to lose and gain focus randomly.

As the optometrist said my strabismus pretty much resolved itself. While this sadly doesn't mean it's completely gone (once my eyes got tired, they started diverging a little again), I didn't really have any double vision, nor headache.

The rest of the day went by fairly uneventfully. The last "exciting" thing was sleeping. I have been a stomach-sleeper all my life. Whether it's a physical or mental thing I'm not sure, but I was never able to fall asleep in any other pose. The problem? The clinic ordered me to sleep on my back and without a pillow.

Yet, despite all my worries, it didn't take me that long to fall asleep. I figure I was pretty exhausted from all that happened. As a precaution, I kept my sunglasses on while I slept. I figured I'd rather break it and pay another 100 or so€, than risk dislodging my flap and need another surgery.

5. The day after

I woke fairly rested and, luckily, with my glasses and eyes intact. There was a bit of itchiness in my right eye, which went away after I used my artificial tears.

Figure 3: My eye drops. Revihyal is artificial tears (with extra stuff in it to promote tear generation), while Tobradex is a steroidal anti-inflammation drops.

From this day forwards, I only have to use my steroid eye drops five times a day (with two hours in between each drop) and the artificial tears either hourly or whenever I feel like my eyes are dry.

It's really weird (though well-documented), but I experienced an almost complete reversal of how my eyes used to work. Whereas before I had trouble seeing farther than 20cm, now I am able to see quite far (several houses away) with abject clarity. At the same time, close things are slightly blurry and hazy.

It's evident that I still need a lot of time to heal before things can normalise. I also see a lot of halos around lights. It's not super bothersome, but I hope they'll too disappear in time.

My strabismus is also still almost completely gone, so I am fairly hopeful it will stay that way.

5.1. Checkup

I had my first checkup this day too. Apparently my flap is healing nicely and the doctor couldn't really see any issues.

My vision was measured too. Apparently it's currently 100% in my right eye and 95% in my left eye. Personally, I'm not so sure. I felt like the doctor was rushing through the procedure and not acknowledging when I struggled to properly read off the chart.

I'm not too worried just yet, because there will be four checkups in total, so I still have plenty of chances to complain or ask for advice, and (more importantly) the clinic claims that your vision only stabilises to its final and hopefully best state in three months. So expecting perfection on day two is simply unreasonable.

6. Day 3

On day three I finally gave "washing" my eyes a shot. What this entailed was boiling some water in the kettle, pouring a tiny bit into a bowl, soaking some fresh cotton pads in this water and then very gently brushing down my eyelids with top to bottom motions.

I am not 100% happy with the results as I was unable to get all of the gunk off (i.e. the drops that didn't go quite where they needed) from my eyelashes, but at the very least I was able to clean the area around my eyes.

It appears that my eye dryness has gotten a bit worse. I haven't really counted, so I cannot give an objective comparison, but I feel like I need more drops to keep my eyes lubricated. It's a bit unfortunate, but the good news, however, is that once I do put drops in my eyes, my vision improves even further.

The same cannot be said when it comes to the steroid drops. They cause quite a bit of burning and discomfort and I'm not quite sure how much I really need them, considering I don't have inflammation at all. I will continue taking them, because thinking you're smarter than your doctor is a great way to endanger your life, but I really hope they'll allow me to stop after the next checkup.

I had a couple of close-calls where things almost got into my eyes: Bedsheets, my shirt, hair, etc. I don't believe anything actually caused issues, but I'd be lying if I said it's not making me just a tad nervous.

I believe my light-sensitivity has improved. I obviously still keep my eyes out of direct sunlight (including keeping the curtains partially drawn as my PC is right next to my window), but whenever I look outside or venture out into the garden in my sunglasses, I feel a lot less discomfort.

My biggest issue so far is the halos I see when I look at the computer screen. Dark modes help mitigate the worst of it, but do not entirely solve the problems. I do see everything sharp, but everywhere where I don't focus has a kind of distracting "glow" to it.

7. Day 4

I woke early in the morning and, while taking a trip to the bathroom on autopilot, rubbed my eyes. I immediately started worrying because eye rubbing is one of those things they quite specifically mentioned that one shouldn't do in the first few weeks, but luckily it seems like I was gentle enough not to cause any issues.

I still feel a lot of itchiness in my eyes, leading to frequent usage of artificial tears. It's tolerable, but I'm hoping by the end of the week it'll go away on its own.

Funnily enough the procedure also forced me to learn to be able to sleep on my back. The doctor said after the first day you're allowed to once again sleep on your stomach, but I'm not taking any chances and are trying to sleep on my back as much as I can for the first week at least.

Day 4 was the first day I ventured outside for several hours. I am not quite sure how much the recovery was to blame and how much just came down to a random bad mood, but I found myself easily irritable and generally a bit down. I suspect the reason may have been partially due to me not being able to use my eye drops as much as I wanted, which led to my eyes drying out, that not only made my eyesight slightly worse, but also exacerbated the itch and general discomfort.

Once I was able to properly treat myself, most of these symptoms went away. I guess moral of the story is that keeping drops on you at all times during the early days of post-op is a very wise choice.

8. Day 5 and Conclusion

More of the usual. Itching eyes, some halos and blur, great eyesight at a distance. Using drops is as uncomfortable as before. As my experience seems to be stabilizing for the time being, I'm going to end this post here and summarize things a little.

In a nutshell, I am very glad to have undergone this procedure. I found it very easy to adapt to a non-glasses lifestyle, with only the occasional idle thought in the mornings about where I could've misplaced my glasses or reaching towards my shelf to put them on.

If there is one thing I could've done differently, it's probably going on a more involved eye-related diet. I'm thinking of taking stuff like Omega-3 fatty-acid and other eye-protecting supplements.

I also should have cut my hair before getting the operation. I have luckily avoided getting locks in my eyes so far, but the danger is always there.

One more thing that might have been good to figure out before going in was better methods at avoiding touching (near) my eyes. While I haven't had any flap-related issues, I had several close calls with clothing, bedsheets, me or others being clumsy, and general sleep-related exposure. Perhaps shelling out for an eye shield would've been wise. I'm hoping that, since nothing happened in the most vulnerable days, I'm past the worst of it, but with some additional planning more worries could've been avoided.

If you're thinking of also undergoing this procedure, please be sure to weigh your options carefully and talk with multiple doctors. Your eyes are a delicate organ and deserve as much care and protection as possible. I hope you learned something new and enjoyed your time with my article.

Thanks for reading!

Footnotes:

In less medical terms: My eyes couldn't exactly agree which direction to look, so (without my glasses to correct their behaviour) one was staring forwards, the other was always wandering about a little.

Look, I know that doesn't sound that much, but as you'll see from the next section, it caused more issues than one might think.

It's a bit embarrassing that I didn't think of this before. But, in my defence, neither did the optometrist and with how many defects my eyes had otherwise, it was well within the realm of possibility, that I could have this kind of refractive issue too.

⁴

Yes, I know there are people who can wear their glasses for 5-10 years. I'm not really one of them, because I'm both clumsy and have had eyes that rapidly worsened year-over-year.

⁵

I know the right approach would be to read the journals themselves, but I'm a lay person when it comes to such things and I don't think thick medical jargon would've helped me too much.

⁶

Again, we are talking about up to two or three months worth of average wages here. This is not a cheap surgery. But with it costing easily double-triple this price in other countries, I count myself lucky to have only paid around 2500€.

⁷

As it turns out I fell for the oldest trick in the book, though I'm not really mad about it. The moment this "timed promotion" ran out, they started another one with the very same benefits, just with a different end date.

I suppose the implied urgency and scarcity is not entirely ethical, but pretty much everyone wins with it (more customers for the company, an incentive for the consumer), so I'm not going to start clutching my pearls.

⁸

Apparently when you're about 6-8 years old, they can cover your stronger eye and force the weaker one to adapt. Once you're older than this window, you can no longer treat this condition in a non-invasive way.

⁹

Also known as the horrible "spits air in your eyes" machine.

¹⁰

Full disclosure, at the time of the surgery my glasses were already two years old and apparently almost a full dioptre weaker than I actually needed.

¹¹

The clinic collects glasses from patients, who no longer need them and gives them to those in need. I was happy to participate, though I'm not sure there are many people who could use glasses exactly like mine.

¹²

Before you get horrified at my irresponsible behaviour, this is actually recommended by the clinic so that your eyes can quickly start adapting to their new shape.

Guix System - One Month Later

2026-03-02T08:58:00Z

1. Community
2. Packaging wows and woes
3. System ups and downs
4. Conclusion

It's been about a month since I installed Guix System on my PC and now that I had some time to play around with it more seriously, I figured I'd record my additional thoughts, positive and negative, and why I ultimately chose not to stick with it.

1. Community

1.1. IRC

I am happy to report, that the IRC chat of Guix is both surprisingly active and very welcoming. I was able to join in and participate in discussions as a complete newcomer and I never once felt like people were ignoring me or valuing my opinion less due to my newness. This is excellent and a high standard for any other community to strive for.

My general impression was that there is plenty of good-hearted banter, people helping each other figure stuff out, people discussing their configs and such. Hell, I even got a few shout outs for my previous post, which was super encouraging as a new author.

1.2. Mailing lists

I feel like it's much harder to engage with Guix discussions on a longer-term scale. By this I mean that there are a few mailing lists, which seem quite active, but as someone who grew up after mailing lists were cool, they're a bit intimidating to me. This doesn't mean I cannot find my way around (with some effort), but it's definitely a barrier compared to having a conventional forum.

However, I recognise that this is a me / my generation problem and that likely for many others forums would prove just as cumbersome. Mailing lists are a very common thing in GNU/FSF related projects and, without even looking at the larger GNU projects and just by perusing the Guix archives, it's very clear that they're an effective way of communication, that requires no account and is compatible with a ton of configurations.

I just wonder if there could be a better way of handling them, that doesn't feel as daunting to people who didn't grow up with this form of communication. I think even something as simple as a bit of CSS applied to the online interface of the mailing list could make it immediately a lot more appealing, but perhaps I'm simply being shallow.

1.3. Subreddit

r/GUIX is not an official community, but it doesn't seem bad. People generally seem to only post questions, with the exception of the occasional screenshot of their config. It is a little barren, with only a couple posts a month, but Guix System is a niche distro and most communication happens on either the mailing list or IRC (or on the Codeberg issue tracker), which leaves only a small subset of people who are both interested enough in Guix too want to talk about it, but are also willing to put up with a closed and not exactly sqeaky-clean platform like Reddit.

1.4. Fediverse

Guix has a presence on Hachyderm, which is one of the more known Mastodon servers out there. I have little experience with the Fediverse (I've never even used Twitter much, which is the mainstream equivalent to Mastodon), but I'm glad that it exists. The account seems quite active too, the team running it is diligently sharing Guix-related posts and even makes some posts of their own.

They actually shared my own article on their page, which I'm super happy about. If you're reading this, thank you very much! Interactions like this make me want to look deeper into this corner of the internet.

2. Packaging wows and woes

After my success with packaging WezTerm, I decided to jump into upgrading some other packages too. These upgrades were mostly minor stuff, not really worth their own posts, but they did come with recurring issues and notes, that I figured would be worth collecting here.

2.1. I really love the go-getter attitude of Guix

You want to upgrade a package? Go ahead, do it. With the exception of trying to do something so big that it requires a team consensus or is so huge that it requires a dedicated team (think GNOME or KDE), nobody will say "That's not your authority!". You can just open a PR, get some eyes on your change and that's it.

At the time I was writing this, I was packaging the Odin language for Guix. Apparently nobody did it before me, their compilation guide seemed simple enough, so I went and did it myself. As someone who works in a corporate environment, this sort of freedom is exhilarating, especially since you're not just simply helping yourself, but all the other people who might want to try this language in the future and happen to be using Guix too.

This is very much unlike Nix, where every package has one or more so-called maintainers, who have first say in how a package is developed and upgraded. On one hand, this does provide a bit of accountability. People will feel stronger about keeping stuff up to date and tidy if it's at least superficially "theirs". On the other hand, it's yet another hurdle for those who would like to help out, but aren't yet in the maintainers list and it makes Nix feel more private than it really is.

2.1.1. A side-note about speed

The only real negative part of this whole contributing experience is the speed of reviews. There are PRs open from eight months ago. While such is not unusual in corporate environments (hell, make it years), I believe it's not healthy for a rolling release Linux distro, except in very specific cases (projects of such magnitude that you really need a year-ish time to develop them).

By the time people actually take a look at the PR, the project had moved on and is substantially different from when the PR was opened. At best this will result in headache-inducing merge conflicts, at worst the PR is no longer relevant, because some other development had obsoleted it. While I haven't experienced such myself yet, I bet it'd be a pretty disheartening feeling.

Now, I'll freely admit, my PRs so far had generally speedy review processes, so I personally don't have anything to complain about. My point more is that this is not a given thing, but rather something that comes down to the maintainers free time and available effort. And long delays can result from something as mild as some irritation to actual breakages (see the section about Thunderbird of this article).

This is nothing new though. The Guix team itself identified the slowness of reviews as one of the main things people find cumbersome about the project. This presentation is from a year, so hopefully the gears are turning in the background as I'm writing this and soon enough this problem will be a thing of the past. Until then, any prospective packagers should be aware that they are more than welcome, but they should also come prepared for long waits of up to a week or more, before their package is considered.

2.2. Debugging is an unpleasant experience

In my experience, errors messages in Guix are not very helpful. This is not super surprising seeing Guix is a massive build system built on a completely dynamic language, but regardless it makes debugging a real pain in the neck. Which is a shame, because one of the main selling points of Lisp(likes) is the fact that their REPL experience is unparalleled and that all other languages lag behind with their tacked-on / simplistic debuggers.

In Guix' case, while it is possible to use the Guile REPL to interface with the build system, so far I didn't find it useful enough to replace the basic "Edit in editor -> Compile in terminal -> Try to figure out errors" loop.

The three most confusing issues I've experienced so far were:

2.2.1. Missing parentheses

For this first example, I'll include the entire stack trace. In the other two, it will be truncated, but be aware that with each error we get this much on our screen.

  /home/nemin/programming/projects/guix/gnu/packages/guile-xyz.scm:7973:1: unexpected end of input while searching for: )
error: googletest: unbound variable
hint: Did you forget a `use-modules' form?

error: bzip2: unbound variable
hint: Did you forget a `use-modules' form?

error: libusb: unbound variable
hint: Did you forget a `use-modules' form?

error: make-lld-wrapper: unbound variable
hint: Did you forget `(use-modules (gnu packages llvm))' or `#:use-module (gnu packages llvm)'?

error: tcc: unbound variable
hint: Did you forget a `use-modules' form?

error: cross-gcc-toolchain: unbound variable
hint: Did you forget `(use-modules (gnu packages cross-base))' or `#:use-module (gnu packages
cross-base)'?

error: gnu-make: unbound variable
hint: Did you forget a `use-modules' form?

error: tar: unbound variable
hint: Did you forget a `use-modules' form?

error: gcc-toolchain: unbound variable
hint: Did you forget a `use-modules' form?

error: xdgpp: unbound variable
hint: Did you forget a `use-modules' form?

error: cross-binutils: unbound variable
hint: Did you forget `(use-modules (gnu packages cross-base))' or `#:use-module (gnu packages
cross-base)'?

Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f)'.
Backtrace:
In guix/status.scm:
    842:4 19 (call-with-status-report _ _)
In ice-9/boot-9.scm:
  1752:10 18 (with-exception-handler _ _ #:unwind? _ # _)
In guix/store.scm:
   504:37 17 (thunk)
   1119:8 16 (call-with-build-handler #<procedure 7f6d9e2ab390 at g…> …)
In guix/scripts/build.scm:
    646:2 15 (_)
   695:42 14 (loop _ _ ())
In gnu/packages.scm:
    512:2 13 (%find-package "haunt-next" "haunt-next" #f)
    392:6 12 (find-best-packages-by-name _ _)
   322:56 11 (_ "haunt-next" _)
In unknown file:
          10 (force #<promise #<procedure 7f6d9e306700 at gnu/packag…>)
In gnu/packages.scm:
   244:33  9 (fold-packages #<procedure 7f6d9d90b778 at gnu/package…> …)
In guix/discovery.scm:
   158:11  8 (all-modules _ #:warn _)
In srfi/srfi-1.scm:
   460:18  7 (fold #<procedure 7f6d9e3437e0 at guix/discovery.scm:1…> …)
In guix/discovery.scm:
   148:19  6 (_ _ ())
    115:5  5 (scheme-modules _ _ #:warn _)
In srfi/srfi-1.scm:
   691:23  4 (filter-map #<procedure 7f6d9e343680 at guix/discove…> . #)
In guix/discovery.scm:
   123:24  3 (_ . _)
In guix/ui.scm:
    365:2  2 (report-unbound-variable-error _ #:frame _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f))'.

Admittedly in this case it's not too bad, because Guile does actually inform you that a closing parenthesis is missing, but the error is still buried under a load of completely irrelevant error messages.

Additionally, if this happens, guix edit no longer works and you need to manually open the file that contains the issue and find the package. Not a big deal, but a bummer.

2.2.2. Non-existent variables

error: reversion: unbound variable
hint: Did you forget a `use-modules' form?

error: googletest: unbound variable
hint: Did you forget a `use-modules' form?

error: bzip2: unbound variable
hint: Did you forget a `use-modules' form?

<... a lot of other stuff ...>

It happened to me once or twice that I was either still referencing a variable that I previously cut or I made an accidental typo.¹

Just like with the missing parentheses, you technically get an error, but it's buried and blends in with all the other completely irrelevant errors (which are actually not even legitimate errors, they're just caused by the process buckling on itself).

Of course, it's hard to blame Guix here. There is no programmatic way of telling if the user was just silly or if there really is a variable somewhere in some yet unused module. But it'd still be so much better if the error stopped right after the first (and only legitimate) missing variable.

Also guix edit breaks as before.

2.2.3. Circular dependencies

This one in my opinion is the most problematic common issue a package author might face. Chiefly because the error message you get in this case is not even useful:

error: gcc-toolchain: unbound variable
hint: Did you forget a `use-modules' form?

error: xdgpp: unbound variable
hint: Did you forget a `use-modules' form?

error: cross-binutils: unbound variable
hint: Did you forget `(use-modules (gnu packages cross-base))' or `#:use-module (gnu packages
cross-base)'?

Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f)'.

<... a lot of other irrelevant junk ...>

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f))'.

The untrained packager might start pulling in stuff like gcc-toolchain or xdgpp, not understanding why they even need these or start poking around (gnu packages freedesktop) to no avail. As far as I know, there is no good method for figuring out what is causing a circular dependency beyond good intuition and bisecting your code until you find the culprit.

I've struggled quite a bit with this while packaging Hare 0.26.0 and, while I did manage to solve the issue I faced there, I wasn't extremely happy with the solution:

(build-system hare-build-system)
(native-inputs
   (list scdoc
         (module-ref (resolve-interface '(gnu packages hare)) 'harec)
         qbe))

In this instance, as you may have guessed, harec is the culprit. I'm still not 100% on all the details, but I believe the problem is caused by hare-build-system pulling in the hare module (which harec belongs to) and so when we're trying to import it in the package definition, it can't work out the right order.

Whatever's the reason, the solution isn't super difficult, but it is also not exactly obvious. Firstly, we need to get the module "behind Guix's back":

-- Scheme Procedure: resolve-interface name [#:select=#f] [#:hide='()]
        [#:prefix=#f] [#:renamer=#f] [#:version=#f]
   Find the module named NAME as with ‘resolve-module’ and return its
   interface.  The interface of a module is also a module object, but
   it contains only the exported bindings.

Next, we need to extract harec from it:

-- Scheme Procedure: module-ref module name
   Look up the value bound to NAME in MODULE.  Like ‘module-variable’,
   but also does a ‘variable-ref’ on the resulting variable, raising
   an error if NAME is unbound.

What we're ultimately left with is the same as if we simply imported the module normally and then put harec into the list. The trick here is that the various inputs Guix takes (including native-inputs) are thunked. This means the code inside these forms isn't immediately run, but is instead delayed to a later moment, unlike the build system which is already resolved during the start of evaluation.

In effect, by only ever referring to harec in a thunked environment, we've completely side-stepped the whole "where should we import the module" problem by forcing the package definition to wait.

I'll freely admit that I would have not figured this out had there not been many other packages whose authors have faced this exact problem before and before the kind help of tinystar, who guided me towards targeting the native-inputs instead of my original idea.²

2.3. A cornucopia of styles

Guix is a very flexible system. This is usually a great thing, because the last thing you want is your build system to constrain you from including a package that otherwise fits into the repo. However, this also bring with itself the fact that (beyond what the linting script offers) there is little guidance on how your package should be organised.

This shows up both in small and big things. A good example is that the order of fields in the package definition is arbitrary. People generally put name first, but there is nothing actually stopping you from putting it last. Sure, this probably wouldn't pass peer-review, but with other fields, the situation is far less obvious.

For instance, should you introduce all static metadata first or should you go by the usual order and put arguments before the description and license? How do you break lists aesthetically? Do you use (arguments (list stuff)) or (arguments `(stuff))?

And then there's the even larger differences:

Path construction: When it comes to constructing paths,
Listing 1: Do you use format?
```
(format #f "~a/path/to/bin" #$output)
```
Listing 2: Or string-append?
```
(string-append #$output "/path/to/bin")
```
Listing 3: Or perhaps in-vicinity?
```
(in-vicinity #$output "path/to/bin")
```

Code repetition: When installing completions,

Listing 4: Do you spell out each shell?

(with-output-to-file bash-file
  (lambda _ (invoke "binary" "output-bash")))
(with-output-to-file zsh-file
  (lambda _ (invoke "binary" "output-zsh")))
(with-output-to-file fish-file
  (lambda _ (invoke "binary" "output-fish")))

Listing 5: Or do you just delegate it to a for-each-match-lambda pair?

(for-each
 (match-lambda
   ((file-name . command)
    (with-output-to-file file-name
      (lambda _ (invoke "binary" command))))
   '((bash-file . "output-bash")
     (zsh-file . "output-zsh")
     (fish-file . "output-fish"))))

Environment variables: If you need to set environment variables,

Listing 6: Do you make a whole phase just for this purpose?

(modify-phases %standard-phases
  (add-before 'build 'set-environment
    (lambda _
      (setenv "VAR1" "VALUE1")
      (setenv "VAR2" "VALUE2")))
  (replace 'build
    (lambda _ ...)))

Listing 7: Or do you use setenv inside the build phase?

(modify-phases %standard-phases
  (replace 'build
    (lambda _
      (setenv "VAR1" "VALUE1")
      (setenv "VAR2" "VALUE2")
      ...)))

Post-processing: If you need your built binary for post-processing (e.g. installing completions, generating extra files, etc.),

Listing 8: Do you call it from your build folder?

(let ((bin "./build/folder/your-binary"))
  (invoke bin "postprocess"))

Listing 9: Or your output folder?

;; Also, do note that the whole previous debacle of which
;; path joining method to use still applies!
(let ((bin (string-append #$output "/bin/your-binary")))
  (invoke bin "postprocess"))

Listing 10: Do you even call it straight or do invoke it indirectly to account for cross-compilation?

;; Taken from gnu/packages/rust-apps.scm, "just" package
(let ((just (if ,(%current-target-system)
                (search-input-file native-inputs "/bin/just")
                (string-append out "/bin/just"))))
  (with-output-to-file
             (string-append bash-completions-dir "/just")
             (lambda _ (invoke just "--completions" "bash"))))

I'm sure there's a lot more, but these are the stuff that I personally experienced. The issue is that for most of these you might feel like one or the other is the obvious answer, but if you scroll through the package definitions, I'd bet money on it that you'd find multiple examples of all of them.

Now, don't get me wrong, I'm not pointing fingers at anybody. Guix is a volunteer project to which hundreds, if not thousands of people contribute to. You cannot expect perfect coordination from so many people, especially volunteers who might just want to see X or Y package in the registry and don't necessarily care about digging super deep into how things work. Not to mention, having ten different similarly good ways of doing something is a known Lisp curse. When you have barely any syntax and very convenient tools to mess with ASTs, all hell breaks loose.

But I think it'd still make sense to codify some basics at least. Have a given order where package fields should go. If someone strays from this, have them justify it with a solid reason. Give pointers on divisive styles like the examples above, providing reasons why Guix recommends one over the other.³

This would serve two important purposes:

Firstly, with less noise in the code, it'd be much easier for everyone to study the code, make changes, and review others' changes. Mundane code beats smart code when it comes to working together and with Lisp(likes) one already needs discipline to write "standardised" code.
Secondly, with these things codified, newcomers would have one less thing to be stumped by. I was so surprised when during my first PR my usage of string-append was replaced with in-vicinity, not only because I had no idea that this function existed in the first place, but because I was working based on another package where string-append was used and didn't even consider it's not the only option.

2.4. ChangeLog is confusing

I briefly touched on ChangeLog in my WezTerm post, but I wanted to bring it up again, because despite my best efforts at trying to build "muscle memory" for it, I still feel nearly as lost as I did at the start.

Okay, that's not entirely fair. I was able to get the provided Emacs's yasnippet templates loaded, which automate some of the tedium that comes with the ChangeLog commit message style. I've also been made aware that there is a file under etc called commiter.scm, which practically writes all the boilerplate for you.

However, it's not really the tedium that bothers me. If ChangeLog were really just a very rigid and verbose system where each possibility is set in stone and obvious from a glance, I probably wouldn't mention it or, hell, maybe even would have put it in as a positive.

But that isn't the case, because where these templates cannot help is the nuanced parts. It is not entirely obvious how involved you need to make your commit messages and, even from my very limited experience, it differs greatly between maintainers who accepts what.

For instance, with Rust applications you are expected to import all dependencies into the registry. So far so good. But how does one reflect this in their commits?

For one, you must include your note about the crate import in the same commit as the one that introduces your package. This goes against the usual convention where each change gets their own commit, but (while I don't remember it mentioned in the guide) it's obvious enough to figure out based on a quick git log.

What's far less obvious, however, is how to phrase this import. To keep everyone in the loop, an entry in a ChangeLog-formatted commit message looks like the following:

An asterisk to denote a new entry,
The name of the file that was edited,
Then the name of the variable / function that was edited in parentheses,
Then, only if what you were editing is a struct with multiple fields, the name of the field in square brackets,
Then, if said field has its own sections, the name of the section in curly brackets,
Finally, after a set of colons, you add a short textual description of what you've done.

For example:

* foo/bar/baz.scm (example-struct)[section]{subsection}: Frobnicated some walruses.

Now that we're on the same page, let's try to construct a line like this for our Rust imports. The start of the line is easy: * gnu/packages/rust-crates.scm. But what comes right afterwards and especially in the description field is nontrivial and wildly varies between authors.

From what I can see, there are two bigger schools of thought:

* gnu/packages/rust-apps.scm ($PACKAGE): Init at $VERSION.
* gnu/packages/rust-crates.scm (lookup-cargo-inputs): Added imports.

This variant only records the essentials. "We're handling $PACKAGE, which is a Rust application" and "We've imported a given number of crates". The pros of this is that it's extremely short and simple, and it conveys intent without going into the details. The con is that it doesn't mention anything about which crates exactly were imported.

And that is exactly what the second variant focuses on:

* gnu/packages/rust-apps.scm ($PACKAGE): Init at $VERSION.
* gnu/packages/rust-crates.scm ($CRATE1, $CRATE2, $CRATE3, ...): New variables.

This is the polar opposite of the first version. Very specific, clearly spells out what crates were imported into the registry and at what version, and fits more into the usual commit message schema.

On the other hand, it occasionally produces monsters like this:

Figure 1: This goes on for four more pages, by the way.

In my personal and, indeed, just as subjective opinion, Variant 1 is the clear winner. The point of a commit message is to convey intent or, as the ChangeLog manual puts it:

ChangeLog Concepts: People can see the current version; they don’t need the change log to tell them what is in it. What they want from a change log is a clear explanation of how the earlier version differed.

Yes, spelling out the whole list is "clear" in a certain sense, but since these crates were imported by a script and (beyond a couple of cases) aren't really touched by human hands, I believe the only relevant thing worth recording is that the importing process happened.

But, while I have laser-focused on a single pain area, it's not the only place where disagreements like this happen. I've been given recommendations to rephrase several of my commit messages and it's not that I'm lazy to do this (in fact I've followed this advice most of the time), I just feel like the system is both rigid enough not to be very pleasant to use, but also loose to be truly automated.

Again, Guix is a very flexible system, so maybe this "looseness" is actually a sheep in wolf's clothing. Better this than constant overrides in case the rigid system doesn't quite cover all the needs of maintainers.

3. System ups and downs

While the previous section was about my experience with packaging stuff, this will be about using others' packages.

3.1. Stability of my config

One thing I found interesting is how stable my config files ended up being while using Guix. Beyond the occasional addition to my home configuration, I found that I didn't have to touch my system config file at all.

While this is obviously partly because I already experimented a bunch on NixOS before finding the right subset of applications that I need to be productive, I also feel like Guix is generally the less fiddly system of the two (in this particular aspect).

Even more notably, I haven't had to touch Shepherd, Guix System's service manager once yet. Everything Just Works™, including changing over to PipeWire (my preferred audio server), which is both very well documented and only required a couple of lines in my home config:

Listing 11: All you need to switch over.

(service home-dbus-service-type)
(service home-pipewire-service-type)

If everything was this simple in the Guix world, I'd have nothing to complain about. This is a gold standard.

3.2. Interfacing with my phone

I wanted to move some files from my phone to my PC. On every other distro I've tried before, all this took was plugging it in and clicking on "Mount filesystem". Or, perhaps if it was a more frugal distro, I had to issue lsblk, find the right disk drive, and manually mount it at a folder of my liking.

With Guix System, I was unable to do this. I plugged my phone in, KDE Plasma offered to mount it. I clicked on it and all I got was a really confusing error. Finally, after quite a bit of digging on Google, I found a topic on the Arch Linux forums where someone mentioned kio-extras and kio-fuse. By adding these to my profile, the phone was finally able to connect.

This particular instance wasn't a huge ordeal, but it is an annoying paper-cut, that makes Guix System feel slightly less polished. I believe the existence of a "Guix Wiki" (in the spirit of the Gentoo and Arch wikis) would help a lot in situations like this.⁴

3.3. Blunderbird

I generally use Thunderbird (or, since Guix doesn't provide Mozilla-branded binaries, Icedove) to handle my mail. It's a far more pleasant process in my opinion than constantly having a tab open in your browser.

Well, as it turns out an update recently broke Icedove, because it implicitly relies on the other Mozilla-packages being the same version. Because of this, none of the build servers were able to build the package. This ultimately resulted in me being unable to update my system (without removing Icedove), because the moment I tried, Guix would notice that there is no pre-built package and began building it on my PC.

This would be fine in most other cases. I do have a 12 core Ryzen CPU and 32 GBs of RAM,⁵ so it's not like I don't have the hardware usually. However, in this particular instance, even such mighty specs failed to cope with all of Icedove's dependencies (I believe it's webkit-gtk that fails specifically, but I'm not 100% sure), so after my PC crashed twice trying to update, I decided to try to pursue different avenues.

My first attempt was using GNOME's Evolution mail client. No luck. No matter what I tried, it couldn't connect GMail using OAuth2 and all the errors I've got were very cryptic.

Fine, whatever, I use KDE Plasma anyway, so why not give KMail a shot? I installed KMail and…

Well, that's annoying. Neither the link, nor the button worked. I tried looking up what's going on and was led to believe the issue is caused by another dependency named akonadi missing. It's packaged in Guix, so I added it to my profile, reconfigured the environment, restarted KMail and… Nothing. Still the same error.

A bit more investigation later, I found that running akonadictl status should give me a bit more insight:

So it's unable to connect to MariaDB (which I've also added to my profile off-screen). At this point I was kind of stuck and abandoned this experiment.

I don't know, maybe there was an easy solution and I was merely a step away from making KMail work, but manually pulling in 5-6 dependencies for an application on a declarative distro is kind of above my tolerance. I get that not everything can work out of the box, but this style of debugging fits Slackware⁶ a lot more than it does a modern Linux distro.

Well, with the obvious alternatives ruled out, I was left with figuring out what to do with the Icedove situation. At the time I started writing this article, the fix was yet unmerged⁷ so there were only a couple of options someone who uses the package could take:

Not update:
- Pros: Requires no actions.
- Cons: No upgrades until the situation is resolved.
Remove icedove from your profile:
- Pros: Very simple to do. You get other upgrades for everything else.
- Cons: You have to use another method to manage your mail. As seen above, if you don't want to use the browser route, this isn't necessarily an easy process.
Use an Inferior: (a.k.a. instruct Guix to pull in an older channel's package)
- Pros: You still have Icedove (even if it's an older version) and upgrades for everything else.
- Cons: Requires tracking down the last commit that still worked, setting up the inferior, and then eventually removing it once the upgrade is done.

Ultimately I chose option #3 and made an inferior for Icedove. In this instance, it was thankfully super easy to find the last good commit, because someone else already did the dirty work. Despite the warning in the manual, it didn't even take particularly long to compute the new Guix derivation.

On one hand, I suppose it's another praise towards Guix's flexibility to be able to "patch" the package lookup with an arbitrary older (or even completely separate) channel. Doing so on a traditional, imperative package manager would be a giant pain.

On the other hand, it's an unfortunate situation to see a mainstream application breaking people's systems and no urgent action being taken for nearly a week, when a PR is already ready and waiting.

This is, of course, the blessing and curse of a volunteer project. Just as you can jump into any task that you fancy, nobody is obligated to check out your work, which can (in unfortunate cases, such as this) cause disruptions.

For some more positive news, this seems to be going to be at least partly addressed soon as Guix is considering a grant system, which would financially support certain developers working in key areas.

3.4. NVIDIA drivers and non-LTS kernels

Massive disclaimer here: This is a Nonguix "issue". And in-fact it's not even an issue, it's more just a case of "things could be explained much better". Still, it was something that caused me quite a bit of pain and if I can spare only one other person from experiencing it, it was already a win in my book.

After one of the updates, my system started being unable to properly start up my desktop environment. I was able to get to GDM, enter my login info, press login, and then it'd either hang there or I'd get my windows stuck in the top left corner, without any of the usual Plasma UX decorations.

Thankfully, as Guix is a generation-based declarative distro, I was able to roll back to an older version and have a working PC, but I found it really annoying that no matter how much I upgraded my system, it never quite seemed to help.

I was quite close to giving up and going back to Nix or some other distro, when I finally found a lead. By reading the dmesg logs, I found out that the problem was the kernel module not finding certain functions:

Listing 12: This is not my exact kernel logs (source), but I saw the same error messages.

[   95.122493] nvidia: loading out-of-tree module taints kernel.
[   95.122503] nvidia: module license 'NVIDIA' taints kernel.
[   95.122507] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[   95.122508] nvidia: module license taints kernel.
[   95.595636] nvidia-nvlink: Nvlink Core is being initialized, major device number 508
[   95.596880] nvidia 0000:01:00.0: enabling device (0406 -> 0407)
[  101.074782] nvidia_drm: Unknown symbol nvKmsKapiGetFunctionsTable (err -2)
[12407.716914] nvidia_drm: Unknown symbol nvKmsKapiGetFunctionsTable (err -2)

While this didn't quite solve the issue yet, it gave me a vital pointer, leading back to the Nonguix README. I gave the NVIDIA section a closer look and lo, the culprit was found:

nonguix-transformation-nvidia [#:driver nvda]
                              [#:open-source-kernel-module? #f]
                              [#:s0ix-power-management? #f]
                              [#:kernel-mode-setting? #t]
                              [#:configure-xorg? #f]

Return a procedure that transforms an operating system, setting up
DRIVER (default: nvda) for NVIDIA graphics card.

OPEN-SOURCE-KERNEL-MODULE? (default: #f) only supports Turing and later
architectures and is expected to work with 'linux-lts'.

S0IX-POWER-MANAGEMENT? (default: #f) improves suspend and hibernate on systems
with supported graphics cards.

KERNEL-MODE-SETTING? (default: #t) is required for Wayland and rootless Xorg
support.

CONFIGURE-XORG? (default: #f) is required for Xorg display managers.  Currently
this argument configures the one used by '%desktop-services', GDM or SDDM.

Use 'replace-mesa', for application setup out of the operating system
declaration.

Can you see it? If not, here's the line of note: "and is expected to work with 'linux-lts'". Yup, that's all the warning you get that "if you use the usual linux package as your kernel, it can crash on you at any time."

Obviously, this doesn't mean that the Nonguix team hasn't done their due-diligence. After all, the solution is there. But I definitely think it'd be worth a stronger emphasis on the fact that you can and will break your install if you don't use the LTS kernel with a newer card / open-source driver.

I'm also certain I'm not the only one who fell for this as there is already an issue on Nonguix' Gitlab, where the ticket opener's phrasing strongly implies they had to figure out the linux-lts solution themselves as well.

3.5. No easy way of seeing what is updated

One thing I sorely feel is missing (though Nix is no better in this regard) is the fact that there is no easy built in way to see what upgrading will do to your system.

There are approximations, sure. You can either pass --dry-run to Guix and get something along the lines of work items. There is also a new project by LiterateLisp's author Wilko, which allows you to diff two derivations, which is super cool and I hope one day it'll be upstreamed into Guix proper, but (unless I massively misunderstood things) it's a tool for after the fact. That is to say this only tells you what changed once the update is done.

Now, of course, there is an argument to be made that, due to the way declarative distros work, you don't really have to care what's what version and it's not a huge deal to just roll back if you're not happy with the changes. But every imperative distro manages to give you a list of "here's what's gonna happen" and give you a choice if you consent to the upgrade or not, and I really miss it from here.

3.6. Sleep causes crashes

I don't know if it's me doing things wrong or the driver not being good enough or something completely different causing it, but I am unable to use the Sleep function of the PC. The moment I press it, the PC freezes and requires a hard restart.

What this means is that, if I know I need to go away for some time, I either leave things on (which wastes a lot of electricity) or I turn my PC off (not a huge deal, but a bit more inconvenient than just continuing from where you've left off).

It's not exactly a vital feature, but all previous distros I've used had this working out of the box, so Guix System struggling with it is really unfortunate.

3.7. Odd freezes and crashes

I cannot effectively quantify this, but Guix System doesn't really feel stable in my experience. In this ~1 month of use, I've experienced at least 4-5 spontaneous freezes and choppy performance while not doing anything particularly strenuous on the PC, which does not inspire confidence when it comes to working uninterrupted.

I had freezes during listening to Youtube, browsing files in Dolphin, writing text in Emacs. Usually these issues went away on their own after a while, but not only does it make me worry that something (physical or digital) will end up damaged, I also get completely thrown out of my flow state.

I definitely can't rule it out that some (perhaps even all) of these were caused by the notoriously finicky NVIDIA drivers. But it is the unfortunate reality, that I cannot swap GPUs for the sake of a distro, no matter how much I like it and none of the other distros I've tried had produced instability this bad before.

4. Conclusion

On a conceptual level, I love Guix and Guix System. I much prefer writing Scheme over Nix's language and I really like that there is far lesser of a divide between the builders and the package definitions.⁸

I also love the low barrier of entry when it comes to contributing to the ecosystem. I'd wager Guix might be one of the easiest distros to have packages accepted for, if you have a bit of Scheme experience and are willing to oblige the maintainers.

But, and I'm sad to say this 'but', both still feel unpolished to me. Ever since I've grown accustomed to Linux in a way that no longer makes me want to distro-hop, my journey was always about finding a distro that maximises stability and package freshness, and settling for it.

Guix System sadly neither fulfilled the stability (due to all the crashes), nor the freshness (due to many of the packages lagging far behind upstream) in the way I was hoping for and I am unlikely to stick with it much longer. I will likely still have Guix present on whichever distro I go back to, but for now I'm buying out of the GNU dream.

Now, I don't want to sound entitled and talk down a project I'm otherwise very much aligned with. I recognise the gargantuan effort that went into getting things this far, especially considering that Guix isn't just aiming towards x86 and ARM, but also to be a host and accelerator for HURD. I also recognise and respect that most of this effort was accomplished with no monetary gain expected and on what is considered (at least in corporate terms) a shoestring-budget.

Even more importantly, things aren't happening in a vacuum and, while Guix's current state didn't prove to be quite what I was looking for, it doesn't mean it's not going to continue developing. Not only are they pulling in fresh funds to fund infrastructure and projects, there's also a lot of ideas floating around how to make things better.

I will only bring one example, but it will be comprehensive: The Shared Cryptpad of Guix Days 2026. This is the loose log of a couple of brainstorming sessions of Guix veterans and core developers, which touches on a massive amount of potential ways to make Guix more approachable including:

How to manage secrets declaratively (this is not simple even on Nix),
How to communicate between the teams better,
How to introduce breaking changes in a way that won't cause pain for everyone,
Bringing a new GC to Guile, that should speed everything up (especially multi-threaded code),
What they could learn from Nix,
How to make the substitution situation better,
How to automate PRs,
How to make package breaks rarer and how to respond to them quicker,
And (this was the one I found most interesting) thoughts about breaking with the GNU hardline: The possibility of enabling installing firmware in the installer, breaking the self-imposed wall between Guix and Nonguix, and even vaguely alluding towards the option of dropping the GNU label as a whole, while still retaining their best qualities and the commitment to free software.

The list goes on. Obviously, all of these exist only as ideas and plans so far, but the important part is that the maintainers aren't sitting on their laurels and doing nothing. They're smart people trying their best to make Guix an even better experience than it already is.

I wanted to end my post on a positive note, especially since much of my post has been anything but. Even though Guix System as it is today didn't quite live up to my expectations, I have no doubts that in a couple years time, if the project continues with this fervour and dedication, it will be a very serious contender. Perhaps still a niche one, because its commitments to Scheme and only free software severely limits its audience, but a well-polished and incredibly powerful system for those that can live within these bounds.

In fact, I've read some comments of people who have been using Guix System for over a decade. You cannot get that amount of dedication, if you yourselves (i.e. the maintainers) aren't dedicated yourself, and Guix's clearly are. I wish them nothing but the best and it's not like I'll completely remove myself from the project's orbit, as I still have a couple packages I'd love to see merged and I'm still interested in the project's future developments.

Thanks for reading!

Footnotes:

At work I happen to use Django, which has an extension called "reversion". It allows reverting objects in your database to a previous revision. Pretty clever name, but it burnt into my mind so much, I accidentally mixed up the two.

I immediately went gung-ho and put both harec and qbe (which doesn't even cause a dependency issue) into hare-build-system.

In hindsight, while I can justify my actions (my reasoning was that harec and qbe are used by the compiler, therefore it makes sense to have them present in the build system), it wasn't the right course of action.

Especially because this issue only really came up with a single package. Just like with any other project a big blast radius has to make sense. In this case, it didn't.

Obviously the best would be if the guix lint script was able to identify and fix these, but let's be real, making a script to rewrite an arbitrary input to something that conforms to a given output is a fool's errand.

⁴

In the strictest sense there is already one or rather two. There is Libreplanet, which has a Guix page, but it's pretty much only used by direct maintainers for storing information that doesn't directly belong in the Guix Manual. For the sake of completeness, there is also the System Crafters Wiki, which at the time of writing hasn't seen any contributions in two years.

⁵

Before you ask, my toilet isn't made from gold. I bought my sticks before the price increase for a third of what they cost now… I'm not rich, just lucky.

⁶

No disrespect towards Slackware or its users. It's a very cool distribution and the fact that it is still going strong is nothing short of impressive. But it's "do it yourself" approach is exactly the opposite of what I'm looking for in a declarative distribution. In an ideal world, your entire setup would be a couple files of Scheme code and you'd practically never have to "figure things out".

⁷

The fix was ultimately merged after six days and I have since removed the inferior from my install.

⁸

In Nix, you're expected to write Bash snippets in your build stages with some rudimentary substitution of variables provided by the system. This works, but is (in my opinion) far less ergonomic or elegant than Guix's all or nothing approach to Scheme.

LLMs Are Taking the Joy Out of Our Lives

2026-02-11T16:50:00Z

1. Job
2. Hype-driven death march
3. Art-robbery
4. Post-truth society
5. We're burning our planet for… this?
6. I'm not fully innocent, but at least I care

This website does not, will not, and has not willingly used AI for its creation. I write every word myself and rely on traditional methods to publish it to the internet.

That means I correct my spelling using Hunspell in Emacs with its convenient flyspell-mode checker. I do not generate pictures for my articles, I either create them myself or take them from the Internet with proper credits.

Obviously, I use tools like LSPs and linters gratuitously, but I write the code I present in my articles by hand. I don't even look at AI output.

If I don't know something, I go on the internet and search. If that doesn't work, I go to a community and ask. You'd be surprised how kind and helpful people are, if you show them a modicum of politeness.

Note: This is a largely unedited rant. You've been warned.

1. Job

I don't like AI. Not because I feel like it's endangering my job—even though for many others, including people I hold dearly—it is a very real possibility. I am embedded nicely into my team and my manager is level-headed enough to understand you cannot pass off our job to a machine and expect things not to collapse eventually.

I don't like it, because the code produced using LLMs are at best laughably bad tangles of over-complicated boilerplate and cookie-cutter repetition of code that could very easily be DRY-d. At worst they generate a simulacrum of what a person might write, causing your intuition (trained on how real people think and what real people write, and which would otherwise help you catch bugs and issues) to become unreliable.

And with how much less effort it takes for an AI to spit out a thousand lines, than it takes a person to review said thousand lines, we have no chance of inspect code with nearly as much care and scrutiny as before.

Projects, both professional and hobby-driven, are suffocating under vibe-code pushed onto them both by people meaning well and people intending to profit. Because of the aforementioned ease of generating more code and how convincingly AI can masquerade as a person, the ever-increasing load of dealing with the crap-deluge is added atop the already thankless workload of these contributors, wasting valuable hours and manpower. cURL may have been the first, but it sure as hell won't be the last.

The solution? Just use AI to filter out the AI! This is untenable. Models made specifically to suss out LLMs written text aren't at all reliable. With code you have even less to rely on, because professional code generally doesn't have "character".¹

So we're left with rudimentary tools, like:

"All PRs above X thousand lines are blanket banned",
"PRs committed by an LLM are blanket banned",
"PRs where the author, after a lengthy questioning, cannot answer questions in a satisfying way are banned".

It's an awkward cat-and-mouse game of developers chasing down more and more convincing models and conniving people, while the reliability of code isn't improving at nearly the same rate.

And this is just programming. In many companies CEOs and boards are using AI as an excuse to lay people off:

Oh, who needs a new generation to replace the old one? We'll just do it with the AI!

And when that old generation ages out and there's nobody to train new people, what will happen then, huh?

Oh, but AI won't make everyone jobless, you'll just be able to do 20 people's job alone!

First, that's bullshit. Second, you can be grateful it's bullshit, because the job market is already terrible. Imagine if suddenly there were 20x less jobs. It'd be catastrophic.

A friend of mine studied visual arts. After many years in university, he entered a job market, that no longer had a need for him. He wasn't a "pro" (despite being skilled), so he had no foot in the door. And he couldn't become a "pro", because all the jobs he tried to apply to declined, saying they'll just use GenAI to make stuff! How do you build a portfolio that way?

He had spent a couple years living off odd jobs and now is re-educating himself as a programmer. While I'm glad he found something else that also interests him, I think it's still tragic he wasn't able to get work doing his dream job. Potential greatness dying at the feet of "eh, good enough."

Or there is that funny story where a business owner didn't bother to hire customer support. Their AI offered a customer an 80% discount. In this instance, the owner was extremely lucky, because they weren't obligated to fulfil the order, but imagine if they were. We might intuitively think a chatbot's responses aren't legally binding, but why not? If companies think they can offload customer complaints to these bots, surely they are created to offer only company-sanctioned information.

2. Hype-driven death march

I don't like AI. Not because I'm a Luddite², I'm not. For most of my childhood and early adult years, the march of technology was something I beheld in awe.

I was born right before smartphones as we know them today were a thing. I saw mobiles go from bricks to hand-held supercomputers. While this too has its own detriments (unchecked social media exposure has made the childhood experience much more stressful than it needs to be), it also brought with itself undeniable benefits.

A minimal smartphone nowadays is affordable to just about anyone, who isn't completely destitute. It won't be fast, won't do most of the stuff a top-of-the-line model can, but it can give you access to a lot of things. Banking, applying to work, handling your communication (both synchronous and asynchronous), entertainment, even security through 2FA/MFA.

Smartphones are indeed so convenient, the idea of life without them is almost unthinkable to many of us. Whether or not that's a good thing is arguable (and you can probably argue towards "it's not" easier), but what nobody can deny is that smartphones are an utter financial and cultural success.

With AI, meanwhile, companies are still figuring out how to even make it profitable. You know, when it's actually AI and not just An Indian. It's not particularly good at coding, you cannot trust important choices on it, because someone has to be responsible for them, it cannot really innovate, just repeat variations. Last year OpenAI lost $11.5 billion. Things are fine, trust us. And all that keeps this bubble of kinda-sorta-works-trust-us cycle alive is five or so companies slipping money into each others' pockets.

When this pops, and I frankly see no possibility that it won't, everyone will suffer. Maybe it will be another 2008 even. My tech ETFs are 25% up since I bought them a year ago. That kind of growth is unnatural and I dread the day the debt catches up or the investors wisen up to the ploy. I'm sure many of them already have, but it's more profitable to keep up the charade.

3. Art-robbery

I don't like AI. Not because I'm good at art. I can barely draw stick figures. For people like me, Generative AI is supposedly a boon and the great equaliser that allows even us to materialise our dreams.

Except all of these models were trained on artists who did not consent to their works being chewed up and regurgitated in a thousand different, yet eerily similar ways, losing all the emotion and originality, that these people poured into each and every piece.

And then there's all the authors, whose books were scraped and fed into LLMs. That resulted in a lawsuit or two, yes, but the damage is already done. You cannot exactly "untrain" a model. You can only put safeguards and rules on it, that clever people will always be able to dodge.

And even if you could selectively remove all this knowledge from them, who in their right mind would? In this rat race, only the smartest, most knowledgeable AI wins, everyone else loses big. Sans comprehensive governmental crackdowns, no company would willingly cripple their own chances. And governments won't crack down on it, because then other, less copyright-concerned countries' AIs will take the lead. That does not make the line go up.

Art is an inherently sentient thing. I originally considered saying it is a "human thing", but there are instances of animals making art too. The loftiest art-piece down to the raunchiest fetish-art is all made because someone wanted someone else to feel something. The actual art-piece may not appeal, but the sentiment is universally beautiful.

So when you delegate this to a machine, that has no understanding of anything more than "what pixel usually goes next to what other pixels", everything you make is hollow. It might be very technically impressive (though, it wasn't you who impressed, but the machine), but there is no intent behind it.

I feel nothing, but disgust when I look at AI "art". It's always the same. Shrimp-Jesus, hyper-sexualised big tiddy anime waifus, diabetes-inducing sugary-cute animals with eyes as big as fists, comically obese people falling through glass bridges, buff gigachads with glowing red eyes telling you that you're not sigma. I will not bring examples, I'm sure you've seen all of these already. Just writing this list down makes me exasperated.

4. Post-truth society

I don't like AI. Not because I'm not tired of Google giving terrible results or because I enjoy digging into ancient threads that much. I don't like it, because you can never be quite sure if what you're reading is true or not without putting in your own research and that the LLM will go out of its way to convince you to trust it.

I can begrudgingly accept that chatbots can be a good springboard, if you have no idea how to start researching something. By demanding sources and justifications, you can get by, perhaps even achieve more than if you were left to use Google alone.

However, many people think it's a miracle-machine and trust its output blindly, leading to at best embarrassment, at worst death. AI struggles with the 'r'-s in "strawberry". LLMs will swear functions that never existed are parts of API-s. People, places, events, just about anything can be hallucinated. Chatbots melt into sobbing messes, if you ask about seahorses. It drove a man to drink Bromine and nearly end his own life.

Hell, forget about "nearly", there is now a list on Wikipedia to count the amount of suicides and deaths attributed to LLMs. At the time of writing fourteen people could be still alive. AI is not just a tool to kill people, but also to make the living more miserable.³ But trust us, just 50 billion more parameters and it'll be perfect!

And even when things don't end so grimly, AI is still a tool for radicalisation. It has never been easier to make up legit sounding hogwash. Claude, give me a 200 page PDF about how my political opponent will bankrupt old people, raises taxes to unprecedented levels, and send off all young men to war. You think that's a ridiculous example, it happened in my country.

Old and/or tech illiterate people not only have no idea if what they're looking at is legit or not, they might not even realize it's a question that needs to be asked. Ten-fifteen years ago something happening on video was either legit or very obviously fake. The few hoaxes that reached the mainstream were memorable exceptions. Today generating stuff that's not outrageously obvious and can easily fool many is an everyday occasion.

Even I get occasionally fooled and that terrifies me, because I'm supposed to be tech savvy. Technology is my livelihood. I've been banging bits together since I was eight years old. And yet every once in a while my judgement lapses and I read a comment or watch a video, and I don't spot the obvious. The whiplash I feel when other comments inform me that I was engaging with slop without knowing is always stinging.

5. We're burning our planet for… this?

I don't like AI. Not because, it's the sole cause for climate change. It existed before AI. Arguably AI isn't even the biggest contributor, global shipping and the private flights of billionaires probably cause magnitudes more problems than Joe Schmoe asking the magic answering machine if he should invest into NFTs in 2026.

But the fact that we're wasting perfectly good land and, far more importantly, perfectly good water to waste on dystopian giga-complexes for AI loads that haven't even materialised yet, while also shipping off nearly all future RAM and GPUs for these same hypothetical AI loads. Now that both baffles me and infuriates me.

This is pure line-go-up mindset. Tomorrow be damned, today we have to shovel a few extra cents into $NVDA. Meanwhile, from June to August, we can barely go outside for a few hours, because temperatures are more often closer to 40°C than they are to 25°C. When I was a child (and I'm in my mid-twenties at the time of writing this, I'm not exactly old!) winters had snow for weeks. Summers were balmy, but never asphalt-melting hot.

Is providing more means of generating zero-views slop really our first priority? Is that really what we need right now?

6. I'm not fully innocent, but at least I care

I don't like AI. And yet, strictly at work, I do occasionally use AI-enabled code completion. Or sometimes make the AI generate me boilerplate for unit tests, that practically any templating system could also generate, just perhaps a bit more rigidly. And every couple of months I toy around with the freely available models online and run a few queries out of curiosity. And for that, it's fine.

I cannot hate people for wanting to use a tool, nor would I want to. It's a shiny toy, with some uses (albeit with caveats). My problem is with this dogged insistence on growth towards some vague faraway goal that seems to shift between AGI, replacing workers, enhancing workers, enhancing processes, replacing processes, etc. ad nauseam. It's gross, it does nothing but generate profits for a very tiny fraction of people out of thin air, while also causing pain on several scales. And it's just plain emotionally and mentally draining.

And for that, as long as I'm able to, I'm keeping AI out of my hobby. Thanks for reading.

Footnotes:

Of course, this isn't universally true, there's definitely eccentric and unusual coding styles out there, that AI has no hope of replicating. However, such style is generally frowned upon in professional contexts, because you're not writing for yourself, rather for a team, that might one day contain people, who you'll never meet.

The actual historical Luddites get a really bad rep. While their methods were destructive, it's hard to seriously blame them. It was never about "uhh, machines bad!" More "this new technology is rapidly causing mass unemployment and that's endangering tons of livelihoods."

Considering how similar this is to today's situation (though one may wonder if AI truly brings as much benefit to society as the mechanic looms did), maybe I am a bit of a Luddite. At least in spirit, since I cannot exactly bring a hammer against a program.

Yes, this is intentionally mimicking the usual AI slop marker of "It's not just X, it's Y". If you're gonna think this whole text is AI generated too just because of this, I'm going to send you a very mean stare.

Adventures in Guix Packaging

2026-02-01T15:58:00Z

1. Introduction
2. Baby steps
3. Enter WezTerm
- 3.1. A mediocre first attempt
- 3.2. A brief second attempt at packaging locally
4. Third time's the charm
5. And yet, some stuff is still better left to the Professionals
6. Conclusion

1. Introduction

Having freshly jumped into Guix System, it didn't take long for me to want to attempt packaging something for the distro.

Unlike the usual, "imperative" distributions, whose build scripts mostly interact with your system directly, Nix and Guix "recipes" provide a set of instructions for the build environment how it needs to compile your package's contents "from zero" and then where to place each of the resulting files.

My first choice was Gamescope, Valve's home-brewed compositor that enabled HDR gaming under Linux.¹ However, I quickly realized I bit bigger than I could chew. It took me less than an hour of trying to run into a wall that was (at least at that time) seemingly completely insurmountable.

The errors I received were somewhat vague, the system couldn't find the necessary dependencies, and I really wasn't sure what I was doing. In hindsight, it really wasn't the right approach and had I went about this project with more planning, it may have gone much better. Luckily dropping this thread allowed me to pick up a similarly interesting, but much more fruitful project, which I'd like to showcase to you in this article.

TL;DR: I spent about a week packaging WezTerm and learning the ropes of being a Guix contributor along the way.

During the packaging process I stumble many times, only to stand back up and figure out a solution. I also explain some of my complaints about the peculiarities of the process, but also provide plenty of praise about of how much the system tries to enable you to do your job. Finally, I also touch on how positive the experience of the code review was.

If you just want to use WezTerm, do a guix pull and guix install wezterm.

2. Baby steps

Being somewhat disappointed in how quickly I failed with my initial attempt, I decided to instead start small and work my way up. To do this, I picked one of Gamescope's dependencies, OpenVR, and updated its package to its newest version.

This might sound impressive without context, but in reality it was little more than me just replacing a hash and a version number in a package definition someone else already wrote:

Listing 1: My massive changes.

  diff --git a/gnu/packages/game-development.scm b/gnu/packages/game-development.scm
index 56f147f956..5cecbf6963 100644
--- a/gnu/packages/game-development.scm
+++ b/gnu/packages/game-development.scm
@@ -3294,7 +3294,7 @@ (define-public instead
 (define-public openvr
   (package
     (name "openvr")
-    (version "1.26.7")
+    (version "2.12.14")
     (home-page "https://github.com/ValveSoftware/openvr/")
     (source
      (origin
@@ -3304,7 +3304,7 @@ (define-public openvr
              (commit (string-append "v" version))))
        (file-name (git-file-name name version))
        (sha256
-        (base32 "09rvrja3pz6ggs41ra71p4dwjl4n0rpqrqw8jiy92xl33hhxbsmx"))))
+        (base32 "0i85awq7w669j0x091chma8rcx1zqwn1j4v0d42bcjcvhqa6iv0v"))))
     (build-system cmake-build-system)
     (arguments
      ;; No tests.

Even though the changes I made are trivial, to get here, I had to set up the development environment, I had to set up a fork of the repository, learn about the project's committing rules, how opening PR-s for Guix works, and how I could test my changes locally. (I'm only making a tally here, all of these will be elaborated on in more detail in the rest of the article.)

I'd really encourage anyone interested in how the packaging process works to seek out similar low hanging fruits to get down the basics in an environment where you have basically no chance of failing.

You walk away with knowledge and a basis to build more involved stuff and in turn some members of the community might just get an update to a package they've been waiting for or someone might get inspired to add yet another package that they couldn't until now.

3. Enter WezTerm

WezTerm is one of the many GPU-accelerated terminal emulators out there, distinguishing itself with a fairly broad Lua-based configuration API and having tabs as a built-in feature among other things.

I admit, I haven't really used or interacted much with it previously. If I remember correctly, I tried it years ago before quickly moving on to other applications for my terminal needs, which begs the question: Why even bother to spend quite a few days on packaging it?

Well, I've basically been nerd-sniped into it. While I was still figuring out my own woes with Guix System's installation, I was frequently reading r/Guix in hopes of getting a bit further. And it just so happened that one of the posts on the front page at the time was a plea from a prospective Guix user for a native WezTerm package for Guix. What I quickly discovered is that there was none. I couldn't even really find discussions about it. This felt like a call.

Note from the future: Along the post, you'll occasionally see little boxes like this one. While the main body of the article documents my thinking and justifications during development, in these I'll bring attention to parts where I've either did things in a not entirely idiomatic way or where there's a much better / easier solution.

The point of this post is less "How to write a 100% correct package definition that will get immediately merged into Guix" and more "What sort of journey would someone face, who has some declarative packaging and Scheme knowledge, but is still quite new to the whole topic".

While the final code is indubitably much better than what I started with, I believe there is more merit in showcasing my iterative process instead of simply going through the merged package, as it doesn't really give any insight into how one would go about packaging something from zero.

3.1. A mediocre first attempt

To start out, I wanted to try to compile WezTerm in an ad-hoc environment to get an idea what it'd need. I cloned it using git clone https://github.com/wezterm/wezterm and created a new shell environment using guix shell rust cargo… Except this didn't actually work, as Guix immediately spit the following error: guix shell: error: cargo: unknown package.

Oh, right. With a cursory read of the Rust package, it quickly turned out Cargo isn't a separate package, but rather an output of Rust. Outputs in Guix are basically separate "sub-packages" of packages, that maintainers can use to group related artifacts together, without all of them having to be installed at the same time in case the user doesn't need them.

For instance most packaged libraries include both dynamic variants under out (which is the default output) and statically-linked ones under static. With Rust, we have the following options (you can find these using guix search):

name: rust
version: 1.85.1
outputs:
  + rust-src: [description missing]
  + tools: [description missing]
  + cargo: [description missing]
  + out: everything else

For our purposes, we need out, which contains the Rust compiler rustc, and we also need cargo. To instruct the shell to load both, the command we actually need is guix shell rust rust:cargo. We could have also explicitly used rust:out for rustc, but if we leave it out, the shell uses it by default anyway.

Armed with the right toolchain, I issued a naive cargo build and for a while things seemed to be in order, only to suddenly come to a crashing halt with the following error:

error occurred in cc-rs: failed to find tool "cc":
No such file or directory (os error 2)

It might come as a surprise, but due to the expectation that most things will be handled using declarative configuration, Guix System doesn't set the CC environment variable (nor CXX, though we won't be using that in this project).

In fact, there isn't even any C compiler toolchain installed by default. This causes any programs that expect Autoconf/Makefile-like conventions to not be able to compile stuff. We can really easily solve it by adding gcc-toolchain to our shell and setting CC to gcc:

guix shell rust rust:cargo gcc-toolchain
export CC=gcc
cargo build

Moments later we experience a new error (which, just like before, I'll abridge by a lot, because it's several pages long):

Could not find openssl via pkg-config:
Could not run `PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --libs --cflags openssl`
The pkg-config command could not be found.

The issue here is twofold, though both come from the same source. The compiler is looking for OpenSSL using pkg-config, but our environment doesn't contain either. While we could do what we previously did and exit the shell, add pkg-config and openssl, go back, call Cargo, and fail again at the next missing dependency, there is a slightly better way.

Note from the future: Look, I'll be honest, the first time I did this process, I was actually doing this completely "manually" as described above. That is to say, I tried compiling and when it eventually failed with an error about a missing dependency, I just added it to the list, rinse and repeat.

It's a horribly inefficient method and I didn't want to drag this post down by emulating it.

Though WezTerm has no Guix package (we're working on it right now!), it does come with a Nix flake and, though Nix and Guix have diverged quite a bit, it's still very helpful to see the list of packages spelled out for us by someone else:

nativeBuildInputs =
  with pkgs;
  [
    installShellFiles
    ncurses # tic for terminfo
    pkg-config
    python3
  ]
  ++ lib.optional stdenv.isDarwin perl;

buildInputs =
  with pkgs;
  [
    fontconfig
    openssl
    zlib
  ]
  ++ lib.optionals stdenv.isLinux [
    libxkbcommon
    wayland

    xorg.libX11
    xorg.libxcb
    xorg.xcbutil
    xorg.xcbutilimage
    xorg.xcbutilkeysyms
    xorg.xcbutilwm # contains xcb-ewmh among others
  ]
  ++ lib.optionals stdenv.isDarwin ([
    libiconv
  ]);

Obviously we cannot use this 1:1 as the two systems have different packaging conventions, but we can at least extract a good first approximation of the dependency list:

guix shell rust rust:cargo gcc-toolchain pkg-config openssl wayland libx11 \
     libxcb xcb-util libxkbcommon xcb-util-image freetype fontconfig
export CC=gcc
cargo build --bin wezterm

And, guess what, the application builds. Victory! Or so we think until we actually try to run it using cargo run --bin wezterm:

ERROR  wezterm_gui::frontend > Failed to create window: with_egl_lib failed:
libEGL.so.1: libEGL.so.1: cannot open shared object file: No such file or directory,
libEGL.so: libEGL.so: cannot open shared object file: No such file or directory,
libEGL.so.1: libEGL.so.1: cannot open shared object file: No such file or directory,
libEGL.so: libEGL.so: cannot open shared object file: No such file or directory

Bummer. WezTerm is a GPU-accelerated terminal emulator, so it (unsurprisingly) needs to communicate with our GPU. Under NVIDIA , this happens with the help of a library called libEGL², which our binary cannot locate without some additional help. The reason for this is that Guix isn't using the standard Linux filesystem hierarchy, so libEGL is nowhere to be found on the list of places the library loader checks by default.

The "fix" I used to circumvent this is really ugly, but for a quick attempt it sufficed. Firstly, I needed to figure out where libEGL.so even is. Thankfully all this took was a simple guix locate libEGL.so (this command is case-sensitive, I learned it the hard way), which spits out a list such as this:

fhs-union-32@0.0     /gnu/store/wr6kq2ixxcnh4nidg64ivsns19k7ynnn-fhs-union-32-0.0/lib/libEGL.so
fhs-union-64@0.0     /gnu/store/9jn31ksjz3frkhwdk5f72s65lrn3gbs7-fhs-union-64-0.0/lib/libEGL.so
mesa@25.2.3          /gnu/store/4kp4rn5vnnaj57464k72wqpg45k45x56-nvda-580.12/lib/libEGL.so
nvda@580.12          /gnu/store/d7vln3cxysi04wf7p8nzwgwabjysznjd-nvda-580.12/lib/libEGL.so
libglvnd@1.7.0       /gnu/store/qhc0y0xzmdmh38bpr9yv2il8alrv5l4g-libglvnd-1.7.0/lib/libEGL.so
mesa@21.3.8          /gnu/store/7rn2s4ip6926sdn8h23qbdyhsr4lj4xk-mesa-21.3.8/lib/libEGL.so

As you can see, due to the way Guix works, multiple versions of the library can coexist without conflicting with each other. As I'm running an NVIDIA card, I picked the line for nvda. Next, I had to set the special environment variable LD_PRELOAD to this file's path and then call wezterm. What this does is instruct the dynamic library loader to add the contents of the environment variable to its load path³ and thus the library is finally visible to the application.

LD_PRELOAD=/gnu/store/d7vln3cxysi04wf7p8nzwgwabjysznjd-nvda-580.12/lib/libEGL.so \
    ./target/debug/wezterm

Et voila, we have WezTerm running. Reddit thread solved. Well, kind of. Our victory is a bit of a hollow one. While we did compel Cargo to build the terminal and it technically works, we have not made a package. Guix isn't aware of WezTerm and anyone else who wants to build the application has to follow these haphazard steps, including overriding a "potentially dangerous" environment variable.

3.2. A brief second attempt at packaging locally

To turn our fickle experiment into a proper package, we need to create a build recipe, which we can later integrate into the guix/guix Codeberg repository. The customary filename for such recipes in Guix is, perhaps unsurprisingly, guix.scm. Inside this file you're expected to return a (package ...) form as your final value, which Guix can then process and turn into a derivation⁴ for you.

 1: (define-module (wezterm))
 2: 
 3: (use-modules (guix git)
 4:              (guix git-download)
 5:              (guix packages)
 6:              ((guix licenses) #:prefix license:)
 7:              (guix build-system cargo)
 8:              (gnu packages)
 9:              (gnu packages commencement)
10:              (gnu packages tls)
11:              (gnu packages freedesktop)
12:              (gnu packages xorg)
13:              (gnu packages xdisorg)
14:              (gnu packages fontutils)
15:              (gnu packages autotools)
16:              (gnu packages guile)
17:              (gnu packages pkg-config)
18:              (gnu packages sdl)
19:              (gnu packages texinfo))
20: 
21: (package
22:   (name "wezterm")
23:   (version "05343b3")
24:   (home-page "https://wezterm.org/")
25:   (synopsis "TODO")
26:   (description "TODO")
27:   (license license:expat)
28:   (source (git-checkout (url "https://github.com/wezterm/wezterm")
29:                         (commit version)))
30:   (inputs (append (list gcc-toolchain pkg-config openssl wayland
31:                         libx11 libxcb xcb-util libxkbcommon xcb-util-image
32:                         freetype fontconfig)))
33:   (build-system cargo-build-system))

Let's go through our code, section by section. We begin by declaring a module for our package. This is not strictly necessary, but it's common practice with Guile code and (as you'll soon see) it won't really matter in the long run anyway. Next we import a bunch of utilities and packages. A common rule of thumb is that packages under guix are utilities, while gnu packages are packages.

We import stuff like methods for importing from a Git repository, definitions of software licenses (more on that below), and Guix's Cargo-based builder preset. The observant might notice that we don't pull in rust, rust:cargo, and gcc-toolchain. All of these are handled by the preset.

Next comes the main package definition. We declare some static metadata, such as the name of the package, its version number (I'm using the current commit of the repository, as WezTerm hasn't had a release since 2024), the project's website, and we leave the synopsis and description empty for now, as I'd rather first have the package working before wasting time on bookkeeping busywork.

Finally we set the package's license. In Guix (and Nix too), licenses aren't simple text fields, so we can't simply say "MIT" and move on with our lives. Rather they are objects of their own. This both allows recording any necessary to fully specify the license and also removes a lot of guesswork from the packagers' workflow such as:

"Do I specify 'MIT'? Or 'Expat'? Or 'MIT/Expat'?"
"Is the field case sensitive?"
"Is it 'GPL-3' or 'GPL3' or maybe 'GPLv3'?"
And so on and so forth.

To access these license objects, we need to pull in the (guix licenses) module and specify from it the exact variant we need. In our case this is license:expat, the MIT license's other name. As you can see, in the imports section I specified license: as the license module's prefix. This means all the identifiers exported from this module are automatically renamed to contain license: in the front. This is done to prevent overshadowing unrelated names and prefixing licenses this way is an idiomatic practice in Guix.

This is followed by the actually interesting stuff. First we declare the source of our package's code. This can be many things, an archive downloaded from the Internet, a Git repository like we see in this case, or even a local folder as seen in this excellent tutorial. We declare our commit to be the same as what we set for our version, i.e. the Git commit with the (short) ID 05343b3.

Next we declare our "inputs", these are all the packages that we either need to use to build our package or we need at runtime. Note the vagueness of the word "use" here: Inputs may not just be source code dependencies. For instance, as with the manual method, pkg-config is used to find other sources' locations and won't actually be part of the final executable. But we might also include tools that generate files. Or we might request assets, like fonts. It's best to think of inputs as not just the ingredients, but the entire kitchen supply.

After that comes the build system. Just like our source, this too can be many things and it is what primarily decides what our build process is going to look like. Since we're trying to make a Rust package, we use cargo-build-system, which itself is based on the gnu-build-system (which is a smarter codification of the good old ./configure, make, make install ritual), except with all the GNU-specific build tools replaced with calls to Cargo.

Well, let's give it a shot. Surely, things cannot be much more complex than this.

Listing 2: Crash and burn…

error: failed to get `finl_unicode` as a dependency of package `termwiz v0.24.0 (/tmp/guix-build-wezterm-05343b3.drv-0/source/termwiz)`

Caused by:
  failed to load source for dependency `finl_unicode`

Caused by:
  Unable to update https://github.com/wez/finl_unicode.git?branch=no_std

Caused by:
  can't checkout from 'https://github.com/wez/finl_unicode.git': you are in the offline mode (--offline)
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "cargo" arguments: ("build" "--offline" "-j" "24" "--release" "-p" "wezterm-gui" "--features" "distro-defaults") exit-status: 101 term-signal: #f stop-signal: #f> 
phase `build' failed after 0.0 seconds
command "cargo" "build" "--offline" "-j" "24" "--release" "-p" "wezterm-gui" "--features" "distro-defaults" failed with status 101
build process 18 exited with status 256
builder for `/gnu/store/nllax38xh9v0hcsc3g9vviw5mqnrj5x0-wezterm-05343b3.drv' failed with exit code 1
build of /gnu/store/nllax38xh9v0hcsc3g9vviw5mqnrj5x0-wezterm-05343b3.drv failed

Things can't be as simple as we'd like, huh?

4. Third time's the charm

The main reason we failed is because Guix is very particular about the way it allows source code to be fetched⁵ and, though Cargo has an ecosystem of its own, Guix wants to have the final say. If packages, such as the previously seen finl_unicode aren't known by Guix, then even though Cargo could fetch it for us, the build system will refuse to proceed.

The good news is that Guix has built in features to allow mass-importing crates, so we don't have to manually go through every single of WezTerm's dozen crates. The bad news is that, for this to work, you need to be working inside Guix's primary repository or else you're unleashing an unreasonable amount of extra work on yourself. Since our end goal is to upstream the package definition anyway, it really is the right choice to just bite the bullet and do it properly.

So, back to tabula rasa, let's create a package inside the actual Guix package repository.

4.1. Setting things up

I'm going to assume at least a bit of Git knowledge, as this post will be long enough as-is without starting from the very basics. Due to my previous tiny contribution with OpenVR, I already had a fork repository of guix/guix, so that's one hurdle down. Next, we do the usual, update the master⁶ branch, create a new branch, switch to it, then prepare our working environment:

git pull
git switch --create add-wezterm
guix shell -D guix -CPWN
./bootstrap  # runs autoreconf, creates configure
./configure  # creates Makefile
make

The first two git commands are fairly trivial, but the third command is worth talking about a little. The interesting thing about Guix development is that it happens 90% inside Guix itself! Isn't that cool? By issuing guix shell -D guix -CPWN, we are:

-C: are transported into a container, a fully isolated environment, in which only the source tree is available,
-D guix: with the development inputs of the guix pacakge included,
-P: with the profile initialized to the source tree's environment,
-W: with the guix executable available,
-N: and finally we request network access.

But, before we can throw ourselves into writing our package with wild abandon, we have one more preliminary thing to take care. We need to set up our development environment by first running ./bootstrap, followed by ./configure. These two commands generate the necessary Makefiles and are a one time cost (unless you're nuking your entire repo checkout and recreating it from scratch, you don't really have to call these ever again). For more info about this part of the process, please see the appropriate manual chapter.

Then, by issuing make⁷, the development environment does several things at once:

It compiles all existing Scheme files into .go files, which aren't Golang source files, but rather Guile byte-code. This speeds up execution as instead of interpreting source code, Guile can work based on pre-chewed binary data,
It compiles all documentation. To our purposes this isn't hugely relevant, but it's a one-time cost, so there's not much point in figuring out elaborate ways to avoid it,
Finally, and most importantly, it places a new script into our workspace named pre-inst-env. The name stands for "[run with] pre-installation environment" and it is the primary driver of our Code->Compile->Test loop.

By prepending all our guix invocations with ./pre-inst-env, we can instruct Guix to use the workspace package registry as its source and thus we can build and test our package without the horribly slow process of manually doing guix pull on our work directory and guix build <package>.

What's even better is that this works even outside the container, so we can use all our usual tools while testing or build in the restricted environment to make sure we're not introducing any external dependencies.

After a couple minutes of wait, our workspace is finally ready for action. Now we can finally handle the actual Guix stuff. First order of business is figuring out where even our package should go. The Guix repository's folder structure is logical, but it is still occasionally non-trivial to figure out where some packages might be located.

A good rule of thumb is that usually things go into general categories (e.g. emulators.scm), but if a set of packages only make sense together (an example being django.scm for all the Python Django stuff out there), it can go into a category, and thus, a new file of its own. For us, there are two possible candidates:

rust-apps, whose purpose I'm still not 100% sure about, since the only thing that connects the stuff inside it seems to be that it's all Rust-based applications,
and terminals.scm, which is for terminal emulators. This is the one I ultimately went with, as it already had Alacritty inside, which is also a Rust-based terminal emulator, just like WezTerm.

So, let's just plop our previous package definition (extended a little bit) into this file and give it a whirl.

(define-public wezterm
  (package
    (name "wezterm")
    (version "05343b387085842b434d267f91b6b0ec157e4331")
    (source
     (origin
       (method git-fetch)
       (file-name "wezterm")
       (uri (git-reference
              (url "https://github.com/wezterm/wezterm")
              (recursive? #t)
              (commit version)))
       (sha256
        (base32 "0q3f1y3bx3g2k21yzp6wkws6kyxsmk4pscmvd8gqmjbbss8az9ap"))))
    (native-inputs (list pkg-config))
    (inputs (append (cargo-inputs 'wezterm)
                    (list openssl wayland libx11
                          libxcb xcb-util xcb-imdkit
                          libxkbcommon xcb-util-image
                          freetype fontconfig libssh2
                          libgit2 sqlite `(,zstd "lib")
                          mesa)))
    (build-system cargo-build-system)
    (home-page "https://wezterm.org/")
    (synopsis "Powerful cross-platform terminal emulator and multiplexer")
    (description
     "A GPU-accelerated cross-platform terminal emulator and
multiplexer written by wez and implemented in Rust.  Features:

@itemize
@item Runs on Linux, macOS, Windows 10, FreeBSD and NetBSD,
@item Multiplex terminal panes, tabs and windows on local and
remote hosts, with native mouse and scrollback,
@item Ligatures, Color Emoji and font fallback, with true color
and dynamic color schemes,
@item Hyperlinks.
@end itemize
")
    (license license:expat)))

There's only really three things of note:

Instead of simply doing a "bare" package form, we wrap our package definition into a define-public form. This is how we ensure that multiple package definitions can coexist in a single file.
Secondly, the package source form was rewritten to use origin instead, which allows for a lot more flexibility in how we download stuff from the net.

Among other things, it allows us to rewrite parts of the source, delete unnecessary files, create wholly new files, and (as can be seen here) it also allows us to cryptographically check whether the source files we get really are what we expect them to be. Packages meant for the main Guix repo all must have their hash checked, so adding it wasn't merely my frivolousness.

Note from the future: As it turns out, as helpful as this step was during development, it is entirely possible to make WezTerm work without recursive cloning and, in fact, this option is only allowed in extraordinary cases.

I also enabled recursive cloning of the repo as there are some submodules involved and once we're past the source-fetching stage, the network is disabled and we wouldn't be able to download them anymore.
Thirdly you may wonder about the weird `(,zstd "lib") form in our inputs. As inputs are actual other packages, not strings-based specifications, we can no longer do the previous "package:output" way of referring to alternative outputs.

For that, we need to create a two-element list, where the first is the dependency and the second is the textual name of the output. So, really, this is just the packaging way of saying zstd:lib.

4.2. Importing Cargo crates

Still, with all this work, if we run this using ./pre-inst-env guix build wezterm, we will be met with the previous error about Cargo not being able to fetch finl_unicode. Which shouldn't be surprising, since as mentioned earlier we haven't imported our Cargo dependencies into Guix yet.

To do this, we will need to issue guix import in our previously checked out WezTerm Git repository in the following way:

guix import -i <path to Guix repo>/gnu/packages/rust-crates.scm \
     crate -f <path to Git repo>/Cargo.lock \
     wezterm

What this does is go through every individual Cargo dependency in the Cargo.lock file and compares it to the list found in rust-crates.scm. If a matching entry is found, nothing is done, if not, the importer adds a new entry to the file. If a crate has a matching crates.io page, an entry such as this is generated:

(define rust-libssh-rs-0.3.6
  (crate-source "libssh-rs" "0.3.6"
                "11f6fj59dqpy7n0g74s7vnnyrbpxbrcyxhnrvfnsb5dvsq8f2rih"))

If not, however, then we get a slightly bigger variant:

(define rust-finl-unicode-1.3.0.a1892f2
  ;; TODO REVIEW: Define standalone package if this is a workspace.
  (origin
    (method git-fetch)
    (uri (git-reference (url "https://github.com/wez/finl_unicode.git")
                        (commit "a1892f26245529f2ef3877a9ebd610c96cec07a6")))
    (file-name (git-file-name "rust-finl-unicode" "1.3.0.a1892f2"))
    (sha256 (base32 "0g9lqwrzm7ca54vlq8sgix3wvbsxwp7glkx3dzjdd591grfbmi6z"))))

It bears resemblance to our own package's origin field and it also has a foreboding comment about how we need to review this generated package to check if it's a "workspace". Elaborating on what a workspace is in Rust is beyond the scope of this article, but the long story short is that a single Cargo project may contain multiple, related subprojects and the importer is not able to untangle these by itself.

If you're packaging something that depends on such a project, you must manually make sure every single subproject gets its own definition, which call back to the main workspace. finl_unicode isn't such a project, however, so we can safely ignore the warning for now.

Where we cannot ignore the comment, however, is with the bindings for OpenSSL, rust-openssl-sys-0.9.111. If we were to leave things as-is, we'd soon find that our project does not build due to not finding openssl-src.

Thankfully, we don't have to figure it out how to fix this issue ourselves, as the package already has several other versions in the Guix repo. We simply have to copy someone else's solution and we're one step closer to making WezTerm build:

diff --git a/gnu/packages/rust-crates.scm b/gnu/packages/rust-crates.scm
index 74fba63cd8..213882b4a2 100644
--- a/gnu/packages/rust-crates.scm
+++ b/gnu/packages/rust-crates.scm
@@ -13605,9 +13605,19 @@ (define rust-openssl-sys-0.9.110
                     (copy-file "Cargo.toml.orig" "Cargo.toml"))))

 (define rust-openssl-sys-0.9.111
-  ;; TODO REVIEW: Check bundled sources.
   (crate-source "openssl-sys" "0.9.111"
-                "08f3mpsabivfi3fd0qv9231qidqy68lr8a4qi32y6xda43av5jl2"))
+               "08f3mpsabivfi3fd0qv9231qidqy68lr8a4qi32y6xda43av5jl2"
+               #:snippet
+               #~(begin
+                   ;; Remove dependency on boringssl and vendor openssl source.
+                   (substitute* "Cargo.toml.orig"
+                     (("vendored = .*") "vendored = []\n")
+                     ((".*bssl.*") "")
+                     ((".*openssl-src.*") "")
+                     ;; Allow any version of bindgen.
+                     (("(bindgen = \\{ version =) \".*\"," _ bindgen)
+                      (string-append bindgen "\"*\",")))
+                   (copy-file "Cargo.toml.orig" "Cargo.toml"))))

Once the importer has gone through every dependency, it also generates a lookup table entry in rust-crates.scm in the form of package-name => (list <list-of-dependencies>). This is ultimately the mechanism that pairs user defined Rust Guix packages to their Cargo defined dependencies. For instance, since we entered wezterm⁸ in our cargo import query, we get the following list:

(wezterm =>
       (list rust-addr2line-0.25.1
        rust-adler-1.0.2
        rust-adler2-2.0.1
        rust-adler32-1.2.0
        rust-ahash-0.8.12
        rust-aho-corasick-1.1.4
        rust-aligned-vec-0.6.4
        ... and like 600 more crates ...
        ))

And somewhere in this list, finl_unicode can also be found. Finally, we are able to provide all our dependencies to the build system:

Listing 3: The build system has access to all the crates that we automagically imported from the Cargo lockfile.

;; cons* takes an arbitrary amount of elements and a list and prepends the former to the latter.
;; E.g. (cons* 'a 'b 'c '(d e)) => (a b c d e)
(inputs (cons*
         openssl
         wayland
         libx11
         ... our previous list of packages ...
         (cargo-inputs 'wezterm)))

We issue ./pre-inst-env guix build wezterm… and run into the same error. What gives?

4.3. Patching Cargo.toml

Though the code itself is fairly trivial, understanding the solution to this issue was perhaps the most difficult part of the entire process to me. Largely because there is almost zero indication what and how you need to do, and the docs barely touch upon the existence of this issue and its fix either. I had to resort to reading other packages' definitions, which worked, but definitely wasn't the smooth-sailing as things had been up to this point.

To finally reveal this hidden menace that has been keeping us from compiling this poor application till now, let's take a look at two different dependencies from WezTerm's Cargo.toml:

finl_unicode = { version = "1.3",  git="https://github.com/wez/finl_unicode.git", branch="no_std" , default-features=false, features=["categories", "grapheme_clusters"]}
fixed = "1.23"

For dependencies like fixed, there is no issue, the build system can match them with their imported package no-problem. However, for some reason that I still don't quite understand, if there is a git field in the dependency list, then that completely breaks the proces, as Cargo will always try to download it from the internet, which then fails due to the build environment not having network access.

The solution?

finl_unicode = { version = "1.3", default-features=false, features=["categories", "grapheme_clusters"]}

Yep. That's it. We just have to instruct Guix to rewrite this one line (well, actually two, because there's two such dependencies in the project, but I'll not bore you with the exact same process) and everything else will magically work.

To do this, we introduce a new section to our package definition, arguments. The role of this field is to override certain aspects of the build system preset, such as the build flags or what so-called "build phases" we wish to execute on the code.

A build phase can be practically anything from setting environment variables, to compiling code, to editing files. We would like to do the last one, so let's introduce a new build phase:

(arguments
 (list
  #:phases
  #~(modify-phases %standard-phases
      (add-after 'unpack 'use-guix-vendored-dependencies
        (lambda _
          (substitute* "Cargo.toml"
            ((",  git.*default-features")
             ", default-features")
            ((", git.*, rev.*}")
             ;; This is added to ensure a different dependency
             ;; uses libraries provided by the inputs instead
             ;; of relying on bundled files.
             ", features=[\"use-system-lib\"]}")))))))

This code adds a new phase after unpack (which is the phase responsible for extracting the actually usable files and folders from our origin) named use-guix-vendored-dependencies. The name of the phase that we're adding is arbitrary, but you're expected to pick something informative and truthful, so please don't try do-stuff or thing.

The magic happens inside substitute*, which takes a filename and a list of regexp => replacement pairs, and then executes the replacements. It's kind of like having a lispy sed in your arsenal.

Careful readers may have noticed the weird #~ symbol in front of the modify-phases function call. This is a Guix-exclusive extension to Scheme's syntax, called G-expressions (abbreviated as "gexp").

Their job is to facilitate working with files as data, therefore whenever we need to directly affect our source code (be that creation, deletion, or modification) or call out into the operating system, we need to do so inside a gexp. This isn't the only place where we'll need to do so, so I'll call into attention when it happens.

In more important news, if we were to issue ./pre-inst-env guix build wezterm now, we'd find that the package actually builds… before failing again:

error: crates-io is replaced with non-remote-registry source dir /tmp/guix-build-wezterm-05343b387085842b434d267f91b6b0ec157e4331.drv-0/source/guix-vendor;
include `--registry crates-io` to use crates.io
error: in phase 'package': uncaught exception:
%exception #<&invoke-error program: "cargo" arguments: ("package" "--offline" "--no-metadata" "--no-verify") exit-status: 101 term-signal: #f stop-signal: #f> 
phase `package' failed after 0.1 seconds
command "cargo" "package" "--offline" "--no-metadata" "--no-verify" failed with status 101
build process 18 exited with status 256

The actual error is a little vague, but the gist is that by default the cargo-build-system attempts to install the sources of all the dependencies we used. For us, this is neither desirable, nor does it actually allow the build to finish, so by adding the following to our arguments, we disable it (along with tests⁹):

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 476e2b743e..84f52b24f8 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -1702,6 +1702,8 @@ (define-public wezterm
       (build-system cargo-build-system)
       (arguments
        (list
+        #:install-source? #f
+        #:tests? #f
         #:phases
         #~(modify-phases %standard-phases
             (add-after 'unpack 'use-guix-vendored-dependencies

Call build again, and…

4.4. We have liftoff… Almost

No errors. Our build was successful.

successfully built /gnu/store/h8d2igkg4vlg687ixgj6hizyd4gbzl64-wezterm-05343b387085842b434d267f91b6b0ec157e4331.drv
/gnu/store/h99jlsdism6jxn3x02fv7jig61r6ydv2-wezterm-05343b387085842b434d267f91b6b0ec157e4331

Let's celebrate by starting a shell that contains our newly built terminal in it and start it up:

guix shell wezterm -- wezterm
guix shell: error: wezterm: command not found

Sadly we're still no quite there, but there is only one step separating us from the same spot as we were with the original "ad-hoc" implementation. If we list the files in our built derivation, we would find that it doesn't contain anything useful:

/gnu/store/h99jlsdism6jxn3x02fv7jig61r6ydv2-wezterm-05343b387085842b434d267f91b6b0ec157e4331
└── share
    └── doc
        └── wezterm-05343b387085842b434d267f91b6b0ec157e4331
            ├── ANGLE.md
            ├── LICENSE.md
            └── README.md

What happened? Simply put, we only told Guix to build our executables, not that we actually need them. The built package contains several different binaries, of which we're primarily interested in one: wezterm-gui.

To access it, we will a phase called install which is supposed to put everything in its rightful place. Let's modify arguments and override it to install our file:

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 84f52b24f8..8f54a79dbe 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -1712,7 +1712,16 @@ (define-public wezterm
                   ((",  git.*default-features")
                    ", default-features")
                   ((", git.*, rev.*}")
-                   ", features=[\"use-system-lib\"]}")))))))
+                   ", features=[\"use-system-lib\"]}"))))
+          (replace 'install
+           (lambda* (#:key inputs native-inputs #:allow-other-keys)
+             ;; Binaries
+             (with-directory-excursion "target/release"
+               (for-each
+                 (lambda (name) (install-file name (string-append #$output "/bin")))
+                '("wezterm" "wezterm-gui"
+                  "wezterm-mux-server"
+                  "strip-ansi-escapes"))))))))
       (home-page "https://wezterm.org/")

Note from the future: Binaries aren't the only thing that need to be installed for a package like this. You also need to copy over stuff like icons, .desktop files, and any other various assets a package might need.

I abridged the package definition here quite a bit, because much of the process is just more of the same and I see very little educational value in repeating 95% the same code.

This snippet of code enters ./target/release, which is the folder where Cargo places our compiled binaries, walks through our supplied list of executable names and copies each to #$output/bin. In Bash terms, you could think of this as cp ./target/release/wezterm $OUTPUT/bin/.

You may wonder what #$output even is. It's actually two separate things combined:

#$ is a so-called reader extension specific to Guix. Reader extensions are a user-defined extension to the usual syntax extensions, which are in turn special characters that affect the behavior of Lispy languages and are mostly used because spelling out the entire form they shorten would be quite unwieldy.

Listing 4: Some examples of common syntax extensions to all Lispy languages.

(+ 1 2)         ;; => 3        (Form is evaluated as usual)
'(+ 1 2)        ;; => (+ 1 2)  (Form is "quoted" and returned as-is)
`(+ 1 2)        ;; => (+ 1 2)  (Form is "quasiquoted" and returned as-is)
`(+ 1 ,(+ 1 1)) ;; => (+ 1 2)  (Form is "quasiquoted", the third element is "unquoted")

In our case #$ is a lot like , (also known as unquote), which is used in conjunction with ` (quasiquote). It allows us to "unquote" (i.e. execute) code inside a gexp, which itself acts as sort of a quasiquote (i.e. a form that isn't evaluated by default, only the parts that are explicitly unquoted). For more information about the concept, Guile has an entire page dedicated to it.

Meanwhile, output is simply a variable provided implicitly in our install phase, that points to the directory where our derivation will be built into. This folder acts similarly to a filesystem root folder (what you may know as /), but it only contains files that either we explicitly placed into it or are automatically copied by the build phases.

When we install a package, the files from its output are made available in our general environment. You can see this by calling ls /run/current-system/profile/bin, which will list out most¹⁰ of the binaries available to you in the current environment. One thing of note is that none of these files here are the actual executables, but rather symlinks to binaries found in the Guix store, which is the organized collection of all built derivations.

Circling back to our package, now that our executables are copied over to the output's bin folder, they will be available to use if we were to install the package. Let's do so:

guix shell wezterm
wezterm

This time the terminal runs, but then immediately crashes…

4.5. GPU maladies

Note from the future: The method shown below might be a viable path for some particularly stubborn libraries, however, it is not a good first approach. As it turns out in this case we can get rid of this entire build phase by simply instructing Cargo to link libEGL using the RUSTFLAGS environment variable.

If you're thinking of making your own package, please be sure to check whether you can simply instruct your linker before you attempt to hack apart the code you're working on.

21:59:33.533  ERROR  wezterm_gui::frontend > Failed to create window: with_egl_lib failed:
libEGL.so.1: libEGL.so.1: cannot open shared object file: No such file or directory,
libEGL.so: libEGL.so: cannot open shared object file: No such file or directory,
libEGL.so.1: libEGL.so.1: cannot open shared object file: No such file or directory,
libEGL.so: libEGL.so: cannot open shared object file: No such file or directory

You might remember, that we've seen this error already. This time, however, we'll do it right and instead of relying on a random build string extracted from a command, we'll rely on our build inputs.

To figure out what we're supposed to do, let's grep for libEGL.so to find all the places the library is used. There are some irrelevant results, but there is some promising code under ./window/src/egl.rs. The definition of the function named with_egl_lib reveals how exactly we're trying to load the library:

fn with_egl_lib<F: FnMut(EglWrapper) -> anyhow::Result<Self>>(
    mut func: F,
) -> anyhow::Result<Self> {
    let mut paths: Vec<std::path::PathBuf> = vec![
        #[cfg(target_os = "windows")]
        "libEGL.dll".into(),
        #[cfg(target_os = "windows")]
        "atioglxx.dll".into(),
        #[cfg(all(not(target_os = "macos"), not(target_os = "windows")))]
        "libEGL.so.1".into(),
        #[cfg(all(not(target_os = "macos"), not(target_os = "windows")))]
        "libEGL.so".into(),
    ];

This piece of code tries to simply look for libEGL.so without any path associated with it. Therefore the dynamic library loader will try all known search places. However, since Guix doesn't put libraries in the normal search paths, this will fail.

So, what if we were to replace this string by an exact path to the library provided by one of our inputs? Turns out that's exactly what we need to do.

As you might have guessed, we need yet another phase:

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index f7eb633624..34758f238e 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -1713,6 +1713,10 @@ (define-public wezterm
                    ", default-features")
                   ((", git.*, rev.*}")
                    ", features=[\"use-system-lib\"]}"))))
+            (add-after 'unpack 'fix-libegl-so
+              (lambda _
+                (substitute* "./window/src/egl.rs"
+                  (("libEGL.so") (string-append #$mesa "/lib/libEGL.so")))))
             (replace 'install
              (lambda* (#:key inputs native-inputs #:allow-other-keys)
                ;; Binaries

Let's rebuild and run our package again.

Success! Well, mostly. If we really wanted to, we could stop here. Our package technically "works" and can be installed. However, in its current state, it'd never be accepted into the registry for two main reasons (and a myriad of small ones, see the final part of this story).

4.6. Finding fonts

Note from the future: WezTerm actually bundles four different fonts. During the development of the package I only packaged JetBrains Mono and Roboto, because those two are considered vital for the terminal to function.

However, by the time the package was merged, one of the contributors added the other two fonts too and replaced this entire phase with much more elegant code.

Of these two big issues, one is that we are still relying on fonts bundled by the source repository. This is a no-go, especially since most of the fonts we wish to use are already packaged in Guix.

By looking into the source files, we find that WezTerm's font-loading code is found in wezterm-font/src/parser.rs:

/// In case the user has a broken configuration, or no configuration,
/// we bundle JetBrains Mono and Noto Color Emoji to act as reasonably
/// sane fallback fonts.
/// This function loads those.
pub(crate) fn load_built_in_fonts(font_info: &mut Vec<ParsedFont>) -> anyhow::Result<()> {
    #[allow(unused_macros)]
    macro_rules! font {
       ($font:literal) => {
           (include_bytes!($font) as &'static [u8], $font)
       };
   }
   let lib = crate::ftwrap::Library::new()?;

   let built_ins: &[&[(&[u8], &str)]] = &[
       #[cfg(any(test, feature = "vendor-jetbrains"))]
       &[
           font!("../../assets/fonts/JetBrainsMono-BoldItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Bold.ttf"),
           font!("../../assets/fonts/JetBrainsMono-ExtraBoldItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-ExtraBold.ttf"),
           font!("../../assets/fonts/JetBrainsMono-ExtraLightItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-ExtraLight.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Italic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-LightItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Light.ttf"),
           font!("../../assets/fonts/JetBrainsMono-MediumItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Medium.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Regular.ttf"),
           font!("../../assets/fonts/JetBrainsMono-SemiBoldItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-SemiBold.ttf"),
           font!("../../assets/fonts/JetBrainsMono-ThinItalic.ttf"),
           font!("../../assets/fonts/JetBrainsMono-Thin.ttf"),
       ],

As you guessed, we need yet another phase, this time to replace all instances of ../../assets/fonts to the font package's own path:

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 13e690e11f..a2a5a71a07 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -67,6 +67,7 @@ (define-module (gnu packages terminals)
   #:use-module (gnu packages sqlite)
   #:use-module (gnu packages elf)
   #:use-module (gnu packages vulkan)
+  #:use-module (gnu packages fonts)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix build-system cargo)
   #:use-module (guix build-system cmake)
@@ -1702,7 +1703,9 @@ (define-public wezterm
                             patchelf
                             vulkan-loader
                             `(,zstd "lib")
-                            mesa)))
+                            mesa
+                            font-jetbrains-mono
+                            font-google-roboto)))
       (build-system cargo-build-system)
       (arguments
        (list
@@ -1721,6 +1724,17 @@ (define-public wezterm
               (lambda _
                 (substitute* "./window/src/egl.rs"
                   (("libEGL.so") (string-append #$mesa "/lib/libEGL.so")))))
+            (add-after 'unpack 'fix-font-load-path
+              (lambda* (#:key inputs #:allow-other-keys)
+                (substitute* "wezterm-font/src/parser.rs"
+                  (("../../assets/fonts/JetBrains")
+                   (string-append
+                    #$font-jetbrains-mono
+                    "/share/fonts/truetype/JetBrains"))
+                  (("../../assets/fonts/Roboto")
+                   (string-append
+                    #$font-google-roboto
+                    "/share/fonts/truetype/Roboto")))))

A rebuild confirms that the terminal still launches as before, only this time it's using fonts from Guix, not the ones bundled in the repository.

4.7. It's Vulkan, not Vulkan't

Note from the future: Just like with libEGL, this isn't the best way to ensure WezTerm (or any other Rust-based package) can see Vulkan and is only shown because this is what I stumbled upon while reading others' code and what any other complete beginner might reasonably reach out for without knowing better.

In this case too, you can simply just instruct the linker, which both helps us get rid of patchelf and any manual mucking with the load paths and is a lot more idiomatic.

While the terminal is functional at this point, if we were to inspect the parent terminal where we started wezterm, we might notice a suspicious error message:

libEGL warning: pci id for fd 20: 10de:2f04, driver (null)

pci id for fd 21: 10de:2f04, driver (null)
kmsro: driver missing
libEGL warning: egl: failed to create dri2 screen
pci id for fd 21: 10de:2f04, driver (null)
kmsro: driver missing
libEGL warning: egl: failed to create dri2 screen

This is in fact the other big issue foreshadowed two sections ago. While we have fixed the situation with libEGL, there is another library we need to really get WezTerm working. This library is libvulkan, also known as Vulkan, OpenGL's successor. WezTerm uses it to enable GPU hardware acceleration and, without it, we're left with an embarrassingly slow CPU-accelerated rendering pipeline, that even stuff as old as the original xterm beat by magnitudes of speed.¹¹

However, this time around, unlike with EGL, there is no hard-coded filename to patch, no matter how hard we're looking. So the usual trick of rewriting won't work here. Instead, we are going to add libvulkan.so to the library loader's search path in another way. Enter patchelf, a handy tool that can manipulate the ELF header of a binary.

ELF or "Executable and Loadable Format" is the Unix solution to storing the metadata of executables. It is a small header that defines (among many other things, this is just a taste) what sort of machine this code is expected to run on (32-bit or 64-bit, x86 or ARM, etc.), what memory location our program code starts at, and most importantly for our purposes, the libraries linked to the executable.

By changing this header table, we are able to slip in a reference to libvulkan.so, without it ever being mentioned directly in the code:

diff --git a/gnu/packages/terminals.scm b/gnu/packages/terminals.scm
index 34758f238e..13e690e11f 100644
--- a/gnu/packages/terminals.scm
+++ b/gnu/packages/terminals.scm
@@ -65,6 +65,8 @@ (define-module (gnu packages terminals)
   #:use-module (gnu packages fcitx5)
   #:use-module (gnu packages version-control)
   #:use-module (gnu packages sqlite)
+  #:use-module (gnu packages elf)
+  #:use-module (gnu packages vulkan)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix build-system cargo)
   #:use-module (guix build-system cmake)
@@ -1697,6 +1699,8 @@ (define-public wezterm
                             libssh2
                             libgit2
                             sqlite
+                            patchelf
+                            vulkan-loader
                             `(,zstd "lib")
                             mesa)))
       (build-system cargo-build-system)
@@ -1717,6 +1721,12 @@ (define-public wezterm
               (lambda _
                 (substitute* "./window/src/egl.rs"
                   (("libEGL.so") (string-append #$mesa "/lib/libEGL.so")))))
+            (add-before 'install 'patch-libvulkan-so
+              (lambda* (#:key inputs #:allow-other-keys)
+                (invoke "patchelf"
+                        "--add-needed"
+                        (string-append #$vulkan-loader "/lib/libvulkan.so")
+                        "./target/release/wezterm-gui")))
             (replace 'install
              (lambda* (#:key inputs native-inputs #:allow-other-keys)
                ;; Binaries

invoke as the name suggests is Guix's mechanism to call out into a different application during build time. Because we're inside a gexp, our code is ensured to only be actually executed when we're done with the building and just before the installation is attempted. Since we added patchelf to our inputs, we don't have to worry about finding it, invoke will sort it out for us.

Another minor, yet important thing to note is that this time we used add-before instead of add-after. We don't really care when exactly patchelf runs, only that it happens before the installation process is finished, as we'd first like to change the ELF header.

With this step done, libvulkan.so is finally visible to the library loader and the system can start using Vulkan to drive its graphics pipeline:

Figure 1: The different GPUs (real or emulated) WezTerm sees, now that Vulkan is enabled.

4.8. A short aside: Committing is hard!

Listing 5: An example of the "ChangeLog" format.

gnu: Add wezterm.

* gnu/packages/terminal.scm: (wezterm): New variable.
* gnu/packages/rust-crates.scm (lookup-cargo-inputs) [wezterm]: New entry.

This was a topic I wanted to mention, but couldn't really find a better place for, so I'll just stick it here before the epilogue.

Guix, like most other GNU projects, follows the so-called "ChangeLog" style of commit messages. The idea is to have all contributors provide mostly consistent descriptions to their commits, based on a set of rules that makes understanding what exactly changed easier and in a sense "algorithmic".

You can basically go through a list of possible commit message formats and figure out what the current change fits most. Was it an addition, a modification, a deletion, a fix? After you nailed down the action, you can extract the exact file, section, and sometimes even subsection that was modified. And then there's still the "free form" part of the commit message, that elaborates on exactly what happened.

Thing is, while this sounds excellent on paper, I found it really difficult to properly follow this style. With every commit I was double guessing myself whether what I'm writing is succinct enough and fits the style, or if I'm making subtle errors and just think it's correct because it looks mostly fine.

Unlike most other things in this article, I have no "and then it all clicked" moment to share here. I basically limped to the finish line, stealing turns of phrases from other contributors and then most of my commit messages disappeared when my submission was overhauled (see below). The rest that remained are such simple messages, that they don't really contain any of the actually iffy stuff, that confused me.

Don't get me wrong, this is still better than total anarchy and I imagine with time you get a "feel" for how to do it right, but it sure as hell didn't inspire much confidence in me while I was working on this project.

5. And yet, some stuff is still better left to the Professionals

So, at this point we have a pretty well-functioning package. In fact, what you're seeing above is 90% the same as what I've submitted to guix/guix, with the high hopes, that the contributors there would accept it and I'd have a proper foot in the ecosystem.

The reality is both a little disappointing and, in a sense, very reassuring. As it turned out, my package definition was lacking in quite a few things:

Instead of handling all dependencies correctly, I relied on (recurisve? #t), which is considered an anti-pattern. Instead, I should have unbundled all dependencies properly.
I missed some bundled files that could've been deleted from the source folder, as they're completely unused during the compilation process.
My install phase didn't quite install all the files necessary. I accidentally left out stuff like shell completions and integrations.
I didn't install the Terminfo files for WezTerm. This caused a lot of subtle errors with command line applications, that rely on these files to know how to manipulate the state of the terminal.
The version string I came up with was incorrect both per the Guix rules and WezTerm's own. The final version conforms to both.
Turns out WezTerm reads a file called .tag to figure its own version out. I didn't include this in my initial submission.
The way I patched libEGL and libvulkan are considered unidiomatic and can be replaced with a much simpler snippet, which just instructs Cargo to link these libraries as you'd usually do:
```
(setenv "RUSTFLAGS"
      (string-join
       '("-C" "link-arg=-lEGL"
         "-C" "link-arg=-lvulkan")
       " "))
```
The description I came up with was not quite up to snuff either, due to some sensationalized words that I didn't manage to cut.
And I had quite a few stylistic gaffes that weren't strictly wrong, but could be expressed much better. For a couple of examples:
- I used string-append to concatenate folders, even though Guile has a dedicated function for it called in-vicinity.¹²
- I kept referencing packages directly in places where search-input-file would have sufficed.
- I destructured lists using car and cdr, when match-lambda works much nicer for these purposes.

Yet, the story doesn't end on a sour note. I had three different contributors jump in and offer help and feedback, turning my package into one that truly deserves to be in the repository.

Of these three people, I'd like to specifically call out and thank hako, who also happens to be the person running and developing "Guix Moe", a project which includes a powerful build farm / mirror, and a hand-crafted, Nonguix-enabled LiveCD, which allows for much easier installation of Guix System.

Hako jumped in fairly early after I opened the PR and practically revamped my code from the ground up. Obviously much of the code remains mine, but the remaining extensions and refactors made the whole thing a lot more readable and correct and, without their help, I don't think my package would have made it in or at least not nearly as easily. They also went the extra mile to include all of the recommended fonts for WezTerm, which further fixed some failing test-cases and issues.

Being a software developer, I was already familiar with the experience of facing a code review, so having my PR thrown back for several days didn't feel too daunting. On the contrary, it was actually quite great to see the amount of care put into and attention given to my work. That's the beauty of free software and people acting out of genuine enthusiasm and willingness to help.

I hope my experience might assuage some worries of potential packagers: Your code doesn't have to be perfect! As long as you're willing to communicate and address change requests, you'll be fine and if things really are above your level, there will be others who will bear that load for you.

6. Conclusion

So ends about a week of coding around and finding out. As I happen to have some Nix experience, the process wasn't nearly as harrowing as it might seem from a first glance, but Guix definitely has a couple of rough edges.

One thing that I found a bit frustrating for example was how the manual can occasionally be outdated, causing people (like myself) who aren't "in the know" to commit mistakes that could've been easily avoided otherwise. For instance, it stipulates that you should use guix style to provide a consistent styling to your code. I've been following this advice and religiously formatting my code with each commit, only to be told by hako, that I actually shouldn't use the formatter at all, because it cannot cope with complex code.

Still, despite all this and even if Guix isn't quite as powerful from an infrastructure-perspective as, say, Nix, I believe the enthusiasm of its community still carries the experience hard and because of that, I came away from the experience with quite a positive impression while Guix came away with a working WezTerm package.

If you're reading this, you're only a guix pull away from being able to add wezterm to your manifest or guix install it and have it available on your system. If you happen to be a WezTerm user, I hope my package will serve you well.

Thank you for sticking with me in this quite long post! Till next time!

Footnotes:

I was trying to play Portal RTX and I was a bit annoyed that even though both that and KDE support HDR, I still cannot make the two work due to Gamescope not being present on Guix System.

I'm being intentionally vague here. The actual trip graphical data takes to your monitor is convoluted and varies by several factors including driver, manufacturer, whether you're using Xorg or Wayland, etc. Because of that I'm not very comfortable talking about it in any authoritative way and so I won't. It doesn't really matter in the context of this blogpost anyway.

Specifically LD_PRELOAD adds libraries to the front of the search path. This can be used to override libraries which can be used for things like injecting debug messages, using alternative memory allocation, etc.

It's an extremely powerful tool and a great attack vector if you happen to load in a tainted library. Since we're working with Guix-packaged stuff, we're fine, but it's not something to use without care and good reason.

⁴

In case you're unused to declarative lingo, you can think of a "derivation" as a deterministic result from a build script. Usually this is a software package (like WezTerm's in this particular instance), but the system is flexible enough to be utilized for basically anything that results in files.

For instance, the Guix home manager allows you to manage your dotfiles in a declarative way. The contents of the derivations built by Guix home are the files that are placed into your home folder including configuration files, scripts, and whatever else you may need.

⁵

Specifically what this means is that by the time the build system is engaged, you're only allowed to access data you've specified either in your inputs or the source of your package. The actual build itself happens inside a sealed off container without even network access. This is both for security reasons (a malicious package has a far smaller attack surface if it cannot talk to the cloud, nor even see your files) and to ensure reproducibility.

While Guix is primarily known for its FSF/GNU affiliation, one of their major goals is to provide a system that can be bootstrapped from the ground up using nothing more than a tiny binary seed and a long-long chain of programs of increasing complexity. It is an utterly fascinating topic and if you find it as fascinating as I do, I really suggest giving this website a read.

⁶

It's completely unrelated to the packaging journey in the post, but I found it really interesting, that Guix had a consensus vote about doing away with the recently controversial "master" name for the base branch.

It was nice to see the kind of pragmatism and forward thinking involved in this process: The maintainers weighed how much effort it'd take to update everyone from one branch to another, how difficult it'd be to undo, what other possible actions they could take, etc. Ultimately, the vote fell through in its infancy, due to not achieving majority support and master was kept.

Whether or not you agree with the outcome, I hope you're similarly pleased to see that this project takes its democratic values seriously. If I happen to stick with Guix for a longer while, I hope to one day join the decision making myself, even if only as a minor voice in the choir.

⁷

If you happen to be following along or thinking of writing your own package, please don't forget about the -j flag. It allows multiple parallel jobs to run and Guix's source is very well decoupled from each other. I have a 24-core Ryzen processor and it's a joy to see how fast make -j24 chews through the build process compared to the utter sluggishness of a single-core run.

⁸

It is worth noting that you have to get the package name right. When I first tried importing my crates, I didn't realize I had to use the final package's name and just entered finl_unicode, since I assumed I have to provide the name of the crate I wanted to import.

This ultimately sent me down a painful side-track that led nowhere until I finally read the docs better and realized I actually need to use wezterm. Learn by my mistake!

⁹

I'm actually not quite sure what's Guix's policy regarding tests. Some packages have them disabled, some enabled, some selectively disable some tests. In my variant of the package, I disabled them following other packages' example, but in the final variant, that other contributors helped out with, the tests are once again enabled.

¹⁰

There's also your personal profile's bin and sbin folders, current-system's sbin folder, stuff managed by guix home, etc.

¹¹

I'm not 100% sure if Vulkan is needed on AMD hardware. I have a sneaking suspicion that the error is at least partly caused by the fact that on Guix System NVIDIA hardware requires a small magic incantation to work with most packages. Still, whether the error is caused by the lack of Vulkan or not doesn't really matter, as the library is still a needed dependency of WezTerm, so adding it wasn't just for kicks.

¹²

In my defense in-vicinity is a fairly horrible name for a function that joins paths. I mean, yeah, sure, it technically means what it does, but surely path-append or construct-path would've worked a lot better.

Guix System First Impressions as a Nix User

2026-01-26T18:09:00Z

1. My Journey to Guix System
2. Installer Impressions
3. I Can't Find my Way-land
4. Sympathy for the Devil
5. Goals
6. Results
7. Overall
8. Notes

1. My Journey to Guix System

Feel free to skip this section if you don't really care about backstories. I just figured it makes sense to recap how and why one might start having an interest in declarative distros before tackling the main topic.

I've been a Linux-only¹ user for about ten years now and, like many others, I too embarked on the arduous journey of distro-hopping. I started with Mint and when that felt too slow, I switched to Ubuntu. When Ubuntu felt too handholdy², I switched to Arch, which proved to be my main driver for well over five or so years. And when I couldn't resist the Siren's call, I moved on to Gentoo, thinking surely "harder is better". Which resulted in severe burnout in a few months, so I capitulated and switched to Fedora, which was very stable and honestly an all around excellent system. But once more, my interest was piqued, and (before today's adventure) I finally switched to NixOS.

I've always had a passing interest towards Nix ever since I've first heard about it, but until fairly recently, I always dismissed it as a tool for DevOps guys. The syntax was weird, the need for reproducible environments seemingly irrelevant, and stuff like the oft-recommended Nix Pills seemed anything but newbie-friendly.

So then why would someone like me, who's so adamant about not needing Nix eventually choose to go all-in? I guess it was at first less about Nix being better and just the rest being worse.

Of the two big reasons for the switch, one was that I realized that having per-directory environments for your projects is actually a very handy thing to do when you like to toy around with many technologies. I used to generate my other blog using Jekyll and, no matter which distro I used, it was always a pain in the neck to have a good Ruby environment set up. bundler install didn't really want to work without privileges and I wasn't really a fan of unleashing sudo on it, but usually that was the only way I could get things to work.

With Nix, however, it was a matter of just describing a few packages in a shell and boom, Ruby in one folder, no Ruby (and thus no mess) everywhere else. I was hooked! I started adding shell.nix files to all my little projects, hell, I started planning projects by first adding a shell.nix with all the dependencies I would reasonably need.

The other reason, which ultimately cemented that I need to commit, was that I was getting tired of my installed packages slowly drifting out of control. Sure, every package manager has some method of listing what's installed, but these are usually cumbersome and completely ephemeral (in the sense that any listing becomes invalid the moment you change anything).

With NixOS, the equation is flipped on its head: No longer did I query the system to tell me what's installed and what's not, it was now the system that worked based on files that I edit. The difference sounds small on paper, but for me it was an extremely liberating feeling to know that I could edit my system configuration in a versionable, explicit, and centralized way.

But NixOS isn't the only declarative distro out there. In fact GNU forked Nix fairly early and made their own spin called Guix, whose big innovation is that, instead of using the unwieldy Nix-language, it uses Scheme. Specifically Guile Scheme, GNU's sanctioned configuration language. I've been following Guix for a bit, but it never felt quite ready to me with stuff like KDE being only barely supported and a lot of hardware not working out of the box.

However, now that (after three years) Guix announced its 1.5.0 release with a lot of stuff stabilized and KDE finally a first-party citizen, I figured now is the best time to give it a fresh shot. This post captures my experiences from installation to the first 3-4 days.

Note: Ultimately, after a tumultuous month of usage, I decided not to stick with Guix System. While my enthusiasm and excitement towards Guix remains the same, it sadly still doesn't deliver quite the amount of stability and availability as I hoped. For more details, please see my followup article.

2. Installer Impressions

Plug your USB in, dd the file onto the drive, reboot, nothing unusual. If you've ever installed a Linux system, it's more of the same.

After selecting the pendrive in my BIOS settings, the monitor began to glow in a deep, radiant blue as the Guix System logo appeared on my screen… only to suddenly switch to a menacing red: My CPU's integrated GPU is not supported by free firmware. A helpful popup gave me a gentle nudge about picking free hardware next time (buddy, have you seen the PC part prices these days?) and off I went into the installer proper.

Figure 1: Picture of the installer graciously borrowed from the Guix installer manual.

The installer itself is refreshingly barebones and I mean this in a positive way. It asks all the necessary questions and provides a nice basic configuration file, all done in a retro Ncurses-based TUI. I was really happy to see that, unlike my last attempt at using Guix System in the early 2020-s, KDE Plasma is now a first-party choice during installation. I never really vibed too much with GNOME and the other options didn't appeal either, so the choice was obvious.

Now, I'm not sure if I just picked the worst possible time or if the Guix servers were facing unusual load or whatever may have happened, but after such a breeze of a setup, the moment I pressed install, my PC became unusable for the next 2.5 hours. Which is unacceptable for an installation process these days in my opinion. I am lucky enough to live in a household with fiber-optic internet, that merely shrugs at bandwidth of up to a gigabit per second and yet nearly all packages downloaded with a whopping 50 kilobit per second, meaning even small-ish 5-10 megabyte packages took long minutes to download.³

A reboot later my issues only got worse.

3. I Can't Find my Way-land

I was assuming I'd get SDDM after having chosen KDE Plasma, but (what a later, closer read of the manual made me realize is the expected outcome for a default config) it was GDM that loaded in. I entered my name and password, and I was greeted with the familiar Plasma 6 spinner. The first hint that something might be off was that it loaded a bit longer than usual, but I was not going to get mad at waiting 10 seconds instead of 3. After all, I did just wait magnitudes longer to get here.

With practically nothing installed beyond the very basics, I clicked on Konsole, hoping to start prodding around my config and add some of my day to day apps. To my horror, it opened in the top left corner, without a titlebar and without any borders. What's more, no matter what I did, I couldn't move it. It also didn't show up on the menu bar, despite the application launcher still being completely usable. At this point I was fairly exhausted by these antics, but I figured,

Well, it's a brand new release, perhaps this just snuck in. Let's give updating a shot and see if that helps.

So I issued guix pull… The download whizzed by with speed quite unexpected after what I experienced with the installer… Only to crash into the brick wall that's indexing. Okay, whatever, another 10-12 minutes down the drain, at least now I have newest version.

Figure 2: Better than before download speeds

Except I didn't. Because, unlike Nix, the guix executable is not an omnipresent, unique thing that anyone and everyone uses on your PC. Not only does every user have their own instance, if you don't issue a certain set of commands, you won't start using the new version, despite updating it.

To Guix's credit, the CLI does scream at you to update your environment or else you'll keep using the old version, but I still find this system very disorientating compared to Nix. I'm certain experienced Guixheads are long past being tripped up by this sort of stuff and might even struggle to remember that there was a time they had to do these special steps too, but as a new user it felt a bit rough, especially consdering this is Guix System, i.e. the system whose whole purpose is to be integrate Guix as much as it can.

Back to our issue at hand. I issued sudo -s and guix pull-ed again. Once more 10-12 minutes passed indexing. But at least I could finally call guix system reconfigure /etc/config.scm. Interestingly things are much faster this time around, I saw speeds up to 30-50 Mbps. Before long the system was updated to the newest commit and I rebooted with high hopes.

High hopes, that were immediately dashed when Plasma loaded in the same messed up way. At this point I started to suspect this might be an issue with the GPU driver, so I enabled the LXQT desktop environment and rebooted once more. Thankfully that one worked like a charm and I was able to boot up both Emacs (editing Scheme with GNU Nano is a pain I do not wish on anyone) and LibreWolf (Firefox's de-Mozilla-d variant).

Not having found anything too useful in the docs, I decided to make my problem someone else's so I fired up ERC⁴ and connected to Libera.chat's #guix channel. After around half an hour of wait, a user by the name of Rutherther stepped up and offered me some help. We were able to figure it out that Nouveau wasn't able to drive my GPU (an RTX 5070), so his recommendation was that I should try booting with nomodeset. I did, but it sadly didn't help much either.

4. Sympathy for the Devil

At this point I was out of ideas. Ideas of solving this using pure-Guix System, that is. There was still one option I wanted to avoid as long as I could, but alas, it seemed like the only option, that still had a realistic chance of working.

Figure 3: Nonguix's official logo, self-described to be "dark and evil".

Enter Nonguix, the Mr. Hyde to Guix's Dr. Jekyll, the shady guy who offers you a hit and first time's for free, the… Erm, in a nutshell, it's the repository for non-free applications and drivers packages for Guix System, basically. Interestingly enough, by Guix's own findings about 64% of users utilize the Nonguix channel, which is perhaps not "literally everyone", but it does paint a picture that there is still stuff out there that you simply cannot replace with FOSS software yet.

Listing 1: At the time of writing, this is all one has to do to enable Nonguix.

 1: (cons* (channel
 2:       (name 'nonguix)
 3:       (url "https://gitlab.com/nonguix/nonguix")
 4:       ;; Enable signature verification:
 5:       (introduction
 6:        (make-channel-introduction
 7:         "897c1a470da759236cc11798f4e0a5f7d4d59fbc"
 8:         (openpgp-fingerprint
 9:          "2A39 3FFF 68F4 EF7A 3D29  12AF 6F51 20A0 22FB B2D5"))))
10:      %default-channels)

Enabling the repo wasn't exactly difficult. You just paste the short excerpt from above (also found in the README) into your ~/.config/guix/channels.scm, guix pull, let it index to its heart's content again, and then you have access to all that is nasty (yet occasionally useful) in the world.

I figured perhaps if Linux-libre and its free firmware couldn't deal with my GPU, then surely Linux proper with its binary blobs could. Hell, for good measure I threw in the NVIDIA transform, which is supposed to automagically translate all dependencies to use the proprietary drivers.

Figure 4: What haste and half-reading manuals gets you…

Turns out my eagerness was a mistake. Not only did the process take yet another half an hour (if not more, I stopped counting), upon reboot all I was met with was a kernel panic about the driver not being able to cope with the GPU it found and a massive spew of FSCK logs.

Figure 5: 'FSCK' was indeed very close to the first words that came to my mind at this moment.

With no better ideas in mind, I took out my pendrive again and burned Nonguix's own pre-built ISO on it using my partner's PC. While it ultimately did get me a working system, this version has three unfortunate hindrances:

It was built in 2022, far before Guix's migration to Codeberg, meaning it still attempts to pull content from the unfathomably slow GNU Savannah mirror. I had to manually override my channels.scm to point at the Codeberg repo instead, but with no easy means of finding its "channel introduction"⁵, I had to pass in --disable-authentication to Guix when updating my system. A bit scary, but I trust the Codeberg repo.
Because of its age, I got a lot of somewhat intimidating errors about hardware not being recognized and other stuff I couldn't even decipher, but ultimately the system booted to the installer without issue.
For some reason while the installer itself does include Nonguix stuff, it actually does not include the repo in the resulting channels files, nor the substitution server for the project. The README has a warning about this, but if you happen to miss it, you could accidentally install a non-Nonguix Guix System (say that three times fast).

None of these were particularly hard to fix, however, and soon enough I was back where I started. That is to say, in a nomodeset X11 session, except this time running i3, as LXQT wasn't an available option on an installer this old. There was certainly a bit of a hacker-ish vibe to messing with code files in an environment like that, but I was honestly much more looking forward to finally having a usable desktop.

Having learned from my hastiness, this time I was smarter. I only enabled the full kernel and firmware blobs, without going anywhere near the NVIDIA transform. I issued another guix system reconfigure and, after having time for another tea session, my update was finally finished.

I rebooted with tentative nervousness and… Success? Huh.

5. Goals

Obviously there is little point in throwing Guix System on my PC and declaring success. I wanted to be able to at least reproduce the kind of workflow I'm used to using NixOS. For that, I need the following:

A browser: preferably Firefox, as I'm not a huge fan of Chrome / Chromium,
An E-mail client: preferably Thunderbird,
A basic office suite: preferably LibreOffice,
Dev environments: for Rust, Zig, Scheme, and TypeScript (with the option for more, if possible),
Emacs: I do almost all my text editing in it these days, falling back to Neovim for quick tasks,
Discord: for chatting with friends,
Telegram: for chatting with family,
Steam: for the very rare occasions I want to game,
NVIDIA drivers: I prefer to offload day-to-day usage to my CPU's integrated GPU, as it cuts my energy usage in half.

Of these it was obvious that two would be relatively hard and one "outright impossible". The two being Steam and the drivers (as both are non-free and thus not in Guix's default repos) and the "impossible" one being Discord (which not even the non-free repo has packaged). But I was ready to compromise a little bit since I am requesting stuff that's explicitly against Guix's goals.

6. Results

Figure 6: My desktop running Wezterm packaged by me and Emacs.

While there has been occasional bumps and hitches along the ride, I must say I'm very impressed with Guix System so far. Let's go through this list in order:

Browser: So far I'm really enjoying LibreWolf. It feels a lot snappier than Firefox and I'm really baffled how much speed I was apparently missing out on.
E-mails: I installed Icedove, which is basically just Thunderbird without Mozilla branding. It works as expected.
Office suite: LibreOffice is available as expected. Not much to say about it. I guess it's interesting that Guix isn't following the usual -stale / -fresh packaging schema, but I don't really mind not having cutting edge versions of an office suite :)
Dev environments: I've only briefly toyed with development environments so far, but to me it seems like for simple use-cases it might be even easier to use than shell.nix (you don't need any sort of ceremony, just a manifest.scm file with a (specifications->manifest <list of packages>) form inside and you have a dev env ready to go.)
Emacs: Installed just fine. I had to install emacs-vterm to make Vterm work, but all that took was the very simple process of adding the library to my home configuration and then referencing it in my Emacs config as per this Reddit post.
Discord: I decided to just use Discord's browser version, which works just as fine (if not better). It's trading a tiny bit of convenience in return for not having to figure out how to manually add a package for it from some random third-party source. From what I've read elsewhere Flatpak is also an option, but I prefer having just one package manager at a time.
Steam: Installed shockingly easily. I have to really give props to the Nonguix team. I tested Portal 2 with the Nouveau driver, it is a little disheartening to see a 15 years old game⁶ lag, but I understand the people's hands are tied when it comes to the free drivers. After I managed to install the proprietary drivers, I was able to play even Portal RTX, which is something I never managed to get to work using NixOS.
NVIDIA drivers: This time I actually read the docs properly and it didn't take long for me to realize the initial problem that caused my previous install to be unbootable was of course found between the chair and keyboard. This time, after making sure I enabled the open drivers and kernel mode-setting, I crossed my fingers, issued a reconfigure and it works beautifully!

6.1. The Good

Helpful community: While I do feel like Guix's community could be much larger (see below), the one that exists is very helpful and nice from my limited experience. In all places I've looked so far (Libera's #guix, /r/Guix, and the guix/guix Codeberg repository) I was met with genuinely kind and helpful people.

That is not to say I haven't seen some bad eggs, especially in posts from years ago, but I don't think there is any community without those, so I'm not going to cite this as a negative.
Home configuration: Having guix home be a built-in, first class citizen, instead of a community made "extension" is excellent. Instead of needing to consult a third-party resource like Home Manager's documentation you can simply use what you already know about Guix and, if you happen to hit a wall, you can just read the official handbook which is guaranteed to always stay up to date with the rest of the system.
Package availability: As long as you largely use FOSS stuff (which is much easier than one might think), the amount of choice is awesome. I could basically just copy over the list of packages from my Nix config and practically everything had an equivalent.
Scheme: I'm not really a seasoned Schemer, but I have dabbled in the language previously and it feels so much better to me than Nix (the language) ever did. One great benefit of this is that it's a lot easier to start digging into package definitions to figure things out for yourself.

This is "Freedom 1" of GNU's Four Essential Freedoms in effect. Since the code is pretty much just Scheme and the different mechanisms available are fairly well documented (see caveat below), the barrier to entry is much lower than with Nix in my opinion.⁷

Another nice benefit of this is that you can use Emacs' extensive Scheme support to help your configuration. Tools like Geiser can plug right into Guix and help you find package and function names and, once you're experienced enough, debug your config/packages on the fly. I personally haven't yet achieved mastery of such level yet, but having the REPL confirm if I've entered names in correctly before running the code is already a boon.
Ease of hacking: In the "to tinker on" sense, rather than "being insecure". With Nix, merely pulling in Nixpkgs is an effort, due to the repository being massive. My otherwise beefy machine struggled to switch between branches and make commits, which doesn't exactly inspire confidence in contributing, even though it was otherwise something I was excited to do. Meanwhile, with Guix I was able to get a fully functioning development environment in 15 minutes tops, which includes cloning the repo, authenticating all commits, generating bytecode for the entire repository, and getting Emacs set up to work nice with the codebase.

Not to mention, at the time of writing my Nixpkgs PR of guile-colorized is still not accepted, despite being open since October, 2025. Which is kind of disheartening, when the package is really trivial and has a very low blast-radius. With Guix I got an answer to an extremely noobish question on my first PR in mere hours.

On a separate, but related note, I also found it a lot easier to test my package in a "live" environment as guix pull supports a parameter called --url which you can easily point to a folder on your own PC. So once I was confident my code should work, I could just "check out" my local repository clone and build it like I was an end user. This let me make sure it really does work.

6.2. The Ambiguous

Search: guix search not taking an extra parameter like nix search is both very convenient and a bit of a bummer.

Its absence is not a deal breaker, but I really loved how with Nix, you could search in anything, that has a flake. Be that Nixpkgs, a repo you downloaded, a repo that's on a git forge, etc. I remember being awestruck that I could just do nix search github:mozilla/nixpkgs-mozilla and search for their builds of Firefox without having to manually check out anything.
The documentation: Oof, this one is a bit hard to pass definite judgment on.

On one hand I love the thoroughness of it all. You can get a fairly decent idea of what Guix, what it can do for your, how to use it, and how to extend it, just by reading the manual. It is evident that the Guix team and GNU in general takes its mission to educate using free software very seriously. Stuff like the Packaging tutorial make it very easy for complete beginners to hack together package definitions without needing to consult any other resource.

On the other hand, it really is just a manual, not a tutorial. What I mean by this is that concepts that could belong together aren't placed near each other. A simple example would be services and customizing them. Assuming, you're in one of the sub-pages of Services and you suddenly realize you want to replace/modify one of the services, you are left completely clueless how that works. You have to go to a completely different chapter and find one particular function's description and then apply what you learn there. The Guix Cookbook has some examples, but you have to know about the cookbook in the first place.

And before anyone misunderstands me, I'm fine with RTFM, but in my opinion one of the preconditions of mass-appeal is having "pre-chewed" solutions for common problems, that don't require perusing multiple chapters.

6.3. The Bad

Substitute server stability: I imagine this is an issue that only a massive bag of money could fix, but the CI/CD servers could definitely use some more processing power. It's really annoying when you're trying to test something and you're suddenly forced to wait 10-15 minutes because the server can only spare 50-100 kbps for you.
Content out there: Clearly this isn't the Guix team's fault (and it's something I'm trying to lessen with this post, even if just a tiny bit), but it's really hard to find good quality material when it comes to Guix.

I mean, sure, there is the excellent System Crafters tutorial series, and the odd gems like DThompson's dev env tutorial, but as a whole you're largely left to your own to trawl through the manual, IRC logs, Reddit threads, Codeberg and the previous issue tracker, etc. It's not an impossible task, especially if you're used to doing Linux things "the hard way", but it's certainly a far cry from such one-stop shops as the Nix Flakes book or Wombat's Book of Nix.
Guix's own build speed: Nix excels in speed, so I was hoping Guix would be the same. Yet stuff like guix pull really bog things down. Doubly so, if you want to update not just your own guix instance, but also root's.
Clarity of commands: The fact that all concerns are lumped together (unlike Nix's many utilities) means that to the new user the many commands such as guix pull, guix {system, home} reconfigure, guix update can easily feel overwhelming and unclear what's updating/changing what. With time I'm sure you obtain a sort of mental muscle memory and you never think about it again, but starting out it's definitely a confusing part.

7. Overall

Listing 2: My current, fairly barebones Guix home config.

 1: (define-module (guix-home-config)
 2:   #:use-module (nongnu packages)
 3:   #:use-module (gnu packages)
 4:   #:use-module (gnu home)
 5:   #:use-module (gnu home services)
 6:   #:use-module (gnu home services shells)
 7:   #:use-module (gnu services)
 8:   #:use-module (gnu system shadow)
 9:   #:use-module (guix gexp))
10: 
11: (define %packages
12:   (list "git" "openssh" "librewolf" "ripgrep"
13:         "bat" "eza" "fd" "zoxide" "bc" "gimp"
14:         "libreoffice" "jujutsu" "starship" "direnv"
15:         "okular" "gwenview" "bitwarden-desktop"
16:         "icedove-wayland" "telegram-desktop"
17:         "emacs-vterm" "ispell" "hunspell" "wezterm"))
18: 
19: (define %nonfree-packages
20:   (list "steam-nvidia"
21:         "mpv-nvidia"))
22: 
23: (define home-config
24:   (home-environment
25:    (packages (specifications->packages (append %nonfree-packages %packages)))
26:    (services
27:     (append
28:      (list
29:       (service home-bash-service-type
30:                (home-bash-configuration
31:                  (aliases '(("ls" . "eza")))
32:                  (bashrc (list (local-file "./bashrc.sh")))))
33: 
34:       (service home-files-service-type
35:                `((".guile" ,%default-dotguile)
36:                  (".Xdefaults" ,%default-xdefaults)))
37: 
38:       (service home-xdg-configuration-files-service-type
39:                `(("gdb/gdbinit" ,%default-gdbinit)
40:                  ("nano/nanorc" ,%default-nanorc))))
41: 
42:      %base-home-services))))
43: 
44: home-config

In a nutshell I'm very positively surprised by Guix System. After struggling so much with it years ago, this time everything just clicked after a much shorter battle. So much so that I'm happy to make it my daily driver for the foreseeable future. Beyond the slightly slower execution speed, I'm getting a comparable experience to NixOS, with all the usual pros a declarative environment brings and without having to put up with Nixlang.

My only recurring issues so far are the occasional slow download speeds and that I have to start my kernel in nomodeset because otherwise the graphical environment crashes without me being able to switch to a TTY. It's a bummer, but honestly, I'm not too bothered by it so far. I'm trusting a driver update will fix it soon enough and, if not, it's not exactly difficult to throw in a kernel parameter into your config.

I'm hoping to do a followup post about packaging in Guix, because I've been dipping my toes into it by trying to package Wezterm and the journey there was similarly arduous as installing the system itself.

Till then, thank you for reading and see you next time!

8. Notes

The stuff you see below are all I managed to write down mid-process. Some of these I threw it into the file from Nano, some from half-broken X11 sessions. Because of this, it's not exactly well-edited, but I hope it might provide a glimpse into my mind at the time.

The installer is decently simple

I appreciate the warning about incompatible hardware

2.5 hours at least to install (mirrors throttle connection to 50kbps)

KDE is simply not working out of the box (titlebars are missing)

It seems to also default to X11, when I'm looking for Wayland

The first guix pull is horrendously slow

Wayland continues to elude me, seems to be an Nvidia issue

IRC recommends nomodeset, doesn't help

Try enabling Nonguix, system no longer boots

Try installing using the Nonguix ISO

Lots of errors, terribly old release

Having to guix pull myself to the present day again

Also I'm missing the introduction, so I have to run it using --disable-authentication, not great, but I trust the Codeberg repo

At least the download speed seems to have normalized

It isn't entirely clear when you have to use sudo

Running i3 on a shitty low-res has a certain vibe to it, but I'd prefer a system working out of the box

Footnotes:

Well, if only life was so easy. What I mean here is that on my personal computer, I've not had Windows since about 2015. For work purposes my hands are currently chained to MacOS (though even there I use a Debian-based container).

No disrespect to Ubuntu-users, past and present! My opinion at the time was quite ignorant and nowadays I far more appreciate an easy to maintain system as you'll see from the rest of this post.

It's merely a hunch, but it feels to me that the servers are far slower during the (Central-European) night. During midday, I get really good download speeds, but after around 8 PM, it slows to a crawl.

⁴

Which, for the uninitiated, is an IRC client built into Emacs. This editor continues to wow me every day.

⁵

I probably could have figured it out in time. But at this point I was a bit exasperated and I really didn't want to type in an 10x4 character hexadecimal code by hand.

⁶

Goodness gracious, Portal 2 is almost 15 years old…

⁷

That being said, my Nix experience was still very much helpful here. Understanding stuff such as build phases, why packages need to be patched and how this usually works, and what the different build flags mean is pretty much a must if you want to attain an understanding deeper than just "kinda getting it."

Implementing Perlin Noise in TypeScript

2026-01-20T19:25:00Z

1. Introduction
2. Basic outline
3. Implementation

1. Introduction

Ever since I first started programming, I was always fascinated by noise functions. The idea that you can take a relatively simple algorithm and generate realistic-looking textures of clouds, fire, cloth, etc. is really cool.

However, as simple as the concept is, I still found myself struggling with putting it into code, until the idea one day clicked and I was able to finally implement it. To help others, who might wonder how this algorithm works, I'd like to share a small tutorial here how one might go about implementing a simple variant of Perlin noise in TypeScript.

One caveat of the code below is that it focuses more on readability, without paying much attention towards performance and optimization, and thus isn't exactly fast, despite the algorithm being Embarrasingly Parallel. For more serious implementations one should consider following the original algorithm's permutation lookup table-based approach, use WebGL with a fragment shader that can easily compute every point's noise value at the same time, ~~or just use a better language than JS…~~

2. Basic outline

Given an arbitrarily sized rectangle, we need to do the following steps to fill it with noise:

First we divide the rectangle into a grid of squares. The size of these squares is freely adjustable by us and it determines the general "roughness" of the result.
For each of these grid points, we generate a so-called gradient vector. In the context of Perlin noise, these are little more than vectors whose magnitude is 1 and which point in random directions.
Then, for every pixel inside the original rectangle, we gather the four closest grid-points and their accompanying gradients.
We calculate the dot product of the vector formed by the pixel's coordinates and each of the gradients.
To smush these values into one, we take a proportional part of both the upper and lower corners' values based on the X coordinate of our pixel and then calculate a final value from that based on the Y coordinate.

3. Implementation

3.1. Vector class

 1: class Vector {
 2:   x: number;
 3:   y: number;
 4: 
 5:   constructor(x: number, y: number) {
 6:     this.x = x;
 7:     this.y = y;
 8:   }
 9: 
10:   static random_gradient(): Vector {
11:     const angle = Math.random() * 2 * Math.PI;
12:     return new Vector(Math.cos(angle), Math.sin(angle));
13:   }
14: 
15:   sub(other: Vector): Vector {
16:     return new Vector(this.x - other.x, this.y - other.y);
17:   }
18: 
19:   add(other: Vector): Vector {
20:     return new Vector(this.x + other.x, this.y + other.y);
21:   }
22: 
23:   dot_product(other: Vector): number {
24:     return this.x * other.x + this.y * other.y;
25:   }
26: 
27:   toString(): string {
28:     return `(${this.x}, ${this.y})`;
29:   }
30: }

We begin by defining a very rudimentary Vector class. Usually we'd define more operations, like multiplication, length, etc., but for our purposes this suffices.¹

You may wonder why we bother to define toString, when our end result will be graphical anyway. The reason is simple: We are going to associate data with our coordinates, using JavaScript's built-in Map. However, because these don't support indexing by objects, we need to first convert our Vector into a string, which does work as a key.²

3.2. Interpolation function

In our algorithm, every pixel's value comes from four different values, but the end result needs to be only a single value. Therefore we need a function that, when given two numbers, allows us to pick a third, that is a mix of a given percentage of one of our numbers and a complementary percentage of the other. For this we utilize Linear interpolation:

31: function lerp(percent: number, start: number, end: number): number {
32:   return start + percent * (end - start);
33: }

This function takes a [start, end] range and a percentage, and has the following properties:

lerp(0, start, end) = start + 0 * (end - start) = start,
lerp(1, start, end) = start + 1 * (end - start) = start + end - start = end,
Otherwise, lerp(x, start, end) = ((1 - x) * start) + (x * end).

Example: Let's say our inputs are 0.25, 1, and 5. We add to 1 a fourth of the difference between 5 and 1, thus get 1 + 0.25 * (5 - 1) = 1 + 0.25 * 4 = 1 + 1 = 2. If we were to pick 0.5 as our percent instead, our result would be 3 which is the exact middle between 1 and 5.

This already works, but it's less than ideal because the edges of the interpolation function are very sharp leading to very obvious artifacts on the edges of grid cells:

Figure 1: Noise full of visual artifacts.

It's easy to see why this happens if we take a look at how interpolating between some random values looks like:

Figure 2: Sharp peaks and valleys that show up as visible lines in our noise.

Thankfully fixing this is fairly simple. If the issue is that the endpoints' connections are too sharp, we simply have to smoothen them out. Enter the "Smoothstep" function:

34: function smoothstep(x: number): number {
35:   return 6*x**5 - 15*x**4 + 10*x**3;
36: }

Figure 3: The Smoothstep function visualized in the range [0, 1].

Given a number between [0, 1], this function returns another value between [0, 1], but "smoothened out". To provide a better visual explanation of what this means, let's see the previous interpolation, after we ran our percentages through Smoothstep:

37: function interpolate(percent: number, start: number, end: number): number {
38:   const smooth_percent = smoothstep(percent);
39:   return lerp(smooth_percent, start, end);
40: }

Figure 4: The peaks and valleys are gone.

As you can see, the end result looks a lot more "natural" as one curve flows nicely into the next, without any obvious edges.

3.3. Noise function

With all the groundwork finally done, we reach the main algorithm. Let's take it in parts:

41: const gradients = new Map<string, Vector>();
42: 
43: function get_gradient(vec: Vector): Vector {
44:   const key = vec.toString();
45:   let gradient: Vector | undefined = gradients.get(key);
46: 
47:   if (!gradient) {
48:     gradient = Vector.random_gradient();
49:     gradients.set(key, gradient);
50:   }
51: 
52:   return gradient
53: }

First we initialize a Map to hold our calculated gradients. This both serves as an optimization (we only need to calculate a gradient for every grid cell corner once) and also ensures that every corner always gets the same gradient (our random_gradient function has no knowledge about the outside state of our function, so it'll happily generate as many random vectors as we ask for).³

55: const offset_vectors: Vector[] = [
56:     new Vector(0, 0),
57:     new Vector(1, 0),
58:     new Vector(0, 1),
59:     new Vector(1, 1),
60: ];

We then create four offset vectors, which will help us address the grid cell's corners.

62: function noise(x: number, y: number): number {
63:   const coordinate_vector = new Vector(x, y);
64:   const floored_vector = new Vector(Math.floor(x), Math.floor(y));
65:   const fraction_vector = coordinate_vector.sub(floored_vector);

Our function takes in an X,Y pair representing the coordinates of a pixel. This pair is turned into three separate vectors:

one for the raw coordinates (coordinate_vector),
one for the grid cell (floored_vector),
and finally the relative position of the coordinates inside the grid cell (fraction_vector),

66:   // top left, top right, bottom left, bottom right
67:   const [tl, tr, bl, br] = offset_vectors.map((offset_vector) => {
68:     const corner_vector = floored_vector.add(offset_vector);
69:     const gradient = get_gradient(corner_vector);
70:     
71:     return coordinate_vector.sub(corner_vector).dot_product(gradient);
72:   });

Next we calculate the dot products between the vector of our pixel's coordinates and each corner's gradient. get_gradient ensures we always get the same gradient for a given corner.

73:   const upper_interpolation = interpolate(fraction_vector.x, tl, tr);
74:   const lower_interpolation = interpolate(fraction_vector.x, bl, br);
75: 
76:   const noise_value = interpolate(
77:     fraction_vector.y,
78:     upper_interpolation,
79:     lower_interpolation,
80:   );
81:     
82:   return noise_value;
83: }
84:

Finally we do a 2D interpolation using the function we defined earlier. We first interpolate between the ranges of [top left, top right] and [bottom left, bottom right] using the pixel coordinate's relative X position, and then, with one final interpolation using the coordinate's relative Y position, we get our noise value.

3.4. Main loop

 85: function generate_noise(
 86:   width: number,
 87:   height: number,
 88:   resolution: number
 89: ): Float32Array {
 90:   gradients.clear();
 91: 
 92:   const values = new Float32Array(width * height);
 93: 
 94:   for (let y = 0; y < height; y++) {
 95:     for (let x = 0; x < width; x++) {
 96:       const x_percent = x / width;
 97:       const y_percent = y / height;
 98: 
 99:       const value = noise(
100:         x_percent * resolution,
101:         y_percent * resolution,
102:       );
103: 
104:       // Map [-1, 1] => [0, 1]
105:       values[y * width + x] = (value + 1) / 2;
106:     }
107:   }
108: 
109:   return values;
110: }

First we clear the gradients map, as we don't want any previous data to interfere in case this isn't the first time we run the function.

Then we iterate through every pixel in our rectangle and calculate its coordinates, mapping [0, width] and [0, height] to [0, 1]. We also take a parameter called resolution, this determines how "zoomed in" our noise looks like:

Figure 5: Noise with high resolution value.

Figure 6: Noise with low resolution value.

Finally, our noise function returns values in the range of [-1, 1], but we need [0, 1], so we add one to our result, mapping it to [0, 2] and then divide it by 2, thus end up with [0, 1].

111: document.getElementById("button").addEventListener("click", () => {
112:   const canvas = document.getElementById("canvas") as HTMLCanvasElement;
113:   const ctx = canvas.getContext("2d");
114: 
115:   const maxFactor = Number(
116:     (document.getElementById("factor") as HTMLInputElement).value
117:   );
118: 
119:   const baseFrequency = Number(
120:     (document.getElementById("frequency") as HTMLInputElement).value
121:   );
122: 
123:   const width = canvas.width;
124:   const height = canvas.height;
125:   const imageData = ctx.getImageData(0, 0, width, height);
126: 
127:   imageData.data.fill(0);
128: 
129:   for (let factor = 0; factor <= maxFactor; factor++) {
130:     const values = generate_noise(width, height, baseFrequency * (2 ** factor));
131: 
132:     for (let y = 0; y < height; y++) {
133:       for (let x = 0; x < width; x++) {
134:         const idx = y * width + x;
135:         const value = values[idx];
136:         const color = Math.floor(Math.max(0, value) * 255 / (2 ** (factor + 1)));
137: 
138:         imageData.data[idx * 4 + 0] += color / 1.5;
139:         imageData.data[idx * 4 + 1] += color / 1.3;
140:         imageData.data[idx * 4 + 2] += color;
141:         imageData.data[idx * 4 + 3] = 255;
142:       }
143:     }
144:   }
145: 
146:   ctx.putImageData(imageData, 0, 0)
147: });

Since I don't want to cause lag immediately on page load, I bound the noise generation to a button that you can find below. We request the underlying image data from our canvas element and zero it out. This is done as a precaution in case the user presses the button multiple times. Without this reset, the += operations below would quickly oversaturate our output image.

For this demo, I added two user-controlled variables, these being factor, which determines how many layers of noise we generate and baseFrequency, which determines the initial resolution (i.e. roughness) of the noise. For some examples, try a factor of 8 and frequency of 1 for a gentle fog and 4 and 16 for a fuzzy carpet.

We generate a noise array with the given iteration's frequency and fill in the current pixel based on the value of the noise. I skewed the numbers a little to get a pleasant blue color, without any modification, we'd be left with a grayscale image.

Factor: Base frequency:

Thank you for reading this post and I hope you may have learned something fun! If you'd like to read the code as a whole, you can access it here.

Footnotes:

In fact, we could easily get away without a class and just use inlined operations with either {x: number, y: number} objects or [x, y] arrays, but I believe the class-based version provides most pedagogical clarity, so that's the one I went with.

Technically the Map really doesn't care what we pass in as key. But since all keys are coerced into primitives, all of our Vector-s would be turned into strings in the form of the dreaded "[object Object]" and lose their identity, which would pretty much defeat the point of a hash-map. To avoid this, we override toString and instead return a sensible and, more importantly, unique string representation, that our map can take with no issue.

Those who are already familiar with the algorithm (or just read its Wikipedia page before continuing this article) might have realized that this is a vastly different way of generating gradients compared to the original version.

In the original we only have a handful (8 or 16) pre-generated gradient vectors and we pick one of them based on a somewhat involved process of hashing the current coordinate and then chopping off the lower 4 bits of the resulting number. While this most likely results in faster code, I find that it somewhat obscures of what we're really doing.

Nemin's Blog

Solar power

Table of Contents

1. The plan

2. Parts of a solar setup

3. My particular setup

3.1. Power station

3.2. Solar panel

3.3. Cabling

4. The initial results

4.1. Shortcomings of the RIVER 3

5. A hasty, but needed upgrade

5.1. Shortcomings of the Anker SOLIX

6. Conclusion

Footnotes:

Be aware of your Locale

Table of Contents

1. The problem

2. The solution

Footnotes:

I got LASIK Surgery

Table of Contents

1. The issue that broke the camel's back

2. The breakthrough

3. Pre-op tests

4. The day of the operation

4.1. The moments before the operation

4.2. The operation

4.3. The moments after the operation

4.4. At home

5. The day after

5.1. Checkup

6. Day 3

7. Day 4

8. Day 5 and Conclusion

Footnotes:

Guix System - One Month Later

Table of Contents

1. Community

1.1. IRC

1.2. Mailing lists

1.3. Subreddit

1.4. Fediverse

2. Packaging wows and woes

2.1. I really love the go-getter attitude of Guix

2.1.1. A side-note about speed

2.2. Debugging is an unpleasant experience

2.2.1. Missing parentheses

2.2.2. Non-existent variables

2.2.3. Circular dependencies

2.3. A cornucopia of styles

2.4. ChangeLog is confusing

3. System ups and downs

3.1. Stability of my config

3.2. Interfacing with my phone

3.3. Blunderbird

3.4. NVIDIA drivers and non-LTS kernels

3.5. No easy way of seeing what is updated

3.6. Sleep causes crashes

3.7. Odd freezes and crashes

4. Conclusion

Footnotes:

LLMs Are Taking the Joy Out of Our Lives

Table of Contents

1. Job

2. Hype-driven death march

3. Art-robbery

4. Post-truth society

5. We're burning our planet for… this?

6. I'm not fully innocent, but at least I care

Footnotes:

Adventures in Guix Packaging

Table of Contents

1. Introduction

2. Baby steps

3. Enter WezTerm

3.1. A mediocre first attempt

3.2. A brief second attempt at packaging locally

4. Third time's the charm

4.1. Setting things up