𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍

If that breaks your brain, I’ve got one for you: herbstluftwm for life.

I want no configuration file. The WM should run a program that configures and sets up everything. Not even as much a config as i3, or Sway. Nothing about the compositor should be configured or set unless it’s through a CLI client call.

There are dozens of compositors, pretty ones like Hyprland and novel ones like Niri, but always with the bespoke configuration files in whatever random config file format the maintainer has a thing for.

River looks similar to herbstluftwm in the configuration area. I did try it a few months ago; I don’t remember why it didn’t work out - lacking multi-monitor support, maybe? But since it’s in active development I’ll have to try it again.

After using Linux almost exclusively for over 20 years and at some point used nearly all of the desktops and window managers that exist for X; and having come to the conclusion that - in general - configuration files for long-running services are bad design, and that nearly all services should be runtime-configurable with tooling, I just won’t use a compositor with a static configuration. Hot reloading is a work-around hack. I3’s live restart is a pretty decent solution, and i3-mesg is close, but the gaps eventually become obvious.

It was surprisingly quick to find one that worked: three regenerations, and I didn’t lock any panes - just let the one-armed-bandit spin.

https://explosm.net/rcg/bxayudbma

Makes you wonder, doesn’t it?

I’d like to mention rook, my project, which is a secret-service-like tool backed by your Keepass DB. Not using a bespoke DB is both more secure, and more importantly, means you don’t have to manually keep your passwords in sync across multiple password managers. It provides support for pin access which, when used with the Linux kernel keychain, can provide session-limited access to unlocked DBs.

Rook is in both the Arch AUR and Alpine Community repositories.

Which is - in my experience - another way of saying “if you don’t care that you’re running hopelessly obsolete versions of software, and don’t have access to about half the software available written in the past several years.” Even if you compile yourself, it’s often a game of bisecting a project’s history to find a point in the when it’ll compile against the ancient versions of libraries available on the system.

That’s been my experience, anyway.

I can believe this. If they hadn’t improved, they wouldn’t still be around, because it was truly awful.

But I can hold a grudge. And, honestly, I have no reason to try it again, so it costs me nothing to be petty about RPM.

Yes, but only one of those hurt me viscerally. The other was too abstract to take precedence.

It may be fixed and perfect, now, but I will never forgive Redhat for RPM, and by extension, every derivative. Fedora. CentOS. Anything rpm-based. I’m not a huge fan of debs, either, but I have never experienced dependency hell as bad as on rpm systems.

Lots of people like it. It’s really popular for installing on a desktop configured to run an obscure, but mission-critical, service, putting the computer in a closet, and then later walling up the closet so that the physical computer can never be found again. It’s great, as long as you never upgrade it.

Look up “capabilities-based operating systems.” They exist; Linux just isn’t one.

Like microkernels, capabilities require certain core architecture designs that Linux doesn’t have. Like all features, there are always tradeoffs: microkernels tend to be slower because of the message passing; capabilities based systems are harder to manage. Linux’s design, for all it’s popularity, is about a simple a kernel design as possible. And you see people making the same decisions now: X11 is inherently multi-user and network capable. Wayland eliminates both, because it makes things more simple.

You’re welcome.

For SMS, someone else touched on KDE Connect, which seems to be a pretty well-rounded solution. I can’t speak first-hand, as I don’t use KDE, but there’s a poorly maintained non-KDE program using the same protocol called mconnect, and from looking at that you get bidirectional SMS & file transfer, browsing your phone like a directory, shared clipboard and notifications, and remote control of your desktop media player from your phone. It does almost everything you might want (except for auto-syncing music a-la iTunes).

The solution for the music I’ve arrived at is based on OpenSubsonic.

I’m running gonic (Navidrome works, too, and there are other servers such as the original Subsonic) on my server. I’m using Android, but there’s probably a similar iOS app, and the OSS Tempo app. Tempo can stream, but it’ll also let you download and cache music locally - including entire playlists. So I have a “Phone” playlist that I add music I want to sync to my phone (my music collection is 84GiB, so I sync only part of it), and occasionally download it. Tempo is smart enough to only download songs it doesn’t already have.

This is only 1-way. There’s no facility to upload music to the server using OpenSubsonic. Also, caching only downloads; if I remove a song from the playlist, it stays on the phone. It’s not a true “sync”.

I used to use SyncThing, but maintaining include/exclude lists was far more work.

For SMS, I wrote a program. But it requires two different OSS apps on the phone, and I doubt they exist on iOS, they don’t sync messages received when the phone wasn’t connected, and while one runs reliably, I have to keep restarting the second (it doesn’t persist well). So it’s not really a good solution, for many reasons, but I can’t bring myself to do mobile development anymore so unless an alternative that does what both SMS to URL Forwarder and RestSMS do all in one app, and include caching unsynced messages, it’s not likely to improve. It’s enough that I can respond to SMSes from my computer, which is the big thing.

Are you me‽

I put 64GiB of RAM in my mini desktop just to never have to deal with swap paging. AMD with integrated GPU, so it immediately steals, like, 4GiB for graphics, but even so I think I’ve never seen it go past 50% usage.

I think 60 is just a default. That’s what mine says, too, and I have 0 swap allocated:

               total        used        free      shared  buff/cache   available
Mem:            59Gi        16Gi       2.1Gi        72Mi        41Gi        43Gi
Swap:             0B          0B          0B

Exactly this. API. ABI. UI. The Interface between human and program, in this case.

Thank you; you’re one out of 6 people who didn’t need an explanation that “UI” and “GUI” or “TUI” are not synonymous.

Again, github. If Mercurial had had something like github, it would have been closer. Github was git’s killer feature; git itself provided nothing except a bunch of kernel devs were using it - and I’m not convinced that alone would have propelled it to success. Kernel contributors don’t make up a large percent of all developers in the world.

Mercurial isn’t perfect. Being written in Python frequently makes it a pain, but it’s slowly converting to Rust.

I do wish darcs - also hindered by the language choice of the author - had done better. Theory-of-patches was incredible to work with, and practically eliminated merging being an issue. Pijul is going that route, but until they open source a server, it’s a non-starter for me.

All of my personal stuff is in hg repositories at Sourcehut. Mercurial is, thankfully, still popular enough that it’s got a reasonably large dev team and still has regular releases. As long as that holds, I’m good.

I had my rant here. Even I have a limit for angry vitriol. Honestly, I wouldn’t care, except there are two things I’m collaborating with where I have to use git. Actually, for one I could probably use Jujutsu, but the other is One Giant Monorepos and has very specific requirements about how history looks, and I just can’t ensure that without using git directly. And it drives my utter bonkers every time I have to commit, because: despite the fact that there are only ever one or two people editing any given file; and none of the files has anything to do with any other; because there are hundreds of people editing hundreds of files in this repo every month or so when I want to make a change it’s a nightmare of pulling and fetching and rebasing and trying to squash things down so it’s pretty enough for an MR to get accepted into master. I’m about to give up contributing to that one; it’s not worth the git pain.

Then, I was collaborating on another project as a contributor; the project owner was slow to merge PRs, so at any point in time I had 6 feature branches waiting to be merged. Sometimes, they conflicted with each other, so I had to wait until they merged one, then I’d have to go in and fix the other so it could be merged. It was a nightmare, and I eventually just hard-forked the project. Granted, this would have been a challenging situation for any VCS, but git’s merge and rebase are so awful it was especially painful. It would have been easier with Mercurial - it’s smarter about merging and rebasing, mainly (I believe) because it doesn’t have to contend with the possibility that someone caused a temporal paradox by changing history, but it would in most cases not been at all problematic with darcs.

My preferred VCS is Mercurial. It used to be darcs, but I started having performance issues with larger projects and gave it up years ago. If it had been able to keep up, I’d probably have stuck with it.

The other tool I use is Jujutsu. It’s in heavy development, and there are still some warts, but I can work with git projects with it without having to suffer git.

I’m keeping my eye on Pijul, which is patch-theory-based, like darcs. I’m a bit concerned about the fact that it smells a little like it’s going to be monotonized through never releasing a self-hostable server - right now they offer free project hosting, but it means you have to host your source on their servers, or not publicly at all, and that gives me the heebes.

Hm. Well, I’ve answered in angry detail in a response to someone else, but as evidence that I’m not some loner, I present you with:

• Mercurial, for which it’s hard to find usage estimates
• Pijul, the spiritual successor to Darcs, much younger that git; also hard to find usage stats
• Jujutsu, an interface currently on top of git, as an attempt to make git suck less by giving it a more Mercurial-like interface (or, “workflow” since a large number of people seem to be struggling with the concept that the set of commands of a CLI tool is its user interface). This one’s a little easier, because we can see it’s got 12k stars on github.
• On the Jujutsu README is a link to a list of “other tools trying to solve similar problems”, the “problems” being how much the git UX sucks. That page mentions git-branchless, sapling, gitless, and sturdy – all front-ends to git with less bad UIs.

Why? It’s clearly an opinion.

But, ok: pull and fetch are really similar, but not really. Here’s a hammer, and another hammer that looks almost exactly the same except it works just a little differently, and if you use the wrong one situationally you can fuck up your history and have to spend an hour unfucking it.

You can change history. Not only can you, but it’s a common workflow, and it, too, easily leads to messed up clones. This was simply a really stupid design decision for a VCS.

The vast variety of errors you can encounter working with others - the one key feature of a DVCS - is astonishing. TF is “fast forward?” Don’t answer that, I know, but you know what no other DVCS suffers from? Fast forward restrictions. Or, how about detached heads? That’s a pretty uniquely git-level idiocy.

Merging is so badly implemented, it’s a common requirement for projects to demand that MRs be squashed down into a single commit.

Rebasing is even worse, such that users find themselves squashing history just to be able to successfully rebase.

git contributed no clever features, such as Darcs’ patch-based management; it provided no simplicity, like Mercurial; and, frankly, if it weren’t for github, it wouldn’t be nearly as popular as it is. Github was so innovative and useful, it overcame the handicap of being implemented on git. git eventually got a bisect command, so I can’t complain about that anymore.

I’m really pinning my hopes on jujutsu; so far, it makes working with git better enough that I don’t mind using it, although it’s still not quite as good as Mercurial, and it’s still very much a work in progress.

You know where git doesn’t suck? If you’re working on a project, alone, and you never branch. Then it’s not so bad. But, then, you may as well just keep your code in btrfs and make snapshots instead of commits.

The shitty set of operations and how they modify history. It’s an interface, the same way that an API is an interface. User Interface =~ Application Programming Interface =~ Application Binary Interface. git’s interface - the set of commands through which the user interfaces with the tool - stinks.

UX. The UI also sucks, though, in that the commands are obtuse, the behavior is complex and demands a relatively high cognitive load, and for very little gain. I guess if you interpret “UI” as “the command line,” I won’t complain. But the interface for me is the set of commands and operations you perform with them, which are awful and poorly designed - bad UI leading to a bad UX.

I just came to say: I hate git with the passion of a thousand burning suns. There is no other open source software I hate nearly as much; not even Poetteringware. It’s astonishingly poorly designed, given who wrote it, has an awful UI, and is just one big footgun.

Edit: honestly, I was expecting far more downvotes by now.

Those are great suggestions; I don’t use them only because neither is keyboard oriented, so I tend to vacillate between Luakit, Surf, vimb, and Nyxt (although the last still has serious hard-hanging issues and an obscene configuration).

On this topic, I’d be interested in a terminal browser that tries harder on the layout front. w3m, links, links2, elinks - they all work, but none focus on layout and rendering even as much as terminal Markdown renderers such as glow and hike.