[HN Gopher] Suckless.org: software that sucks less
___________________________________________________________________
Suckless.org: software that sucks less
Author : flykespice
Score : 106 points
Date : 2025-02-21 18:27 UTC (4 hours ago)
(HTM) web link (suckless.org)
(TXT) w3m dump (suckless.org)
| sitkack wrote:
| One can embrace minimalism without all of this
| https://news.ycombinator.com/item?id=25751853
| indrora wrote:
| Or the self-reich-ousness of folks like Suckless[0], like
| telling the OG author of redare (pancake, who is a very
| competent malware reverse engineer) he's an idiot [1].
|
| [0] https://tilde.team/~ben/suckmore/ [1]
| https://dev.suckless.narkive.com/mEex8nff/cannot-run-st#post...
| jauntywundrkind wrote:
| Software that has an attitude & advertises based off of it.
| xmichael909 wrote:
| Yah, I don't know, DWM looks like it kinda sucks imho...
| jauntywundrkind wrote:
| I used it for a year or two before I switched to wmii. It was
| pretty great... In like 1997 or so.
| snailmailstare wrote:
| If the goal were not to suck at all a GUI would be the wrong
| choice of genre.
|
| But I do hope the st buffer overflow fixes my st usage in
| builds..
| postepowanieadm wrote:
| https://github.com/siduck/chadwm
| oblio wrote:
| Unclear, what is that actually? It looks like an IDE? Or a
| window manager?
| SahAssar wrote:
| My guess is its a theme for dwm.
| chjj wrote:
| Heresy.
| SoftTalker wrote:
| I've used awesome for years. Love it, and never really looked
| at anything else since I found it. It's based on a fork of dwm
| I guess, so maybe I would like dwm also.
|
| https://awesomewm.org/
| lugu wrote:
| It's been around ten years that my desktop barely changed except
| a few pixels thanks to dwm and dmenu. I am a bit exaggerating but
| I love the stability that minimalism brings. If only they could
| make a pdf viewer...
| vq wrote:
| Are you aware of Sioyek[0]? It's a PDF viewer with a fairly
| minimal UI and a focus on keyboard interaction.
|
| [0]: https://sioyek.info
| SoftTalker wrote:
| Thanks, I love finding little nuggets like this here.
| naasking wrote:
| SumatraPDF: https://www.sumatrapdfreader.org/free-pdf-reader
|
| No frills, super fast and small. Been using it on Windows for
| years.
| flubbergusto wrote:
| Have any issues with mupdf? I find it suckless.
| homebrewer wrote:
| zathura is close enough -- it's very minimalistic and supports
| everything under the sun: pdf, djvu, comics, epub...
|
| https://pwmt.org/projects/zathura/
| clintonc wrote:
| From the page about dwm:
|
| > Because dwm is customized through editing its source code, it's
| pointless to make binary packages of it. This keeps its userbase
| small and elitist. No novices asking stupid questions.
|
| ...sucks less than what? :) Simple is good, but simpler does not
| necessarily mean better.
| nicebyte wrote:
| yeah no. I've mainlined dwm + dmenu all the way back in 200x,
| I've written tons of makefiles and have the scars to prove it.
|
| These days I'm off of this minimalism crap. it looks good on
| paper, but never survives collision with reality [1] (funny that
| this post is on hn front-page today as well!).
|
| [1] http://johnsalvatier.org/blog/2017/reality-has-a-
| surprising-...
| snailmailstare wrote:
| I like these tools because they are minimalist.. I don't really
| care for the fact that they are C/make oriented and would
| rather help someone rewriting them in go or rust than show that
| I have a non minimal amount of scar tissue to work with a
| needlessly complicated past.
| nicebyte wrote:
| my comment isn't about things being written using
| c/make/whatever, it's precisely about the faulty assumption
| that complexity is needless.
| snailmailstare wrote:
| Oh then I totally disagree (or don't understand why you
| would need to see a psychoanalysis of a blacksmith to
| evaluate their offerings?). Many projects have places that
| need some complexity, configuration or advanced tools that
| doesn't imply the hardware store should stop selling
| average hammers or make you wade through an aisle of crap
| from providers like peloton to see if they better meet your
| needs.
|
| (I.e. show me where in the article he replaced a standard
| tool like the hammer or pot with a complex one customized
| to exactly what he wanted to solve or explain why that
| advanced tool wouldn't suck given that there's a lot more
| details than one would expect.)
| imiric wrote:
| The drama around this community is silly. I use these tools
| because I absolutely love their philosophy on software, and
| software alone. I couldn't care less what the authors personal
| beliefs and political leanings are, or who they offended on IRC
| or social media.
|
| I recently spent a few hours evaluating different terminals. I
| went back to urxvt, tried Alacritty again, gave Ghostty a try,
| and spent quite some time configuring Kitty. After all this I
| found that they all suck in different ways. Most annoying of all
| is that I can't do anything about it. I'm not going to spend days
| of my life digging into their source code to make the changes I
| want, nor spend time pestering the maintainers to make the
| changes for me.
|
| So I ended back at my st fork I've been using for years, which
| sucks... less. :) It consists of... 4,765 SLOC, of which I only
| understand a few hundred, but that's enough for my needs. I
| haven't touched the code in nearly 5 years, and the binary is
| that old too. I hope it compiles today, but I'm not too worried
| if it doesn't. This program has been stable and bug-free AFAICT
| for that long. I can't say that about any other program I use on
| a daily basis. Hhmm I suppose the GNU coreutils can be included
| there as well. But they also share a similar Unixy philosophy.
|
| So, is this philosophy perfect? Far from it. But it certainly
| comes closer than any other approach at building reliable
| software. I've found that keeping complexity at bay is the most
| difficult, yet most crucial thing.[1]
|
| [1]: https://grugbrain.dev/#grug-on-complexity
| 9283409232 wrote:
| Whenever suckless comes up, I see more people saying "the drama
| is silly" than I do actual drama. I don't even know what drama
| people are talking about.
| imiric wrote:
| 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=fals
| e&qu...
| indrora wrote:
| 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.
| deadbabe wrote:
| In order to write highly opinionated software you have to
| be some kind of an asshole, otherwise other people wear you
| down with their own opinions.
| ivirshup wrote:
| Not defending them, the Hitler laptop thing seems bad, but
| within Germany torchwalks are pretty normal and not Nazi
| associated. For example, there was one as part of a
| ceremony honoring Merkel as she left office.
| timewizard wrote:
| I took dwm and made it my own 15 years ago. Hasn't really
| changed since. From my point of view they're not wrong.
|
| Open Source Software used to be about individuality.
|
| They're not actively campaigning to remove other window
| managers are they? That seems to be a feature of "community
| software" for whatever reason.
| azthecx wrote:
| It also makes for very "efficient" software, the amount of time
| Sent has saved me, with very minor styling modifications, makes
| it one of the best software I've ever used.
| Barrin92 wrote:
| > I'm not going to spend days of my life digging into their
| source code to make the changes I want
|
| 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.
|
| The entire philosophy behind is entirely performative in many
| ways. 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.
|
| 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.
| imiric wrote:
| > 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.
| Avshalom wrote:
| >I can go through a 5K SLOC program and understand it
| relatively quickly
|
| you already said in your first post that you can't
| understand it.
| imiric wrote:
| I said I don't understand it, not that I couldn't.
|
| I don't because I haven't needed to. Understanding just a
| few hundred lines has been enough for my needs.
| eadmund wrote:
| But he _can_ , and pretty quickly. That's unlike most
| programs, which are more or less unintelligible to those
| not working on them.
| imiric wrote:
| Right, but "pretty quickly" is relative :D
|
| I'm not a C programmer, so it would probably personally
| take me days, maybe weeks to fully grok 5K SLOC of C.
| Still, it is potentially possible if I made the effort,
| unlike with other programs, like you say.
|
| It's a testament to the quality of the original C code
| that I was able to configure and use st and other
| suckless tools with my limited experience. An experienced
| C developer would probably find it a breeze.
| flubbergusto wrote:
| > I recently spent a few hours evaluating different terminals.
| I went back to urxvt, tried Alacritty again, gave Ghostty a
| try, and spent quite some time configuring Kitty. After all
| this I found that they all suck in different ways
|
| Last time I did the same (days not hours tho lol) was somewhat
| surprised to find myself landing on xterm. After resolving a
| couple of gotchas (reliable font-resizing is somewhat esoteric;
| neovim needs `XTERM=''`; check your TERM) I have been very
| pleased and not looked back.
|
| urxvt is OG but xterm sixel support is nice.
| klaussilveira wrote:
| > I went back to urxvt, tried Alacritty again, gave Ghostty a
| try, and spent quite some time configuring Kitty. After all
| this I found that they all suck in different ways.
|
| After moving to a gigantic monitor and gigantic resolutions, my
| poor st fork was suffering. zutty was a great replacement for
| me: https://git.hq.sig7.se/zutty.git
| imiric wrote:
| Ah, interesting. Thanks for sharing!
| saidinesh5 wrote:
| The biggest impact suckless had on me was via. Their Stali Linux
| FAQ: https://sta.li/faq/ .
|
| They've built an entirely statically linked user space for Linux
| . Until then i never questioned the default Linux "shared
| libraries for everything" approach and assumed that was the best
| way to deliver software.
|
| Every little cli tool i wrote at work - i used to create distro
| packages for them or a tarball with a shell script that set
| LD_LIBRARY_PATH to find the correct version of the xml libraries
| etc i used.
|
| It didn't have to be this way. Dealing with distro versioning
| headaches or the finnicky custom packaging of the libraries into
| that tar ball just to let the users run by 150 kb binary.
|
| Since then I've mostly used static linking where i can. AppImages
| otherwise. I'm not developing core distro libraries. I'm just
| developing a tiny "app" my users need to use. I'm glad with newer
| languages like Go etc... static linking is the default.
|
| Don't get me wrong. Dynamic linking definitely has it's place.
| But by default our software deployment doesn't need to be this
| complicated.
| jimmaswell wrote:
| There's definitely value in the static approach in some cases,
| but there are some downsides 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.
|
| If you require a library, you can specify it as a dependency in
| your dpkg/pacman/portage/whatever manifest and the system
| should take care of making it available. You shouldn't need to
| write custom scripts that trawl around for the library. Another
| approach could be to give your users a "make install" that
| sticks the libraries somewhere in /opt and adds it as the
| lowest priority ld_library_path as a last resort, maybe?
| butterisgood wrote:
| "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!
| dgfitz wrote:
| My current day job has probably 60 apps the depend on one
| shared library.
|
| Static linking has its place pace, no doubt, but it should
| not be the norm.
| zamadatix wrote:
| 60 programs y'all maintain as part of an overall larger
| solution or 60 randomly selected apps maintained fully by
| 3rd parties that just happen to share the same major
| library version?
|
| The former often makes a lot of sense in terms of
| deployment or maintenance - it's all really 1 big system
| so why rebuild and deploy 60 parts to change 1 when it's
| all done by you anyways. I'm not sure that's really what
| every build environment should default to assuming is the
| use case though but going shared libraries makes a ton of
| sense for that regardless.
|
| 60 programs maintained and built by 3rd parties which
| just happen to share major version of a library (other
| than something like stdlib obviously) would seem nuts to
| manage in a single runtime environment (regardless of
| static or shared) though!
| saidinesh5 wrote:
| > 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.
| viraptor wrote:
| > Half of them don't even use semantic versioning.
|
| This is a red herring. Distros existed before semantic
| versioning was defined and had to deal with those issues
| for ages. When packaging, you check for the behaviour
| changes in the package and its dependencies. The version
| numbers are a tiny indicator, but mostly meaningless.
| gleb wrote:
| I think semantic versioning actually predates
| distributions. It just was not called "semantic
| versioning." It was called Unix shared library
| versioning.
| wakawaka28 wrote:
| >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.
|
| I don't believe that it causes more problems than it fixes.
| It's just that you didn't notice the problems being
| silently fixed!
|
| There are issues related to different distros packaging
| different versions of libraries. But that's just an issue
| with trying to support different distros and/or their
| updates. There are tradeoffs with everything. Dynamic
| linking is more appropriate for things that are part of a
| distro, because it creates less turnover of packages when
| things update.
| realo wrote:
| You might want to take a good look at how Nix and Guix do
| things..
| saidinesh5 wrote:
| I know. But Nix doesn't make any of this complexity go away.
| It just helps you to tame this complexity and give you a
| reproducible system. Even Gobo Linux for that matter.
|
| At the end of the day the apps were a simple end user
| applications. They used a handful of library functions from
| different libraries. My users cared about just using my apps
| to do whatever the apps did. I just care that my app should
| work on their machines easily - no matter what version of
| what distro they're using.
| delta_p_delta_x wrote:
| Fun fact... Many Windows programs generally do some sort of
| 'hybrid static linking' (this is my own terminology) where
| programs are distributed with the `.dll` libraries just next to
| the binary. 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.
|
| Windows programs generally _do_ link dynamically to core
| Windows libraries--which users are never expected to mess with
| anyway--and the C and C++ runtimes, but even these can be
| statically linked against with `cl.exe /MT`. Some programs
| even distribute newer versions of the C/C++ runtimes; that's
| where the famous Visual C++ Redistributables come from.
|
| I agree, though--static linkage should be the default for end-
| user programs. 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.
| jclulow wrote:
| The thing is, dynamic linking doesn't mean using
| LD_LIBRARY_PATH or building full blown OS packages as the only
| way to find the correct libraries. There's a first class
| facility for locating shared libraries, using the -R flag to
| provide a RUNPATH/RPATH in the binary. The runtime link editor
| will use that path to locate shared libraries. You can make
| your binaries relocatable as well, by using $ORIGIN in the
| RPATH: this gets expanded at runtime to the path of the
| executable, so, e.g., $ORIGIN/../lib would go up one from bin/
| where the executable is and down alongside into the lib
| directory for your software.
|
| LD_LIBRARY_PATH is a debugging and software engineering tool,
| and shouldn't ever be part of shipped software.
| znpy wrote:
| I wonder how they are doing in the era of X11 leaving its spot to
| Wayland.
| christophilus wrote:
| My suckless stack is Niri (Wayland WM), Foot (terminal), and
| Neovim. The suckless folks wouldn't call it suckless, but it
| does suck less than anything else I've used on Wayland.
| woodrowbarlow wrote:
| dwl is a great wayland port of dwm, maintains the original
| philosophy well
| Gormo wrote:
| I assume they're doing fine, since that isn't really happening.
| swfsql wrote:
| I think I miss a suckless but async and for everything (lots and
| lots of apps). To the point where each of those different apps
| are single thread, and in such a way that they collaboratively
| all share the same single thread. So I'm looking for a single app
| that has many library-apps inside of it, all brutalistic, async
| and single thread.
| otabdeveloper4 wrote:
| Single threading sucks. It's 2025 and even low-end computers
| have dozens of hardware threads. I don't want to compute like
| it's 1995 anymore.
| swfsql wrote:
| If it sucks we can call it suckmore then
| unclad5968 wrote:
| > Do not use for loop initial declarations
|
| > Variadic macros are acceptable, but remember
|
| Maybe my brain is too smooth, but I don't understand how for(int
| i = 0...) is too clever but variadic macros are not. That makes
| no sense to me.
___________________________________________________________________
(page generated 2025-02-21 23:00 UTC)