💾 Archived View for gemini.dimakrasner.com › june-post.gmi captured on 2024-05-12 at 15:10:29. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-07-22)
-=-=-=-=-=-=-
I'm done with two weeks of antibiotics. I was very very weak and I think I lost even more weight: I'm probably close to 50 Kg and BMI of 20.
My appetite is slowly coming back and I feel much better since Monday or so. I was able to carry my flugelhorn (in its heavy wooden case) to my lesson, play it (loudly!), then carry it and myself back home. And I was OK afterwards! No pain, no heartburn while playing, no tiredness on Tuesday.
gemini://ploum.net/2023-06-19-more-rms.gmi
I think RMS was right about many things, but the 4 freedoms are not enough. The industry will find ways to monetize and eventually control everything it can get for free, and every centralized entity holds power (economic, cultural or political). IMO decentralization, de-commercialization and democratization of the "means of production" (digital literacy, free access to tech knowledge) are far more important than they used to be before the "Web 2.0" era. RMS's focus is too narrow, if we look at all the ways "the internet" and the tech industry take away people's rights or power.
We need a fifth rule.
It's a slippery slope, isn't it? I'm not sure if the missing stuff fits in one additional rule, and the first 4 are too busy with software licensing or ownership. Therefore, I don't think it's super important to patch the free software definition like this: it's too flawed and can't be fixed so easily.
Plus, RMS and the FSF are 'tainted': IMO the free software movement needs to refocus and find new leadership that can steer the ship.
Bubble is the first capsule I see, where the user has to create a client certificate to authenticate, but the client doesn't receive a 6x response.
Lagrange has nice UI that abstracts away client certificate ("identities"), making this easy, but my client (and possibly others) only generates certificates when asked to: it doesn't have a certificates management UI that allows users to create a certificate for a given URL. (If I understand correctly, Bubble also uses Titan, so it's a "best viewed in Lagrange" capsule anyway.)
(I have a similar problem with Station, which requires the user to create a certificate for /, when asked to create a certificate from a page below /. I guess it assumes that all clients create a certificate for / when /foo returns 6x, like Lagrange did by default, last time I checked.)
A /login URL that responds with 6x and leads to other pages that require authentication (/login/x, /login/y ...) is 100% consistent with the protocol spec, and should work with all clients that support client certificates. This is something I'd change in the protocol spec: forbid pages that return 2x without a client certificate, or different content when viewed with a client certificate.
I prefer not to make my client's implementation of Gemini more 'complex' and less 'strict', but I want to be able to use Bubble and possibly other capsules like this.
There's another thing I'd add to the spec: "clients MAY cache 1x responses". In my Gemini client (gplaces), one can do this:
geminispace.info/search "gemini specification"
or:
set search geminispace.info/search search "gemini specification"
However, I don't see myself doing this for pages I visit less often: for example, I'd like my client to cache the prompt of the Antenna URL submission page or the Station new post page, so my client doesn't have to send two requests every time. I can't do this, because it's unspecified whether or not clients are allowed to cache 1x responses (a-la permanent redirects), but I might do this anyway and provide a feature flag.
(I tried to email solderpunk to discuss this proposal, but I have a custom domain and it was probably classified as spam)
Spartan looks like an almost perfect protocol to me. Things I'd change:
1. UTF-8 everywhere.
2. Unify status codes 4 and 5, unless the meaning of 5 is changed to "temporary server-side error", so the two need different client-side handling.
3. Drop the := line type and require clients to allow users to pass input to any spartan:// URL: content authors can describe a link in a way that make it clear whether or not input is required, and return a human-readable error when input is required but unspecified.
I'm trying to design my own, Spartan-like protocol over UDP. The codename is "Guppy" because it's Gopher over UDP minus gophermaps plus other changes. I'm constantly changing the spec, then changing the reference implementation, then struggling to adjust the spec when I hit a corner case in the implementation ...
UDP definitely reduces the complexity of the protocol stack as a whole, but it introduces so much complexity in the layer above it. Now I'm struggling with re-transmissions: the server needs an ack for every chunk of the response, so it knows when to send the next one, but the acks themselves get lost. I think I have a solution but I'm sure I'll find at least one problem once I implement it.
Yay, I'm reading again! Just finished Neuromancer, Burning Chrome is on its way, and I'm starting to read The Dispossessed. I really enjoy the warmth of the writing and the way it questions the things we preceive as normal.
Neuromancer got me interested in the Matrix film series, which I always hated. I tried to watch the first film multiple times throughout my life, hated it and gave up on it after 5-10m. Now I see things differently and I'm curious.
It's not really surprising, but I'm always surprised to see how much Puppy Linux users want the 'tradition' to stay and refuse to accept the facts. Puppy's package manager is extremely slow, it fails to install packages way too often, it doesn't understand concepts other package managers understand (like multi-arch packages, or dependency on a OR b) and it can break your system quite easily.
One of the best distros for old computers, and there aren't many of those, is in very bad shape. The number of active contributors is lower than ever, and <=1 if trivial contribution ("remove this ready-made package, add that ready-made package") are ignored. I believe the number of users is low, too, and 4-5 users produce most the vast majority of noise in the distro's forums. Who's going to fix all the known issues users have been complaining about for years?
Yet, people complain when provided with a Puppy Linux flavor with apt and Synaptic, some even boycott it. And when provided with a "big" Puppy Linux flavor that includes VA API drivers that prevent battery drain and overheating when watching online videos, they complain about the slightly bigger download size or deny the possibility that sometimes, bigger is faster and not the other way around.
The best example is probably zstd: take any Puppy Linux release and recompress all squashfs images with zstd instead of xz. You'll probably get an immediate 8-12% size increase, but application start times drop drastically and everything feels more responsive. Storage is easy to expand and upgrade, but maximum RAM is limited, the CPU can't be upgraded (or only from generation n to n+1) and the GPU is often soldered or not worthwhile to upgrade. A distro for old computers should trade space for speed whenever possible, because many old computers already have plenty of storage, storage can be expanded, storage can replaced with something faster (for example, by switching to a SSD), and problems with internal storage can be bypassed (for example, by booting from USB).
Puppy's quirks are all nice, cute, fun and unique, until they cause real problems. Once you look back from a distro without these shortcomings, there's no coming back. Many Puppy users seem to prefer a 'unique' distro, to a distro that does some things the 'vanilla' or 'upstream' way, even if the latter is more lightweight or more suitable for old hardware. People are irrational, very irrational, I guess.
I'm disappointed with myself, because I allow people's ungrateful words, stubbornness and irrationality to take away my motivation to continue my (volunteer) work as the maintainer. For all practical purposes, I'm a single maintainer. People don't realize Puppy will die: GTK+ 2, X.Org, aufs, pure ALSA audio and other things Puppy relies on are on their way out, and the 'traditional' Puppy things, like its awful package manager, are unmaintained for years. People complain and boycott, but they don't realize that this is a volunteer project, a do-ocracy: complaints don't fix bugs, and the complaints vs. commits ratio is very very bad.
I decided to 'hard fork' woof-CE, Puppy's build system, and created DARLS: a Puppy Linux derivative for my personal use. It's relatively huge, but it's much lighter (CPU and RAM wise) and faster than 'official' Puppy: it's free from legacy cruft like X.Org or GTK+ 2, RAM consumption is very low and it boots in seconds even on this 8 years old laptop. Others might find it useful or interesting, and there's a 'sister' distro with practically the same packages, where dwl and yambar are replaced by labwc and sfwbar.
I'm still maintaining Vanilla Dpup, though, and fixing high impact bugs when needed. It's very future-proof at this point, and very easy to maintain as a single developer.