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...
Maybe I have been reading too many of his emails.
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.
Running a big infra to run a single binary once in a while feels like a burden to some of us.
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.
https://forum.snapcraft.io/t/limitations-in-snapd/9718
This actually means that at some point I will have to move away from Ubuntu.
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.
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
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'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.
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.
And if you really want a single redistributable binary, any existing package can easily be bundled into one without decompiling it.
Traditional static linking is strictly worse.
Anyone disagree?
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...
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.
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?
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.
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.
Also there is value in being able to fix a library without having to recompile everything.
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.
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.)
Every day on my distribution, when I have to download 5kb of library instead of 3GB of everything recompiled…
The functional package management/build system design instantiated by Guix and Nix show 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.
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
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/
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.
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.
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?)
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.
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.
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.
Is that what you expect to get as replies to your question?
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.
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.
In general, I'd prefer to have something both simple and easy, but in most cases that's not an option.
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.
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.
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.
>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.