Earlier quoted context omitted.
Versioned glibc symbols are part of the reason that binaries aren't portable across Linux distributions and time.
Only because people aren't putting in the effort to build their binaries properly. You need to link against the oldest glibc version that has all the symbols you need, and then your binary will actually work everywhere(*). * Except for non-glibc distributions of course.
Loss32: Let's Build a Win32/Linux
311–320 of 493 posts
Re: Loss32: Let's Build a Win32/Linux
#312Re: Loss32: Let's Build a Win32/Linux
#313Re: Loss32: Let's Build a Win32/Linux
#314Earlier quoted context omitted.
I started with VB6 so I'm sometimes nostalgic for it too but let's not kid ourselves. We might take it for granted but React-like declarative top-down component model (as opposed to imperative UI) was a huge step forward. In particular that there's no difference between initial render or a re-render, and that updating state is enough for everything to propagate down. That's why it went beyond web, and why all modern…
> and why all modern native UI frameworks have a similar model these days. Personally I much rather the approach taken by solidjs / svelte. React’s approach is very inefficient - the entire view tree is rerendered when any change happens. Then they need to diff the new UI state with the old state and do reconciliation. This works well enough for tiny examples, but it’s clunky at scale. And the code to do diffing and…
Re: Loss32: Let's Build a Win32/Linux
#315This might offend some people but even Linus Torvalds thinks that the ABI compatibility is not good enough in Linux distros, and this is one of the main reasons Linux is not popular on the desktop. https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s
This might be why OpenBSD looks attractive to some. Its kernel and all the different applications are fully integrated with each other -- no distros! It also tries to be simple, I believe, which makes it more secure and overall less buggy. To be honest, I think OSes are boring, and should have been that way since maybe 1995. The basic notions: multi-processing, context switching, tree-like file systems, multiple user…
Why should everything pretend to be a 1970s minicomputer shared by multiple users connected via teletypes?
If there's one good idea in Unix-like systems that should be preserved, IMHO it's independent processes, possibly written in different languages, communicating with each other through file handles. These processes should be isolated from each other, and from access to arbitrary files and devices. But there should be a single privileged process, the "shell" (whether command line, TUI, or GUI), that is responsible for coordinating it all, by launching and passing handles to files/pipes to any other process, under control of the user.
Could be done by typing file names, or selecting from a drop-down list, or by drag-and-drop. Other program arguments should be defined in some standard format so that e.g. a text based shell could auto-complete them like in VMS, and a graphical one could build a dialog box from the definition.
I don't want to fiddle with permissions or user accounts, ever. It's my computer, and it should do what I tell it to, whether that's opening a text document in my home directory, or writing a disk image to the USB stick I just plugged in. Or even passing full control of some device to a VM running another operating system that has the appropriate drivers installed.
But it should all be controlled by the user. Normal programs of course shouldn't be able to open "/dev/sdb", but neither should they be able to open "/home/foo/bar.txt". Outside of the program's own private directory, the only way to access anything should be via handles passed from the launching process, or some other standard protocol.
And get rid of "everything is text". For a computer, parsing text is like for a human to read a book over the phone, with an illiterate person on the other end who can only describe the shape of each letter one by one. Every system-level language should support structs, and those are like telepathy in comparison. But no, that's scaaaary, hackers will overflow your buffers to turn your computer into a bomb and blow you to kingdom come! Yeah, not like there's ever been any vulnerability in text parsers, right? Making sure every special shell character is properly escaped is so easy! Sed and awk are the ideal way to manipulate structured data!
Re: Loss32: Let's Build a Win32/Linux
#316This might offend some people but even Linus Torvalds thinks that the ABI compatibility is not good enough in Linux distros, and this is one of the main reasons Linux is not popular on the desktop. https://www.youtube.com/watch?v=5PmHRSeA2c8&t=283s
To quote a friend; "Glibc is a waste of a perfectly good stable kernel ABI"
Turns out that Nix is built against a different version of glibc than SteamOS, and for some reason, that matters. You have to make sure none of Steam's libraries are on the path before the Nix code will run. It seems impractical to expect every piece of software on your computer to be built against a specific version of a specific library, but I guess that's Linux for you.
Re: Loss32: Let's Build a Win32/Linux
#317Can somebody explain: 1. The exact problem with the Linux ABI 2. What causes it (the issues that makes it such a challenge) 3. How it changed over the years, and its current state 4. Any serious attempts to resolve it I've been on Linux for may be 2 decades at this point. I haven't noticed any issues with ABI so far, perhaps because I use everything from the distro repo or build and install them using the package man…
The model of patching+recompiling the world for every OS release is a terrible hack that devs hate and that users hate. 99% of all people hate it because it's a crap model. Devs hate middlemen who silently fuck up their software and leave upstream with the mess, users hate being restricted to whatever software was cool and current two years ago. If they use a rolling distro, they hate the constant brokenness that com…
Re: Loss32: Let's Build a Win32/Linux
#318Earlier quoted context omitted.
> Hundreds of other widely-used open source libraries don't. Correct me if I'm wrong but I don't think versioned symbols are a thing on Windows (i.e. they are non-portable). This is not a problem for glibc but it is very much a problem for a lot of open source libraries (which instead tend to just provide a stable C ABI if they care).
> versioned symbols are a thing on Windows There’re quite a few mechanics they use for that. The oldest one, call a special API function on startup like InitCommonControlsEx, and another API functions will DLL resolve differently or behave differently. A similar tactic, require an SDK defined magic number as a parameter to some initialization functions, different magic numbers switching symbols from the same library;…
Re: Loss32: Let's Build a Win32/Linux
#319Earlier quoted context omitted.
That’s possible, but the hardware (a rodecaster pro 2 connected over usb) works just fine in other Linux apps. I can record audio in audacity. And I can play back audio in resolve. I just can’t record audio in resolve. I think it’s a software issue in how resolve uses the Linux audio stack. But I have no idea how to get started debugging it. I’ve never had any problems with the same hardware in windows, or the same s…
It is hard to blame Linux if only one proprietary app has sound issues. FWIW I lost sound completely 3 times in the last 2 months on my works windows laptop and it would only come back after a reboot. I assumed it was a driver crash.
It depends on having a properly good implementation, which will come eventually for most apps.