Hacker News Reader

Comment by Telaneo | Hacker News Reader

Many devs love to shit on the guy from the 'I just want the exe. Why is there no exe'? meme. On some level I get it. And in some cases it's not even reasonable to provide a single binary or whatever. But on the other hand, github is being used to deliver end-user software. It is no longer just a dev's workspace/playground. That and the amount of makefiles and python scripts I've seen fail due to some dependency nonsense fills me with rage. It's never Just™ typing 'make' unless the code is trivial. I can wade through the bullshit. I shouldn't have to, and many others aren't even able to.

View on HN

A lot of mature applications just gave up chasing the bleeding edge, and now only distribute Flatpack/snap/AppImage which is similar to classic exe/DLL ecosystems. A kind of silent tragedy for efficient shared library paradigms.

The hard truth is OSS is often chaotic as there is no authority saying a given API is "good-enough" to version freeze, and it limits how much individuals can integrate without upstream source-tree contiguous-integration at the mercy of 150k devs whims. =3

Given the amount of dependency bullshit I've had to deal with over the years, I'm glad the idea of using shared libraries for everything is dying. I like the core idea of it, but the implementation has never actually Just™ Worked™ in my experience outside of either trivial or curated examples. I guess all those mature applications discovered the same thing.

Flatpacks are great. I've barely ever had a problem with them, and the problems I did have were solvable with a cursory web search. Yes, they take up more space. That's a worthwhile trade-off in exchange for actually working.

>A kind of silent tragedy for efficient shared library paradigms.

This only tells me you have no idea how distributions work. The distributions themselves decide what kind of artifact they want to get out of building the software. The developer of the application cannot know that by definition because there is an unbounded quantity of distributions out there.

The only thing the application developer can do is provide a solution that works everywhere or provide a solution that helps with customized builds. There is no solution that both works everywhere and is customized everywhere.

>This only tells me you have no idea how distributions work

Packagers do try to coordinate distro release cycle mess, but ultimately long term support for complex programs is tied to the OS version constellation in upstream builds. Thus, the users are going to experience the Beta stage of that code... even though people often assume a polished release-candidate isn't just a euphemism for public Beta.

Thus, the assets needed to maintain a projects function are likely to stop working within 3 years or less. Indeed, some parts of the ecosystem are worse than others.

Low attention code creates 2 paradoxes:

1. new versions may not be supported on newer OS releases due to API mutation, and old dependency injection

2. versions may not be back-ported due to old releases missing API features, and new dependencies

I think it is hilarious people make up silly stories like it is not a fundamental constraint/liability in FOSS. The situation is not anecdotal, and reaches deep into the kernel driver areas. This is why we can't have nice things, as a billion conflicting use-cases is just a chaotic ecosystem. =3

Reply on news.ycombinator.com