Hacker News Reader

Comment by codedokode | Hacker News Reader

Linux still is not friendly to proprietary code. To install third-party software user often has either to run a bash script with root privileges that can potentially break the system, or add a proprietary repository (which allows its owner to replace any software on user's machine). Before flatpack and snapcraft there was no sane way to install third-party software.

The same problem is with drivers. Maybe there is a way to allow drivers with closed source code and get better hardware support? For example, what about copying or supporting Android's driver model?

View on HN

Linux is much more than general distros and closed source drivers are pain in the ass for everybody. Vendors should just mainline the support for their HW, especially if they benefit from Linux overall.

Maybe there is a way to run them safely. For example, have an open source part running in kernel, and closed source part that is properly isolated in userspace.

That's AMD's current model. There's both community open drivers and closed vendor drivers sharing an open and upstreamed kernel module.

There are a number of things that could be done to improve the experience with proprietary drivers, but all of them undermine the Linux driver philosophy. For the kernel community, any driver that is not mainlined is doing it wrong (and there are a number of compelling arguments behind this position), so the out of tree / proprietary driver experience is intentionally not improved.

Is this trolling or are you serious?

Proprietary drivers are shipped with many distributions. For example nvidia drivers are shipped with Ubuntu. If the repo drivers don't suit you, you can (just like on all other platforms) download drivers from the vendors website.

Proprietary drivers are allowed and are shipped in many distros (just like in Android), but they cannot be included in the kernel upstream (then they wouldn't be proprietary).

Every vendor is welcome and encouraged to submit their driver to the upstream linux kernel project. Some vendors do however chose not to do so, for a variety of terrible-to-mediocre reasons.

Welcomed and encouraged to submit their driver for consideration. I would guess that the vast majority of vendor-proprietary drivers would get rejected from upstream, so for most cases the viable options for vendors wishing have an driver in mainline are to improve an existing reverse-engineered driver or rewrite the driver to fit the kernel standards.

If they accounted for mainlining from the start and not just as an afterthought, they would not have this issue.

A lot of the drivers are older than their Linux port, which makes mainlining from the start not really make sense. Nvidia and PowerVR I know for a fact are in that category.

Sure, that makes sense.

Getting your driver accepted upstream is a conversation with the maintainers of that kernel part.

You can't just throw a pile of code over the fence and assume it will be accepted.

When adding support for your device keep in mind that this is something everyone wants, maintainers/users/vendors alike.

> Before flatpack and snapcraft there was no sane way to install third-party software.

This is simply false, because AppDirs and AppImage existed long before those. And of course static binaries existed since the beginning. Sadly, Linux user space is such a horrific mess that none of those much simpler and saner solutions took off, so now we have to put up with non-portable garbage like Snap and Flatpak that are still tied to a repo model.

You can compile a static binary or distribute a private copy of libraries, but it doesn't get you integrated into the system. For example, your app will not be upgraded using a package manager.

And main reason for this is because package managers were not designed for third-party software. They were designed only to install software from a distribution and maybe from your private repositories.

That makes proprietary software "not welcome" in Linux distributions.

> For example, your app will not be upgraded using a package manager.

Good. That means it won't break because someone arbitrarily changed an ABI.

> That makes proprietary software "not welcome" in Linux distributions.

No disagreement there.

Linux isn't supposed to be friendly to developers wanting to rob people of their rights.

But as a user, I want to be able to use proprietary applications in a safe way, so that they cannot steal my browser cookies or read my MAC address, or patch my kernel. So I would prefer that Linux distributions support proprietary apps like Android Open Source Project does, rather than tell me what I should use and what I shouldn't.

> rather than tell me what I should use and what I shouldn't.

You shouldn't be telling the developers what they should or shouldn't be doing either.

That effort is better spent writing reverse engineering and writing replacements for said proprietary software.

> Installing proprietary code requires adding proprietary repositories

How is this unexpected?

This is not a sane way to install third-party software because by adding their repository, you allow them to "upgrade" and package in your system, including Linux kernel, bash, sshd. Is your system secure if companies like Microsoft, Sublime Text, Slack Inc have root access to it?

So you either give them root access or install and update software manually. Because package managers like apt do not have a sane method to install third-party proprietary software.

And even with open source software, it is a bad method. For example, a developer that provides a Debian repository with different versions of PHP, has overwriten openssl library for users of his repository despite it can break something else.

So there should be a safer way to install third-party software.

Reply on news.ycombinator.com