As a way to learn linux, I did LFS. I even did the harder HLFS, when it was a thing. LFS and the gnu stuff generally was pretty handy to build.

Now I find myself having to learn to build stuff again. But it's messier. There's a multitude of build systems with their obtuse options. If you ever got stuck building, you could run './configure --help' and it would list you all the options. What are you supposed to do in these new underperforming build systems?

An increasing number of programs are being distributed as flatpacks, tarballs, AppImages, Flatpacks, or whatever, throwing away the advantages of shared resources. And there's more scripting languages in everything that you can't faultfind - especially the GUI.

For example, my Ultimaker-Cura crashed on file/open until I installed xdg-desktop-portal-gtk-1.4.0-x86_64-2salix15.0 package. What's that? I'm on Slackware! I posted here last week, was fooling with it for 3 days, until some kind soul told me that somebody else on XFCE has solved his problem that way. I thought I might as well try it as not, and I'm going.

I exploded the xdg-desktop-portal package. It described itself as "APIs for building sandbox portals of desktop services and integrations." An end user shouldn't need APIs. They're for programmers, surely?

That' no way to maintain and fix a linux system for a non-software guy. Am I supposed to have a working knowledge of every one of the scripting formats used in X or Wayland? Over the years, I've been given dbus enquiries, an alsa config, intricate option sets for more inscrutable programs than I can count, and I've helped many others out too. But there's too many scripting formats now for a non-software guy to stay abreast of. Why does there have to be so much pain with linux? I can boot my unused win11 OS and I'm sure Cura would have opened a file there. but the files are on a linux partition.

I totally agree with you. Things are much more complicated (than it was 20/30 years ago). Producing an app which can be built on all the distros is almost impossible (not to speak about the backward compatibility with older releases).
And we have now much more developers and much more code (and unfortunately sometimes the quality is not that good).
Using appimage, flatpack and similar distribution independent solutions mean they do not even want to care about it (configure is not supported any more).

1 members found this post helpful.

You could always give up Slackware and use a distro with a repository that contains the stuff you need! I can't remember the last time I compiled a program.

I tried that on a RazPi when I had Rapberry Pi OS = Debian in disguise. They probably pimped out their devs to work up an OS for the various flavours of SBC.

I got stuck with no sound after the first update on Bullseye. Debian didn't care, Raspberry didn't know or care why, and no user had a clue. And you had to endure their choice of software - Cinnamon, Systemd, etc. And I couldn't pull some odd wifi driver off github, compile, package, & install it. Making a .deb must be a @$#£&€%! nightmare.

I won't deny it does have it's bright side IF there are a large number of devs there building stuff. Otherwise, you're selling yourself short.

Let's pick an obvious example: I use a 32/64 bit wine install just for a 32bit program, needing 32bit libs. I use that many times a week. No alternative exists. That's a nightmare in most distros.

It may also have to do with programs getting bigger and more involved. Combine that with wanting it usable by as many as possible and the installation from source is going the way of the Dodo. When you can use something to build a package for you that is universal there is little incentive to go through the process of making the stuff necessary to compile from source. And naturally the more complicated the program is it becomes easier every time to skip that part. This becomes even more of a problem when libraries are mismatched on the distro verses what the program was designed for.

I think when people say it's the Windowsification of Linux they fail to realize that everything changes and makes progress. Less about becoming Windows and more about efficiency. I love shared resources and libraries. Just the concept makes me happy. But at the end of the day after awhile it gets so involved and complicated that people will just say screw it and turn away from it. Couple that with raw hardware resources. Back in the day when you had to worry about every free kb on the drive it mattered. These days storage is dirt cheap (relatively) so there is little reason to go out of ones way to squeeze every kb out of it. Ram is the same way. While there are plenty of games and other software that burn up ram the majority of programs don't use much. With machines coming with 16+ gigs of ram these days while it may eventually become necessary for now there is far more ram available than one realistically needs for typical usage. The only real losers so to speak are people trying to maintain old hardware that can't be upgraded. As that isn't a huge market segment developers won't go out of their way to support it.

It is a bit more faff than it needs to be, but ultimately involves putting data in one archive, metadata and install scripts in a second archive, and both of those with a version file, into a third archive (the deb file).

If one tries to do that with the official tools, they'll get numerous packages occupying hundreds of megabytes of disk space - in reality it only takes one extra package* and a short shell script.

*(binutils, because the deb archive uses "ar" format, even though the other two can be either regular or compressed tar)


-

As for why buildings things is getting so difficult, that comes down to fewer people choosing to understand what they're doing.

This results in self-fulfilling justifications like "software is complicated", causing more an more dependencies and less and less understanding, even though it can almost always be simpler if developers would put in a bit more effort upfront.

Sometimes it might not be the developer's fault - in bad corporate environments it can be all some people know - but other times the developers are absolutely to blame - they make things over-complicated because they're [insert chosen pejorative].

2 members found this post helpful.

@jmgibson1981: Mostly true. But you also can get irritating library conflicts. A per hate is libreoffice & boost: Every time I install libreoffice, it pukes over my boost version. It wants only one boost lib, and usually one minor version later, so a symlink does nicely on slackware.

Does that work on other systems? I always ground to a halt quick enough in regular distros because I'd compile something & install it. Then in a few months, updates would discover it and I'd get these really weird errors, which I wasn't able to sort out at the time. I had Slackware-14.2 for 3 years before I had to update to current. Admittedly, I was over 6 months in hospital.

yes, that is not slackware/ubuntu/raspberry/whatever specific. It is quite general. If you want to write music, draw a picture or play a game you need to upgrade, patch and solve conflicts...

I beckon this. Now there may be cultural influences, but I encounter too many people (relatively “more” than before) who do hot ask for more, who have no expectations and are – themselves – completely unaware of the alternatives. Complaints are not uttered, because they measure a degree of inconvenience against some established scale, but hearsay indicates that they could.

We have an immense problem with education on any tier of decision-taking- and execution.

I use Eric's boost-compat package and that seems to insulate me against LO update problems. But I agree that everything is getting more and more complicated.

I think that's a real and valid issue but a different one to what I'm bellyaching about. I raised a family in the 80s, 90s & 00s. I didn't have television until I was nearly 8 and it was low budget bought in shows in the main. I read books, I fixed stuff, I had a meccano set and scalextric (racing cars on a track). I had patience & persistence.

My kids had much more tech, and time on a pc from an early age. They never bother to look things up in a book - it's too slow. My kids will still read a book, although younger ones don't. Their dictionary, thesaurus, etc is google. They have neither the patience or persistence that I have. I haven'tthe patience I had in former years.

Apply that to software: folks want to install & go; they want to point & click, not type or read a man page. It's no coincidence that slackware attracts the older user.

MAKE has been around nearly 50 years, and has changed only a bit during that time. All of the other build systems exist because developers tired of riding a horse when everywhere else they see motorcycles, so they built something that worked better for them. Had they all combined efforts on one thing it would have been boring, but they do not agree even today on what "better" should look like: so we have options.

Options are good. Options that are decided by someone else and you are stuck with them much less good. The options here are the build system the developer decides to use: that choice belongs to them and users are stuck with it unless they want to resort the code and migrate it to a different development system (non trivial). No developer is going to want to take time out form being productive to migrate their projects to multiple build systems, so here we are mired in the developers options (probably as we SHOULD be: since they did all the hard work).

It is no unreasonable of the developer to assume that people who want to recompile their code, possibly with changes, will have the horsepower to understand and replicate their build environment. The good ones even leave instructions and clues about how to do it successfully.

It is often fun. No one said it was supposed to be easy. The really fun stuff is often not easy. ;-)

Really? I'd say that any distro would give you 32-bit libraries for Wine, since people use Wine for games (still often 32-bit) or legacy software. When I was looking for a replacement for CentOS, I naturally tested Wine and I had no problems with PCLinuxOS, Solyd, Mageia, or Mint.

Last time I tried Mint was about 19.0 and there were long forum threads. I think devs realised 32bit windows software wasn't going away anytime soon, and bent their systems to suit. I have heard more positive noises of late from a few sources, so you may be right. Slackware and Fedora iirc were the only ones to go the lib/lib64 route for 32/64 bit libraries which is the way Slackware was since 13.0. It is also the most elegant solution. The 32/64 compile of wine is no mean feat either, btw. Most offer wine(=64bit) & wine32 as separate packages. I don't have to know the bittiness(64/32) of any program to run it.

it is getting bad, i use "qmake" "cmake" and good old autotools

Then there is "scons" i use for one program .