Hacker News Reader

Comment by young_unixer | Hacker News Reader

This whole ideology of "the user should get all their software from their Linux distribution" and it's implicit consequence: there's no clear difference between system software (internal tooling) and application software installed by the user (Audacity and friends) should just die already.

I want my OS to just provide a decent interface over which I can install application packages myself, packages that I get from my own sources, just like on Windows. if those packages are statically linked, fine. I know most Linux users disagree, but I don't want the relationship between software vendor and user to be distorted by some distro maintainer, or having to be limited to a package manager. I want to be able to store application installers in my filesystem.

I also want my distribution to hide it's Python binary from me so I can install my own Python without breaking the OS.

Basically: stop assuming that I want to live under your wing. I just want you to give me a nice desktop environment, a terminal and a well docomented way to install third party software.

I know distro developers don't owe me anything, and it's fine if they do something else, but this is the actual reason why Linux isn't used in the desktop.

View on HN

First of all, you can do that already. No one stops you. So I guess what you actually want is someone to fix the problems that come with your wishes, but do not agree with the way the distributions try to do so. You know what? Thet really don't owe you anything. Go ahead, build the system you want. But please don't come along whining when it ends up unmaintainable, instable, or starts acting against you, like, you know, Windows does.

Second, linux distribution maintainers are usually much better informed about the technical details of installing software in a stable manner than any software vendor. Sure you can get your software from the vendor. But then you should be willing to accept that it is often broken, inefficient, and insecure. Software vendors have no interest whatsoever in installing their software in a professional and sustainable way on your system, package maintainers do.

> But please don't come along whining when it ends up unmaintainable, instable, or starts acting against you, like, you know, Windows does.

As a die-hard linux user, this line of thinking really plays against Linux. Software distribution hasn't caused problems in windows since XP. Likewise, all mac users seem pretty happy with .app bundles.

> Second, linux distribution maintainers are usually much better informed about the technical details of installing software in a stable manner than any software vendor. Sure you can get your software from the vendor. But then you should be willing to accept that it is often broken, inefficient, and insecure. Software vendors have no interest whatsoever in installing their software in a professional and sustainable way on your system, package maintainers do.

Do you realise how insulting this comes across ? As a software dev, my personal experience of "professional linux distro packagers" is people literally removing random lines of code of my software until it builds - who cares if it crashes as soon as you do more than open it anyways. I'd rather not have my software packaged than have it like that. My subjective experience from the software I use is that stuff like AppImage made straight by the dev is generally much more stable and works much better than whatever chtonian hack a debian packager decided to apply.

Software distribution in Windows and Mac comes with a lot of problems, they are simply problems that you-personally don't see as part of the class of "distribution problems". Please don't tell me you've never encountered post-install errors with Windows and Mac software. Linux packages have a higher bar to meet for integration quality, and also have a more difficult job to do because of the more-fragmented nature of the platform.

> As a software dev, my personal experience of "professional linux distro packagers" is people literally removing random lines of code of my software until it builds

I'm sorry this happened, but I can assure you that the vast majority of maintainers do not do anything like this.

One specific problem I always had in Linux but never had on other systems is installing a newer version of a software than the one that is present or supported by the official package manager.

It's most of the time difficult, and sometimes impossible, which is very user hostile; I, the user, should be deciding which version of the software I want to run, not the distribution.

There are distributions that cater for the bleeding edge, there are distributions that focus on stability, there are plenty that fall somewhere between.

But with any distro, you call install whatever you like wherever you want. You, the user, make that call. You, the user, should have the knowledge to tidy up if it goes wrong.

What if I want a stable distribution, but need latest versions of some software?

Installing anything outside of distro repositories and Flatpak (& alternatives) is, in most cases, PITA.

Tracking down missing dependencies, figuring out which libraries are compatible, downloading source for those libraries, because the system provided are outdated, etc. You can literally spend a whole day just building a somewhat simple application.

I'm not a fan of binary blobs, like it's customary on macOS/Windows, but at least I can actually use an application in a minute or so, after downloading it. There is no fussing around, it just simply works.

You should try out Arch linux or one of its derivatives. I never have any of the issue you're talking about, were almost always at the bleeding edge, and for packages that aren't, we have the AUR which is straightforward to build into your system from upstream git repositories.

Arch looks tempting but my feeling is that a lot of software built by devs who run Arch needs initial help to run on Ubuntu/Debian. The other way around works better (software built to run on the latest Debian usually runs everywhere).

Maybe that observation is incorrect, please give me data points. Also this won't mean you have to run Debian (but maybe a VM with Debian in it).

If you need to run something that only runs within debian, you'll likely be able to that in a straightforward way using LXC or docker containers. I wouldn't reach for a VM unless I needed the extra layer of security offered by the VM.

> There is no fussing around, it just simply works.

Because they have huge teams maintaining API and ABI stability.

On any Linux distribution worth its name you can also use the software within seconds after installation. The teams are just smaller and their approach is more centralised and principled, but I never had a problem using, e.g., emacs after installing it.

You need to fuss around with software from their parties. Simply because these third parties do not care enough about your Linux to make the installation work well. These same third parties also do not care much about how stuff is supposed to work under windows, they just drop their binaries and assume that the windows ABI will somehow keep working.

> One specific problem I always had in Linux but never had on other systems is installing a newer version of a software than the one that is present or supported by the official package manager.

Because the newer version (of the lib, I presume) changes the ABI and borks all the packages that were compiled against the old version?

Trying to upgrade something like Mesa from Rawhide or whatever is just going to mess up your install like nobody's business but if you just need a couple minor libs (for a specific program) I've not had any problems.

For programs, I've had ones running for years after they got dropped from the distros with zero problems or that I built and installed from some random srpm I found on the interwebs.

In all honesty the only 'song & dance' I have to do on a semi-regular basis is rebuild my python modules when Python gets updated on a distro upgrade.

What do you mean by post-install errors?

>Please don't tell me you've never encountered post-install errors with Windows and Mac software.

Mac user here, can't ever remember encountering post-install errors with Mac software in 15+ years (bugs sure, like every software has, but nothing related to incomplete installation or whatever)...

>Linux packages have a higher bar to meet for integration quality

Isn't it actually a lower bar?

They don't have to follow the platform's look and feel and UI libs (there isn't a standard, a distro can package Gnome, GTK+ only, KDE, XFCE, even CDE and Athena stuff, plus all kinds of ad-hoc UIs). They don't have to work with the same shortcuts, use the same system for configuration, or even play well with the same window compositor...

When it comes to "integration quality" in Linux it's mostly "compiles with the distro's version of libs".

> lease don't tell me you've never encountered post-install errors with Windows and Mac software.

Sorry to say, but I have to raise my hand here.

The only post-installation issues I ever had on Mac and Windows were related to drivers, not applications.

Plus since like a decade or so, I rarely "install" software on Windows anyway, because all the tools I use come as a "portable" version, which is just a ZIP archive.

In an Apple-like fashion, these "just work" after unpacking to an arbitrary location (e.g. a USB-stick or SD-card)...

What am I doing wrong here? ¯\_(ツ)_/¯

> Please don't tell me you've never encountered post-install errors with Windows and Mac software.

I don't remember the last time that happened. Not that I'd exchange my ArchLinux setup against either but you gotta be honest - installing stuff on windows and mac is a solved problem.

However the number of times a Debian or Ubuntu update borked something... that I don't have enough fingers nor toes - I had at least 3 installs of debian that I fucked up enough that I couldn't recover them in the last ten years - in comparison the last time that happened for me on windows was in 98' era. Not that windows doesn't suck - I still get the occasional BSOD even on win10 while Linux kernel panics are... uncommon for me but that's just my experience).

> Please don't tell me you've never encountered post-install errors with Windows and Mac software

For most user-facing Mac software that comes with a GUI, there are no post-install. Installation simply consists of copying the application bundle into the /Applications folder.

>As a software dev, my personal experience of "professional linux distro packagers" is people literally removing random lines of code of my software until it builds - who cares if it crashes as soon as you do more than open it anyways.

That is, at least in my experience, very false. They often do care about build systems more than the maintainers, as they're the ones who have to make it work for everyone.

I've worked with the Gentoo packagers and those people I have interacted with have a lot of knowledge about how to distribute software. It's not for nothing the Gentoo community has to push changes upstream when upstream assumptions don't hold up downstream.

> They often do care about build systems more than the maintainers, as they're the ones who have to make it work for everyone.

Every interaction I've had with packagers has been them trying to make the build system work for their single distro. None of them have ever tried to help make it work for "everyone" running linux, much less spend any time thinking about the other two platforms that have 90% of the actual users.

IME they also tend to be much more focused on making the build system work on their distro than making the actual software work. Not surprising given that that's what they know, but they tend to be perfectly happy to make changes which cause functional problems to get things to build.

> As a die-hard linux user, this line of thinking really plays against Linux. Software distribution hasn't caused problems in windows since XP. Likewise, all mac users seem pretty happy with .app bundles.

If you don't know what you are missing, you won't miss it.

Agreed. What happens in two weeks when a security vulnerability or data loss bug is identified and fixed?

Nothing, unless you have a application-specific upgrade daemon running. Sounds like a good design, right? :)

> What happens in two weeks when a security vulnerability or data loss bug is identified and fixed?

The automatic update process breaks software by making incompatible changes, thus preventing a security problem by just not allowing me to run the software in the first place?

Don't Linux distributions like Debian avoid this by backporting security fixes rather than upgrading to an incompatible version? https://www.debian.org/security/faq#oldversion

> As a software dev, my personal experience of "professional linux distro packagers" is people literally removing random lines of code of my software until it builds

That's sad. But fortunately, not all packagers are like this. As a software dev too, I have a great experience with packagers from various distributions. When they have an issue (either build or runtime) they tell me about it and we discuss a patch together that I include in my next release.

> My subjective experience from the software I use is that stuff like AppImage made straight by the dev is generally much more stable and works much better than whatever chtonian hack a debian packager decided to apply.

Sure it works if you are in the most common case (Linux on x86_64), but it has some downsides:

* It only supports CPU architectures the dev can build for

* It only supports operating systems the dev can build for

* The dev needs to publish an update every time there is a vulnerability in a bundled dependency (assuming they are even watching for vulnerabilities)

> Software distribution hasn't caused problems in windows since XP.

The windows way of installing software (download random .exe or .msi files from random websites on the internet) has been a problem for every non tech-savy people and the people helping them manage their computer forever.

Every modern OS comes with its own package manager nowadays for a good reason.

Windows has chocolatey, which works quite okay. I usually use this with with automatic update scripts to keep the software on my parents windows machines up to date.

Maybe differentiating between types of software could help? Desktop apps or games don't seem to have the same requirements as system and development stuff. As a Mac user I'm indeed pretty happy to have both app bundles and the Homebrew subsystem depending on the type of software I want to install.

If you think that some linux distribution maintainer knows my software better than I do, then you are high as a kite.

That's not quite the right perspective.

You most likely do know your software better, after all, you wrote it. However, their concern is the integration of your software into larger system, and they may well be more familiar with those issues than you are.

In all my years of (Debian) distribution maintenance, this was the most typical cause of disagreement between packagers and upstreams. It's very common for upstreams to make fairly arbitrary decisions which might make sense in the context of an individual project, but which are not appropriate when considered as part of the system as an integrated whole. Neither are wrong per se, but as an upstream, your focus is on your project and it's easy to miss the bigger picture issues. Conversely, packagers' focus upon the system as a whole, so their view is at a higher level.

Additional to this, don't just discount the knowledge and expertise of distribution maintainers. There are of course some who just blindly package up other people's work and aren't experts. However, there are others who are software authors in their own right, with decades of accumulated experience and understanding. The latter may well know more than you do, and might be able to provide some keen insights you could benefit from. There are an awful lot of developers who don't know how to make software releases properly in a way that allows it to be consumed straightforwardly by others, with proper understanding of API and ABI issues, proper versioning, and proper use of build systems.

I don't really agree with the comment you're responding to, but your comment is needlessly incendiary and not particularly useful. All software critique has an assumed element of "if the developers wish to make this better for users like me", and so remarks like "[they] don't owe you anything" should be reserved for people who lean into specific developers with demands, not people earnestly offering suggestions to make the third-party software ecosystem better.

One of the big problems with the Linux Desktop evangelism community is that they've entangled their identity with their OS of choice, and thus interpret all criticism as a personal attack.

I still maintain that for all its many technical and architectural faults, the biggest thing holding back wider Linux Desktop adoption is the Linux Desktop community itself.

You are right on only one thing: 1 version globally is stupid. Global properties in general are stupid. Have a notion of public vs private dependencies and one gets the right amount of coherence, not too much or too little.

Otherwise, hell fucking no. This misconception is causing so many mistakes. Software is an ecosystem; I give 0 shits about individual libraries programs whatever, just that the end composition meets my criteria. The app bundle / flatpak / corse-grained Docker vision of software is plain wrong, and will basically prevent future gains in productivity.

Nix and friends get it right: no single version dumbness, everything is installed the same way, be it by the admin or by regular user, and with proper notions of dependencies.

Socially, I understand where OP is coming from. The common view that distros are some crusty 90s holdover held hostage by a bunch of neckbeards who don't care about users not like themselves. But distros like NixOS put the user in full control. There's feeling of de-alienation using a NixOS machine that's really hard to convey to those that haven't yet tried it (and gotten over the initial learning curve).

Yeah one version really is an antediluvian limitation. The ideal state of this would be something like this: I can have 100 different versions of a library, stored on disk only once per each version, and any application I install could use the special version it wants as a shared library. Does NixOS provide this capability currently?

Yes. NixOs uses the NiX package manager (that you can install in any other distro too).

The NiX package manager installs each version of a package to a directory, the trick being that each version of each package goes to a folder whose name is a hash of all the inputs of the build (files, build parameters, specific build folders of this builds dependencies, etc).

As a result, not only can you have different versions of a package: you can even have different builds of the same version (that you built with different build configuration and/or versiona of its dependencies).

The concept is sound. The issue is that you need the ability to actually build the application (you need the source) and you probably have to adjust its own build process to get it to work properly with NiX.

Yes, just as the other comment says.

To me, Nix is "Noah's trampoline", no-holds-barred mud-wresting all the nasty details of Unix and software as it actually exits, all the way down, into something just every so slightly saner so we can sale over the floodwaters and land on the shore of an actually sane practice of computing.

And yes, I would basically want describe in in those terms even if it weren't for your nick and vocabulary :).

I think having a separate package manager for every piece of software I use is just terrible. I also don't want to be forced to use application bundles.

You get isolation (re "hide its Python binary"), multiple package variants, a unified software management interface for all applications, etc -- from functional package managers like Nix or Guix.

And you only have to learn two new programming languages to use them!

Well, one, because you wouldn't use both of them.

To disagree with the least important part of what you said:

> but this is the actual reason why Linux isn't used in the desktop

I still believe the actual biggest issue with Linux on the desktop is graphics card drivers (and other aspects of the graphics stack like handling High DPI). Too many machines fail the basic test of 'can I install Linux, plug my screen in and have it behave sensibly'.

Just stick to Intel/AMD graphics and it's absolutely fine. Wifi/Bluetooth/LAN support is a bigger issue, tbh. Even audio can be an issue sometimes.

TBH unless you're on Intel you'll still probably have some trouble. That's still a problem though - you shouldn't have to (within reason) select your hardware carefully, ignoring a large part of the consumer market, to have Linux do basic things.

If you really want your system to work, you have to. This has been the case since the dawn of the computer age. Nowadays most desktop hardware is intended for Windows users. Therefore, hardware vendors make their stuff work with Windows systems and jump through Microsoft's hoop to get certified. Linux is just irrelevant for many hardware vendors. And without vendor collaboration, it is just plain difficult to write drivers that make full use of the hardware.

>absolutely fine

It's mostly fine. But high DPI, or worse, mixed DPI desktops are somewhere between unusable and sort of tolerable.

I dual boot my desktop, and I've given up getting my 4K main screen and old 19" off screen working together in Linux (and I've tried everything). I like moving IRC off to a smaller screen to glance at once in a while, so I never miss an internet argument, but mixing DPI monitors just doesn't work in Linux.

I do have to run a non-distribution supported mainline kernel (with some DMKS config changes and some drivers installed from the distro's dev branch) for my relatively recent AMD GPU (RX5500, released at the end of last year) not to freeze seconds after I start chromium, or at least twice a day if I avoid it. That's tolerable for a technical user, but definitely not "absolutely fine".

There's still weird AMD graphics bugs. Built a new Ryzen based system, with a RX 5500 XT, but get weird GPU lockups all the time

Ubuntu Mate + Intel GFX + 2 4k monitors = Works perfectly™

Wayland or xorg?

xorg, but I'm open to wayland in the coming years.

Graphics card drivers is a solved problem. Intel/AMD "just work". Nvidia works okay-ish if you don't mind closed source drivers and unless it's a card nvidia has dropped support for. In both cases, switching to Windows is not an improvement: all the bad parts of nvidia on Linux also apply to Nvidia on Windows.

HiDPI is mostly fine, with the exception of mixing high dpi in xorg. Mixing DPI works in wayland. So I'll grant you that the combination of nvidia+mixing DPI doesn't work, because nvidia's drivers don't support wayland.

Otherwise I strongly disagree, and I'm genuinely confused as to why this myth persists. Wrangling drivers on windows is a huge pain. There's no one "update" button I can press to update all my drivers, let alone all my other software. I have to go through the driver manager and manually right click and select "update driver" which frankly nuts. And to update the graphics card I have to periodically go to nvidia's website and check manually? What year is it again? Why doesn't Windows do this for me?

Windows Update keeps drivers up to date except for ones installed manually.

It will not update all of them, just some. Clicking through the device manager on my work computer, it seems the driver for "Standard Enhanced PCI to USB Host Controller" was not up to date, and had not been updated by Windows Update. I never installed this driver manually.

If you're on a Windows machine right now, try it. Right click on a bunch of stuff in device manager and hit update driver. Clicking through on my machine and maybe 1/5 have an update.

The crazy thing is that it's a really painful process. It takes 15-30 seconds per device just to come back with "no updates" and you can't just select a whole bunch of them and do them all at once: you have to do it one at a time and go through the wizard for everything. And there are simply too many devices to do them all, so all of us are using plenty of outdated drivers. This is an absurd situation, it's 2020.

There are third party apps that do this automatically, but I don't know that I trust them.

This is likely a result of your system admins not including drivers in their WSUS or other patch management system.

WSUS is sort of a corporate Windows Update server where you can approve updates to groups of machines on whatever schedule you want.

A lot of WSUS admins skip drivers because they massively slow down the sync/approval process and take tons of disk space. Windows has tens of thousands of drivers.

I think the original reason for shared libraries, and the only true one is that it’s meant to save hard drive (and maybe memory) space. But the ratio between assets vs code is now so big (media files, or data in data intensive algorithms) with code representing nothing, i don’t think any optimisation is really worth it anymore.

There are also security implications. Update one shared lib with a security patch and all applications that use it are now using a patched version.

This is very often repeated argument in favor of giving control over shared libraries to the distribution, but it is mostly distribution's marketing. In practice, most users don't really care about security. That very small portion of users who do care about security, don't wait 2 weeks or more for distribution to make fixes available, they fix it/mitigate it themselves as soon as possible.

It is true that it is easier to fix one version of a library than 10 different versions. But if you need 10 different versions for different applications, you probably do not need to patch all 10 of them.

Most people don't care about security ... until they do.

Most people don't understand security and are not equipped with the necessary knowledge to correctly judge risk. As long as security is just something that gets in the way to get some job done, most people will just plow ahead, since not getting the job done right now has a high and easy to understand cost.

It's become increasingly common for desktop applications to aggressively and/or automatically update themselves the same way the OS does, often without even having to go through a "wizard" prompt of any kind. Off the top of my head Chrome, Firefox, VSCode, and Slack (probably my four most-used non-system applications) automatically update themselves whenever I restart them (and prompt me to do so when applicable).

Not to mention the fact that an increasing fraction of consumer-facing software now lives in the browser, where updating implicitly happens every time you go to use it.

Regardless of how you feel about these trends, they make out-of-date applications much less of a concern than they used to be.

Shared libraries are also important for apps that want to load plugins via the shared library mechanism.

That's absolutely not true for desktop GUI apps because so many of them are written in Electron these days.

Even small desktop accessories carry their own copy of the Electron and Chromium libraries, usually around 150 MB. It would be a tremendous improvement to use a shared browser engine for this, but developers are resistant.

Shared browser engine or any other library would be ideal and in a single project a preferable way. But in practice it is hard to synchronize requirements of different applications, because they are different projects and different people on different schedules. 100 times 150 MB is still only 15GB, a minor part of hard drive, a very acceptable price for 100 functioning independent applications.

How many of those apps are running simultaneously? Often quite a few. The memory footprint of the engine is larger than the code size on disk. Users may be wasting gigabytes of RAM on trivial desktop tools.

The point of the web is to support multiple user agents rather than forcing the user to a specific browser. I don’t understand why that shouldn’t apply to web apps running on the desktop.

> The memory footprint of the engine is larger than the code size on disk. Users may be wasting gigabytes of RAM on trivial desktop tools.

That may be the case. Usually it is not a problem, there is mmap and swap and unneeded parts are paged out of physical RAM.

If it becomes a problem, one has to change tools or get more RAM.

Not for the vast majority of libraries at any rate, but for libraries that most OSs consider part of their core platform (a concept eschewed by Linux Desktop) they are still a good idea.

I’m not a lawyer, but I recall seeing a comment that one reason companies currently prefer dynamically linked apps in bundles like Snap and Flatpak over static linking, is that dynamic linking permits more open-source libraries to be used without legal issues. I think it had to do with what legal precedents had been set for linking GPL/LGPL libraries with non-GPL binaries?

Yeah, I'm happy to keep track of all my third party software that I install manually and I never forget about what applications I have installed so far and I always update my packages manually when there are any security flaws and I get to know about all the security flaws right away when they are discovered because I'm on all seclists. Even if I forget to update my third party apps/packages, my third party apps/packages remind me of the new updates and I never turn the update-notifications off.

> This whole ideology of "the user should get all their software from their Linux distribution"

This isn't true at all, and I struggle to think where you came up with this idea.

Linux distributions do distribute a hand-picked set of packages. That's essentially what a distribution does: distribute packages. Some are installed by default, others are made available. That's pretty much the full extent of it.

Yet, just because a distribution distributed packages, that doesn't mean you are expected to no use anything else. In fact, all the dominant Linux distributions even support custom repositories and allow everyone to not only put together their repository but also offer a myriad of tools and services to allow anyone to build their very own packages.

Even Debian and debian-derived distributions such as Ubuntu, which represent about half of Linux install base, offer personal/privayr package archives (PPA), which some software makers use to distribute their stuff directly to users.

So, exactly where did you get the idea that that so called ideology even exists?

You can live in this world right now.

1. Snap and/or Flatpak allow you to install GUI applications from most places nowadays. The internal tooling (system packages) are kept separate from the User installed applications and are effectively sandboxed in this way

2. Linuxbrew allows a Mac OS-like separation from your personal development tools and your OS's internal packages. Notably, this also allows you to install far newer tooling than your distribution would typically provide

3. Drop application binaries in ~/.local/bin if all else fails

If I weren't on a rolling release distribution I'd probably go that route. I hate being restricted by whatever my distro provides, I hate upgrading the entire world when new releases are made, and I hate third party repos and the hell the provide reconciling everything together.

It's really the in-between state that's terrible. Either go full *BSD or Mac OS and separate the concepts or full Arch Linux (w/ AUR) and don't. All other ways of distribution software tend to be more server centric anyway

> Either go full *BSD or Mac OS and separate the concepts or full Arch Linux (w/ AUR) and don't.

Regarding the first alternative, I think it will be interesting to see how Fedora Silverblue [1] turns out. It’s basically going for an immutable base system coupled with Flatpak for apps the user installs.

Haven’t tried it myself, but for average desktop users, I think that sounds like a very good solution in the long run: a stable base system with up-to-date user-facing apps.

[1]: https://docs.fedoraproject.org/en-US/fedora-silverblue/

What do you make of Go's approach where the build outputs a single binary file [0] that, roughly speaking, 'just works'?

[0] https://stackoverflow.com/a/19286458/

This is exactly what Rust does by default too, btw.

Thanks, I didn't know that.

Given the current state of the ecosystem, I think Go's approach is the sane thing to do.

Now the Go dev has to voluntarily update said binary whenever a security issue or bug is found in his code or any of its dependencies.

And you have to replace that whole binary everywhere it is installed.

Think about how many systems would still be vulnerable to heartbleed if every thing that used libopenssl had to be re-compiled and redistributed as a statically linked binary.

This proposed “statically linked” world might be worse than the current mess. See Docker.

> And you have to replace that whole binary everywhere it is installed.

Not if your package manager supports binary diffs [1]. Which for many platforms is already the case, and other package managers would likely implement the feature if downloading large binaries becomes a problem. Right now, I’d however call it a premature optimization as the bandwidth of most people is dominated not by downloading updates but by streaming. But it is a solved problem since e.g. Fedora has supported package diffs for a decade.

Regarding the heartbleed, that is a valid and often repeated argument, but I think it is also overblown. One could e.g. have a static binary with embedded or bundled info about what library versions it was statically compiled with, and a way to automatically flag which binaries are thus vulnerable. Such a system would make it possible to push out new builds of high-priority targets like Firefox and Chromium without testing every other libssl-based app for compatibility first, thus cutting down on the response time for patching the most vulnerable apps. But the flagging would make it clear that the other apps need updating too. (Or in the case of automated builds, that the other apps need testing.)

I’m not saying that the whole OS should be statically linked, but for end-user apps I think it makes a lot of sense, and it’d remove a lot of friction where a library update can break a previously working app (that happens).

[1]: https://en.m.wikipedia.org/wiki/Delta_update

So if you want to download precompiled static binaries and "install" them into your home directory or /usr/local/bin that's fine. You can do that, and it works, although now you're stuck in the same quagmire Windows users are stuck in.

My question though... why? Everything about that seems to me worse in every way.

Specifically regarding python, on my system right now, I have python 2.7, 3.8.5 and 3.9rc1 installed on my system and maintained by the package manager. When 3.9rc2 or 3.9.0 final is released it will update to that. It's configured to run 3.8.5 when I just run "python", although I can manually run other versions by running the command python2 or python3.9, and I could reconfigure the default to be one of the other versions if I wanted. The package manager has versions going back to 3.4. I guess I don't understand the desire to install python manually - what can you do with a manually installed python that you can't do with the one installed by the package manager?

> and a well documented way to install third party software

I have made a few packages for Debian ARM Linux when I needed them. I wouldn’t call the documentation great, but it’s not too bad either. Same with the infrastructure, the OS support versioning and dependencies, can be configured for custom repositories and to verify signatures…

It’s not terribly hard to make them fully working, install/remove/start/stop systemd services, support upgrade/purge/reinstalls, matter of a few shell scripts to write. The command to install a custom package from a local file is this:

    sudo dpkg -i custom-package_0.11.deb

However, this all was for embedded or similar, where I had very good idea about the target OS version and other environmental factors. Not sure how well the approach would work for a desktop Linux.

Arch does this best. If you are displeased with the official repos, you can use the AUR.

Additionally, there's often a package in the AUR for the software you want to install already. Just gotta look at the votes and comments beforehand, and if you're feeling paranoid, the PKG itself.

>Just gotta look at the votes and comments beforehand, and if you're feeling paranoid, the PKG itself.

ALWAYS check the PKG-file when using AUR!!:

https://www.bleepingcomputer.com/news/security/malware-found...

So do that? Distros provide packages but they don't make you install them. Download the applications from their website and stick them in /usr/local or your home directory. If the applications don't provide builds, that's their problem. We have AppImages for a single-file solution, but I've used plenty of application directories you can just unpack and use. Julia is one.

Put your stuff in /usr/local. Use Gnu Stow for poor man's package management. Then you can have your programs coexist with the OS.

Or use a BSD where System and packages/ports are two things.

/bin /etc = System

/usr/local/bin /usr/local/etc = Programs

…? You can have all of this today.

> this is the actual reason why Linux isn't used in the desktop.

Yeah, no.

Just curious, what do you think the actual reason is?

Hm, hard to find “the one reason”. I think the most important factors are:

* What people (not necessarily the users but corporate decision-makers) are used to (Windows)

* Enterprise manageability (achievable on Linux, but built-in on Windows)

* What is preinstalled (Windows)

* What some exotic business applications work with (Windows)

Almost purely soft factors, very hard to counter if virtually all the computers you can buy at your local PC shop come with Windows preinstalled.

My neighbors (70+) accidentally got hold of a laptop that didn’t come with Windows but Ubuntu and they’re perfectly fine with it. It still has Firefox after all. :-)

Preinstallation is as close to "the one reason" as you can get. Microsoft had a hard time getting Windows over with end users -- until Windows 3.0, when the average new low-end PC had a 386-class processor and VGA, and oukd reasonably run Windows. Microsoft pressured OEMs to bundle Windows, and turned Windows into something that could be reasonably expected to be installed on a new computer, and that attracted ISVs, which meant end users were more likely to use Windows to get work done.

> My neighbors (70+) accidentally got hold of a laptop that didn’t come with Windows but Ubuntu and they’re perfectly fine with it. It still has Firefox after all. :-)

What you think you just said: Linux is so easy to use anyone can do it and it works better than alternatives!

What you actually just said: Linux makes a great webkiosk!

And what else is it that the average PC user needs? Because I cannot think of a single thing.

That's because you have a disingenuous definition of "average PC user", a strawman, so that your argument works.

What you call the "average PC user" is really the average smartphone user these days. PC users are doing office work, running a business, development, gaming, content creation in more ways than I can enumerate, etc.

People who have a bulky desktop computer in their home just to browse the internet are vanishingly few.

> People who have a bulky desktop computer in their home just to browse the internet are vanishingly few.

1. a PC isn't necessarily a "bulky desktop computer", it can also be a slimline laptop!

2. "browse the internet" and "office work/run a business/etc" are not mutually exclusive. Google Docs/Office 365 etc. proves that. I'd argue the majority of business operations requires some level of internet interaction these days.

It seems to me like you've come up with a strawman definition to bat away another strawman definition. Almost everyone I know owns both a smartphone and a laptop, and the vast, vast majority of their time on that laptop is spent in a web browser.

What argument even? I never said or implied that Linux is better or whatever. That was you.

I merely stated that a lifelong Windows user of advanced age can in fact use Ubuntu because it is, on the surface, similar enough. Same goes for a Mac, of course.

largely it's the network effect. in days of yore unix dominated the minicomputer market and VMS played second fiddle. these days, windows dominates via the network effect and macos plays second fiddle (and linux third).

Reply on news.ycombinator.com