[Annatar]

"No need to install". This is every system administrator's nightmare: users running arbitrary executables bypassing operating system packaging. Come time to upgrade or reinstall what can happen? If there are security updates which are needed to the program, what could happen, since this is statically linked?

This is the pinnacle of destructive lazyness and amateurism in IT: as a developer it is one's job to master every operating system packaging format for the target platform one develops for. OS packaging is a tool invented for developers, not a tool meant to be subverted at every turn and opportunity like this.

[etaioinshrdlu]

Literally the reason why PCs won over mainframes. Users want to run the software they want to run.

If you don't trust your users to run software on your server you probably shouldn't let them on your server in the first place... or else contain and isolate them with a VM or similar.

Multi-user operating systems are feeling a bit like they are going the way of the dodo, to me... That is acutall multi-user systems, not user accounts for system services.

[Annatar]

What do you think powers the InterNet that you're connected to right now? Multiuser systems, running applications under different logins. Even the much hated systemd brought physical multiuser computing back to GNU/Linux.

[etaioinshrdlu]

Yeah, but the user accounts are at the application level not the os level.

I doubt there is a top internet company around that makes a unix account for each web user. That would be an antipattern...

[Annatar]

Search for "free shell accounts". You might be surprised.

[etaioinshrdlu]

It kind of reminds me of shared hosting providers without root access. Sure they exist but really have been overtaken in a big way by virtual private servers... That's what I mean by they seem going out of style.

[viraptor]

I don't believe this is really a problem for administrators. Reasonable multi-user hosts will have both home and tmp mounted no-exec and will not allow fuse - appimage will not work. This solution will work just fine of personal machines though. I'd rather native packages were distributed too, but if the choice is this or nothing... why disappoint people?

[pjmlp]

Any savy UNIX admin will be able to prevent new executables to run under user accounts.

[Annatar]

But it won't solve the problem of developers' unwillingness to learn how to make operating system packages now will it?

I don't get it: people like that will sink and waste hundreds of hours learning useless garbage like Puppet, Ansible, Chef, Docker or Kubernetes without batting an eyelash or even thinking twice about it, but they'll argue and fight back like hell come time to deliver their software as clean OS packages because they don't want to learn the technology. Technology which exists for them first and foremost: OS packaging is meant to be a developer's tool and best friend.

[pjmlp]

Because those providing the said technology cannot agree what it means to be a GNU/Linux OS, and we have limited time on our life to bother with thousand variants of it.

[Annatar]

Linux is just a kernel, so every distribution is a somewhat similar yet completely different operating system.

Reality is, most software targets CentOS / RHEL, OpenSUSE / SLES and Debian / Ubuntu. That's exactly two packaging formats, RPM and DPKG.

Now, let's presume for the purpose of illustration that learning both of those takes 100 hours (it takes much less): to learn Chef, Puppet, Docker, Ansible and Kubernetes to any degree of proficiency takes about 1,000 hours. Where's the business value?

[pjmlp]

Try to install a random RPM package targeted to Red-Hat on SLES to see how far you will go.

[Annatar]

That's again due to incompetence and not a fault of RPM. My own spec files build cleanly across both without any additional effort. It's not rocket science but insight.

[Annatar]

But you don't have limited time to re-invent the wheel over and over again by inventing new programming languages, learning new frameworks and re-implementing what already exists? How many headlines here were of the "why do it inefficiently? Because I can!" type? The limited time argument is a fallacy in this context.

[pjmlp]

A language package manager works everywhere, regadless of the OS.

Thankfully modern languages are mostly OS agnostic due to their rich runtimes and library eco-systems.

[Annatar]

A language package manager is system administrator's enemy and her or his nightmare.

Now you explain to me why and how that is the case.