Z Space Blog - Libre Software

Vim Author Bram Moolenaar Has Died

2023-08-05T12:38:00-07:00

I woke up to a huge gut punch this morning: Bram Moolenaar, legendary author of the Vim text editor, has passed away. Given the occasion, I want to express some thoughts regarding both Bram and his software. Without his work, I'm not sure I would be the same person.

How I found Vim

On a wintry Wisconsin night in 2004, I was looking for better, more customizable software. I was a teenager, learning about alternative OSes and losing patience with Windows every passing day. I had started getting more serious about learning web development, and began trying different text editors, to see what was to my taste. As we all know, Notepad on Windows is NOT sufficient for programming.

On this path of discovering text editors, I stumbled across all sorts of things, from UltraEdit to metapad, Notepad++, gedit, AceHTML, Emacs, and eventually I found this free software called "vim", but it came with some newbie-friendly settings, called Cream. (I was surprised to see it's still around!) One thing that stood out to me about Vim, at the time, was the fact I didn't have to enter some weird licensing scheme. I didn't have to pay to unlock features, and the big thing was -- if I wanted to help, I could donate to a charity that actually helped people! That stuck with me, morally. "Huh, all these companies are making software for profit, but this guy from Europe just wants me to help some less fortunate people. That's awesome."

I would not realize it until years later, but discovering Vim was a key step in my journey to libre software and GNU/Linux. Had I not been looking for a free, customizable text editor to do what I wanted, it may have delayed or slowed my introduction to that world.

How I Use Vim Today

These days, I keep a small group of plugins (mostly things like fugitive, tabular, sparkup, and some syntax stuff), a hefty vimrc with keyboard layout switching capabilities, and there's almost always a Vim process open on my machines. It earned a place as my favorite piece of software when I learned how easy it is to extend its behavior. No other piece of software evolves with me and my skill level like Vim does.

I love Vim's documentation system the most, I think. If there's anything I don't know about Vim, I can consult :help and get answers immediately. For anything else, there is a broad community of fellow text-heads out there, who might even have saved a fricken macro for the task you're trying to achieve.

Each time I learn something new about Vim, I feel like I've unlocked a new ability, or added a new text wrangling tool to my belt. This, in turn, improves my ability to manipulate text and makes the editing experience that much better.

The Future of Vim

It seems that Bram had tapped a successor, in some way, before he died, but the state of things with the Vim project seem to indicate his death was not expected, per se, though he had been ill for a few months prior to his death. It is sad to see another one of the "original breed" of FOSS hackers pass on. It stands as a reminder of how little time we really have on this rock, and the importance of choosing goals that one can look back on with pride. I hope that the new primary author and maintainer, Christian Brabandt, leads the project with the same core values that Bram did. Christian expresses his thoughts in the Google Groups thread.

Vim is the reason I discovered the Free Software movement. It's the software that I use most in my day-to-day computing. How strange, that a journey for a good text editor led to me discovering an entire social movement of hackers that I still hover around to this day, nearly 20 years later. Thank you, Bram, for bringing joy to my computing and rewarding every new morsel of knowledge I gain about this beautiful tool.

I have nothing but condolences for the Moolenaar family in their time of grieving. I hope their hearts are made lighter by the worldwide celebration of Bram's wonderful work, and the many testimonies people are publishing today which show how influential he was. We are all privileged to have received his work.

Please consider donating to ICCF Holland if you wish to leave a token of appreciation for Bram. It's what he would ask for.

Free Software is Politics

2022-04-21T00:00:00-07:00

It seems that the systemd debate has made its way to Alpine Linux, and naturally that gets people out of the woodwork to bang their drum about it again. The irony's not lost, either. It's really tiring to see people complain about politics, in a software movement that's entirely about the politics of software to begin with. Have you guys forgotten why we're here? Are you more open source instead of free software? That's still a political statement; one of practicality and reduced costs.

For those unfamiliar, Alpine Linux is a Linux distribution (NOT GNU/Linux) powered by busybox, musl libc, and OpenRC. By contrast, systemd is a project aiming to provide a "system layer" between userland and the kernel. It explicitly depends on a recent build system (meson) and generally only supports glibc and the Linux kernel. It explicitly does not support any alternative libc. In short, Alpine and systemd go together like oil and water, on purely a technical basis. The social half even moreso, since this incompatibility resulted in users having access to a simpler system that isn't built on systemd. Choice is great, right? Some disagree, but they're free to make their own projects.

When dealing with the systemd debate, many try to reduce it to the early years of the debate, where people used the false dichotomy of technical and social. Or they derail and assume it's a personal vendetta against Lennart Poettering, without accounting for Lennart's behavior when he was advocating for systemd, and the smug ways that his project has treated contributions, criticisms, and distros like Gentoo. We do personal responsibility, first impressions, and all that civil shit, right? Can we not apply this to our fellow developers? Are we not responsible, to some degree, for how others perceive us and our projects? If so, then I think it's fair to criticize a developer.

Lennart said "Gentoo, this is your wakeup call," concerning the ability to run udev without systemd, when eudev was created. He actively asked GNOME to depend on systemd. Granted, GNOME was probably going to use it anyway due to Red Hat employing both Poettering and many GNOME developers... A number of Arch developers (particularly its sysvinit maintainer) were early contributors to systemd. It's safe to say, influencing other projects is the bread and butter of the systemd project, and I challenge anyone to argue otherwise.

If you're going to participate in the debate, at least understand the history of the project and the actions of the principal authors -- cultural origin matters here because their values are baked into the project. The discussions from the Arch and Debian communities are also worthwhile, to show examples of how NOT to deal with the issue. Arch promised sysvinit would remain as an option, then pulled the rug out from users with their switch. Debian had an ugly debate that resulted in some developers leaving the distribution altogether, and sparked the creation of the systemd-free Devuan distribution.

Arch and Debian both went systemd, while Fedora and SuSE leaned into systemd first. As a witness to both Arch and Debian's decisions as-it-happened, the one thing most distro devs missed was user transparency. Whatever plan you go with, you need a pathway for the users who get left out, or you're going to create a rift in the community or even a fork. So many users who didn't want systemd got stuck with it. Some people who were using systemd on neutral distros found themselves having to make a decision, where there wasn't a need to before. Systemd support was not uniform across the ecosystem (wrt build options), and still isn't.

The decisions affected a ton of users, ironically creating more forks and attempts to maintain control of one's computing -- the dreaded "fragmentation" boogeyman, often coming from those who don't see the value in a diverse software ecosystem. The fatal flaw of consolidation is the assumption that every developer in the problem space can agree on how its problems get solved. Given human nature, that is very flatly a false assumption. Every solution in software has different benefits and pitfalls. Some optimize for CPU speed. Some for memory. Some for I/O. Others for networking! No single project can solve every problem in a space. The solution to this is coexisting via multiple projects, all of which can solve the problem(s) in the style that they choose. The openness of software diversity is why systemd had a chance of adoption at all.

The ways that various distributions handled their decisions were decidedly high temperature, and it's clear from the beginning of the systemd project that it was intent on changing distributions. Denying that is to side with groups trying to manipulate the ecosystem into carrying their software on every default install. It's competitive behavior that has no place in a collaborative environment.

Not every piece of disruptive software causes this much trouble, though. One of Lennart's other projects, PulseAudio, hasn't caused nearly as much trouble even though it, too, has its share of critics. I posit that the limited scope of the project and its less aggressive appeal to the ecosystem allowed it to coexist with ALSA and JACK in a better way than systemd does with other inits. Many environments can treat PulseAudio as "another supported stack" with a little maintenance, without upsetting their software's architecture.

Even the Wayland project, with its own brand of smugness and the specific goal of replacing X11, hasn't done much to create an actual, damaging rift in the communities they are near. Programs can support both Xorg and Wayland; at least for the features that they both share.

It could also just be the nature of init systems. You generally have to make an all-or-nothing decision. Coexisting init or service systems are a somewhat new idea, which is why most distributions choose a single init. Apparently it's possible, though, to mix and match between OpenRC, s6, and runit. Neat.

The technical and social are inescapably intertwined, just like politics is to free software. Two sides of the same coin. The movement itself began as the desire to fix a printer driver and compute their way. Furthermore, the decision of which packages to include in a distribution is also political. It affects the "computing lives", for lack of a better phrase, of the users who trust the distribution's choices on software, or are otherwise aligned with their software philosophy. Anything that has far-reaching consequences on how people interact or conduct themselves could be interpreted as political.

So, what's really being called for when we're asked to "stahp being political"? To ignore the social history of a project? To censor jokes we don't find funny? To ignore prior debates, the outcomes of said debates, or the project management of upstream? Software isn't developed in a vacuum, and software with a big picture agenda (anything involving the desire to standardize is automatically political) is not doing itself any favors by accusing others of being problematic, when the politics is the point. It comes off as intellectually dishonest or in bad faith.

Why shouldn't we consider the whole when we make software decisions? If given the choice between two technically identical upstreams, would you rather deal with the upstream who's helpful and receptive to contributions and doesn't mind if people don't use their software, or one that sees itself above you, decides the structure of your system without helpful or constructive feedback for contributions, wants every system you touch to run their software, and has a nasty habit of displacing other software? You sure that last part is really an oopsie? Am I "not allowed" to notice that part?

I know what I'd choose, and it doesn't have to be highly personal. It's a matter of one's own software standards. As a programmer, I find it shameful to push one's project in a way that creates a lot of discord in the community. I don't try to get people to use VGStash over Backloggery or their other favorite game manager, but I might bring it up in a conversation if someone doesn't sound sure of how they want to fix that problem, and it's relevant to the conversation. Even then, I'd rather know that I have users because they like the software, and not because I screamed about it from the digital rooftops or pressured people into using it. That's a false merit, if anything.

Coexisting as a software project is not particularly hard. I could not, in good conscience, act in the ways that Lennart has regarding systemd, even if it was my own project. While some of the responses he's gotten have been over the top (death threats? Crazy), I think it's entirely fair to apply my personal standard to my software choices, and the people who write them.

I think there are many other people in free software who use similar criteria to determine which software they use. This is especially important for software that you think you might contribute to! If you don't like the ideas of the author, or their tech choices, or their philosophy to software, those are valid reasons to avoid their software! It's also valid to tell others that's your reason. They don't have to agree with you.

But, I have to question the motives and values of a person who tells me to stop paying attention to the politics that happen from a project with a decidedly political aim. The technical and social parts of free software cannot be reliably separated, any more than a human being's identity can be separated between heart and mind. Separating the art from the artist only shows half the picture.

Focus on the whole, and make the right decision for your computing. No outside entity knows your needs better than you do.

-z

(Who can read the GNU Manifesto and not gather that it's political?)

GNOME as a Platform

2021-10-28T00:00:00-07:00

I came home today and strolled my usual Web haunts before diving into the Underground, and stumbled across a piece by GNOME developer jwestman, titled Platforms, Compatibility, and the Future of the Free Desktop. In it, he advocates for GNOME (and by extension XDG) to become the platform that "everyone can work on together". Isn't it funny that the kind of people that suggest this are always talking about the platforms, software, or APIs that they have control over? Does this person not understand why people choose other software, or choose to create something different? Do they not understand the risks present when the vast majority of your userbase is on one or two platforms and a 0-day is found?

Something jwestman doesn't comprehend about the libre software world, I think, is that its diversity is both a help and a hindrance. To get the best software from the community, it needs to be able to grow, change, and adapt at the individual level. Those adaptations will create the behavior of the ecosystem. This is observable in wildlife, as well.

Congregating the majority of an ecosystem so that they all use the same platform is not helpful to anyone except the builder of the platform and those that depend on them. It's commercial behavior, not social. These projects can exist just fine on their own without trying to get everyone to use them.

The overarching goal of organizations like GNOME are to have control over the future of the software ecosystem. If you provide the platform, you control the platform, you control the users. If you define the standards, you control the platform.

Where's the incentive?

What do I gain from XDG and GNOME as a software developer? It's yet another piece of software or interface I don't control, forcing me to update my software if I want to remain functional ON your platform. It's based on bureaucratic consensus, where decisions are gatekept by the top two funded and top two largest implementations (GNOME and KDE). If I disagree with a decision or propose an addition to the standards, or the interfaces, what hope does my voice have of being heard and given honest consideration? That's the problem I have with these organizations that are companies pretending to be communities, so they can gain resources from the community.

GNOME has not demonstrated themselves to be a good player when it comes to collaboration. A lot of concerns have been cast aside, and their chief funding company, Red Hat, employs these developers.

Do tell me why I would want to work with such an organization. I challenge GNOME to show the choices they allow within their platform, especially in light of the recent dwindling in options across GTK, GNOME, and GNOME core apps like the file chooser and Nautilus. Interestingly, jwestman does a rhetorical trick where they characterize the choices GNOME offers as "real" while other choices are less "real". If someone switches away from GNOME, there is still a cost!

GNOME is and has been obsessed with image, UX, branding, and community outreach the past 5-8 years. To increase broader appeal, you dumb things down. Novice users overwhelmed by options? Remove some, or hide them in dconf/gsettings! Marketing alone isn't going to make a good platform, and neither is suggesting people use your platform because of some fake appeal to collaboration that doesn't hold to scrutiny if you look at your bug tracker.

The direct result of coalescing on any standard is to give power to those who wrote the standard. I do not trust the groups in charge of FreeDesktop or GNOME, so I have no reason to learn how to write a GNOME app.

Some Thoughts on the GNOME Experience

For the record, ~~I'm a daily user of GNOME right now~~ (nope, lol ¹), since my laptop shipped with it as the default environment and I chose to try my best to set it up, so I could zero in on what I dislike about it.

It's a struggle to use this environment. It's a struggle to navigate the bullshit XDG docs for defining a desktop file, so I could make a launcher for PICO-8. The one GUI program I found to manipulate the menu and launchers didn't have a clear interface as to which fields meant what, and the launchers it did produce didn't work. I ended up returning to the spec, and fucking around until something finally worked. Then I needed a systemd unit to get some semblance of "run this bash script once on boot" so I could set a sysfs value while waiting for an EC firmware fix. GNOME also can't switch audio output when I plug in headphones, and there isn't a GUI to fetch programs that have tray icons, like Nextcloud and Steam. I have to use the Task Manager clone that GNOME has and make sure it's not in the process list. (ps aux | grep is loads better btw) I often leave Steam, Nextcloud, and Mumble all in their own workspaces, to avoid losing the windows. How on Earth is that better than a system tray!? The worst part about this is a naive GNOME user would assume these programs are broken, when they are not: GNOME simply doesn't implement tray icons! Load them on any other DE, and I can access the tray icons with no problem.

Add to that the uselessness of the icon spec. For defining something visual, you might want to provide a complete set of blank or example icons. Nobody wants to navigate through the ridiculous amount of XDG-defined icon names and try to figure out the correct one to use. Can't we use sane names, and document them better? Half the problem are the atrocious docs. They're not written for app developers or even independent, self-taught folks. They're written for other standards writers.

Honestly it just feels like GNOME and XDG, if we were to consider them "a platform", are designed to be difficult to integrate with, and you're stuck with whatever Trolltech/KDE and Red Hat/GNOME decide on for their systems because there's no evidence that any outside opinion would be given consideration or be able to get any ideas merged into the standard(s).

Every step of the way of my using this "platform" is a disaster. It's like it actively doesn't want me to use it, or enjoy myself at the computer.

My first Linux experience was on Ubuntu, back in 2005. It used GNOME 2 and had tons of options and supported a great amount of shit. I got bored and frustrated trying to customize it, so I moved onto Fluxbox and Openbox, then got into tiling WMs: dwm, awesomewm, ratpoison, finally settling on i3-gaps.

So, GNOME used to be good, and I come from an angle of control and customizability. GNOME 3 is not good, and as a libre software developer I do not see GNOME as a stable platform to build software on. Between version 2 and 3 there was a huge upheaval, both technical and social. GTK3 to GTK4 is already pissing off developers and some users. What do you really have to offer other than an API that doubles as a treadmill?

Choice is Empowering

The diversity of the software ecosystem is precisely why initiatives like XDG could even form. Were this not possible, the platform we'd be using would in fact be called GNU, or we'd be stuck on XFree86 or some other big project nobody wanted to fork from at first. It's odd to me that those peddling new technologies -- pipewire, wayland, GNOME3/4, systemd, they all lament that there are choices in the environment and seek to actively replace other choices instead of trying to just be a good choice. This competitive approach does not convey an air of collaboration at all.

Why should people all use one platform? "So they can gain the benefits of standardization." Yeah I get the boilerplate answer, but think about long term risks of using someone else's platform to build your program. If FreeDesktop changes something, now you have to change with them. "Bitrot happens," one might riposte. Bitrot is an artificial phenomenon caused by other people intentionally changing things so that other software does not work. It's not a magic force of nature.

A Fractal of Projects

I think the last part of jwestman's post was the most accurate. I would take it a step further: computing itself is fragmented. We use computers for different reasons; already, we cannot reasonably expect every interface or API to be suitable for everyone. Standardization helps for interoperability, yes, but to make the most of that, you need a stable spec from a level-headed, experienced group of API writers and implementers, developers who are aware of computer users who don't use MacBook Airs or desktops with kilowatt power supplies, and people who are good at simplifying.

The best standards are the ones easiest to understand and easiest to implement. But another truth is, some have seen the downsides of standardization and fully understand what you're giving up when you "just use XDG" or "just use this framework", etc. You're inviting an entirely new set of bugs into your code, and problems to your project. And they don't come up at first. At first, integration's great! You just read the spec and tested it a bunch. It's when change happens upstream, long after you've committed resources to this platform, that it bites you in the ass. And by that point, you're dealing with the Sunken Cost fallacy. Congrats, your pet project is now dependent on Daddy Platform. Do you beg and plead with upstream to address your problem, refactor to suit Daddy Platform's preferences (i.e. making development decisions FOR you), or fork/restart on another toolkit? If you choose the latter, now you're stuck for a minimum of a few months, if your tool is non-trivial.

If you build from scratch, there are only a few things that can change and upset your project. First is any libraries you happen to use, then the standard library of your language. Lastly, the kernel.

That may result in a less integrated app, but I'm not concerned with my software looking like it belongs in GNOME or KDE. We are never going to have One True Interface that everybody likes. We won't have One True Audio Stack, or One True Networking Stack. This pursuit in finding The (only) One seems... almost religious.

Personally, I like the vast software diversity available to me in the libre software world. If XDG was the only game in town, it'd be really dull. Same for Apache, or even just GNU. What we need is for platforms to try being platforms on their own merits instead of parroting advocacy.

Choice is Inspiring

One of the most exciting things I experienced in libre software was realizing "I'm not stuck with Paint or Paint Shop Pro or Photoshop!" I learned about The GIMP, and Krita, MyPaint, mtpaint, libresprite, and so on. If we take the ideology of "consolidate and collaborate" to its conclusion, there would only be one image editor available for Linux, and it would have such a slew of features it would be an unmaintainable mess. I feel the same way about platforms. Whether it's elementaryOS, Tizen, enlightenment, GNOME, or KDE, each one has a different flavor of GUI, with conflicting or oddly accenting views on how a GUI should behave. As I mentioned before, humans use computers differently. That should reflect in their interfaces, and yes, even their choice of software.

As for The Free Desktop, it's been around for a long time, and it's practically a meme at this point. What people are shooting for with the Linux desktop now is mainstream appeal. That is not going to result in improved software, any more than adding more people to the Internet will improve its discourse. What we're more likely to see is less helpful bug reports, burned out or frustrated triage devs, lots of stupid community positions to fill, arbitrating all this labor coordination now needed from the influx of users... it sounds a lot like the way a business grows...

Conclusion

So yeah, I dunno who jwestman thinks they're fooling. A platform isn't what GNU/Linux needs. It needs APIs that can be left alone for a year or two and not need babysitting because upstream took Adderall and is gazing at glowsticks while they design the next iteration. If things are designed well, they don't need to be changed as much. Platforms need to be stable, predictable, reproducible, portable, and perhaps MOST importantly, slow moving!

Ideally, we shouldn't be asking anyone to waste lines of code on a standard that's not ready to be finalized in print. It's disrespectful to ask developers to rely and build on something you can't make any stability or mutability promises on. It's like building a Jenga tower on a table someone lent to you, but they shake the table every so often, ruining your progress up to that point. Would you want to build on that surface anymore? I wouldn't.

Stay independent, fellow devs.

-z

I no longer run GNOME on my laptop, mostly due to the lack of a proper tray without using an extension, and issues capturing windows in OBS. There doesn't appear to be a way to run or build OBS so that it sees both Wayland and X11 windows. Since most of my software was X11, I switched to XFCE until I get the gumption to put together an awesome-wm or i3 config for my laptop. While it still uses XDG standards, it at least doesn't limit me in how I arrange my UI or spin up my GPU for fancy effects. It's quite adaptable and gets out of the way. It also hasn't crashed yet. ↩