Hacker News Reader

Comment by haunter | Hacker News Reader

Linus at DebConf 2014 https://www.youtube.com/watch?t=310&v=Pzl1B7nB9Kc&feature=yo...

>I’m on a record saying, that maybe Valve will actually save the Linux desktop. And it’s actually not because I think games are important! I don't care, I don't play games. I think some people do, so games maybe important. But the really important issue is I guarantee you Valve will not make 15 different binaries. And I also guarantee you that every single desktop distribution will care about Valve binaries. The problem is Valve though build everything statically linked and it creates huge binaries. And that's kind of sad but that's what you have to do right now.

View on HN

Id rather have static binaries than a flatpak/snap for "universal distribution", personally.

Snap really sucks because it forces you to have a /home/user/snap folder on the same filesystem as /. If you don't have that (e.g. home folder symlinked to another filesystem), then snap starts breaking in very weird ways.

https://forum.snapcraft.io/t/limitations-in-snapd/9718

This actually means that at some point I will have to move away from Ubuntu.

Debian is very nice these days if you don't mind a tiny bit of enabling non-free repos. Or Pop OS for a more It Just Works approach, if their desktop suits your fancy.

Right now I'm stuck with nVidia's Jetson line of products which is vendor-locked to Ubuntu. The problem is that while you can extend them with a large SSD drive, these products have a really small disk used for /. I could run another OS inside a Docker container, all to avoid this limitation in snap, but of course things will not become prettier.

You've been able to run the root on (nvme) SSD for a while now with Dusty's scripts, and more recently with the official installer.

I have great sympathy though, I am also using Ubuntu on Jetson and resent snap, especially since the new releases are 20.04 which have it more tightly integrated.

You can change the root parameter in extlinux.conf to point to whatever block storage you want it to

Or reconfigure U-Boot to load extlinux.conf (and the kernel image, initrd, etc) entirely from other type of media. IIRC NVMe, USB and external SDs are all supported

Thanks, I'll have to look into it.

Why don't you just mount your big disk on /home, like we used to do in the olden days?

Because I suspect that snap uses both /home/user/snap and /var/.../snap, and needs them to be on the same disk (to allow hardlinking, I suppose).

Have you tried it?

Sounds like something a bindmount might fix.

Back in the olden days before simple and convenient packaging systems like snap had been invented, we had to get pretty creative so that stuff didn't freak out because it was split across filesystems.

I haven't tried it, but I can remember people on forums having mixed results with a bindmount. I guess there is no guarantee that it works until Snap has been running for a while without problems.

I don't see anything there about needing to be on the same filesystem, just that the path is of the form /home/$user/snap. It says that having a home directory that isn't mounted at boot doesn't work, but that's different. Am I missing something?

I'm not sure why you'd need to symlink /home/ to another filesystem instead of just mounting that on /home/ directly, that's what I'm doing with root on ZFS and a separate dataset for /home/ with it's own mountpoint.

Snap also stores stuff in /var/snap, and that probably also has to live on the same filesystem.

Anyway, now I'm working around limitations in Snap instead of Snap working around its own limitations in certain circumstances. The fact that Snap shows weird behavior and illogical error messages in these cases tells me that Snap is not (yet) up to the task of fulfilling this rather fundamental role in my OS.

Either static or dynamic is fine, package management has to be solved at another layer a la Nix.

Nix is effectively transforming dynamic binaries to static ones. Might as well skip the step, stop pretending that drive space is expensive, and link everything statically.

No. The Nix approach lets you retain the reuse, and it can be extended to allow quick, unified security patching as well (which has been done already in the Guix project).

And if you really want a single redistributable binary, any existing package can easily be bundled into one without recompiling it.

Traditional static linking is strictly worse.

Huh, never heard it put this way. I guess it's true though.

Anyone disagree?

Farid Zakaria recently gave a talk¹ (at NixCon 2022) where I think he put it better: Nix (and Guix) blur the line between dynamic and static linking.

I think this is true, because with Nix and Guix, you actually have an end result with the positive characteristics of both kinds of linking.

His talk, based on his work on shrinkwrap² and nix-harden-needed², called for the creation of a new executable format for the Nix world. Seems apropos as a reminder that there are other possibilities!

(I think these kinds of solutions are definitely within reach for Valve from a technical perspective. Other tools are using them today.)

1a: https://youtu.be/HZKFe4mCkr4

1b: https://youtu.be/lzk4sldexX4

2: https://fzakaria.com/2022/03/15/shrinkwrap-taming-dynamic-sh...

3: https://fzakaria.com/2022/09/12/making-runpath-redundant-for...

What about completely optional dependencies which might get loaded at runtime based on some dynamic criteria? Dynamic libs are not primarily for space saving. Also, there are thousands of other packaging problems not solved by static binaries, so yes, I do disagree with grandparent commenter :D

Conceptually that's kind of true, if you only consider the end result for a given binary, (since it would load only shared libs as if they were statically linked).

But multiple derivations can share dependencies, which does save space and also makes it easy to identify dependencies of a given derivation, where statically linking would make that opaque.

Also, the story goes way beyond binaries, as dependencies often carry additional resources not bundled into the binary.

RAM is still expensive…

Given the choice I prefer native package -> AUR package -> AppImage -> Flatpack, in that order. (snap, you'll notice, is absent)

Arch is pretty good at making the native packages work, so that's always ideal. The community is generally pretty good at competently packaging AURs, and they'll do it for slightly less free things, so that fills a lot of gaps. AppImages and Flatpaks are great when they work, but opaque and difficult to diagnose when they don't :/ And snap is just... unpleasant. It's insistence to auto update separately from my package manager has really turned me off of it's whole ecosystem. No thanks.

flatpak > appimage for security and updates.

Well you can statically link stuff in a flatpak… a distribution package however gets automatically rebuilt when a dependency changes, if it's statically linked.

sorry, is this an argument that appimage has advantages over flatpak for security and updates? could u elaborate?

No I'm saying that flatpack can be as bad as appimage because nobody checks.

Why AppImage over Flatpack? I like the Flatpack ability to easily restrict network access to binaries. Probably possibly in all of the packaging formats, but limiting permissions feels like a functional piece of Flatpack.

Because AppImages need no daemons and plumbing. They are self contained binaries which contain everything it needs to run.

Running a big infra to run a single binary once in a while feels like a burden to some of us.

Flatpak also doesn't need daemons beyond what the app is using.

Yet you need to install flatpak package and its dependencies to run flatpak applications. Not to mention the flatpak package contains a four ".service." files, too.

They might not be triggered and launched all the time, but this mode of operation is different from .appimage files, which are just ordinary binary files you directly run.

appimage > flatpack > snap

I agree static binaries or at the very least something akin to nix where every binary has a pinned dynamic lib.

Please, $DEITY, deliver us from this hell wrought by Canonical.

Unless we’re talking about embedded systems (and most of the time, not even then I’d guess for portable gaming devices for example), what is the actual drawback of these “huge” binaries?

Wasn’t the reason to separate binaries and libraries in the first place to conserve disk space? They are then clearly versioned to signal that you can’t expect just any version of the library to work with the program you wrote.

The trade-off in using more disk to contain “an application” to “a binary” seems fine to me, if you’re not sacrificing anything else.

The only drawback I can think of is that it makes very minor patches, like security fixes, to the library impossible, which is a nice thing to have I guess, but on the other hand you’re now giving the library maintainer the capability to crash your application, and since that would presumably go through some kind of review and rebuild of the application in the first place to avoid crashes against the new library code, why does it matter if the lib is a part of the actual binary or not?

Is it really down to nothing but bandwidth and disk usage, or am I missing something here? Because if it is, and “blob binaries” becomes the norm, I’m sure you could still figure out partial patches somehow to conserve bandwidth and IO, while still keeping the binary essentially a built monolith.

Maybe one argument is that abandoned programs can still be “patched” in a way because a library it depends on fixes an issue that library was responsible for, but doesn’t that seem pretty risky to begin with to run software that is no longer being patched?

Indeed what constitutes “software” just seems to be multiple pieces in one case, and one piece in the other, no?

The biggest case against “vendoring”, which in my mind is similar to “huge” binaries, that I can think of at least is that it gives developers a false sense of security to not have to think about keeping libraries up to date: but aren’t they already equally able to be sloppy about this when the libs are separate?

> what is the actual drawback of these “huge” binaries?

The problem isn’t size. The problem is that with static linking it gets significantly more difficult to patch security vulnerabilities, because with dynamic linking, the vuln is gone once the underlying library is updated, however this wouldn’t happen with static linking.

You need to be regularly updating the higher level packages anyway though, as they might contain vulnerabilities that are not due to underlying libraries. At which point, we might as well update them for library issues too.

Many games rarely update, though. They put out the original version, and then maybe a few patches to fix game-breaking bugs, and then that's how they exist from then on. If you're expecting them to update to address vulnerabilities, you're going to be very disappointed.

That said, if the library changes the API or functionality at all, dynamic linking is going to break the game, and that's not good either. So gamedevs are going to opt for static linking and call it a day rather than deal with support requests.

For single-player games, I doubt it matters if there are unpatched vulnerabilities.

Many single player games do still phone home or otherwise cause network activity, so it’s not like they are guaranteed a safe bubble in which to run.

That's true, sadly.

But then you're relying on every single higher level package owner to pull in patches for all their dependencies and update their binaries in a timely fashion. That works for, say, Debian packages (my distro of choice), but as soon as you move outside of that circle it'll make it harder to guarantee quality.

In contrast, on (for example) Debian, I know that the Debian Security Team is looking after the libraries and that gives me a lot of peace of mind. Instead, I'd be wondering if every single third-party apt repository package owner is doing a professional job. At least if they're shipping binaries that are dynamically linked to Debian packages, I can have confidence that those library issues are being handled. (XML parser update, anybody?)

This is only a problem if the tooling to track dependencies doesn't exist.

Many programming models (e.g. monomorphization as done in C++ and Rust) are fundamentally incompatible with dynamic linking. The tooling needs to handle those cases anyway.

> Unless we’re talking about embedded systems (and most of the time, not even then I’d guess for portable gaming devices for example), what is the actual drawback of these “huge” binaries?

The functional package management/build system design instantiated by Guix and Nix shows that you can have the best of both worlds when it comes to static and dynamic linking, even without any form of containerization. Guix in particular has a feature called 'grafts' which implements a kind of hot patching for libraries in programs which are nominally dynamically linked but which in fact never search for libraries other than the exact versions they were built with.

So there's no need to choose between the portability of static linking or the efficiency and flexibility of dynamic linking. You can get all of those things together, today, for many thousands of packages.

If you're not familiar with the basic outline of these build systems, the idea is basically this:

  - every package gets installed to a unique, quasi-content-addressed location
  - each such location has its own FHS-like tree which gets treated as a prefix for that package at build time
  - every package gets manually pointed to each of it's dependencies' unique, full paths at build time

this ensures that each package always tries to load the libraries it was built with, and allows multiple versions of libraries to safely exist side-by-side, even when everything is dynamically linked.

To ship a package, you then just ship the whole dependency closure, which gives you the portability that motivates people to distribute static binaries.

Here's some info on Guix grafts, for an idea of how security updates can still be managed in such a system.

The official docs for grafts: https://guix.gnu.org/manual/en/html_node/Security-Updates.ht...

Original blog post/announcement for the feature: https://guix.gnu.org/blog/2016/timely-delivery-of-security-u...

Detailed writeup of further implementation details: https://guix.gnu.org/en/blog/2020/grafts-continued/

Shared libraries can reduce load time as they might already be in page cache. There’s also potential for a small impact in reduced instruction cache misses.

On the other side, link time optimization on static libraries allows deletion of unused functions and more aggressive inlining, so you might get that performance back and more.

People say this but every test case I've seen has proven otherwise. Static binaries load much faster. Maybe it depends on the size of the libraries involved an the quality of the OS' dynamic linking machinery (supposedly OSX has better runtime dynamic linking startup times than linux), but at the very least it is conditional, not a pure win.

Not only that, but executable images are demand-paged anyway. You can link 1 GB of static library code if you like; you won't pay the penalty unless and until those functions are actually called.

The whole debate is just stupid. If it inconveniences even one fewer user, then static linking is the way to go, because of the sheer number of drawbacks that shared libraries bring. Nobody cares how big the executable is. If you do, well... the best time to stop caring was 10 years ago, and the second best time is now.

But the called functions need to be loaded in memory for every process using them, instead of once.

Also there is value in being able to fix a library without having to recompile everything.

Everything is getting recompiled all the time anyway. At least with FreeBSD, any time a dependency is updated, all the packages that depend on that package get rebuilt. There's no concept of "this was a small update and its dynamically linked", its just "the version string changed, so rebuild everything that lists it as a dependency". This is particularly "fun" for web browsers because they have a lot of dependencies, ensuring they're rebuilt often, and they take a long time to build.

> Everything is getting recompiled all the time anyway.

Source? I know when stuff on my distribution gets recompiled because then I have to download and unpack it, so I notice.

I can assure you that it isn't as you say.

> with FreeBSD

Despite the monorepo thing, I assure you that most FreeBSD users do use software coming from other places as well.

If nothing else, you probably see several megabytes' worth of JIT compilation whenever you visit a JavaScript-heavy web page. Same effect... namely, none at all.

Lol sure… JIT only does the hot paths, not the whole thing. It certainly will not make several mb of output without my computer sounding like an ariane5 launch

Also there is value in being able to fix a library without having to recompile everything.

Number of times I have benefited from this process: 0 (AFAIK)

Number of times this process has hosed previously-working applications and components: too many to count

On Windows, this "feature" was called "DLL Hell," and was generally considered a bad thing. Nothing has fundamentally changed since it was a common practice for every installer to have its way with c:\windows, IMHO. (Admittedly shared MSVC runtimes aren't as big a problem as the Winsock-provider-du-jour was, but still... there is simply no point.)

> Number of times I have benefited from this process: 0 (AFAIK)

Every day on my distribution, when I have to download 5kb of library instead of 3GB of everything recompiled…

If we're talking about binaries for game titles, meh. Load time for the executable is utterly insignificant compared to the load time of a title's assets. Heck, shared libraries probably slow things down.

Typical games I have experience with were in the 5-20Mb range for executables, with tens of GB for assets. Most titles I looked at the performance of were terrible at scheduling I/O, often leaving 80% of their available disk bandwidth unused.

I just checked and I have 5600 binaries in my /usr/bin. They take an average of 100kb. If statically compiling them means an average of 50M that means 281gb.

You're arguing against a strawman saying that no binaries should ever be anything but statically compiled, including system binaries bundled with the operating system. I certainly did not say that.

A tiny bit off topic, but for the record: video games are, for me, extremely important. They are my favorite art form and an oasis in a daily nightmare; if I were unable to play my favorite games, the system I am running would be completely useless. Fortunately, the kind of games I like run mostly fine on Linux.

Why would I use Linux Desktop over Windows Desktop? Because it's FOSS, because of price, UX? I don't get it.

It's like asking me asking you why I would drive a Mercedes over my BMW. How would you know? All you could do is to list a million things that are different on a Mercedes compared to a BMW and then claim every one of those differences makes a Merc better.

Is that what you expect to get as replies to your question?

For a casual user who uses computer for work and gaming I would go with Windows. People say Linux is free and open source, more secure and you get privacy but is it really worth it? Idk.

To me, Linux means having the option of a system that lacks distractions. That’s a drastic ux improvement for me personally; IMO windows UX peaked with 2000, and XP was nearly as good.

I haven’t played much multiplayer anything (a little MTGa, among us, tabletop simulator and beat saber) but none of the single player games I’ve tried on Ubuntu have had any issues; just open steam and press play.

Windows started pushing f2p games in the start menu, changed UI toolkits twice in two generations, etc; it’s become unpleasant for me to use. Apple have similarly dropped the ball on UX in the past 5 years. IMO Linux UX has caught up thanks to those companies failures.

What are some DEs / window managers you think are quite simple and let you focus?

I’m using classic i3, with a nearly stock config. I have a key binding to start a launcher (in lieu of a start button).

I3bar to indicate which workspaces have new chat messages etc.

Default black background, all non-critical notifications disabled; I get distracted easily, so I craft an environment that avoids distractions.

simple window manager - how can you say i3?! most people wouldnt know how to do anything in there

Most window managers are easy, but not simple. i3 is simple, but not easy.

In general, I'd prefer to have something both simple and easy, but in most cases that's not an option.

Xfce is nice.

I was a long time Windows user. Since the 3.11 days. Windows was originally very much "You do you". Outside of Domain-joined machines, it was much more of a suggestion to update. Thing would update when you restarted/shut down.

A basic Windows install had some basic tools and utilities, but they largely didn't push things on you - and once you had set preferences, that was that.

Then Windows 8/10/11 came around.

Ads through the UI. A half-dozen or more sponsored bits (both 3rd party and their own other products). You'd log in one day and find they'd installed some other piece of crap. Features were disappearing behind the Microsoft Store. You'd try and set up a machine, and it'd play stupid games about "Oh, you need a Microsoft Account to log in", hiding/removing options to skip if it detected an internet connection.

You'd install Chrome or Firefox, and it would beg and whine. They changed up how you set browser preferences twice, to deliberately make it harder to switch. It would "helpfully" reset browser preferences back to Edge "for security".

Updates were force-installed, regardless of whether you wanted to. I remember being at a conference and hearing from maybe a half-dozen presenters who'd all had Windows push an update during the conference. Some it was just before they were about to present. Some had their machine sitting in it's various phases of Updating for an hour or more. Some had Windows reset a bunch of other preferences/configuration, and fuck up demos they had planed.

For me, the security and privacy benefits are secondary to "Let me use the machine that I'm paying for".

Ubuntu/Pop_OS might prompt me to install updates, but I've never had it tell me I have 15 minutes before it is going to force applying updates, 5 minutes before I'm supposed to join a meeting. Ubuntu might have some sponsored bits, but they're gone when you remove them.

The end of Windows 7 was the end of me using Windows, because I just can't trust the OS to do what I want, when I want.

This isn't just me, either - I've converted three other non-techie folks over to Ubuntu, too - all they did was stuff in Chrome and the occasional bit of printing. They had similar issues with Windows forcing changes on them that they didn't want. Multiple times I'd had to reset browser settings, because Windows decided that Edge was better. So Edge imported their contacts, but not the Chrome apps and couldn't sync passwords to the Google Passwords service.

I keep Windows around for Serif products and (currently, due to a Mesa bug) AOE 4. I use it for nothing else.

The amount of popups, nags, helpful hints, setup your system (which is nothing more than an interstitial to reset your browser to Edge+Bing) and other bullshit I get when logging in is mindbendingly infuriating.

This is after only being mostly away from Windows for a year. It's a shit product. I was merely a happy toad in some hot water. Things are much nicer once you actually climb out of the pot.

All of the above.

It's free (along with everything in the "app store"), it's stable, it isn't infested with ads, and the browser and word processor work exactly the same for all normal users. The OS shouldn't matter much to regular people who just want a web browser and maybe a word processor.

It's really easy to use now. The installation process is far less arduous than Windows and you don't have to sign up for a Microsoft account or get nagged about not doing so.

I would really struggle to imagine someone having trouble doing all their normally-Windows-based (filesystem, office suite, web browser) work on a mainstream distro now, even for the most technically illiterate user.

If you're a power user though, it's like moving from a Corolla to an F-35.

> Why would I use Linux Desktop over Windows Desktop?

For example it doesn't keep installing "apps" that are just ads for netflix/spotify/tiktok/whatever without me ever having wanted them to appear.

didn't valve mostly mitigate the fat binary problem with their soldier runtime set of shared libs?

Yes, and then they realized that even that wasn't good enough because Linux Desktop ABIs are a shitshow, so they refocused on providing Windows ABIs instead to great success.

huh? When I run a Linux native game via steam it uses Windows dependencies? What is this dark magic.

I think they meant Valve switched their focus to emulating Windows through WINE, practically adopting Windows' APIs, instead of solving Linux' dependency problems and pushing developers to compile for Linux natively (something they've always been reluctant to do).

I'm going to go out on a limb and say that excluding work related stuff gaming is very important to those who own a Windows PC.

Space is cheap for now, so I'll accept that

"I don't play games, I think some people do."

Multi-billion dollar industry raking in higher profits than Hollywood and that at this point is an unregulated online casino for teens.

Yeah, some people do...

Well, yeah. His comic timing’s not the best but I think that was meant to be the joke.

Yes, very dry, if not awkward, humor. I actually think Linus is quite funny in most of his interviews.

Would have never guess it was meant to be a joke.

To be clear, you're joking right now, right? I think you must be, but given your previous comment I'm not sure. Dry sarcasm in text is hard...

No, I am not. Linus is not exactly an average person; it seems perfectly reasonable to me that among his many eccentricities would be the belief that only some people play games on a PC.

Maybe I have been reading too many of his emails.

You're not alone. I wasn't able to discern that quote as humor either.

He's aware that video games exist, so obviously he knows some people play video games. I don't really see how you could confuse this.

Reply on news.ycombinator.com