64 ms·

Win32 Is the Only Stable ABI on Linux?

456 points by pantalaimon 4y ago

notRobot 4y ago
Related: Win32 is the stable Linux userland ABI (and the consequences): https://news.ycombinator.com/item?id=30490570 https://news.ycombinator.com/item?id=30490570 336 points, 242 comments, 5 months ago
wmf 4y ago
I assume Flatpak fixes this by locking your app to a compatible version of glibc.
- layer8 4y ago
  …also locking in any security vulnerabilities.
  - rtontic 4y ago
    I mean, we are talking about videogames here.
    - formerly_proven 4y ago
      Multiplayer is a thing, where both crashing servers and also attacking other clients (even in non-p2p titles) is not that uncommon. Many titles don't permit community servers any more, of course.
    - maeln 4y ago
      Wasn't it Elden Ring or another From Software game that had a RCE ? This article talks about it : https://wccftech.com/dark-souls-rce-exploit-fixed-elden-ring/ https://wccftech.com/dark-souls-rce-exploit-fixed-elden-ring... A lot of games have multiplayer functionalities these days. That make them a potential target for RCE and related vulnerabilities. Granted, if you don't play video game as root, the impact should be limited, but it is still something to be aware of.
      - Beltalowda 4y ago
        Skimming over the details, that seems like a bunch of bugs in the game code. I don't think dynamic linking would help there.
  - deleted 4y ago
    [deleted]
- AshamedCaptain 4y ago
  Static linking -- always the ready-to-go response for anything ABI-related. But does it really help? What use is a statically linked glibc+Xlib when your desktop no longer sets resolv.conf in the usual place and no longer speaks the X11 protocol (perhaps in the name of security) ?
  - gabereiser 4y ago
    Even statically linked, the problems you just described are valid. The issue is x11 isn’t holding up and no one wants to change. Wayland was that promise of change but has taken 15+ years to develop (and still developing). Linux desktop is a distro concern now. Not an ecosystem concern. It’s long left the realm of an linux concern when MacOS went free (with paid hardware of course) and Windows was giving away free windows 10 licenses to anyone who asked for it. Deepin desktop and elementary are on the top of my list for elegance and ease of use. Apps and games need a solid ABI and this back and forth between gnome and kde doesn’t help. With so many different wm’s and desktop environments, x11 is still the only method of getting a window with an opengl context in any kind of standard way. Wayland, X12, whatever it is, we need a universal ABI for window dressing for Linux to be taken seriously on the desktop.
    - pengaru 4y ago
      > Linux desktop is a distro concern now. Not an ecosystem concern. It’s long left the realm of an linux concern when MacOS went free (with paid hardware of course) and Windows was giving away free windows 10 licenses to anyone who asked for it. You seem fixated on the Free Beer misinterpretation of Free Software.
      - gabereiser 4y ago
        No, but it sounds that way I guess. It’s more about where the developer en-masse focus lays. Few developers are interested in the desktop for Linux because they are supported on windows or Mac and during the time period I mentioned, it didn’t cost them anything monetary. There were indications that windows and Linux May converge. Instead we got WSL2. A lot of times we decide to develop something because of the pain of using the other thing. Sometimes we develop something as a “me too”. Sometimes we develop something that is just better. Sometimes, it’s worse. My point is the fight for a foothold in Linux desktop looked promising for a bit. SteamOS looked like it was gaining, steam… The reality is there are complexities at that level that people don’t want to deal with and we all have opinions on how it should work, should look, and should be called. Red Hat (former RH’er myself) should take this on and really standardize something outside of core and server land. And no, it should not be Gnome.
- spicybright 4y ago
  If you're never going to update your program and don't care about another heartbleed effecting your product and users, then sure.
  - lanstin 4y ago
    Would you rather run a statically linked go or rust binary with the native crypto implementations of ssl or a dynamically linked OpenSSL that is easier to upgrade? (Honest question)
- mananaysiempre 4y ago
  Surprisingly, that seems correct—a Flatpak bundle includes a glibc; though that only leaves me with more questions: - On one hand, only one version of ld.so can exist in a single address space (duh). Glibc requires carnal knowledge of ld.so, thus only one version of glibc can exist in a single address space. In a Flatpak you have (?) to assume the system glibc is incompatible with the bundled one either way, thus you can’t assume you can load host libraries. - On the other hand, a number of system services on linux-gnu depend on loading host libraries. Even if we ignore NSS (or exile it into a separate server process as it should have been in the first place), that leaves accelerated graphics: whether you use Wayland or X, ultimately an accelerated graphics driver amounts to a change in libGL and libEGL / libGLX (directly or through some sort of dispatch mechanism). These libraries require carnal knowledge of the kernel-space driver, thus emphatically cannot be bundled; but the previous point means that you can’t load them from the host system either. - Modern toolkits basically live on accelerated graphics. Flatpak was created to distribute graphical applications built on modern toolkits. - ... Wait, what?
  - anon291 4y ago
    There is no 'system' glibc. Linux doesn't care. The Linux kernel loads up the ELF interpreter specified in the ELF file based on the existing file namespace. If that ELF interpreter is the system one, then linux will likely remap it from existing page cache. If it's something else, linux will load it and then it will parse the remaining ELF sections. Linux kernel is incredibly stable ABI-wise. You can have any number of dynamic linkers happily co-existing on the machine. With Linux-based operating systems like NixOS, this is a normal day-to-day thing. The kernel doesn't care. > These libraries require carnal knowledge of the kernel-space driver, thus emphatically cannot be bundled; but the previous point means that you can’t load them from the system either. No they don't. The Linux kernel ABI doesn't really ever break. Any open-source driver shouldn't require any knowledge of internals from user-space. User-space may use an older version of the API, but it will still work. > whether you use Wayland or X, ultimately an accelerated graphics driver amounts to a change in libGL and libEGL / libGLX (directly or through some sort of dispatch mechanism) OpenGL is even more straightforwards because it is typically consumed as a dynamically loaded API, thus as long as the symbols match, it's fairly straightforwards to replace the system libGL.
dvfjsdhgfv 4y ago
This is by design, and everybody should be aware of that. I don't know about glibc, but as far as the kernel is concerned, Linus has never guaranteed ABI stability. API, on the other hand, is extremely stable, and there are good reasons for that. In Windows, software is normally distributed in a binary form, so having ABI compatibility is a must.
- josephcsible 4y ago
  The kernel absolutely does guarantee a stable userspace ABI. This post is entirely about other userspace libraries.
- deleted 4y ago
  [deleted]
- wmf 4y ago
  The Linux kernel maintains userspace API/ABI compatibility forever but inside the kernel (e.g. modules) there is no stable API/ABI.
- mort96 4y ago
  Uh, the kernel ABI is extremely stable. You could take a binary that's statically compiled in the 90s and run it on the latest release of the kernel. "Don't break userspace" is Linus's whole schtick, and he's taking about in terms of ABI when he says that. This is about the ABIs of userspace "system-level" libraries, glibc in particular.
  - deleted 4y ago
    [deleted]
iforgotpassword 4y ago
Agree. Had a few games on Steam crap out with the native version, forced it to use proton with the Windows version, everything worked flawlessly. Developers natively porting to linux seem to be wasting their time. Funnily enough with wine we kinda recreated the model of modern windows, where Win32 is a personality on top of the NTAPI which then interfaces with the kernel. Wine sits between the application and the zoo of libraries including libc that change all the time.
- dleslie 4y ago
  FWIW, targeting proton is likely the best platform target for future Windows compatibility too.
- Aachen 4y ago
  > Developers natively porting to linux seem to be wasting their time. Factorio runs so much better than any of this emulationware, it's one of the reasons I love the game so much and gifted licenses for friends using Windows. Some software claims to support Linux but uses some tricks to avoid recompiling and it's always noticeable, either as lag, as UI quirks, or some features plainly don't work because all the testers were windows users. Emulating as a quick workaround is all fair game but don't ship that as a Linux release. I appreciate native software (so long as it's not java), and I'm also interested in buying your game if you advertise it as compatible with WINE (then I'm confident that it'll work okay and you're interested in fixing bugs under emulation), just don't mislead and pretend and then use a compatibility layer.
  - jbverschoor 4y ago
    Wine Is Not an Emulator
    - bombcar 4y ago
      I believe it now actually is again, or was, or something. It's a question when dealing with Win16 and now Win32 (Windows-on-Windows).
    - 4y ago
guardiangod 4y ago
I can run a Windows 95 app on Windows 10 and it has a reasonable chance of success. Should Linux (userland) strive for that? Or is Year of the Linux Desktop only covers things compiled in the last 10 years?
- deleted 4y ago
  [deleted]
- ivraatiems 4y ago
  It's what the kernel strives for. They're remarkably consistent in their refrain of "we never break userspace." I think it would be reasonable for glibc and similar to have similar goals, but I also don't run those projects and don't know what the competing interests are.
  - pantalaimon 4y ago
    > I think it would be reasonable for glibc and similar to have similar goals I don’t think userspace ever had this goal. The current consensus appears to be containers, as storage is cheap and maintaining backwards compatibility is expensive
    - lpghatguy 4y ago
      Containers are not a great solution for programs that need graphics drivers (games) or quick startup times (command line tools). I've been wrestling with glibc versioning issues lately and it has been incredibly painful. All of my projects are either games or CLI tools for games, which means that "just use a snap/flatpak/appimage" is not a solution.
      - bityard 4y ago
        There's no reason launching a container _must_ be slow. Under the hood, launching a containerized process is just making a few kernel syscalls that have very little overhead. You might be thinking of docker, which is slow because it's intended for certain use cases and brings a lot of baggage with it in the name of backward compatibility from a time when the Linux container ecosystem was much less mature. There are several projects working on fast, slim containers (and even VMs) with completely negligible startup times. I don't know what is holding back container/VM access to graphics hardware, but it can't be insurmountable if the cloud providers are doing it.
amadeuspagel 4y ago
Stable APIs on linux: https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API
- cowtools 4y ago
  I used to disagree with this browser-as-OS mentality, but seeing as it's sandboxed and supports webGL, wasm, WebRTC, etc. I find it pretty convienient (if I'm forced to run zoom for example, I can just keep it in the browser). Just as long as website/application vendors test their stuff across different browsers.
myself248 4y ago
like Excel is more stable than Windows itself, you can open a spreadsheet from the win16 days and it'll just work....
- croes 4y ago
  Nope, had multiple that did even work after the latest update
- mananaysiempre 4y ago
  Personal experience: Office 2021 and Office 97 do not paginate a DOC file created (by Microsoft employees) in Office 97 the same way, so the table of contents ends up different.
captainmuon 4y ago
The ABI of the Linux kernel seems reasonably stable. Somebody should write a new dynamic linker that lets you easily have multiple versions of libraries - even libc - around. Then its just like windows where you have to install some weird MSVC runtimes to play old games.
- anon291 4y ago
  Just use nix.
- mort96 4y ago
  Or, GNU could just recognise their extremely central position in the GNU/Linux ecosystem and just not. break. everything. all. the. time. It honestly really shouldn't be this hard, but GNU seems to have an intense aversion towards stability. Maybe moving to LLVM's replacements will be the long-term solution. GNU is certainly positioning itself to become more and more irrelevant with time, seemingly intentionally.
  - mike_hearn 4y ago
    The issue is more subtle than that. The GNU and glibc people believe that they provide a very high level of backwards compatibility. They don't have an aversion towards stability and in fact, go far beyond most libraries by e.g. providing old versions of symbols. The issue here is actually that app compatibility is something that's hard to do purely via theory. The GNU guys do compatibility on a per function level by looking at a change, and saying "this is a technical ABI break so we will version a symbol". This is not what it takes to keep apps working. What it actually takes is what the commercial OS vendors do (or used to do): have large libraries of important apps that they drive through a mix of automated and manual testing to discover quickly when they broke something. And then if they broke important apps they roll the change back or find a workaround regardless of whether it's an incompatible change in theory or not, because it is in practice. Linux is really hurt here by the total lack of any unit testing or UI scripting standards. It'd be very hard to mass test software on the scale needed to find regressions. And, the Linux/GNU world never had a commercial "customer is always right" culture on this topic. As can be seen from the threads, the typical response to being told an app broke is to blame the app developers, rather than fix the problem. Actual users don't count for much. It's probably inevitable in any system that isn't driven by a profit motive.
skyde 4y ago
what about the web browser. Isn't that also a stable ABI ? Or its not a "Binary interface" because it only support Javascript? What about web assembly ?
- 0x457 4y ago
  If web browsers had any kind of stable interface we wouldn't have: https://caniuse.com/ https://caniuse.com/, polyfils, vendor CSS prefixes and the rest of crutches. WASM isn't binary. But that's all irrelevant when we talk about ABI. ABI is specifically binary interface between binary modules. For example: my hello_world binary and glibc or glibc and linux kernel or some binary and libsqlite3.
_hudj 4y ago
This is a long standing question and has nothing to do with Linux or windows. It's a design philosophy. Yes the win32 abi is very stable. It's also a very inflexible piece of code and it drags it's 20 year old context around with it. If you want to add something to it you are going to work and work hard to ensure that your feature plays nicely with 20 year old code and if what you want to do is ambitious...say refactor it to improve it's performance...you are eternally fighting a large chunk of the codebase implementation that can't be changed. Linux isn't about that and it never has been, it's about making the best monolithic kernel possible with high level Unix concepts that don't always have to have faithful implementations. The upside here is that you can build large and ambitious features that refactor large parts of how core components work if you like, but you might only compile those features against a somewhat recent glib. This is a choice. You the developer can link whatever version you want. If you want to build in support for glib then just use features that only existed 10 years ago and you'll get similar compatibility to win32. If not then you are free to explore new features and performance you don't have to implement or track provided you consider it a sensible use cases that someone has to be running a somewhat recent version of glib. The pros and cons are up for you to decide but it's not as simple as saying that windows is better because it's focus is backwards compatibility. There is an ocean of contexts hidden behind that seemingly magical backwards support...
- karamanolev 4y ago
  According to Wikipedia, "Win32 is the 32-bit application programming interface (API) for versions of Windows from 95 onwards.". Also from there "The initial design and planning of Windows 95 can be traced back to around March 1992" and it was released in '95. So arguably, the design decisions are closer to 30 years old than 20 :)
  - deleted 4y ago
    [deleted]
  - jdsully 4y ago
    The main structure is from win16, although adding support for paging and process isolation was a pretty big improvement in win32. IMO its held up extremely well considering its 40 years old.
jwilk 4y ago
OK, glibc ABI stability may not be perfect, but is there any evidence that Wine is any better? That sounds implausible to me.
- modeless 4y ago
  The difference is if Wine breaks an application that works on Windows, it's considered a bug that should be fixed, regardless of why.
blibble 4y ago
glibc != Linux a better analogy would be targeting the latest version of MSVCRT that happens to be installed on your system (instead of bundling it) ... also which mostly works but sometimes breaks
- int_19h 4y ago
  Windows has switched from app-redistributed MSVC runtimes to OS-distributed "universal CRT" since Windows 10 (2015). Unlike MSVCRT, uCRT is ABI-stable.
- itvision 4y ago
  Nearly 99% of Linux software is linked to glibc. What the f are you talking about? This is not MSVCRT by a long shot.
CameronNemo 4y ago
Proprietary devs should use static linking (with musl) or chroots/containers. What makes the author think they are the target audience of glibc?
- calvin_ 4y ago
  Have fun with libGL!
  - CameronNemo 4y ago
    I hadn't thought of that... Flatpaks let you use specific mesa versions, though.
- davikr 4y ago
  Thanks, but I think I'll stick with Windows: their target audience is famously everyone and for an unlimited time.
hu3 4y ago
Sidenote. I remember when Warcraft 3 ran better in Wine+Debian than in Windows. Athlon II x2 CPU and Nvidia Geforce 6600 GT with a wooping 256MB of VRAM. That was one hot machine. Poor coolers.
- benibela 4y ago
  I tried to run WoW and Starcraft 2 with Wine, and it did not install/run
ddevault 4y ago
The kernel <> userspace API is stable, famously so. Dynamic linking to glibc is a terrible idea, statically link your binaries against musl and they'll still work in 100 years.
- nibbleshifter 4y ago
  Trying to statically link with glibc throws specific warnings that certain calls aren't portable. With musl? No such problem. Fuck even uclibc is more portable than glibc and its a dead project afaik
  - SubjectToChange 4y ago
    > With musl? No such problem. Does musl even implement the functionality glibc was warning about?
- sylware 4y ago
  game binaries need to dynamically load system libs. A statically linked binary would have to include a full ELF loader.
oppositelock 4y ago
Many moons ago, one of the things I did was to port the Windows version of Google Earth to both Mac and Linux. I did the mac first, which was onerous, because of all the work involved in abstracting away system specific API's, but once that was done, I thought Linux would be a lesser task, and we hired a great linux guy to help with that. Turns out, while getting it running on linux was totally doable, getting it distributed was a completely different story. Due to IP reasons, this can't ship as code, so we need to ship binaries. How do you do that? Do you maintain a few separate versions for a few popular distributions? Do you target the Linux Standard Base? The first approach is a lot of work, and suffers from breakages from time to time, and you alienate users not on your list of supported distros. The second version, using LSB, was worse, as they specify ancient libraries and things like OpenGL aren't handled properly. End result; management canned the Linux version because too much ongoing support work was required, and no matter what you did, you got hate mail from Gentoo users.
- frozenport 4y ago
  Wait. Google Earth has always been available for Linux? https://www.google.com/earth/versions/ https://www.google.com/earth/versions/
  - cyral 4y ago
    They probably mean the old desktop one that has been re-branded to "Google Earth Pro". The UI looks a decade old but it's still useful for doing more advanced things like taking measurements.
    - oppositelock 4y ago
      Yup. That's the one. If it works for you, great, but it crashes on symbol issues for many people.
      - freedomben 4y ago
        FWIW, I use Google Earth Pro on Fedora quite often, and I'm deeply appreciative of the work it took to make that such a simple and enjoyable experience. I hate that the vocal and tiny minority of linux users who are never satisfied are the ones that most people hear from.
bjourne 4y ago
Glibc is not Linux, and they have different backwards compatibility policies, but everyone should still read Linus Torvalds' classic 2012 email about ABI compability: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75 Teaser: It begins with "Mauro, SHUT THE FUCK UP!"
- DiggyJohnson 4y ago
  Really appreciate your stuff Bjorn, this link always brings a smile to my (too young to be cynical) face.
  - bjourne 4y ago
    Thanks!
- efficax 4y ago
  man it's always a trip to see how much of a jerk torvalds could be, even if exasperation is warranted in this context (i have no idea), by god, this is not how you build consensus or a high functioning team
  - moomin 4y ago
    People often think that because jerks work at successful companies, you need to be a jerk to be successful. It’s more the other way around: a successful firm can carry many people who don’t add value, like parasites. Guarantee you Linus wasn’t this bad in the 90s.
    - tasuki 4y ago
      I think he's not this bad these days? He issued some public apologies for his behaviour. He gave us Linux and Git. Yes, he used to be an asshole, but he still did way more for the betterment of humanity than most people.
      - freedomben 4y ago
deleted 4y ago
[deleted]
adolph 4y ago
Maybe a counterpoint is "x86-64 Linux ABI Makes a Pretty Good Lingua Franca" [0] from αcτµαlly pδrταblε εxεcµταblε of Aug 2022. 0. https://justine.lol/ape.html https://justine.lol/ape.html
ChikkaChiChi 4y ago
Without getting into spoilers, I'll say that playing "Inscryption" really got me thinking about Docker's continued development could help consumers in the gaming industry. I would love to see game being virtualized and isolated from the default userspace with passthrough for graphics and input to mitigate latency concerns. Abandonware could become a relic of the past! Being able to play what you buy on any device you have access to would be amazing. I won't hold my breath, though. The industry pretty loudly rejected Nvidia's attempt to let us play games on their cloud without having to buy them all again. Todd needs the ability to sell us 15 versions of Skyrim to buy another house.
- rstat1 4y ago
  For games on Steam there's the Steam Linux Runtime which can run games on Linux in a specialized container to isolate them from these sort of bugs. There's also a variant of this container that contains a forked version of Wine for running Windows games as well.
  - mort96 4y ago
    Doesn't the Steam Linux Runtime have a problem in the other direction though? Games are using libraries which are so old that they have bugs which are long since fixed or don't work properly in modern contexts. Apparently a lot of issues with Steam + Wayland comes from the ancient libraries in the Steam Linux Runtime from what I have been able to find out from googling issues I've experienced under Wayland.
- disintegore 4y ago
  > Abandonware could become a relic of the past! That would eat into some business models though, like Nintendo's quadruple-dipping with its virtual consoles
  - matheusmoreira 4y ago
    Good. All those games should be in the public domain anyway. It's been 30-40 years, Nintendo has been more than adequately compensated.
phendrenad2 4y ago
One way to achieve similar results on Linux might be for the Linux kernel team to start taking control of core libraries like x11 and wayland, and to extend the same "don't break userspace" philosophy to them also. That isn't going to happen, but I can dream!
- rodgerd 4y ago
  There was a period where a Linux libc was maintained, but it was long-ago deprecated in favour of glibc. Perhaps that was a mistake.
- yjftsjthsd-h 4y ago
  My understanding is that the Linux devs like only having "Linux" only be the kernel; if they wanted to run things BSD-style (whole base system developed as a single unit) I assume they would have done that by now (it's been almost 30 years).
- matheusmoreira 4y ago
  I'm not sure about taking over the entire GUI ecosystem but I certainly do want more functionality in the kernel instead of user space precisely because of how stable and universal the kernel is. I want system calls, not C libraries.
kazinator 4y ago
"DT_HASH is not part of the ABI" is like saying "DNS is not part of the Internet".
franga2000 4y ago
I recently experienced this in a critical situation. Long story short, something went very wrong during a big live event and I needed some tool to fix it. I downloaded the 2 year old Linux binary, but it didn't run. I tried running it from an old Ubuntu Docker container, but there were dependencies missing and repos were long gone. Luckily it was open source, but compiling was taking ages. So in a case of "no way this works, but it doesn't hurt to try" I downloaded the Windows executable and ran it under Wine. Worked like a charm and everything was fixed before GCC was done compiling (I have a slow laptop).
- nicce 4y ago
  I have personally used containers for this reason to set my gaming environment. If something breaks, all I need to do is to run older image and everything works.
knorker 4y ago
Yeah Linus's "we don't break user space" is a joke. Great, the kernel syscalls API is stable. Who cares, if you can't run a 7 year old binary because everything from vdso to libc to libstc++ to ld-linux.so is incompatible. Good luck. No it's not just a matter of LD_LIBRARY_PATH and shipping a binary with a copy. That only helps with third party libs, and only if vdso and ld-linux is compatible. My 28 year experience running Linux is that it's API (source code) unbroken, but absolutely not ABI.
- MichaelCollins 4y ago
  Linus does provide a stable ABI with Linux, it's GNU who drops the ball and doesn't. You're criticizing Linus for something he has nothing to do with. What's the point in that?
  - phendrenad2 4y ago
    Linus chose to only care about the kernel. So there's possibly some fault there.
    - sph 4y ago
      So it's Linus' fault he didn't just write the kernel but should also decided to being responsible for the entire userspace as well? What kind of argument is that.
      - zbird 4y ago
        He should have run for president.
      - phendrenad2 4y ago
        By that logic nothing is anyone's fault. "I did exactly what I meant to do, nothing more, nothing less. Therefore you cannot say anything negative about it. Have a nice day." I feel like there's a Peanuts comic like this: "No matter what happens any place or any time in the world, this absolves me from all blame!"
userbinator 4y ago
The change that caused the break would be equivalent to the PE file format changing in an incompatible way on Windows, to give an idea of how severe it is.
Animats 4y ago
Notes: "EAC" is Easy Anti Cheat, sold by Epic.[1] Not EarthCoin. "EOS", in this context, is probably Epic Online Services, not one of the 103 other known uses of that acronym.[2] Here's a list of the games using those features.[3] So, many of these issues are for people building games with Epic's Unreal Engine on Linux. The last time I tried UE5, after the three hour build, it complained I had an NVidia driver it didn't like. I don't use UE5, but I've tried it out of curiosity. They do support Linux, but, as is typical, it's not the first platform they get working. Epic does have support forums, and if this is some Epic problem encountered by a developer, it can probably be fixed or worked round. Wine is impressive. It's amazing that they can run full 3D games effectively. Mostly. Getting Wine bugs fixed is somewhat difficult. The Wine people want bugs reported against the current dev version. Wine isn't set up to support multiple installed versions of itself. There's a thing called PlayOnLinux which does Wine version switching, but the Wine team does not accept bug reports if that's in use.[4] So you may need a spare machine with the dev version of Wine for bug reproduction. [1] https://www.easy.ac/en-us/ https://www.easy.ac/en-us/ [2] https://acronyms.thefreedictionary.com/EOS https://acronyms.thefreedictionary.com/EOS [3] https://steamcommunity.com/groups/EpicGamesSucks/discussions/0/4149469212598904161/ https://steamcommunity.com/groups/EpicGamesSucks/discussions... [4] https://wiki.winehq.org/Bugs https://wiki.winehq.org/Bugs
- Hello71 4y ago
  > Wine isn't set up to support multiple installed versions of itself. huh? the official wine packages for ubuntu, debian, and i believe fedora provide separate wine-devel and wine-staging packages, which can be installed in parallel with each other and with distro packages. in fact, debian (and ubuntu) as well as arch provide separate wine and wine-staging packages as part of the distro itself, no separate repo required. wine has no special support for relocated installations, but no more or less so than any large Unix program; you can install as many copies as you want, but they must be compiled with different --prefixes, and you cannot use different versions of wine simultaneously with the same WINEPREFIX.
  - Animats 4y ago
    Oh, that's good to know. Thanks.
littlestymaar 4y ago
At this point I'm pretty convinced that no-one at Microsoft ever did a better job in keeping people on Windows than what the maintainers of glibc are doing …
- CoolCold 4y ago
  Well, the WSL team did a lot I think (including new Terminal). WSL, WSL2, WSLg, WSA - I almost never use full Linux VMs now, my pretty simple needs are covered with it.
mid-kid 4y ago
- deleted 4y ago
  [deleted]
Kukumber 4y ago
It's not, and it is super sad to hear people advocating for such horrible idea Linux being infested by windows is the beginning of its death to me, what a tragedy A well deserved death after the system-d drama anyways
- phendrenad2 4y ago
  Why is it a horrible idea?
justin66 4y ago
I was going to make a joke about a.out support (and all the crazy stuff that enables, like old SCO binaries) but apparently a.out was removed in May as an option in the Linux kernel. https://lwn.net/Articles/895969/ https://lwn.net/Articles/895969/ At least we still have WINE.
codebolt 4y ago
Coincidentally, Win32 is also the only stable API on Windows. WinForms and WPF are still half-broken on .NET 5+, WinRT is out, basically any other desktop development framework since the Win32 era that is older than a couple of years is deprecated. Microsoft is famous for introducing new frameworks and deprecating them a few years later. Win32 is the only exception I can think of.
- ahtihn 4y ago
  Since when is .NET 5+ part of Windows?
  - markmark 4y ago
    And .NET 4.8 is still installed by default on Windows 11 and will presumably happily run your WPF app if you target it.
    - solarkraft 4y ago
      .NET 4.8 might be one of those things they won't be able to get rid of.
      - int_19h 4y ago
        Windows 11 still ships msvbvm60.dll - that's the runtime for Visual Basic 6, released back in 1998. And it is officially supported: https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy https://docs.microsoft.com/en-us/previous-versions/visualstu...
  - codebolt 4y ago
    Since MS decided to deprecate .NET Framework, making .NET 5+ the recommended basis for C# desktop development going forward. Yes you will still be able to run your old apps for many decades still, but you can never move to a newer version of the C# language and maintaining them is going to be an increasing pain as the years go by. I've already been down this road with VB6.
beebeepka 4y ago
Not news. In fact, wine/proton really is the preferred wayof doing things. Valve saw the light years but they weren't the first. Even Carmack has been saying it before the whole gaming on Linux thing became viable.
cosmin800 4y ago
oh, no, not again: kids working for big tech constantly, but randomly, deprecating, removing and breaking apis/abis/features in the kernel/libraries/everywhere. I honestly belive that all relationships between big tech companies and opensource are toxic and follow the microsoft principle of the embrace, extend, and extinguish.
sylware 4y ago
The glibc libs should be ELF clean. Namely, a pure and simple ELF64 dynamic exe, should be able to "libdl"/dynamically load any glibc lib. It is maybe fixed and possible in latest glibc. The tricky part is the sysv ABI for TLS-ized system variables: __tls_get_addr(). For instance errno. It seems the pure and simple ELF64 dynamic exe would have to parse the ELF headers of the dynamically loaded shared libs in order to get the "offsets" of the variables. Never actually got into this for good though. And in the game realm, you have c++ games (I have an extremely negative opinion about this language), and the static libstdc++ from gcc does not "libdl"/dynamically load what it requires from the glibc, and it seems even worse, namely it would depends on glibc internal symbols.
- sylware 4y ago
  Then, if I got it right for TLS-ized variables, dlsym should do the trick. Namely, dlsym will return the address of a variable for the calling thread. Then this pointer can be cached the way the thread wants. On x86_64, it can "optimize" the dlsym calls by reusing the same address for all threads, namely 1 call is enough. Now the real pain is this static libstdc++ not libdl-ing anything, or worse expecting internal glibc symbols (c++ ...)
z3t4 4y ago
Linux has a more stable windows ABI then windows itself. If a game stops working on windows it will likely still work with wine on Linux.
zzo38computer 4y ago
I suppose that Win32 can be helpful if you want to make programs that run on both Windows and on Linux (and also ReactOS, I suppose), but might not work as well for programs with Linux specific capabilities. (Also, I have problems to install Wine, due to package manager conflicts.) There are other possibilities, such as .NET (although some comments in here says it is less stable, some says it works), which also can be used on Windows and on Linux. There is also HTML, which has too many of its own problems and I do not know how stable HTML really is, either. And then, also Java. Or, you can write a program for DOS, NES/Famicom, or something else, and can be emulated in many systems. (A program written for NES/Famicom might well run better on many systems than a native code does, especially if you do not do something too tricky in the code (in which case some implementations might not be compatible).) Of course also the different ways they have different advantages and disadvantages, with compatibility, efficiency, capability, and other features.
bartwe 4y ago
As a gamedev that tried shipping to linux, we really need some standardized minimized image to target with ancient glibc and such, and some guarantees that if it runs on the image that it runs on future linux versions.
- sph 4y ago
  Just target Flatpak. You got a standardised runtime, and glibc is included in the container. If it works on your machine, it'll work on my machine, since the only difference will be the kernel and Linus is pretty adamant in retaining compatibility at the syscall level.
titzer 4y ago
Dynamically-linked userspace C is a smouldering trash heap of bad decisions. You'd be better off distributing anything--anything--else than dynamically-linked binaries. Jar files, statically-linked binaries, C source code, Python source code, Brainfuck code ffs... The "./configure and recompile from source" model of Linux is just too deeply entrenched. Pity.
evasb 4y ago
In my opinion, Valve+distros should fork glibc and do a glibc distribution that focuses in absolute stability. Didn't glibc devs said that distros have the freedom to choose what to maintain to not break their applications? This would be just a collaboration between the distros to maintain the stability.
pabs3 4y ago
Heh, I've just been debugging an issue that is triggered by the upgrade to glibc 2.29 (Debian bullseye era). https://github.com/pst-format/libpst/issues/7 https://github.com/pst-format/libpst/issues/7
ajuc 4y ago
I wrote a game for my masters thesis in 2008. I wrote it in C++ and targeted Linux. Recently i tried to run it and not only binaries didn't work (that's a given), but even making it compile was a struggle cause I used some gui libraries that were abandoned and there was no version working with modern libc. It was easier to port the game to windows than to make it compile on Linux again...
IYasha 4y ago
I laugh so hard... with tears! But, to be fair, Unreal 2004 still works almost perfectly on not too obsolete Ubuntu. Or did I have to do some glibc trickery?.. Can't remember for sure.
ece 4y ago
If anything, not breaking things makes you more careful about what you put in. I feel like that's not a bad rule to go by.

456 points by pantalaimon 4y ago

Related: Win32 is the stable Linux userland ABI (and the consequences): https://news.ycombinator.com/item?id=30490570 https://news.ycombinator.com/item?id=30490570 336 points, 242 comments, 5 months ago

wmf 4y ago

I assume Flatpak fixes this by locking your app to a compatible version of glibc.

layer8 4y ago
…also locking in any security vulnerabilities.
- rtontic 4y ago
  I mean, we are talking about videogames here.
  - formerly_proven 4y ago
    Multiplayer is a thing, where both crashing servers and also attacking other clients (even in non-p2p titles) is not that uncommon. Many titles don't permit community servers any more, of course.
  - maeln 4y ago
    Wasn't it Elden Ring or another From Software game that had a RCE ? This article talks about it : https://wccftech.com/dark-souls-rce-exploit-fixed-elden-ring/ https://wccftech.com/dark-souls-rce-exploit-fixed-elden-ring... A lot of games have multiplayer functionalities these days. That make them a potential target for RCE and related vulnerabilities. Granted, if you don't play video game as root, the impact should be limited, but it is still something to be aware of.
    - Beltalowda 4y ago
      Skimming over the details, that seems like a bunch of bugs in the game code. I don't think dynamic linking would help there.
- deleted 4y ago
  [deleted]
AshamedCaptain 4y ago
Static linking -- always the ready-to-go response for anything ABI-related. But does it really help? What use is a statically linked glibc+Xlib when your desktop no longer sets resolv.conf in the usual place and no longer speaks the X11 protocol (perhaps in the name of security) ?
- gabereiser 4y ago
  Even statically linked, the problems you just described are valid. The issue is x11 isn’t holding up and no one wants to change. Wayland was that promise of change but has taken 15+ years to develop (and still developing). Linux desktop is a distro concern now. Not an ecosystem concern. It’s long left the realm of an linux concern when MacOS went free (with paid hardware of course) and Windows was giving away free windows 10 licenses to anyone who asked for it. Deepin desktop and elementary are on the top of my list for elegance and ease of use. Apps and games need a solid ABI and this back and forth between gnome and kde doesn’t help. With so many different wm’s and desktop environments, x11 is still the only method of getting a window with an opengl context in any kind of standard way. Wayland, X12, whatever it is, we need a universal ABI for window dressing for Linux to be taken seriously on the desktop.
  - pengaru 4y ago
    > Linux desktop is a distro concern now. Not an ecosystem concern. It’s long left the realm of an linux concern when MacOS went free (with paid hardware of course) and Windows was giving away free windows 10 licenses to anyone who asked for it. You seem fixated on the Free Beer misinterpretation of Free Software.
    - gabereiser 4y ago
      No, but it sounds that way I guess. It’s more about where the developer en-masse focus lays. Few developers are interested in the desktop for Linux because they are supported on windows or Mac and during the time period I mentioned, it didn’t cost them anything monetary. There were indications that windows and Linux May converge. Instead we got WSL2. A lot of times we decide to develop something because of the pain of using the other thing. Sometimes we develop something as a “me too”. Sometimes we develop something that is just better. Sometimes, it’s worse. My point is the fight for a foothold in Linux desktop looked promising for a bit. SteamOS looked like it was gaining, steam… The reality is there are complexities at that level that people don’t want to deal with and we all have opinions on how it should work, should look, and should be called. Red Hat (former RH’er myself) should take this on and really standardize something outside of core and server land. And no, it should not be Gnome.
spicybright 4y ago
If you're never going to update your program and don't care about another heartbleed effecting your product and users, then sure.
- lanstin 4y ago
  Would you rather run a statically linked go or rust binary with the native crypto implementations of ssl or a dynamically linked OpenSSL that is easier to upgrade? (Honest question)
mananaysiempre 4y ago
Surprisingly, that seems correct—a Flatpak bundle includes a glibc; though that only leaves me with more questions: - On one hand, only one version of ld.so can exist in a single address space (duh). Glibc requires carnal knowledge of ld.so, thus only one version of glibc can exist in a single address space. In a Flatpak you have (?) to assume the system glibc is incompatible with the bundled one either way, thus you can’t assume you can load host libraries. - On the other hand, a number of system services on linux-gnu depend on loading host libraries. Even if we ignore NSS (or exile it into a separate server process as it should have been in the first place), that leaves accelerated graphics: whether you use Wayland or X, ultimately an accelerated graphics driver amounts to a change in libGL and libEGL / libGLX (directly or through some sort of dispatch mechanism). These libraries require carnal knowledge of the kernel-space driver, thus emphatically cannot be bundled; but the previous point means that you can’t load them from the host system either. - Modern toolkits basically live on accelerated graphics. Flatpak was created to distribute graphical applications built on modern toolkits. - ... Wait, what?
- anon291 4y ago
  There is no 'system' glibc. Linux doesn't care. The Linux kernel loads up the ELF interpreter specified in the ELF file based on the existing file namespace. If that ELF interpreter is the system one, then linux will likely remap it from existing page cache. If it's something else, linux will load it and then it will parse the remaining ELF sections. Linux kernel is incredibly stable ABI-wise. You can have any number of dynamic linkers happily co-existing on the machine. With Linux-based operating systems like NixOS, this is a normal day-to-day thing. The kernel doesn't care. > These libraries require carnal knowledge of the kernel-space driver, thus emphatically cannot be bundled; but the previous point means that you can’t load them from the system either. No they don't. The Linux kernel ABI doesn't really ever break. Any open-source driver shouldn't require any knowledge of internals from user-space. User-space may use an older version of the API, but it will still work. > whether you use Wayland or X, ultimately an accelerated graphics driver amounts to a change in libGL and libEGL / libGLX (directly or through some sort of dispatch mechanism) OpenGL is even more straightforwards because it is typically consumed as a dynamically loaded API, thus as long as the symbols match, it's fairly straightforwards to replace the system libGL.

dvfjsdhgfv 4y ago

This is by design, and everybody should be aware of that. I don't know about glibc, but as far as the kernel is concerned, Linus has never guaranteed ABI stability. API, on the other hand, is extremely stable, and there are good reasons for that. In Windows, software is normally distributed in a binary form, so having ABI compatibility is a must.

josephcsible 4y ago
The kernel absolutely does guarantee a stable userspace ABI. This post is entirely about other userspace libraries.
deleted 4y ago
[deleted]
wmf 4y ago
The Linux kernel maintains userspace API/ABI compatibility forever but inside the kernel (e.g. modules) there is no stable API/ABI.
mort96 4y ago
Uh, the kernel ABI is extremely stable. You could take a binary that's statically compiled in the 90s and run it on the latest release of the kernel. "Don't break userspace" is Linus's whole schtick, and he's taking about in terms of ABI when he says that. This is about the ABIs of userspace "system-level" libraries, glibc in particular.
- deleted 4y ago
  [deleted]

iforgotpassword 4y ago

Agree. Had a few games on Steam crap out with the native version, forced it to use proton with the Windows version, everything worked flawlessly. Developers natively porting to linux seem to be wasting their time. Funnily enough with wine we kinda recreated the model of modern windows, where Win32 is a personality on top of the NTAPI which then interfaces with the kernel. Wine sits between the application and the zoo of libraries including libc that change all the time.

dleslie 4y ago
FWIW, targeting proton is likely the best platform target for future Windows compatibility too.
Aachen 4y ago
> Developers natively porting to linux seem to be wasting their time. Factorio runs so much better than any of this emulationware, it's one of the reasons I love the game so much and gifted licenses for friends using Windows. Some software claims to support Linux but uses some tricks to avoid recompiling and it's always noticeable, either as lag, as UI quirks, or some features plainly don't work because all the testers were windows users. Emulating as a quick workaround is all fair game but don't ship that as a Linux release. I appreciate native software (so long as it's not java), and I'm also interested in buying your game if you advertise it as compatible with WINE (then I'm confident that it'll work okay and you're interested in fixing bugs under emulation), just don't mislead and pretend and then use a compatibility layer.
- jbverschoor 4y ago
  Wine Is Not an Emulator
  - bombcar 4y ago
    I believe it now actually is again, or was, or something. It's a question when dealing with Win16 and now Win32 (Windows-on-Windows).
  - 4y ago

guardiangod 4y ago

I can run a Windows 95 app on Windows 10 and it has a reasonable chance of success. Should Linux (userland) strive for that? Or is Year of the Linux Desktop only covers things compiled in the last 10 years?

deleted 4y ago
[deleted]
ivraatiems 4y ago
It's what the kernel strives for. They're remarkably consistent in their refrain of "we never break userspace." I think it would be reasonable for glibc and similar to have similar goals, but I also don't run those projects and don't know what the competing interests are.
- pantalaimon 4y ago
  > I think it would be reasonable for glibc and similar to have similar goals I don’t think userspace ever had this goal. The current consensus appears to be containers, as storage is cheap and maintaining backwards compatibility is expensive
  - lpghatguy 4y ago
    Containers are not a great solution for programs that need graphics drivers (games) or quick startup times (command line tools). I've been wrestling with glibc versioning issues lately and it has been incredibly painful. All of my projects are either games or CLI tools for games, which means that "just use a snap/flatpak/appimage" is not a solution.
    - bityard 4y ago
      There's no reason launching a container _must_ be slow. Under the hood, launching a containerized process is just making a few kernel syscalls that have very little overhead. You might be thinking of docker, which is slow because it's intended for certain use cases and brings a lot of baggage with it in the name of backward compatibility from a time when the Linux container ecosystem was much less mature. There are several projects working on fast, slim containers (and even VMs) with completely negligible startup times. I don't know what is holding back container/VM access to graphics hardware, but it can't be insurmountable if the cloud providers are doing it.

amadeuspagel 4y ago

Stable APIs on linux: https://developer.mozilla.org/en-US/docs/Web/API https://developer.mozilla.org/en-US/docs/Web/API

cowtools 4y ago
I used to disagree with this browser-as-OS mentality, but seeing as it's sandboxed and supports webGL, wasm, WebRTC, etc. I find it pretty convienient (if I'm forced to run zoom for example, I can just keep it in the browser). Just as long as website/application vendors test their stuff across different browsers.

myself248 4y ago

like Excel is more stable than Windows itself, you can open a spreadsheet from the win16 days and it'll just work....

croes 4y ago
Nope, had multiple that did even work after the latest update
mananaysiempre 4y ago
Personal experience: Office 2021 and Office 97 do not paginate a DOC file created (by Microsoft employees) in Office 97 the same way, so the table of contents ends up different.

captainmuon 4y ago

The ABI of the Linux kernel seems reasonably stable. Somebody should write a new dynamic linker that lets you easily have multiple versions of libraries - even libc - around. Then its just like windows where you have to install some weird MSVC runtimes to play old games.

anon291 4y ago
Just use nix.
mort96 4y ago
Or, GNU could just recognise their extremely central position in the GNU/Linux ecosystem and just not. break. everything. all. the. time. It honestly really shouldn't be this hard, but GNU seems to have an intense aversion towards stability. Maybe moving to LLVM's replacements will be the long-term solution. GNU is certainly positioning itself to become more and more irrelevant with time, seemingly intentionally.
- mike_hearn 4y ago
  The issue is more subtle than that. The GNU and glibc people believe that they provide a very high level of backwards compatibility. They don't have an aversion towards stability and in fact, go far beyond most libraries by e.g. providing old versions of symbols. The issue here is actually that app compatibility is something that's hard to do purely via theory. The GNU guys do compatibility on a per function level by looking at a change, and saying "this is a technical ABI break so we will version a symbol". This is not what it takes to keep apps working. What it actually takes is what the commercial OS vendors do (or used to do): have large libraries of important apps that they drive through a mix of automated and manual testing to discover quickly when they broke something. And then if they broke important apps they roll the change back or find a workaround regardless of whether it's an incompatible change in theory or not, because it is in practice. Linux is really hurt here by the total lack of any unit testing or UI scripting standards. It'd be very hard to mass test software on the scale needed to find regressions. And, the Linux/GNU world never had a commercial "customer is always right" culture on this topic. As can be seen from the threads, the typical response to being told an app broke is to blame the app developers, rather than fix the problem. Actual users don't count for much. It's probably inevitable in any system that isn't driven by a profit motive.

skyde 4y ago

what about the web browser. Isn't that also a stable ABI ? Or its not a "Binary interface" because it only support Javascript? What about web assembly ?

0x457 4y ago
If web browsers had any kind of stable interface we wouldn't have: https://caniuse.com/ https://caniuse.com/, polyfils, vendor CSS prefixes and the rest of crutches. WASM isn't binary. But that's all irrelevant when we talk about ABI. ABI is specifically binary interface between binary modules. For example: my hello_world binary and glibc or glibc and linux kernel or some binary and libsqlite3.

_hudj 4y ago

This is a long standing question and has nothing to do with Linux or windows. It's a design philosophy. Yes the win32 abi is very stable. It's also a very inflexible piece of code and it drags it's 20 year old context around with it. If you want to add something to it you are going to work and work hard to ensure that your feature plays nicely with 20 year old code and if what you want to do is ambitious...say refactor it to improve it's performance...you are eternally fighting a large chunk of the codebase implementation that can't be changed. Linux isn't about that and it never has been, it's about making the best monolithic kernel possible with high level Unix concepts that don't always have to have faithful implementations. The upside here is that you can build large and ambitious features that refactor large parts of how core components work if you like, but you might only compile those features against a somewhat recent glib. This is a choice. You the developer can link whatever version you want. If you want to build in support for glib then just use features that only existed 10 years ago and you'll get similar compatibility to win32. If not then you are free to explore new features and performance you don't have to implement or track provided you consider it a sensible use cases that someone has to be running a somewhat recent version of glib. The pros and cons are up for you to decide but it's not as simple as saying that windows is better because it's focus is backwards compatibility. There is an ocean of contexts hidden behind that seemingly magical backwards support...

karamanolev 4y ago
According to Wikipedia, "Win32 is the 32-bit application programming interface (API) for versions of Windows from 95 onwards.". Also from there "The initial design and planning of Windows 95 can be traced back to around March 1992" and it was released in '95. So arguably, the design decisions are closer to 30 years old than 20 :)
- deleted 4y ago
  [deleted]
- jdsully 4y ago
  The main structure is from win16, although adding support for paging and process isolation was a pretty big improvement in win32. IMO its held up extremely well considering its 40 years old.

jwilk 4y ago

OK, glibc ABI stability may not be perfect, but is there any evidence that Wine is any better? That sounds implausible to me.

modeless 4y ago
The difference is if Wine breaks an application that works on Windows, it's considered a bug that should be fixed, regardless of why.

blibble 4y ago

glibc != Linux a better analogy would be targeting the latest version of MSVCRT that happens to be installed on your system (instead of bundling it) ... also which mostly works but sometimes breaks

int_19h 4y ago
Windows has switched from app-redistributed MSVC runtimes to OS-distributed "universal CRT" since Windows 10 (2015). Unlike MSVCRT, uCRT is ABI-stable.
itvision 4y ago
Nearly 99% of Linux software is linked to glibc. What the f are you talking about? This is not MSVCRT by a long shot.

CameronNemo 4y ago

Proprietary devs should use static linking (with musl) or chroots/containers. What makes the author think they are the target audience of glibc?

calvin_ 4y ago
Have fun with libGL!
- CameronNemo 4y ago
  I hadn't thought of that... Flatpaks let you use specific mesa versions, though.
davikr 4y ago
Thanks, but I think I'll stick with Windows: their target audience is famously everyone and for an unlimited time.

hu3 4y ago

Sidenote. I remember when Warcraft 3 ran better in Wine+Debian than in Windows. Athlon II x2 CPU and Nvidia Geforce 6600 GT with a wooping 256MB of VRAM. That was one hot machine. Poor coolers.

benibela 4y ago
I tried to run WoW and Starcraft 2 with Wine, and it did not install/run

ddevault 4y ago

The kernel <> userspace API is stable, famously so. Dynamic linking to glibc is a terrible idea, statically link your binaries against musl and they'll still work in 100 years.

nibbleshifter 4y ago
Trying to statically link with glibc throws specific warnings that certain calls aren't portable. With musl? No such problem. Fuck even uclibc is more portable than glibc and its a dead project afaik
- SubjectToChange 4y ago
  > With musl? No such problem. Does musl even implement the functionality glibc was warning about?
sylware 4y ago
game binaries need to dynamically load system libs. A statically linked binary would have to include a full ELF loader.

oppositelock 4y ago

Many moons ago, one of the things I did was to port the Windows version of Google Earth to both Mac and Linux. I did the mac first, which was onerous, because of all the work involved in abstracting away system specific API's, but once that was done, I thought Linux would be a lesser task, and we hired a great linux guy to help with that. Turns out, while getting it running on linux was totally doable, getting it distributed was a completely different story. Due to IP reasons, this can't ship as code, so we need to ship binaries. How do you do that? Do you maintain a few separate versions for a few popular distributions? Do you target the Linux Standard Base? The first approach is a lot of work, and suffers from breakages from time to time, and you alienate users not on your list of supported distros. The second version, using LSB, was worse, as they specify ancient libraries and things like OpenGL aren't handled properly. End result; management canned the Linux version because too much ongoing support work was required, and no matter what you did, you got hate mail from Gentoo users.

frozenport 4y ago
Wait. Google Earth has always been available for Linux? https://www.google.com/earth/versions/ https://www.google.com/earth/versions/
- cyral 4y ago
  They probably mean the old desktop one that has been re-branded to "Google Earth Pro". The UI looks a decade old but it's still useful for doing more advanced things like taking measurements.
  - oppositelock 4y ago
    Yup. That's the one. If it works for you, great, but it crashes on symbol issues for many people.
    - freedomben 4y ago
      FWIW, I use Google Earth Pro on Fedora quite often, and I'm deeply appreciative of the work it took to make that such a simple and enjoyable experience. I hate that the vocal and tiny minority of linux users who are never satisfied are the ones that most people hear from.

bjourne 4y ago

Glibc is not Linux, and they have different backwards compatibility policies, but everyone should still read Linus Torvalds' classic 2012 email about ABI compability: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75 Teaser: It begins with "Mauro, SHUT THE FUCK UP!"

DiggyJohnson 4y ago
Really appreciate your stuff Bjorn, this link always brings a smile to my (too young to be cynical) face.
- bjourne 4y ago
  Thanks!
efficax 4y ago
man it's always a trip to see how much of a jerk torvalds could be, even if exasperation is warranted in this context (i have no idea), by god, this is not how you build consensus or a high functioning team
- moomin 4y ago
  People often think that because jerks work at successful companies, you need to be a jerk to be successful. It’s more the other way around: a successful firm can carry many people who don’t add value, like parasites. Guarantee you Linus wasn’t this bad in the 90s.
  - tasuki 4y ago
    I think he's not this bad these days? He issued some public apologies for his behaviour. He gave us Linux and Git. Yes, he used to be an asshole, but he still did way more for the betterment of humanity than most people.
    - freedomben 4y ago

deleted 4y ago

[deleted]

adolph 4y ago

Maybe a counterpoint is "x86-64 Linux ABI Makes a Pretty Good Lingua Franca" [0] from αcτµαlly pδrταblε εxεcµταblε of Aug 2022. 0. https://justine.lol/ape.html https://justine.lol/ape.html

ChikkaChiChi 4y ago

Without getting into spoilers, I'll say that playing "Inscryption" really got me thinking about Docker's continued development could help consumers in the gaming industry. I would love to see game being virtualized and isolated from the default userspace with passthrough for graphics and input to mitigate latency concerns. Abandonware could become a relic of the past! Being able to play what you buy on any device you have access to would be amazing. I won't hold my breath, though. The industry pretty loudly rejected Nvidia's attempt to let us play games on their cloud without having to buy them all again. Todd needs the ability to sell us 15 versions of Skyrim to buy another house.

rstat1 4y ago
For games on Steam there's the Steam Linux Runtime which can run games on Linux in a specialized container to isolate them from these sort of bugs. There's also a variant of this container that contains a forked version of Wine for running Windows games as well.
- mort96 4y ago
  Doesn't the Steam Linux Runtime have a problem in the other direction though? Games are using libraries which are so old that they have bugs which are long since fixed or don't work properly in modern contexts. Apparently a lot of issues with Steam + Wayland comes from the ancient libraries in the Steam Linux Runtime from what I have been able to find out from googling issues I've experienced under Wayland.
disintegore 4y ago
> Abandonware could become a relic of the past! That would eat into some business models though, like Nintendo's quadruple-dipping with its virtual consoles
- matheusmoreira 4y ago
  Good. All those games should be in the public domain anyway. It's been 30-40 years, Nintendo has been more than adequately compensated.

phendrenad2 4y ago

One way to achieve similar results on Linux might be for the Linux kernel team to start taking control of core libraries like x11 and wayland, and to extend the same "don't break userspace" philosophy to them also. That isn't going to happen, but I can dream!

rodgerd 4y ago
There was a period where a Linux libc was maintained, but it was long-ago deprecated in favour of glibc. Perhaps that was a mistake.
yjftsjthsd-h 4y ago
My understanding is that the Linux devs like only having "Linux" only be the kernel; if they wanted to run things BSD-style (whole base system developed as a single unit) I assume they would have done that by now (it's been almost 30 years).
matheusmoreira 4y ago
I'm not sure about taking over the entire GUI ecosystem but I certainly do want more functionality in the kernel instead of user space precisely because of how stable and universal the kernel is. I want system calls, not C libraries.

kazinator 4y ago

"DT_HASH is not part of the ABI" is like saying "DNS is not part of the Internet".

franga2000 4y ago

I recently experienced this in a critical situation. Long story short, something went very wrong during a big live event and I needed some tool to fix it. I downloaded the 2 year old Linux binary, but it didn't run. I tried running it from an old Ubuntu Docker container, but there were dependencies missing and repos were long gone. Luckily it was open source, but compiling was taking ages. So in a case of "no way this works, but it doesn't hurt to try" I downloaded the Windows executable and ran it under Wine. Worked like a charm and everything was fixed before GCC was done compiling (I have a slow laptop).

nicce 4y ago
I have personally used containers for this reason to set my gaming environment. If something breaks, all I need to do is to run older image and everything works.

knorker 4y ago

Yeah Linus's "we don't break user space" is a joke. Great, the kernel syscalls API is stable. Who cares, if you can't run a 7 year old binary because everything from vdso to libc to libstc++ to ld-linux.so is incompatible. Good luck. No it's not just a matter of LD_LIBRARY_PATH and shipping a binary with a copy. That only helps with third party libs, and only if vdso and ld-linux is compatible. My 28 year experience running Linux is that it's API (source code) unbroken, but absolutely not ABI.

MichaelCollins 4y ago
Linus does provide a stable ABI with Linux, it's GNU who drops the ball and doesn't. You're criticizing Linus for something he has nothing to do with. What's the point in that?
- phendrenad2 4y ago
  Linus chose to only care about the kernel. So there's possibly some fault there.
  - sph 4y ago
    So it's Linus' fault he didn't just write the kernel but should also decided to being responsible for the entire userspace as well? What kind of argument is that.
    - zbird 4y ago
      He should have run for president.
    - phendrenad2 4y ago
      By that logic nothing is anyone's fault. "I did exactly what I meant to do, nothing more, nothing less. Therefore you cannot say anything negative about it. Have a nice day." I feel like there's a Peanuts comic like this: "No matter what happens any place or any time in the world, this absolves me from all blame!"

userbinator 4y ago

The change that caused the break would be equivalent to the PE file format changing in an incompatible way on Windows, to give an idea of how severe it is.

Animats 4y ago

Notes: "EAC" is Easy Anti Cheat, sold by Epic.[1] Not EarthCoin. "EOS", in this context, is probably Epic Online Services, not one of the 103 other known uses of that acronym.[2] Here's a list of the games using those features.[3] So, many of these issues are for people building games with Epic's Unreal Engine on Linux. The last time I tried UE5, after the three hour build, it complained I had an NVidia driver it didn't like. I don't use UE5, but I've tried it out of curiosity. They do support Linux, but, as is typical, it's not the first platform they get working. Epic does have support forums, and if this is some Epic problem encountered by a developer, it can probably be fixed or worked round. Wine is impressive. It's amazing that they can run full 3D games effectively. Mostly. Getting Wine bugs fixed is somewhat difficult. The Wine people want bugs reported against the current dev version. Wine isn't set up to support multiple installed versions of itself. There's a thing called PlayOnLinux which does Wine version switching, but the Wine team does not accept bug reports if that's in use.[4] So you may need a spare machine with the dev version of Wine for bug reproduction. [1] https://www.easy.ac/en-us/ https://www.easy.ac/en-us/ [2] https://acronyms.thefreedictionary.com/EOS https://acronyms.thefreedictionary.com/EOS [3] https://steamcommunity.com/groups/EpicGamesSucks/discussions/0/4149469212598904161/ https://steamcommunity.com/groups/EpicGamesSucks/discussions... [4] https://wiki.winehq.org/Bugs https://wiki.winehq.org/Bugs

Hello71 4y ago
> Wine isn't set up to support multiple installed versions of itself. huh? the official wine packages for ubuntu, debian, and i believe fedora provide separate wine-devel and wine-staging packages, which can be installed in parallel with each other and with distro packages. in fact, debian (and ubuntu) as well as arch provide separate wine and wine-staging packages as part of the distro itself, no separate repo required. wine has no special support for relocated installations, but no more or less so than any large Unix program; you can install as many copies as you want, but they must be compiled with different --prefixes, and you cannot use different versions of wine simultaneously with the same WINEPREFIX.
- Animats 4y ago
  Oh, that's good to know. Thanks.

littlestymaar 4y ago

At this point I'm pretty convinced that no-one at Microsoft ever did a better job in keeping people on Windows than what the maintainers of glibc are doing …

CoolCold 4y ago
Well, the WSL team did a lot I think (including new Terminal). WSL, WSL2, WSLg, WSA - I almost never use full Linux VMs now, my pretty simple needs are covered with it.

mid-kid 4y ago

deleted 4y ago
[deleted]

Kukumber 4y ago

It's not, and it is super sad to hear people advocating for such horrible idea Linux being infested by windows is the beginning of its death to me, what a tragedy A well deserved death after the system-d drama anyways

phendrenad2 4y ago
Why is it a horrible idea?

justin66 4y ago

I was going to make a joke about a.out support (and all the crazy stuff that enables, like old SCO binaries) but apparently a.out was removed in May as an option in the Linux kernel. https://lwn.net/Articles/895969/ https://lwn.net/Articles/895969/ At least we still have WINE.

codebolt 4y ago

Coincidentally, Win32 is also the only stable API on Windows. WinForms and WPF are still half-broken on .NET 5+, WinRT is out, basically any other desktop development framework since the Win32 era that is older than a couple of years is deprecated. Microsoft is famous for introducing new frameworks and deprecating them a few years later. Win32 is the only exception I can think of.

ahtihn 4y ago
Since when is .NET 5+ part of Windows?
- markmark 4y ago
  And .NET 4.8 is still installed by default on Windows 11 and will presumably happily run your WPF app if you target it.
  - solarkraft 4y ago
    .NET 4.8 might be one of those things they won't be able to get rid of.
    - int_19h 4y ago
      Windows 11 still ships msvbvm60.dll - that's the runtime for Visual Basic 6, released back in 1998. And it is officially supported: https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-basic-6/visual-basic-6-support-policy https://docs.microsoft.com/en-us/previous-versions/visualstu...
- codebolt 4y ago
  Since MS decided to deprecate .NET Framework, making .NET 5+ the recommended basis for C# desktop development going forward. Yes you will still be able to run your old apps for many decades still, but you can never move to a newer version of the C# language and maintaining them is going to be an increasing pain as the years go by. I've already been down this road with VB6.

beebeepka 4y ago

Not news. In fact, wine/proton really is the preferred wayof doing things. Valve saw the light years but they weren't the first. Even Carmack has been saying it before the whole gaming on Linux thing became viable.

cosmin800 4y ago

oh, no, not again: kids working for big tech constantly, but randomly, deprecating, removing and breaking apis/abis/features in the kernel/libraries/everywhere. I honestly belive that all relationships between big tech companies and opensource are toxic and follow the microsoft principle of the embrace, extend, and extinguish.

sylware 4y ago

The glibc libs should be ELF clean. Namely, a pure and simple ELF64 dynamic exe, should be able to "libdl"/dynamically load any glibc lib. It is maybe fixed and possible in latest glibc. The tricky part is the sysv ABI for TLS-ized system variables: __tls_get_addr(). For instance errno. It seems the pure and simple ELF64 dynamic exe would have to parse the ELF headers of the dynamically loaded shared libs in order to get the "offsets" of the variables. Never actually got into this for good though. And in the game realm, you have c++ games (I have an extremely negative opinion about this language), and the static libstdc++ from gcc does not "libdl"/dynamically load what it requires from the glibc, and it seems even worse, namely it would depends on glibc internal symbols.

sylware 4y ago
Then, if I got it right for TLS-ized variables, dlsym should do the trick. Namely, dlsym will return the address of a variable for the calling thread. Then this pointer can be cached the way the thread wants. On x86_64, it can "optimize" the dlsym calls by reusing the same address for all threads, namely 1 call is enough. Now the real pain is this static libstdc++ not libdl-ing anything, or worse expecting internal glibc symbols (c++ ...)

z3t4 4y ago

Linux has a more stable windows ABI then windows itself. If a game stops working on windows it will likely still work with wine on Linux.

zzo38computer 4y ago

I suppose that Win32 can be helpful if you want to make programs that run on both Windows and on Linux (and also ReactOS, I suppose), but might not work as well for programs with Linux specific capabilities. (Also, I have problems to install Wine, due to package manager conflicts.) There are other possibilities, such as .NET (although some comments in here says it is less stable, some says it works), which also can be used on Windows and on Linux. There is also HTML, which has too many of its own problems and I do not know how stable HTML really is, either. And then, also Java. Or, you can write a program for DOS, NES/Famicom, or something else, and can be emulated in many systems. (A program written for NES/Famicom might well run better on many systems than a native code does, especially if you do not do something too tricky in the code (in which case some implementations might not be compatible).) Of course also the different ways they have different advantages and disadvantages, with compatibility, efficiency, capability, and other features.

bartwe 4y ago

As a gamedev that tried shipping to linux, we really need some standardized minimized image to target with ancient glibc and such, and some guarantees that if it runs on the image that it runs on future linux versions.

sph 4y ago
Just target Flatpak. You got a standardised runtime, and glibc is included in the container. If it works on your machine, it'll work on my machine, since the only difference will be the kernel and Linus is pretty adamant in retaining compatibility at the syscall level.

titzer 4y ago

Dynamically-linked userspace C is a smouldering trash heap of bad decisions. You'd be better off distributing anything--anything--else than dynamically-linked binaries. Jar files, statically-linked binaries, C source code, Python source code, Brainfuck code ffs... The "./configure and recompile from source" model of Linux is just too deeply entrenched. Pity.

evasb 4y ago

In my opinion, Valve+distros should fork glibc and do a glibc distribution that focuses in absolute stability. Didn't glibc devs said that distros have the freedom to choose what to maintain to not break their applications? This would be just a collaboration between the distros to maintain the stability.

pabs3 4y ago

Heh, I've just been debugging an issue that is triggered by the upgrade to glibc 2.29 (Debian bullseye era). https://github.com/pst-format/libpst/issues/7 https://github.com/pst-format/libpst/issues/7

ajuc 4y ago

I wrote a game for my masters thesis in 2008. I wrote it in C++ and targeted Linux. Recently i tried to run it and not only binaries didn't work (that's a given), but even making it compile was a struggle cause I used some gui libraries that were abandoned and there was no version working with modern libc. It was easier to port the game to windows than to make it compile on Linux again...

IYasha 4y ago

I laugh so hard... with tears! But, to be fair, Unreal 2004 still works almost perfectly on not too obsolete Ubuntu. Or did I have to do some glibc trickery?.. Can't remember for sure.

ece 4y ago

If anything, not breaking things makes you more careful about what you put in. I feel like that's not a bad rule to go by.