turboponyy

> It seemed reasonable to me record the deployment history in the repository

That doesn't seem reasonable to me. You'd be using Git for persistence concerns that are not directly related to source code management.

"Environment X had commit a1b2c3d deployed at 1970-01-01T00:00:00Z" is all you need to store, and I don't see why you'd want to do that in the repo itself. Commit a1b2c3d exists regardless of where or when it's deployed.

Store that data in the thing that handles the deployments.

Not really. If I'm using a linter, I go and configure the strictest possible ruleset, and only disable rules when justified on a need-by-need basis. It's just a matter of discipline.

I guess the Gnome-specific part is that Gnome comes with the Nautilus file browser, and the instructions add a script for Nautilus.

But yea, this will work as long as you have imagemagick and Nautilus installed.

I'm currently using niri (was previously using Hyprland).

Having used dwm-like tiling window managers for most of the time, I don't really care for the scrolling or dynamic workspace aspects of niri at all - in fact, I kinda dislike them (or haven't gotten used to them, at least). To me, it kills the point of a keyboard-centric desktop environment - which is the speed and lack of friction in making the window you want appear in front of your eyes.

Despite that, I still really like it. Mostly because I have so much more faith in its development. The documentation is excellent. The configuration file is sane, and not as arcane and ad hoc as the hyprland.conf format. The source repository looks well-maintained. Being written in Rust rather than C++ means onboarding new developers is easier. The discourse is more measured, owing to the lack of a somewhat stubborn lead maintainer in the case of Hyprland.

The surrounding ecosystem seems to be flourishing as well, with projects like Noctalia Shell, DankMaterialShell, and niri-flake natively supporting niri.

And perhaps most importantly, the out-of-the box experience is really nice. You have proper monocle and tabbed layouts without any compromises - features Hyprland has still not developed, where they are only possible with scuffed C++ plugins, or where its BDFL has stated they will never be introduced. Most features one would expect from a WM are already there and well-documented, which can't be said about Hyprland.

Exactly.

"GitHub actions bad" is a valid take - you should reduce your use to a minimum.

"My build failed because of GitHub actions couldn't install a dependency of my build" is a skill issue. Don't use GitHub actions to install a program your build depends on.

Samesies - need a Majjit before I can consider trying it out.

> If Vizo never licensed the software to you under the GPL [...]

That may be true.

> [...] you can't say they violated the GPL.

That does not necessarily follow.

If they used GPL-licensed code in their product, they may be obligated to provide the source code to that product's consumer.

No, you really don't have to. Partially complete software can have a lot of value too.

Anyone can fork it and quickly add the i18n (or just translate into a different language) for their own purposes. People will likely want to contribute i18n. People may fix or improve things for you.

Of course, it's entirely up to you - but I've appreciated half-complete software countless times before.

It is unique and looks cool.

When it comes to providing an enjoyable blog post reading experience, it really does creep into the "fuck off" territory for me, though.

Even better is "" since it's not really adding anything

`for` loops are a superfluous language feature if your collections have `map` for transformations and `forEach` for producing side effects

It's quite nice for the following reasons:

- Image previews (for file management with dired/dirvish)

- PDF viewing

- In-buffer images (e.g. profile pictures in git log with Magit)

- Browsing simple HTML pages (e.g. API docs)

There's probably more I've yet to discover.

You only need that much protein if you're trying to build muscle. The amount needed for a generally healthy diet is much lower.

If that's something you care about, then don't define your CI build in terms of GitHub Actions steps. Instead, call your build that takes care of using whichever version of Node you want in CI.