Elementary OS is imploding

Re:Elementary OS is imploding by moron4hire on Wednesday March 09, 2022 @05:52AM (#30613145)

I am struggling to think of any open source project of any size beyond small NPM packages that I've experienced that do not have an arcane build system. At least all of the ones I've encountered have been incredibly obtuse, to the point that I've mostly just given up. Anything Mozilla, Google, or Facebook writes. Actually, come to think of it, the only open source projects of non-trivial size I've ever been able to build without dedicating several weeks of time to have been from Microsoft.

[ Parent | on HN ]

Re:Elementary OS is imploding by badsectoracula on Wednesday March 09, 2022 @06:48AM (#30613467)

I've built a bunch of software from source myself and pretty much all of it is

    ./configure [options]
    make
    make install

...or the closest equivalent (e.g. some use meson or cmake).

[ Parent | on HN ]

Re:Elementary OS is imploding by dwohnitmok on Wednesday March 09, 2022 @07:13AM (#30613607)

To be fair, these steps can go wrong when the project doesn't make clear that there are a lot of implicit dependencies for the configure step to even work (and then make can sometimes break if those implicit dependencies aren't the expected version).

But to your point, there are a lot of projects for which those steps work just fine.

[ Parent | on HN ]

Re:Elementary OS is imploding by badsectoracula on Wednesday March 09, 2022 @09:03AM (#30614471)

Sure and in fact it did happen with one of the software i was trying to build, but the (first) error is usually along the lines of "cannot open include file foobarlib.h" - so i can search for that library (and many package managers let you search for the header files directly) or "this struct doesn't have that field" (common with -IIRC- libjpeg that at some point made some structs opaque). The latter is a bit more work (fixing the code) but it is also very rare.

[ Parent | on HN ]

Re:Elementary OS is imploding by ModernMech on Wednesday March 09, 2022 @09:18AM (#30614615)

Indeed which is why I like rust so much. The best thing they did was to make every program statically linked, so the build process succeeds 99% of the time. The only time I’ve had it fail for me really is when a project depends on OpenSSL and I don’t have it configured to it’s liking. Those time bring me back to the “make” days when I’d have to spend an afternoon installing some tool with all its dependencies, and even then sometimes I’d sometimes give up in frustration.

[ Parent | on HN ]

Re:Elementary OS is imploding by badsectoracula on Wednesday March 09, 2022 @09:50AM (#30614994)

The problem with static linking is that if all you have is a binary (e.g. closed source program) you do not get any new fixes or features from the libraries you depend on.

For example many early 2000s games that used SDL 1.x can be made to work on modern Linux simply by removing the SDL so file they were bundled with and let them use the one the system provides (most common issue would be audio but also mode setting or full screen support).

This isn't a thing only on Linux btw, SDL games that have an old DLL can also have issues on Windows (in fact a game of mine was like that :-P) but be made to work by simply replacing the DLL with a newer one.

[ Parent | on HN ]

Re:Elementary OS is imploding by ModernMech on Wednesday March 09, 2022 @10:58AM (#30615861)

That’s surely a problem but I try to avoid closed source software for this very reason. Obviously there are a million and one ways closed source software can leave you high and dry, and static linking is one of those but really I think the operative word driving the sadness here is “closed” rather than “static”.

[ Parent | on HN ]

Re:Elementary OS is imploding by badsectoracula on Thursday March 10, 2022 @05:53AM (#30625495)

This can be an issue with open source programs as well from a practical perspective. For example let's say i modified Gtk to use a sane file dialog - i'd rather replace the system installed shared object once and have everything use it rather than recompile everything that uses Gtk.

[ Parent | on HN ]

Re:Elementary OS is imploding by dwohnitmok on Wednesday March 09, 2022 @06:04AM (#30613223)

If I think about the software that I use on a regular basis that I've built from scratch at least once, quite a few of them are fairly straightforward and basically just the two lines I indicated. Just off the top of my head all of these were just those two lines (download build tool then run the install step):

1. Kubernetes

2. git-annex

3. The new generation of replacements for various core command tools (e.g. ripgrep, fd, etc.)

EDIT:

> several weeks of time

Out of curiosity, what projects were those that took several weeks? My presumption is probably very GUI heavy ones?

[ Parent | on HN ]

Re:Elementary OS is imploding by umanwizard on Wednesday March 09, 2022 @07:47AM (#30613842)

I don’t know about weeks, but I remember LibreOffice, Firefox, and Clang all having their own ad hoc build systems requiring some amount of custom configuration.

Debezium is also very Byzantine, or maybe it’s just that I don’t understand maven.

[ Parent | on HN ]

Re:Elementary OS is imploding by ramses0 on Wednesday March 09, 2022 @01:05PM (#30617900)

apt source hello

apt build-dep hello

dpkg-buildpackage ...

https://wiki.debian.org/BuildingTutorial#Building_the_source...

https://ostechnix.com/how-to-build-debian-packages-from-sour...

https://buildd.debian.org/

https://buildd.debian.org/stats/

...all hail distribution package maintainers!

There's a little more to it (deb-src into /etc/apt/sources.list), but it's super-instructive to do it on something like 'busybox' and be able to make legitimate changes to something like 'ls' ... or do it to 'coreutils' and make modifications to the "real ls".

Although the "speed-bump" to being able to build packages for the first time is a bit rough, the benefit is that the documentation is outstanding and the process is pretty seamless for most/all packages, regardless of complexity.

The docs and tools are written by engineers and maintainers for people just like you... an independent consumer/programmer, sitting at their computer, trying to (re-) build a package to add a feature or fix a bug.

The other benefit is that the process is relatively consistent across literally thousands of packages and there's a lot of docs + tools +features to handle almost any scenario that Debian (Ubuntu) supports. If you learn it for one use case, your investment pays dividends across all other packaged software.

[ Parent | on HN ]