Compare commits

10 Commits

Author SHA1 Message Date
flancian 1a0ab09858 autopushed 2023-07-04 15:35:05 +02:00
flancian b1be771aeb autopushed 2023-07-04 15:33:59 +02:00
flancian 0b3fa6e183 autopushed 2023-07-04 15:32:19 +02:00
flancian d26c96b82c autopushed 2023-07-04 15:31:44 +02:00
flancian 267f81cfed autopushed 2023-07-04 15:27:48 +02:00
flancian e67beea217 autopushed 2023-07-04 15:27:13 +02:00
flancian 2c21a8de90 autopushed 2023-07-04 15:25:31 +02:00
flancian 5389b8ba45 autopushed 2023-07-04 15:22:42 +02:00
flancian ac5e472c59 autopushed 2023-07-04 15:21:34 +02:00
flancian c082344fe9 autopushed 2023-07-04 15:18:01 +02:00
3 changed files with 29 additions and 0 deletions
+25
View File
@@ -0,0 +1,25 @@
- a [[ritual]].
- part of [[Festivus]].
I love computers and humans, and they come together beautiful in phenomenons like open source, which I love particularly. I am eternally thankful for the *millions* of humans who contribute to free software and make the world a better place.
Having said that, here are some out-of-season [[airing of grievances]] about software, in no particular order:
## [[Flatpak]]
Flatpak sucks, yet is somehow also the best known (to me) solution to the problem of shipping apps in a platform/distribution agnostic way as of the time of writing ([[2023]]). [[Snap]] is clearly worse. How can this be?
Why, WHY, am I able to `flatpak search chromium` and even `flatpak install chromium` but (I kid you not) I need to write `flatpak run org.chromium.Chromium` to actually run the package?
Oh, it's because the developers refuse to accept patches to implement short forms for the run subcommand specifically. In practice this means ~millions of people around the world are maintaining independent collections of shoddy one-liners or aliases to make flatpak command invocations sane again.
Also, if you run `flatpak search` in a narrow terminal it will helpfully elide the full application ID, so flatpak search cannot even be depended on to retrieve the right incantation consistently. WHY.
## [[Systemd]]
I love Systemd; I remember curating SysV Init scripts and I think the process of writing Systemd services is much improved. Having said that :)
Why is it so hard to just make sure a service will actually start and keep retrying forever if it can't start? There are several incantations in the configuration spec that *seem* like they should achieve indefinite retries, but really don't (or do only in some cases). I understand why you'd want to have something like a sane retry policy (with backoff), but I really would like to tell it: just keep trying for me. Under no situation it seems reasonable for me to find a service marked as `inactive (dead)`, run start on it and have it work flawlessly. The computer should have done that for me.
Also, why is it non-trivial to go from operating over a service (with e.g. `systemctl --user status/stop/start foo`) to operating over its logs? For the latter you need (checks notes) `[[journalctl]] --user-unit foo`. Maybe it just took me longer than normal to find this, but it's unclear to me why `systemctl --user logs` doesn't exist, or why it's --user-unit in the case of journalctl instead of --user.
+1
View File
@@ -0,0 +1 @@
- [[airing of grievances]]
+3
View File
@@ -0,0 +1,3 @@
- The invocation for user services is e.g.:
- `journalctl --user-unit agora-server`
- Why it's --user-unit instead of --user (like systemctl) I'm going to assume nobody knows (I sure don't).