Suckless.org: software that sucks less

Build systems often make it a huge pain to get the right rpath. The chrpath tool makes it easy to fix the rpath after libtool got it wrong.

And the main advantage of doing all that work vs statically linking is? Don’t get me wrong - dynamically linking for dev builds makes a lot of sense to cut down on relink times. But I just don’t see it for distribution since doing that RPath work reduces the main argument for dynamic linking (i.e. the OS can patch the vulnerability for all installed packages without waiting for each to release).

> e.g. your utility will need to be recompiled and updated if a security vulnerability is discovered in one of those libraries. You also miss out on free bugfixes without recompiling.

This was the biggest pain point in deploying *application software* on Linux though. Distributions with different release cycles providing different versions of various libraries and expect your program to work with all of those combinations. The Big famous libraries like Qt , gtk might follow proper versioning but the smaller libraries from distro packages - guarantee. Half of them don't even use semantic versioning.

Imagine distros swapping out the libraries you've actually tested out your code with with their libraries for "security fixes" or whatever the reason. That causes more problems than it fixes.

Custom start up script was to find the same xml library I've used in the tar ball i packaged the application in. They could then extract that tar ball wherever they need - including /opt and run the script to start my application and it ran as it should. Iirc we used to even use rpath for this.

"Free bug fixes without compiling". I think YMMV.

It depends a lot on ABI/API stability and actual modularity of ... components. There's not always a guarantee of that.

Shared libraries add a lot of complexity to a system for the assumption that people can actually build modular code well in any language that can create a shared library. Sometimes you have to recompile because, while a #define might still exist, its value may have changed between versions, and chaos can ensue - including new, unexpected bugs - for free!

Imo this is a much saner solution for a system that supports precompiled applications.

Every time I tried to get a third-party binary app running on Linux, I discovered what the vendor did is they shipped half their dependencies as blobs, and relying on the system for the other half - which is an incredibly brittle system that breaks constantly.

The entry point usually is a script that sets LD_LIBRARY_PATH and then calls into the executable.

> There is no concept of RPATH on Windows—the loader looks for dynamically-linked libraries in a fixed set of locations which includes the binary's directory.

This is not true - you can control the DLL path via manifests. There's also a "known DLLs" list in registry which can globally redirect basically any DLL system-wide.

Many programs link various libraries of theirs statically, but then dynamically link to the system C library.

For instance, GNU Make uses some of GNULib.

https://git.savannah.gnu.org/cgit/make.git (gl subdirectory)

For Rust, cargo zigbuild lets you compile against arbitrary old glibc. Probably can get that working with C as well.

Compiling for CentOS 6 is a linking problem, and any linker lets you link with whatever you want, it's a matter of running the linker with the right arguments.

> I long for a time when Linux gets 'libc' redistributables and I can compile for an old-hat CentOS 6 distribution on a modern, updated, rolling-release Arch Linux without faffing with a Docker container.

The Linux linking model is so bad. So extremely very bad. Build systems should never rely on whatever garbage happens to be around locally. The glibc devs should be ashamed.

Nobody knows how to use the package manager. What happens in practice, is every single program uses the the package versions the distro happens to ship with.

If you want a newer version, too bad - your OS doesn't ship that so better luck in the next release. OR you can set up a private repo, and either ship a binary that has the dependencies included (shipping half the userland with your audio player), or they package the newer version of library, which will unwittingly break half your system, if not today, then surely at the next distro upgrade.

It speaks volumes of Linux package management woes, that no vendor ships anything analogous to brew or chocolatey.

> I am convinced that every argument in favor of static linking is because they don't know how to package-manager.

Which would be a fair reason. People who like to build things might just not want to also learn how to package stuff.

The sane thing here is to maintain a clear notion of what the "OS" is versus the "app", and use dynamic linking on that boundary, but not elsewhere. Which is more or less how Windows and macOS do things.

I would be more accepting of the trade-off if it wasn't so brittle in practice.

Nix is much closer to a "good" dynamic linking solution IMO except that it makes it overly difficult to swap things out at runtime. I appreciate that the default is reproducible and guaranteed to correspond to the hash but sometimes I want to override that at runtime for various reasons. (It's possible this has changed since I last played with that tooling. It's been awhile.)

The article touches on that. If "your whole distribution" comparable to a Chrome in size? That gets updated.

SumatraPDF: https://www.sumatrapdfreader.org/free-pdf-reader

No frills, super fast and small. Been using it on Windows for years.

Thanks, I love finding little nuggets like this here.

Eh, it vendors an old version of mupdf. Very bad idea, considering that it's a C program/library handling a notoriously complex format often shared on the Internet.

Personally, I just use mupdf (which I sandbox through bubblewrap).

To the currently dead sibling comment by kjrfghslkdjfl (on the off chance they get to see this): mupdf is extremely cross platform. I felt that should have at least been mentioned before your comment reached being dead over that misunderstanding.

Seconding this. It's my default choice for many file formats, not just pdf. However it doesn't support jpegxl so in those cases I use Okular (very much not minimal but quite usable).

That's android only. He's talking about desktop.

I like it too though.

> There's no rationale given

True and it would indeed be desirable that it were. Here I go out on a limb and assume it's because someone got bitten by attempting to use the loop index outside the loop (common for search operations) while declaring the index within and outside the loop. A bug (gcc and clang can warn about using -Wshadow, but which sadly isn't part of -Wall) which might easily occur when multiple people edit the code over a longer time-span.

their rationale is very inconsistent: tells you to use c99 but you must place declarations at the top, and you can't use C++ style // comments (introduced in c99 aswell).

Why not force c90 altogether then?

I had a look at your links, and I think the assertion that the people involved in Suckless are National Socialists is insufficiently supported. I don't know these people outside their software, but if you're going to accuse someone of being part of some reviled political group I think you should have something stronger than "they went on a hike carrying torches around the time some extremist group had a march with torches".

Having been on their mailing lists and IRC channel for over four years, I have seen maybe a handful of "edgy" comments that made me go "sigh" or "Ew!" and they are generally from two or so people that are on the fringe of the community. Yes, it is possible that this is some sort of elaborate trick, but they sure give the appearance of mostly a bunch of helpful folks that care deeply about their own code and projects while caring very little to police people and rather just ignore them.

Oh, there are also the edgelords occasionally lured in by Luke Smith's videos (who has never sat foot in community or contributed code while I have been around and I am not sure if he ever did) who usually get laughed out of IRC after delivering an unhinged chanspeak rant.

I get that, they're probably assholes. But if I limited my usage of software and consumption of art to only those not authored by assholes, I would probably have a less enjoyable and boring existence. Not to mention exhausting.

I think it's possible to separate the art from the artist, and enjoy the art without being concerned about the artist's beliefs, and whether I disagree with them.

Also, you don't necessarily support them by using their software. The software is free to use by anyone, and you never have to interact with the authors in any way. Software is an amorphous entity. Unless they're using it to spread their personal beliefs, it shouldn't matter what that is. By choosing not to use free software, you're only depriving yourself.

But this is your own choice, of course, and I'm not saying it's wrong. Just offering a different perspective.

That would indeed be concerning if true; do you have a reference? Unfortunately, the vast majority of such claims I've found to be misconstrued which makes me skeptical (the boy keeps crying wolf).

Then, when people are no longer allowed to talk about what (stupid shit) they believe and jokes should only be made behinds peoples back.

Who should be on the committee that decides what we may talk and joke about and how should the committee inform it self?

The new forbidden topics will be chosen from the set of topics people talk about which get smaller, stranger and more political. What people secretly believe will be much closer to the secret dialog while the public dialog floats away.

That people are saying things is the least of your concern.

Fascinating perspective tho. It is much easier if one is more secure, talks easy or has a more mundane world view. Not someone one can choose. Thicker skin however.

Also interesting, if one didn't like the people running the lunchroom at the end of the street or didn't like the visitors you use to be able to go to some other place. Today they are all part of the same chain. We've lost a lot of freedom there.

It's honestly distressing how all of these violent ideologies are growing in popularity. Nazism, socialism, and whatever else should be thrown on the pile. If you're a queer black "executive" like myself, there are a lot of people that believe the world would be a better place with you dead.

It's getting to the point that I'm considering keeping myself ignorant of developers' beliefs for my own mental wellness.

Absence of obsession with identity politics is not the same as wanting you dead. I don't want my tax dollars funding your personal lifestyle choices, just as you wouldn't want yours funding mine.

[flagged]

> This is an odd thing to bring up though because that's quite literally the only way to make any changes to suckless software, editing source code in C.

You're ignoring the part where the tools are often a fraction of the size and complexity of similar tools. I can go through a 5K SLOC program and understand it relatively quickly, even if I'm unfamiliar with the programming language or APIs. I can't do the same for programs 10 or 100x that size. The code is also well structured and documented IME, so changing it is not that difficult.

In practice, once you configure the program to your liking, you rarely have to recompile it again. Like I said, I'm using a 5 year old st binary that still works exactly how I want it to.

Maintaining a set of patches is usually not a major problem either. The patches are often small, and conflicts are rare, but easily fixable. Again, in my experience, which will likely be different from yours. Our requirements for how we want the software to work will naturally be different.

The madness you describe to me sounds like a feature. It intentionally makes it difficult to add a bunch of functionality to the software, which is also what keeps it simple.

Sometimes, I have had to change software (although not from suckless, since I do not use any of their software) by modifying and recompiling it, to do what I wanted.

> There's nothing simple or "unbloated" about having to recompile a piece of software every time you want to make what should really be a runtime user configuration, and it makes an entire compiler toolchain effectively a dependency for even the most trivial config change.

It is true, but depending on the software, sometimes this is acceptable. (Some of the internet server software that I wrote (such as scorpiond) are configured in this way, in order to take advantage of compiler optimizations.)

For some other programs, some things will have to be configured at compile time (mostly things that probably don't need to be changed after making a package of this program in some package manager), although most things can be configured at run time and do not need to be onfigured at compile time.

> I tried their window manager out once and the only way to add some functionality through plugins is to apply source code patches, but there's no guarantee that the order doesn't mess things up, so you basically end up manually stitching pieces of code together for functionality that is virtually unrelated. It's actual madness from a complexity standpoint.

This is a valid criticism, and is why I don't do that for my own software. However, it is sometimes useful to make your own modifications to existing programs, but just applying sets of patches that do not necessarily match is the madness that you describe.

Not when you want to write your own patches, it isn't. I think the design of DWM could be improved to make patching easier, but it was a revelation to me when I discovered it: for the first time in my life, I was using open source software that was actually designed to be extended.

Ah, interesting. Thanks for sharing!

Short form:

* One of the lead devs' laptops is named after Hitler's hideout in the forest

* Their 2017 conference had a torchwalk that was a staple of Nazi youth camping (and heavily encouraged by the SS as a nationalism thing)

* Multiple of the core devs are just assholes to people on and offline.

* Most of the suckless philosophy is "It does barely what it needs to and it was built by us, so it's superior to what anyone else has written". A lot of it shows in dwm, dmenu, etc.

I'm not sure how you missed it, since it comes up in practically every Suckless-related thread[1], including this one. The drama is mostly in social media and IRC circles, though it tends to spill over here as well.

[1]: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

I use foot and with a catpucchin theme , oh it's so nice and cozy.

I use pure zsh with some plugins manually installed , the luke smith dot files, and the history part sometimes take a lot to load but foot is just fast

I agree, but there is a sort of beauty in programs that were written for absurdly slow hardware.

There was a thing on HN like seven years ago [1] that talked about how command line tools can be many times faster than Hadoop; the streams and pipelines are just so ridiculously optimized.

Obviously you're not going to replace all your Hadoop clusters with just Bash and netcat, and I'm sure there are many cases where Hadoop absolutely outperforms something hobbled together with a Bash script, but I still think it serves a purpose: because these tools were written for such tiny amounts of RAM and crappy CPUs, they perform cartoonishly fast on modern computers.

I don't like coding like it's 1995 either, and I really don't write code like that anymore; most of the stuff I write nowadays can happily assume several gigs of memory and many CPUs, but I still respect people that can squeeze every bit of juice out of a single thread and no memory.

[1] https://adamdrake.com/command-line-tools-can-be-235x-faster-...

If it sucks we can call it suckmore then

Unclear, what is that actually? It looks like an IDE? Or a window manager?

my comment isn't about things being written using c/make/whatever, it's precisely about the faulty assumption that complexity is needless.

Same. I ran dwm for a long time. These days I just run Gnome. You can make it work very similar to a tiling window manager, and all that random crap the world throws at you (printers, projectors, random other monitors, Java programs) "Just Work".