akdev1l

It’s not bog-standard. Containers are not equivalent to doing what is described in the article.

Containers are in fact redirecting writes so an installer script could not replace system libraries.

The equivalent would be a Linux distro having the assumption that installer scripts will overwrite /usr/lib/libopenssl.so.1 with its own version and just keeping a backup somewhere and copying it back after the script executes.

No OS that I know of does that because it’s unhinged and well on Linux it would probably break the system due to ABI compatibility.

If they had taken essentially the same approach as wine and functionally created a WINEPREFIX per application then it would not be unhinged.

edit: also to be clear, I respect their commitment to backwards compatibility which is what leads to these unhinged decisions. I thoroughly enjoy Raymond Chen’s dev blog because of how unhinged early windows was.

>Windows 95 worked around this by keeping a backup copy of commonly-overwritten files in a hidden C:\Windows\SYSBCKUP directory. Whenever an installer finished, Windows went and checked whether any of these commonly-overwritten files had indeed been overwritten.

This is truly unhinged. I wonder if running an installer under wine in win95 mode will do this.

Ironically this is one of my main use cases for LLMs

“Can you give me an example of how to read a video file using the Win32 API like it’s 2004?” - me trying to diagnose a windows game crashing under wine

>Wi-Fi which is a lot higher quality than a consumer router

I am not really sure about it. My ISP provided AP can do a gigabit over wifi.

I need to change it because the ISP hardcodes the dns for spying reasons.

But sadly to match that performance I need to spend like $180 to get an AP with that performance

I think people are more complaining about windows crashing on updates or Microsoft putting ads everywhere or forcing one drive

That’s way more than just the “position of the start menu”

It does weird things in multi monitor because dragging a window on top of the newly “maximized” window somehow does not work

Yes MacOS breaks down the user until they give up on window management

The window management style of Mac OS is complete chaos imo

I have been using it for years and I just gave up entirely on managing anything and if I zoom out to see all my windows it looks like the freaking Milky Way from windows I forgot

>just a slow decline into incompetence.

Give them some credit, it’s been quite rapid.

Also we could probably achieve this by using dnsfs and regular doom install

https://blog.benjojo.co.uk/post/dns-filesystem-true-cloud-st...

From all this what I got is that Microsoft is connecting to some random servers not using TLS and then somehow outputting that data straight into the Nintendo Switch

I believe Android will be blocking installations from outside Google play except through adb

I should clarify my original comment about stability only applies to glibc itself. Once we go out of glibc there will be varying degrees of API/ABI stability simply because at that point it’s just different groups of people doing the work

In some cases such libraries are also cross-platform so the same issues would be found on Windows (eg: try to build application which depends on openssl3 with openssl4 and it will not work on either Linux or windows)

For future reference if you ever need to do that again, it would be way easier to spin up a container with the build environment the software expects. Track down the last release date of the software and do podman run —-rm -it ubuntu:$from_that_time and just build the software as usual.

You can typically link the dependencies statically during build time to create system independent binaries. So the binary produced inside the container would work on your host as well.

>On my 2020 Dell XPS, I still haven't figured out how to enable the subwoofers

If I remember correctly dell never provided drivers/firwmare/docs upstream to drive the subwoofer. ref: https://bugzilla.kernel.org/show_bug.cgi?id=215233

Depends on the distro.

Fedora looks like it carries a whooping 2 patches on top of upstream

glibc must match the linker so you would need a separate linker and the binaries usually have a hardcoded path to the system linker (and you need to binary patch the stuff - https://stackoverflow.com/questions/847179/multiple-glibc-li...)

So in practice you can only have 1 linker, 1 glibc (unless you do chroot or containers and at that point just build your stuff in Ubuntu 12.04 or whatever environment)

I thought you meant Proton-GE or such other patched builds of proton.

They announced Rosetta 2 will be deprecated and eventually removed (MacOS 28?)

By that point they already hit the developers enough to get them to port to aarch64

(arguably though this could be a special case because it is due to architectural transition)

Sorry I am not sure if 2.12 is a a recent release or older, I made up this number up

If the application is built against 2.12 it may link against symbols which are versioned 2.12 and may not work against 2.11 - the opposite (building against 2.11 and running on 2.12) will work

>If true (I don't think it is), that is a hard showstopper for most companies that want to develop for Linux.

Not really a show stopper, vendors just do what vendors do and bundle all their dependencies in. Similar to windows when you use anything outside of the win32 API.

The only problem with this approach is that glibc cannot have multiple versions running at once. We have “fixed” this with process namespaces and hence containers/flatpak where you can bundle everything including your own glibc.

Naturally the downside is that each app bundles their own libraries.

Maybe you are right about esync but anyway I would also gather a lot of people don’t have that either. At least personally I don’t bother with custom proton builds or whatever so if Valve didn’t enable that on their build then I don’t have it.

Plenty of operating systems work like this. Just not highly commercial ones because proprietary software is the norm on those.

From a bit of research it looks like FreeBSD for example only provides a stable ABI within minor versions and I imagine if you build something for FreeBSD 14 it won’t work on 13.

Stable ABI literally only benefits software where the user doesn’t have the source. Any operating system which assumes you have the source will not prioritize it.

(Edit: actually thinking harder MacOS/iOS is actually much worse on binary compatibility, as for example Intel binaries will stop working entirely due to M-cpu transition - Apple just hits developers with a stick to rebuild their apps)

Because dnf4 used the same dependency resolution as yum but they revamped it in dnf5 (it was initially supposed to be a whole new package manager with a different name)

It can revert back to building from source under some cases and I still think even when doing binary downloads it will execute install hooks which are ruby inside the recipe

I would agree with you that probably Ruby itself is probably not the bottleneck (except maybe for depsolving cuz that’s cpu bound)

Well I can tell you that if it didn’t make it upstream Fedora didn’t ship it.

It looks there was a copr for a custom kernel-fsync and projects like Bazzite or Nobara are adding patches.

From my understanding the fsync patches were never upstreamed.

Proprietary software needs a stable ABI. Not games.

DOOM runs on any Linux system since forever because we had access to the source. You can build it for Linux 2.6 and it’ll probably still work today.

Sadly most games are proprietary

People always say this to shit on glibc meanwhile those guys bend over backwards to provide strong API compatibilities. It rubs me off the wrong way.

What glibc does not provide is forward compatibility. An application built with glibc 2.12 will not necessarily work with any older version.

Such application could be rebuilt to work with an older glibc as the API is stable. The ABI is not which is why the application would need to be rebuilt.

glibc does not provide ABI compatibility because from their perspective the software should be rebuilt for newer/older versions as needed. Maintaining a stable ABI mostly helps proprietary software where the source is not available for recompilation. Naturally the gnu guys building glibc don’t care about that use case much.

I guess you didn’t mention glibc in your comment but I already typed this out

>These extreme gains are the result of benching against vanilla without fsync, which is what anyone gaming on linux uses

Not for anyone using a kernel without these patches. Which would be most people.

The recipes for building and installing homebrew packages are written in Ruby

You cannot really be compatible with this unless you run the Ruby as the install scripts could do whatever arbitrary computations

In reality most recipes contain a simple declarative config but nothing stops you from doing Ruby in there.

Hence to achieve total compatibility one would need to run Ruby

pacman is faster simply because it does less things and it supports less use cases.

For example pacman does not need to validate the system for partial upgrades because those are unsupported on Arch and if the system is borked then it’s yours to fix.

yum was slow not because of python but because of the algorithm used to solve dependencies

Anyway the python program would call into libsolv which is implemented in C.

dnf5 is much faster but the authors of the program credit the algorithmic changes and not because it is written in C++

dnf < 5 was still performing similarly to yum (and it was also implemented in python)