[HN Gopher] Win32 Is the Only Stable ABI on Linux
___________________________________________________________________
Win32 Is the Only Stable ABI on Linux
Author : pantalaimon
Score : 329 points
Date : 2022-08-15 16:19 UTC (6 hours ago)
(HTM) web link (blog.hiler.eu)
(TXT) w3m dump (blog.hiler.eu)
| cosmiccatnap wrote:
| 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 wrote:
| 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 :)
| jdsully wrote:
| 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.
| [deleted]
| guardiangod wrote:
| 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?
| CommanderData wrote:
| Just try changing your hosts or nameservers across different
| versions of Ubuntu Server.
|
| The fragmentation is such a mess even between 1.x major
| versions. Their own documentation is broken or non existant.
| [deleted]
| SubjectToChange wrote:
| > Should Linux (userland) strive for that?
|
| The linux "userland" includes thousands of independent
| projects. You'll need to be more specific.
|
| > Or is Year of the Linux Desktop only covers things compiled
| in the last 10 years?
|
| If you want ABI compatibility then you'll have to pay, it's
| that simple. Expecting anything more is flat out unreasonable.
| cbarrick wrote:
| > The linux "userland" includes thousands of independent
| projects. You'll need to be more specific.
|
| I think it's pretty clear from the context.
|
| The core GNU userland: glibc, coreutils, gcc, etc.
| Woodi wrote:
| Here is some game from '93. Compile it yourself (with some
| trivial changes).
|
| https://github.com/DikuMUDOmnibus/ROM
|
| Trivial !
|
| But if you still have some obiections then let's wait ~27 years
| and then talk about games developed _on Linux_ / *nix.
| BugsJustFindMe wrote:
| YSK, this code will likely fail in weird ways on platforms
| with default unsigned char like ARM because it makes the
| classic mistake of assuming that the getc return value is
| compatible with char type despite getc returning int and not
| char. EOF is -1, and assigning a char on ARM changes to 255
| so you'll read past the end of some buffers and then crash.
| Woodi wrote:
| Maybe there will be some problems on weird platforms. But
| if game is good some datails can be resolved. With bad
| games too ;) With source code, that is.
| erk__ wrote:
| Does that not miss the point of the above poster, this does
| not show that Linux have good binary compatibility, but that
| C is a very stable language. Would it run fine if you
| compiled it on a 27 year old compiler and then tried to run
| it on Linux is the question that should be asked if I am not
| mistaken.
| janef0421 wrote:
| Is it really a reasonable goal to want an operating system
| to run a 27 year old binary without any modification or
| compatibility tool? There does need to be some way to run
| such binaries, but doing that by making the kernel and all
| core ABIs stable over several decades would make evolving
| the operating system very difficult. I think it would be
| better to provide such compatibility via compatibility
| layers like wine and sandboxing in the style of flatpak.
| kibwen wrote:
| Which is also how Windows itself does it. Wanna run DOS
| or 16-bit binaries, you reach for an emulator.
| Woodi wrote:
| I think it shows that compiling is prefered way to go. So
| it's more like twisting around the point :)
|
| But what with old, binary only games ? Same as with old
| movies you want to watch and Hollywood prefers to not show
| anymore... They are super stupid IMO but maybe they have
| their reasons.
|
| And that DT_HASH lack can be easily patched if someone
| wants. And if GNU will keep to sabotage like this then
| there is time to move off GNU. Ah, right - noone wants to
| sponsor libc fork for few years... Maybe article is right
| about binaries after all ;)
| ivraatiems wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| bnieuwen wrote:
| The problem with containers and graphics drivers is that
| those drivers have an userspace component. This depends
| on the hardware (e.g. AMD vs. Intel vs. NVidia all have
| different drivers of course) and in the case of NVidia
| this has to be exactly matched with the kernel version
| (this is less of an issue with VMs, but then you need
| something like SR-IOV which isn't quite on consumer HW,
| or do dedicated PCIE throughput which doesn't allow the
| host to use it).
|
| So version management becomes a major pita, from shipping
| drivers too old to support the hardware to having a
| driver that doesn't match the kernel. In the cloud this
| is mostly solved by using VMs and hardware with SR-IOV.
| (and a fixed HW vendor so you know which set of drivers
| to include)
| vetinari wrote:
| > 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.
|
| Cloud providers have graphics hardware with SR-IOV
| support. It is exactly the kind of functionality, that
| the GPU vendors use for segmentation of their more
| expensive gear.
| hu3 wrote:
| 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 wrote:
| I tried to run WoW and Starcraft 2 with Wine, and it did not
| install/run
| userbinator wrote:
| 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.
| zzo38computer wrote:
| 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.
| littlestymaar wrote:
| 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 ...
| [deleted]
| sylware wrote:
| 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.
| adolph wrote:
| Maybe a counterpoint is "x86-64 Linux ABI Makes a Pretty Good
| Lingua Franca" [0] from actually pdrtable executable of Aug 2022.
|
| 0. https://justine.lol/ape.html
| knorker wrote:
| 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 wrote:
| 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?
| beebeepka wrote:
| 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.
| jwilk wrote:
| OK, glibc ABI stability may not be perfect, but is there any
| evidence that Wine is any better? That sounds implausible to me.
| modeless wrote:
| The difference is if Wine breaks an application that works on
| Windows, it's considered a bug that should be fixed, regardless
| of why.
| amadeuspagel wrote:
| Stable APIs on linux: https://developer.mozilla.org/en-
| US/docs/Web/API
| cowtools wrote:
| 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.
| ddevault wrote:
| 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 wrote:
| 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 wrote:
| > With musl? No such problem.
|
| Does musl even implement the functionality glibc was warning
| about?
| sylware wrote:
| game binaries need to dynamically load system libs. A
| statically linked binary would have to include a full ELF
| loader.
| kazinator wrote:
| "DT_HASH is not part of the ABI" is like saying "DNS is not part
| of the Internet".
| myself248 wrote:
| like Excel is more stable than Windows itself, you can open a
| spreadsheet from the win16 days and it'll just work....
| croes wrote:
| Nope, had multiple that did even work after the latest update
| mananaysiempre wrote:
| 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.
| oppositelock wrote:
| 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.
| perryh2 wrote:
| Are these Linux app distribution problems solved by using
| Flatpak?
| entropicdrifter wrote:
| Most of them are, yes. AppImage also solves this, but doesn't
| have as robust of an update/package management system
| akvadrako wrote:
| Yeah, their Linux guy obviously didn't know what he was
| doing.
| Shared404 wrote:
| Google Earth was released in 2001, and Flatpak in 2015.
| That's a 14 year window of time in which this wasn't an
| option.
| zsims wrote:
| Flatpack only came out in 2015
| jcelerier wrote:
| > Due to IP reasons, this can't ship as code, so we need to
| ship binaries. How do you do that?
|
| I build on an distro with an old enough glibc following this
| table:
| https://gist.github.com/wagenet/35adca1a032cec2999d47b6c40aa...
| (right now rockylinux:8 which is equivalent to centos:8 and
| good enough for debian stable and anything more recent than
| that ; last year I was still on centos:7), use dlopen as much
| as possible instead of "normal" linking and then it works on
| the more recent ones without issues.
| edflsafoiewq wrote:
| That's the trick. AppImage has a pretty good list of other
| best practices too: https://docs.appimage.org/reference/best-
| practices.html (applies even if you don't use AppImages).
| LawnGnome wrote:
| I worked on a product that shipped as a closed source binary
| .so (across four OSes and two architectures) for almost seven
| years, and that's exactly what we did too -- build on the
| oldest libc and kernel any of your supported distros (or OS
| versions) support, statically link as much as you can, and be
| defensive about _any_ runtime dependencies you have.
| curt15 wrote:
| >The first approach is a lot of work, and suffers from
| breakages from time to time
|
| Are there any distros that treat their public APIs as an
| unbreakable contract with developers like what MS does?
| dfabulich wrote:
| No, no one does. It's a lot more work to maintain all public
| APIs _and their behavior_ for all time; it can often prevent
| even fixing bugs, if some apps come to depend on the buggy
| behavior. Microsoft would occasionally add API parameters /
| options to let clients opt-in to bug fixes, or auto-detect
| known-popular apps and apply special bug-fix behaviors just
| for them.
|
| Even Apple doesn't make that level of "unbreakable contract"
| commitment. Apple will announce deprecations of APIs with two
| or three years of opportunity to fix them. If apps don't
| upgrade within the timeframe, they just stop working in newer
| versions of macOS.
| salmo wrote:
| RedHat claims or at least claimed that for EL. I think it's
| limited to within minor releases though, with majors being
| API.
|
| That's fine if you're OK relying on their packages and 3rd
| party "enterprise" software that's "certified" for the
| release. No one in their right mind would run RHEL on a
| desktop.
|
| The most annoying to me was that RHEL6 was still under
| support and had an ancient kernel that excluded running Go,
| GRaalVM, etc. static binaries. No epoll() IIRC.
|
| Often times you find yourself having to pull more and more
| libraries into a build. It all starts with wanting a current
| Python and before you know it you're bringing in your own
| OpenSSL.
|
| And they have no problem changing their system management
| software in patch releases. They've changed priority of
| config files too many times. But that's another rant for
| another day.
|
| This is a place where I wish some BSD won out. With all the
| chunks of the base userspace + kernel each moving in their
| own direction it's impossible to get out of this place. Then
| add in every permutation of those pieces from the distros.
|
| Multiple kernel versions * multiple libc implementations *
| multiple inits * ...
|
| I'd never try to make binary-only software for Linux. Dealing
| with packaging OSS is bad enough.
| bachmeier wrote:
| > The second version, using LSB, was worse, as they specify
| ancient libraries and things like OpenGL aren't handled
| properly.
|
| That was a shame. There was a lot of hope for LSB, but in the
| end the execution flopped. I don't know if it would have been
| possible to make it succeed.
| ok_dad wrote:
| Could you have used something like this:
|
| https://justine.lol/cosmopolitan/index.html
| naniwaduni wrote:
| I'd assume not without violating causality?
| pxc wrote:
| I took the question to be whether having something like
| that available, at the time, would have solved any of their
| problems with distributing Google Earth for Linux
| frozenport wrote:
| Wait. Google Earth has always been available for Linux?
| https://www.google.com/earth/versions/
| cyral wrote:
| 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 wrote:
| Yup. That's the one. If it works for you, great, but it
| crashes on symbol issues for many people.
| freedomben wrote:
| 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.
| scoopr wrote:
| FWIW, these days Valve tries to solve same problems with their
| steam runtime[0][1]. Still doesn't seem easy, but looks like
| almost workable solution.
|
| [0] https://github.com/ValveSoftware/steam-runtime
|
| [1]
| https://archive.fosdem.org/2020/schedule/event/containers_st...
| littlestymaar wrote:
| In that context, cannot the issue be sidestepped entirely by
| statically linking[1] everything you need?
|
| AFAIK the LGPL license even allows you to statically link
| glibc, as long as you provide a way for your user to load their
| own version of the libs by themself if that's what they want.
|
| [1]: (or _dlopen_ ing libs you bundle with your executable)
| jefftk wrote:
| _> 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?_
|
| When I worked on mod_pagespeed we went with the first approach,
| building an RPM and a DEB. As long as we built on the oldest
| still-supported CentOS and Ubuntu LTS, 32-bit and 64-bit, we
| found that our packages worked reliably on all RPM- and DEB-
| based distros. Building four packages was annoying, but we
| automated it.
|
| (We also distributed source, so it may be that it didn't work
| for some people and they instead built from source. But people
| would usually ask questions on https://groups.google.com/g/mod-
| pagespeed-discuss before resorting to that I don't think I saw
| this issue.)
| jrockway wrote:
| Was static linking not enough?
|
| I feel like the problem most people run into today is glibc vs.
| musl differences. They develop on Ubuntu, then think they can
| just copy their binaries into a "FROM alpine:latest" container,
| which doesn't actually work.
|
| It is possible, though, that whatever you statically link
| doesn't work with the running kernel, of course. And there are
| a lot of variants out there; every distribution has their own
| patch cadence. (A past example of this was the Go memory
| corruption issue from 1.13 on certain kernels. 1.14 added
| various checks for distribution + kernel version to warn people
| of the issue, and still got it wrong in several cases. Live on
| the bleeding edge, die on the bleeding edge.)
| rascul wrote:
| > I feel like the problem most people run into today is glibc
| vs. musl differences. They develop on Ubuntu, then think they
| can just copy their binaries into a "FROM alpine:latest"
| container, which doesn't actually work.
|
| Could it work with gcompat? Alpine has it in the community
| repo.
|
| https://git.adelielinux.org/adelie/gcompat
| naniwaduni wrote:
| gcompat is roughly the "yeah the plugs look the same so
| just stick the 120 V device into the 240 V socket" approach
| to libc compatibility.
| [deleted]
| notRobot wrote:
| Related:
|
| _Win32 is the stable Linux userland ABI (and the consequences):_
| https://news.ycombinator.com/item?id=30490570
|
| _336 points, 242 comments, 5 months ago_
| wmf wrote:
| I assume Flatpak fixes this by locking your app to a compatible
| version of glibc.
| spicybright wrote:
| If you're never going to update your program and don't care
| about another heartbleed effecting your product and users, then
| sure.
| lanstin wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kmeisthax wrote:
| > 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.
|
| [laughs in Nvidia]
| anon291 wrote:
| NVIDIA is not an open-source driver [1], and if you look
| in your dmesg logs, your kernel will complain about how
| it's tainted. That doesn't change the truth value about
| what I said about 'open-source' drivers.
|
| [1] I think this may have changed very very recently.
| mananaysiempre wrote:
| I know, I both run NixOS and have made syscalls from
| assembly :) Sorry, slipped a bit in my phrasing. In the
| argument above, instead of "the system glibc" read "the
| glibc targeted by the compiler used for the libGL that
| corresponds to the graphics driver loaded into the running
| kernel". (Unironically, the whole point of the list above
| was to avoid this sort of monster, but it seems I haven't
| managed it.)
| eklitzke wrote:
| This is all correct and I'd also add that ld.so doesn't
| need to have any special knowledge of glibc (or the kernel)
| in the first place. From the POV of ld.so, glibc is just
| another regular ELF shared object that uses the same
| features as everything else. There's nothing hard-coded in
| ld.so that loads libc.so.6 differently from anything else.
| And the only thing ld.so needs to know about the kernel is
| how to make a handful of system calls to open files and
| mmap things, and those system calls that have existed in
| Linux/Unix for eternity.
| mananaysiempre wrote:
| Needs to have? In an ideal world, probably not. Has and
| uses? Definitely. For one thing, they need to agree about
| userland ABI particulars like the arrangement of thread-
| local storage and so on, which have not stayed still
| since the System V days; but most importantly, as a
| practical matter, ld.so lives in the same source tree as
| glibc, exports unversioned symbols marked GLIBC_PRIVATE
| to it[1], and the contract between the two has always
| been considered private and unstable.
|
| [1] https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/
| Version...
| vetinari wrote:
| > 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.
|
| Yes
|
| > 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.
|
| Not exactly. You must assume that the host glibc is
| incompatible with the bundled one, that's right.
|
| But that does not mean you cannot load host libraries. You
| can load them (provided you got them somehow inside the
| container namespace, including their dependencies) using the
| linker inside the container.
|
| > hether 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).
|
| In Wayland, your app tells the server to render a bitmap. How
| you got that bitmap rendered is up to you.
|
| The optimization is that you send dma-buf handle instead of a
| bitmap. This is a kernel construct, not userspace driver one.
| This allows also cross-API app/compositor (i.e. Vulkan
| compositor and OpenGL app, or vice-versa). This also means
| you can use different version of the userspace driver with
| compositor than inside the container and they share the
| kernel driver.
|
| > 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.
|
| Yes and no; Intel and AMD user space drivers have to work
| with variety of kernel versions, so they cannot be too tight.
| Nvidia driver has tightly coupled user space and kernel
| space, but with the recent open-sourcing the kernel part,
| this will also change.
|
| > but the previous point means that you can't load them from
| the host system either.
|
| You actually can -- bind mount that single binary into the
| container. You will use binary from the host, but load it
| using ld.so from inside container.
| mananaysiempre wrote:
| >> 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.
|
| > Not exactly. You must assume that the host glibc is
| incompatible with the bundled one, that's right.
|
| > But that does not mean you cannot load host libraries.
| You can load them (provided you got them somehow inside the
| container namespace, including their dependencies) using
| the linker inside the container.
|
| I meant that the glibcs are potentially ABI-incompatible
| both ways, not just that they'll fight if you try to load
| both of them at once. Specifically, if the bundled (thus
| loaded) glibc is old, 2.U, and you try to load a host
| library wants a new frobnicate@GLIBC_2_V, V > U, you lose,
| right? I just don't see any way around it.
|
| >> 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.
|
| > Yes and no; Intel and AMD user space drivers have to work
| with variety of kernel versions, so they cannot be too
| tight. Nvidia driver has tightly coupled user space and
| kernel space, but with the recent open-sourcing the kernel
| part, this will also change.
|
| My impression of out-of-tree accelerated is mainly from
| fighting fglrx for the Radeon 9600 circa 2008, so extremely
| out of date. Intel is in-tree, so I'm willing to believe it
| has some degree of ABI stability, at least if an i915 blog
| post[1] is to be believed. Apparently AMD is also in-tree
| these days. Nvidia is binary-only, so the smart thing for
| them would probably be to build against an ancient Glibc so
| that it runs on everything.
|
| But suppose the year is 2025, and a shiny new GPU
| architecture has come out, so groundbreaking no driver
| today can even lay down command buffers for it. The vendor
| is kind enough to provide an open-source driver that gets
| into every distro, and the userspace portion compiled
| against a distro-current Glibc ends up referencing an
| AVX-512 memcpy@GLIBC_3000 (or something).
|
| I load a flatpak using Gtk3 GtkGLArea from 2015.
|
| What happens?
|
| [1] https://blog.ffwll.ch/2013/11/botching-up-ioctls.html
| captainmuon wrote:
| Does graphics on Linux work by loading the driver into your
| process? I assumed it works via writing a protocol to shared
| memory in case of Wayland, or over a socket (or some
| byzantine shared memory stuff that is only defined in the
| Xorg source) in case of X11.
|
| From my experience, if you have the kernel headers and have
| all the required options compiled into your kernel, then you
| can go really far back and build a modern glibc and Gtk+
| Stack, and use a modern application on an old system. If you
| do some tricks with Rpath, everything is self-contained. I
| think it should work the other way around, with old apps on a
| new kernel + display server, as well.
| bnieuwen wrote:
| So there are two parts to this: the app producing the image
| in the application window and then the windowing system
| combining multiple windows together to form the final image
| you see on screen.
|
| The former gets done in process (using e.g. GL/vulkan) and
| then that final image gets passed onto the windowing system
| which is a separate process and could run outside the
| container.
|
| As an aside, with accelerated graphics you mostly pass a
| file descriptor to the GPU memory containing the image,
| rather than mucking around with traditional shared memory.
| wmf wrote:
| _Does graphics on Linux work by loading the driver into
| your process?_
|
| Yes, it's called Direct Rendering (DRI) and it allows apps
| to drive GPUs with as little overhead as possible. The
| _output_ of the GPU goes into the shared memory so that the
| compositor can see it.
| layer8 wrote:
| ...also locking in any security vulnerabilities.
| rtontic wrote:
| I mean, we are talking about videogames here.
| formerly_proven wrote:
| 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 wrote:
| 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...
|
| 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 wrote:
| 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]
| AshamedCaptain wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| cogman10 wrote:
| With the rise of WSL, I have a real hard time justifying
| wanting a linux desktop.
|
| I've got a VM with a full linux distro at my fingertips.
| Virtualization has gotten more than fast enough. And now,
| with windows 11, I get an X server integrated with my WSL
| instance so even if I WANTED a linux app, I can launch it
| just like I would if I were using linux as my host.
|
| It does suck that the WSL1 notion of "not a vm" didn't take
| off, but at the same time, when the VM looks and behaves
| like a regular bash terminal, what more could you
| realistically want?
| vetinari wrote:
| WSL2 is very limited; from not having a "proper init" to
| having NAT-ed network, it is fine for running simple
| docker containers, but proper linux it is not.
|
| Comparing it to the real linux is like comparing
| powershell prompt to full windows.
| blibble wrote:
| > what more could you realistically want?
|
| some privacy, no telemetry, no ads, and the computer only
| applying updates that I choose and only rebooting when I
| ask it to?
|
| (I know it's a lot to ask for these days...)
| gabereiser wrote:
| :pulls out wallet: where?
| gabereiser wrote:
| Yeah, WSL(2) was a huge huge win for Microsoft. It seems
| silly, but it's kept thousands of devs from dual
| booting...
| blibble wrote:
| I dunno
|
| it's quite possible it'll work out as well as IBM's OS/2
| running Windows apps did
| Beltalowda wrote:
| I guess that kind of proves the point that there is no
| "stable", well, anything on Linux. Something like
| /etc/resolv.conf is part of the user-visible API on Linux; if
| you change that, you're going to break applications.
|
| /etc/sysctl.conf is a good example; on some systems it just
| works, on some systems you need to enable a systemd service
| thingy for it, but on some systems the systemd thingy doesn't
| read /etc/sysctl.conf and only /etc/sysctl.d.
|
| So a simple "if you're running Linux, edit /etc/sysctl.conf
| to make these changes persist" has now become a much more
| complicated story. Writing a script to work on all Linux
| distros is much harder than it needs to be.
| vetinari wrote:
| > Something like /etc/resolv.conf is part of the user-
| visible API on Linux; if you change that, you're going to
| break applications.
|
| Apps were not supposed to open /etc/resolv.conf by
| themselves. If they did, they are broken. Just because the
| file is available, transparently, doesn't mean it is not a
| part of the internal implementation.
|
| Even golang runtime checks nsswitch for known, good
| configuration before using resolv.conf instead of thunking
| to glibc.
| Beltalowda wrote:
| The point was that if you're statically linking something
| that paths such as /etc/resolv.conf become "hard-coded",
| so that seems like an unimportant detail; _something_
| needs to check it, whether that 's an application or an
| application through a library call: it's the same thing.
| /etc/nsswitch.conf is just kicking the can down the road
| from /etc/resolv.conf to /etc/nsswitch.conf.
| blibble wrote:
| 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
| z3t4 wrote:
| 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.
| cosmin800 wrote:
| 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.
| ChikkaChiChi wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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
| ece wrote:
| Flatpak is basically Docker for linux, there are layers and
| everything. What you're saying should be possible if you make a
| AppImage/Flatpak out of the Steam Runtime+Proton(if
| needed)+Game, it should run anywhere with the right drivers.
| LtWorf wrote:
| Good luck once wayland starts to actually be used to run any
| game from before wayland.
| jacooper wrote:
| Xwayland exists, all my games use Xwayland, there are no
| stable proton/wine implementation that's uses Wayland
| natively.
| solarkraft wrote:
| Isn't that what gamescope has been doing for quite some
| time?
| mid-kid wrote:
| Inflammatory title is inflammatory.
| Kukumber wrote:
| 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
| justin66 wrote:
| 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/
|
| At least we still have WINE.
| codebolt wrote:
| 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.
| alkonaut wrote:
| WinForms is just mostly a managed Win32 wrapper so
| unsurprisingly it's very stable on the OS frameworks (4.X).
|
| Building for .NET Framework using any APIs is extremely stable
| as development has mostly ceased. You pick a target framework
| depending on how old windows versions you must support.
| pjmlp wrote:
| WinRT lives on as WinAppSDK.
| solarkraft wrote:
| The names aren't getting better either ...
| Longhanks wrote:
| Metro lives on as UWP lives on as WinRT lives on as Project
| Reunion lives on as WinAppSDK.
|
| Exactly the point the OP was making. Win32 is stable.
| taneq wrote:
| I was gonna say, I think Win32 is the only stable API full
| stop. Everything else is churn city.
| FpUser wrote:
| >"Coincidentally, Win32 is also the only stable API on Windows"
|
| And this is what I use for my Windows apps. In the end I have
| self contained binaries that can run on anything starting from
| Vista and up to the most up to date OS.
| int_19h wrote:
| .NET Framework is still there by default out of the box, and
| still runs WinForms and WPF like it always did.
| actionfromafar wrote:
| Which version of it? 1.0?
| ahtihn wrote:
| Since when is .NET 5+ part of Windows?
| markmark wrote:
| 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 wrote:
| .NET 4.8 might be one of those things they won't be able to
| get rid of.
| int_19h wrote:
| 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/visualstu...
| bjourne wrote:
| 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 Teaser: It begins with
| "Mauro, SHUT THE FUCK UP!"
| efficax wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yep Linus is reformed these days. He took some time off
| and went to sensitivity training a few years ago. I'm
| sure like all humans he has bad days and makes mistakes,
| but all in all he's really trying.
| pdntspa wrote:
| He's a product of a different time. Personally, I love his
| attitude -- wouldn't want to work under him though.
| moonchrome wrote:
| >by god, this is not how you build consensus or a high
| functioning team
|
| Says you, while criticizing Linus Torvalds from 2012. Who has
| a better track record of building consensus and high
| functioning teams ?
| 542458 wrote:
| Says Linus Torvalds from 2018...
|
| > My flippant attacks in emails have been both
| unprofessional and uncalled for. Especially at times when I
| made it personal. In my quest for a better patch, this made
| sense to me. I know now this was not OK and I am truly
| sorry.
|
| > The above is basically a long-winded way to get to the
| somewhat painful personal admission that hey, I need to
| change some of my behavior, and I want to apologize to the
| people that my personal behavior hurt and possibly drove
| away from kernel development entirely.
|
| https://lkml.org/lkml/2018/9/16/167
|
| He still writes very frankly, but he generally doesn't
| resort to personal insults like he did in the past.
| fezfight wrote:
| That doesn't change his point about building high
| functioning teams in the past, though. Just that he is
| capable of adapting to the times. He had 27 years of
| career leading Linux before 2018. Successful, by any
| measure.
| dshpala wrote:
| Speaking about consensus - there is another thread on the HN
| where people complain about Android 13 UI. I guess that was
| built with a healthy dose of consensus.
|
| The point is - sometimes you need a jerk with a vision so
| that the thing you're building don't turn into amorphous
| blob.
| a9h74j wrote:
| The old quote: _I would trust Einstein, but I wouldn 't
| trust a committee of Einsteins._
| celtain wrote:
| You need someone with vision who enforces strict adherence
| to that vision. I'm not convinced you have to be a jerk to
| do that though.
| tasuki wrote:
| Yes, you don't need to be a jerk to do that. Linus
| Torvalds used to be a jerk (perhaps still is, but I think
| much less so these days). Do you have a non-jerk with
| Torvalds' vision?
| kurupt213 wrote:
| How is Steve Jobs getting left out of this conversation
| pestatije wrote:
| Maybe because: if you cannot say anything good about a
| dead person, don't say anything.
| robertlagrant wrote:
| > 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
|
| True. I think Linux could've been pretty successful if
| someone with good management practices had been in charge
| from the start.
| rayiner wrote:
| It's not my personal style, but there's plenty of high
| functioning teams in different domains headed by leaders who
| communicate like Torvalds. From Amy Klonuchar throwing
| binders (https://www.businessinsider.com/amy-klobuchar-
| throwing-binde...) to tons of high level folks in banking,
| law firms, etc.
|
| Put differently, you can construct a high functioning team
| composed of certain personalities who can dish out and take
| this sort of communication style without burning out on it.
| blablabla123 wrote:
| That probably works if people get bribed with interesting
| enough projects (Linux) or money (banks, lawfirms...). Most
| other projects probably fall apart before you can blink an
| eye
| martincmartin wrote:
| Are the teams high functioning _because_ of that, or
| _despite_ that?
| nomel wrote:
| I would assume a little of both. I've seen weeks wasted
| just because someone wouldn't say "that's a bad idea".
| I've also seen whole projects turn to crap, and then get
| canceled, when people that new better decided to remain
| silent, to avoid conflict.
|
| Through my years, it seems to be increasingly rare to
| find disagreeable people, and that agreeableness is being
| favored/demanded. I'm not one to judge if it's working or
| not, but when I see people getting upset at managers
| because the manager criticized their work/explanation
| during the presentation of that work, which is literally
| meant for criticism, I know quality coming from that
| group will be impacted. Maybe not surprising, but many of
| these people are new graduates. The few "senior" people I
| know, like this, are from companies who are in the
| process of failing, in very public ways.
|
| I think the ideal scenario is a somewhat supportive
| direct manager, and a disagreeable, quality demanding,
| manager somewhere not far above, keeping the ship from
| sinking.
| worik wrote:
| > but there's plenty of high functioning teams in different
| domains headed by leaders who communicate like Torvalds
|
| Maybe in the past. It is not acceptable now.
|
| A lot of men from the "old days" are finding that their
| table thumping "plain talking" (obscenity shouting) ways
| are getting them sidelined and ignored.
|
| Good.
| mikewave wrote:
| Some of us would love to work on a team like this. It
| would be nice to have the option. Your definition of
| "acceptable" might not actually result in teams that can
| take on the big challenges we face as a species as men
| who did find this kind of thing acceptable retire out of
| the workforce.
| nomoreusernames wrote:
| you are right on this shithead.
|
| and imagine you get to one up on torvalds.
|
| thats satisfaction no money can motivate.
| shadowgovt wrote:
| If "We've always done it this way and it's a risk to do
| it differently" was the argument that carried the day,
| few of us would have to worry about these questions at
| all because we'd never have gotten out from under
| feudalism.
| beebeepka wrote:
| We might all die but at least no one's feelings would be
| hurt, no matter what they did or didn't do.
|
| I am only half joking. It's a good thing no one is being
| forced to work with Linus. People really need to keep
| that in mind
| StevePerkins wrote:
| You're literally responding to an Amy Klobuchar cite,
| with a sweeping implication that being a jerk in the
| workplace is a "men" thing. Wow.
| JamesBarney wrote:
| I've definitely seen teams that were low functioning
| because they were so worried about consensus and upsetting
| someone else that no one ever criticized any decisions any
| team member made even if they were both impactful and
| objectively terrible.
| kurupt213 wrote:
| This is worse
| nomoreusernames wrote:
| naw man, let the old git be. he is a lovely old man. one day
| we wont have people like this. he gave more than he took.
| blibble wrote:
| maybe it is how you build the world's most popular operating
| system?
|
| because he did
| pydry wrote:
| I think if you take it out of context (which most people do),
| it looks a lot worse than it is.
|
| A very senior guy who shouldve known better was trying,
| fairly persistently, to break a very simple rule everybody
| agreed to for a very bad reason. Linus told him to shut the
| fuck up.
|
| I wouldnt say that Linus's reaction was anything to look up
| to but I wouldnt say that calling the tone police is at all
| justified either.
| mrtranscendence wrote:
| I mean, the guy sent one short email before Torvalds flew
| off the handle; that's hardly "trying persistently" to
| break a rule. I can think of a thousand assertive ways to
| tell the guy to shut up that wouldn't have required
| behaving like an angry toddler.
| kochb wrote:
| The context, from Mauro's previous message:
|
| > Only an application that handles video should be using
| those controls, and as far as I know, pulseaudio is not a
| such application. Or are it trying to do world domination?
| So, on a first glance, this doesn't sound like a regression,
| but, instead, it looks tha pulseaudio/tumbleweed has some
| serious bugs and/or regressions.
|
| Style and culture are certainly open for debate (I wouldn't
| be as harsh as Linus), but correcting a maintainer who was
| behaving this way towards a large number of affected users
| was warranted. The kernel broke the API contract, a user
| reported it, and Mauro blamed the user for it.
| Spivak wrote:
| Glibc is GNU/Linux though and cannot be avoided when
| distributing packages to end users. If you want to interact
| with the userspace to do things get users, groups, netgroups,
| or DNS queries you have to use glibc functions or your users
| will hit weird edge cases like being able to resolve hosts in
| cURL but not your app.
|
| Now, do I think it would make total sense for syscall wrappers
| and NSS to be split into their own libs (or dbus interfaces
| maybe) with stable ABIs to enable other libc's, absolutely! But
| we're not really there. This is something the BSD's got
| absolutely right.
| kllrnohj wrote:
| But there are other "Linux"'s that are not GNU/Linux which
| was I think the point. Like Android, which doesn't use glibc,
| and doesn't have this mess. I think that was one of the
| things people used to complain about, that Android didn't use
| glibc, but since glibc seems to break ABI compatibility kinda
| on the regular that was probably the right call.
| emidln wrote:
| There are other libc implementations that work on Linux with
| various tradeoffs. Alpine famously uses musl libc for a
| lightweight libc for containers. These alternate libc
| implementations implement users/groups/network manipulation
| via well-known files like /etc/shadow, /etc/passwd, etc. You
| could fully statically link one of these into your app and
| just rely on the extremely stable kernel ABI if you're so
| interested.
| Spivak wrote:
| We're not disagreeing. You can, of course, use other libc's
| on Linux the kernel, but you cannot use other libc's on
| GNU/Linux the distro that uses glibc without some things
| not working. This can be fine on your own systems so long
| as you're aware of the tradeoffs but if you're distributing
| your software for use on other people's systems your users
| will be annoyed with you.
|
| Even Go parses /etc/nsswitch.conf and farms out to cgo when
| it finds a module it can't handle. This _technically_ doesn
| 't work because there's no guarantee that the hosts or dns
| entries in nsswitch have consistent behavior, it's just the
| name of a library you're supposed to dlopen. On evil, but
| valid, distro resolv.conf points to 0.0.0.0 and hosts
| module reads an sqlite file.
| nickelpro wrote:
| > you cannot use other libc's on GNU/Linux the distro
| that uses glibc without some things not working
|
| As the comment your replying to points out, you can
| statically link your libc requirements and work on any
| Linux distro under the sun.
|
| You can also LD_PRELOAD any library you need, and also
| work on any Linux distro under the sun. This is
| effectively how games work on Windows too, they ship all
| their own libraries. Steam installs a specific copy of
| the VCREDIST any given game needs when you install the
| game.
|
| If you are not releasing source code, it's unreasonable
| to think the ABIs you require will just be present on any
| random computer. Ship the code you need, it's not hard.
| david_draco wrote:
| If in distribution discussions Linux is name for the operating
| system and shell, downplaying the role of GNU, then it is also
| fair game to say here: Linux does not have a stable ABI because
| glibc changed.
| DiggyJohnson wrote:
| Really appreciate your stuff Bjorn, this link always brings a
| smile to my (too young to be cynical) face.
| phendrenad2 wrote:
| 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 wrote:
| 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.
| captainmuon wrote:
| 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.
| mort96 wrote:
| 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 wrote:
| 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.
| LtWorf wrote:
| > 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.
|
| This is false. Actual problems get fixed, and very quickly
| at that.
|
| Normally the issues are from proprietary applications that
| were buggy to begin with, and never bothered to read the
| documentation. I'd say to a paying customer that if a
| behaviour is documented, it's their problem.
| jandrese wrote:
| The issue I see most often is someone compiled the
| application on a slightly newer version of Linux and when
| they try to run it on a slightly older machine it barfs
| saying that it needs GLIBC_2.31 and the system libc only
| has up to GLIBC_2.28 or something like that. Even if you
| aren't using anything that changed in the newer versions
| it will refuse to run.
| LtWorf wrote:
| That is not a bug. Just make a chroot with an older glibc
| and build there if you want to link against an older
| glibc. That easy.
|
| It works with future versions, not with past versions.
| int_19h wrote:
| That's an ergonomic deficiency. In practice, you probably
| need more than glibc, so then you have to make sure that
| other bits are available in this chroot. And if it so
| happens that one of the build tools that you rely on
| needs a newer version of glibc than the one you're
| building against, it still breaks down.
|
| On Windows, you specify the target version of the
| platform when building, and you get a binary that is
| guaranteed to load on that platform.
| jacooper wrote:
| Flatpak exists to solve this.
| mook wrote:
| > Normally the issues are from proprietary applications
| that were buggy to begin with, and never bothered to read
| the documentation. I'd say to a paying customer that if a
| behaviour is documented, it's their problem.
|
| ... But that's exactly why Win32 was great; Microsoft
| actually spent effort making their OS was compatible with
| broken applications. Or at least, Microsoft of long past
| did; supposedly they worked around a use-after-free bug
| in SimCity for Windows 3.x when they shipped Windows 95.
| Windows still has infrastructure to apply application-
| specific hacks (Application Compatibility Database).
|
| I have no reason to believe their newer stacks have
| anything like this.
| alerighi wrote:
| Well you talk about Windows, that was true in the pre-
| Windows 8 era. Have you used Windows recently?
|
| I bought a new laptop, and decided to give Windows a second
| chance. With Windows 11 installed, there were a ton of
| things that didn't worked. To me it was not acceptable for
| a 3000$ laptop. Problems with drivers, blue screens of
| death, applications what just didn't run properly (and
| commonly used applications, not something obscure). I never
| had these problems with Linux.
|
| I mean we talk about Windows that is stable mostly because
| we use Windows versions after they are out since 5 years
| and most of the problems were fixed. Good, now companies
| are finishing the transition to Windows 10, not Windows 11,
| after staying with Windows 7 for years. After 10 years they
| will probably move to Windows 11, when most of its bug are
| fixed.
|
| If you use a rolling-release Linux distro, such as
| ArchLinux, some problems on new software are expected. It's
| the equivalent of using an insider build of Windows, with
| the difference that ArchLinux is mostly usable as a daily
| OS (it requires some knowledge to solve the problems that
| inevitably arrive, but I used it for years). If you use
| let's say Ubuntu LTS, you don't have these kind of
| problems, and it mostly run without any issue (less issues
| than Windows for sure).
|
| By the way, maintaining compatibility has a cost: have you
| ever wandered because a full installation of Ubuntu that is
| a complete system with all the program that you use, an
| office suite, driver for all the hardware, multimedia
| players, etc is less than 5Gb while a fresh install of
| Windows is minimum 30Gb but I think nowadays even more?
|
| > 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.
|
| Never saw Microsoft do that: whey will simply say that it's
| not compatible and the software vendor has to update. That
| is not a problem by the way... OS developer should move
| along and can't maintain backward compatibility forever.
|
| > The GNU and glibc people believe that they provide a very
| high level of backwards compatibility.
|
| That is true. It's mostly backward compatible, having a
| 100% backward compatibility is not possible. Problems are
| fixed as they are detected.
|
| > 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.
|
| There is one issue: GNU can't test non-free software for
| obvious licensing and policy issues (i.e. an association
| that endorses free software can't buy licenses of
| proprietary software to test it). So a third party should
| test it and report problems in case of broken backward
| compatibility.
|
| Keep in mind that binary compatibility is something that is
| not fundamental on Linux, since it's assumed that you have
| the source code of everything and in case you recompile the
| software. GNU/Linux born as a FOSS operating system, and
| was never designed to run proprietary software on it. There
| are edge cases where you need to run a binary for other
| reasons (you lost the source code, compiling it is
| complicated or takes a lot of time) but surely are edge
| cases and not a lot of time should be spent to address
| them.
|
| Beside that glibc it's only one of the possible libc that
| you can use on Linux: if you are developing proprietary
| software in my opinion you should use MUSL libc, it has a
| MIT license (so you can statically link it into your
| proprietary binary) and it's 100% POSIX compliant. Surely
| glibc has more feature, but probably your software doesn't
| use them.
|
| Another viable option is to distribute your software with
| one of the new packaging formats that are in reality
| containers: snap, flatpack, appimage. That allows you to
| distribute the software along with all the dependencies and
| don't worry about ABI incompatibility.
| dataangel wrote:
| "Linux is really hurt here by the total lack of any unit
| testing" says volumes about what you actually know about
| the space. Shit tons of Linux software has unit tests!
| game-of-throws wrote:
| You cut out a key word:
|
| > Linux is really hurt here by the total lack of any unit
| testing or UI scripting standards.
|
| > standards
|
| I've been very impressed reading how the Rust developers
| handle this. They have a tool called crater[1], which
| runs regression tests for the compiler against all Rust
| code ever released on crates.io or GitHub. Every front-
| facing change that is even slightly risky must pass a
| crater run.
|
| https://github.com/rust-lang/crater
|
| Surely Microsoft has internal tools for Windows that do
| the same thing: run a battery of tests across popular
| apps and make sure changes in the OS don't break any user
| apps.
|
| Where's the similar test harness for Linux you can run
| that tests hundreds of popular apps across Wayland/X11
| and Gnome/KDE/XFCE and makes sure everything still works?
| leeter wrote:
| > Surely Microsoft has internal tools for Windows that do
| the same thing: run a battery of tests across popular
| apps and make sure changes in the OS don't break any user
| apps.
|
| And hardware, they actually deploy to hardware they buy
| locally from retailers to verify things still work too
| last I checked. Because there is always that "one popular
| laptop" that has stupid quirks. I know they try to focus
| on a spectrum of commonly used models based on the
| telemetry too.
| Ygg2 wrote:
| And crater costs a bunch, runs for a week, and it's not a
| guarantee things won't break. I'm not sure it runs every
| crate or just top 1 million. It used to, but I could see
| that changing, if
|
| And in case of closed source software, that isn't
| publicly available, crates wouldn't work.
| kibwen wrote:
| Crater's an embarrassingly parallel problem though, it's
| only a matter of how much hardware you throw at it.
| Microsoft already donates the hardware used by Crater, it
| would have no problem allocating 10x as much for its own
| purposes.
| Ygg2 wrote:
| How much of crates are ran on crater? All of them?
|
| Also I think there are magnitudes more C libs/apps, than
| Rust crates.
| kibwen wrote:
| There are certainly more things written in C than in Rust
| --the advantage of being fifty years old--but the
| standardization of the build system in Rust means that it
| would be difficult for any C compiler (or OS, or libc, or
| etc.) to produce a comparable corpus of C code to
| automatically test against (crates.io currently has
| 90,000 crates). But that's fine, because for the purpose
| of this thread that just means that Microsoft's
| theoretical Crater-like run for Windows compatibility
| just takes even less time and resources to run.
| mike_hearn wrote:
| Well, let's see. What do I know about this topic?
|
| I've used Linux since the Slackware days. I also spent
| years working on Wine, including professionally at
| CodeWeavers. My name can still be found all over the
| source code:
|
| https://gitlab.winehq.org/search?search=mike%20hearn&nav_
| sou...
|
| and I'm listed as an author of the Wine developers guide:
|
| https://wiki.winehq.org/Wine_Developer%27s_Guide
|
| Some of the things I worked on were the times when the
| kernel made ABI changes that broke Wine, like here, where
| I work with Linus to resolve a breakage introduced by an
| ABI incompatible change to the ptrace syscall:
|
| https://lore.kernel.org/all/1101161953.13273.7.camel@litt
| leg...
|
| I also did lots of work on cross-distribution binary
| compatibility for Linux apps, for example by developing
| the apbuild tool which made it easy to "cross compile"
| Linux binaries in ways that significantly increased their
| binary portability by controlling glibc symbol versions
| and linker flags:
|
| https://github.com/DeaDBeeF-
| Player/apbuild/blob/master/Chang...
|
| So I think I know more than my fair share about the guts
| of how Win32 and Linux work, especially around
| compatibility. Now, if you had finished reading to the
| end of the sentence you'd see that I said:
|
| _" Linux is really hurt here by the total lack of any
| unit testing or UI scripting standards"_
|
| ... unit testing or UI scripting standards. Of course
| Linux apps often have unit tests. But to drive real world
| apps through a standard set of user interactions, you
| really need UI level tests and tools that make UI
| scripting easy. Windows has tons of these like
| AutoHotKey, but there is (or was, it's been some years
| since I looked) a lack of this sort of thing for Linux
| due to the proliferation of toolkits. Some support
| accessibility APIs but others are custom and don't.
|
| It's not the biggest problem. The cultural issues are
| more important. My point is that the reason Win32 is so
| stable is that for the longest time Microsoft took the
| perspective that it wouldn't blame app developers for
| changes in the OS, even when theoretically it could. They
| also built huge libraries of apps they'd purchased and
| used armies of manual testers (+automated tests) to
| ensure those apps still seemed to work on new OS
| versions. The Wine developers took a similar perspective:
| they wouldn't refuse to run an app that does buggy or
| unreasonable things, because the goal is to run all
| Windows software and not try to teach developers lessons
| or make beautiful code.
| danieldk wrote:
| > But to drive real world apps through a standard set of
| user interactions, you really need UI level tests and
| tools that make UI scripting easy. Windows has tons of
| these like AutoHotKey, but there is (or was, it's been
| some years since I looked) a lack of this sort of thing
| for Linux due to the proliferation of toolkits.
|
| This made me remember a tool that was quite popular in
| the Red Hat/GNOME community in 2006-2007 or so:
|
| https://gitlab.com/dogtail/dogtail
|
| I wonder if it every got any traction?
| bartvk wrote:
| Thank you for your work!
| emaginniss wrote:
| Right, but Linux (the OS) doesn't have unit tests to
| ensure that changes to the underlying system doesn't
| break the software on top. Imagine if MS released a new
| version of Windows and tons of applications stopped
| functioning. Everyone would blame MS. The Linux community
| does it all the time and just says that it's the price of
| progress.
| mort96 wrote:
| So, I very much agree with mike_hearn, their description
| of how glibc is backwards compatible in theory due to
| symbol versioning matches my understanding of how glibc
| works, and their lack of care to test if glibc stays
| backwards compatible in practice seems evident. They
| certainly don't seem to do automated UI tests against a
| suite of representative precompiled binaries to ensure
| compatibility.
|
| However, I don't understand where unit testing comes in.
| Testing that whole applications keep working with new
| glibc versions sounds a lot like integration testing.
| What's the "unit" that's being tested when ensuring that
| the software on top of glibc doesn't break?
| mike_hearn wrote:
| You're right, I should have written "integration tests".
| Beltalowda wrote:
| I think the problem is that there isn't really a thing
| like "Linux the OS"; there's Debian, Ubuntu, Gentoo, Red
| Hat, and more than I can remember, and they all do things
| different: sometimes subtly so, sometimes not so subtly.
| This is quite different from the Windows position where
| you have one Windows (multiple editions, but still one
| Windows) and that's it.
|
| This is why a lot of games now just say "tested on Ubuntu
| XX LTS" and call it a day. I believe Steam just ships
| with half an Ubuntu system for their Linux games and uses
| that, even if you're running on Arch Linux or whatnot.
|
| This has long been both a strong and weak point of the
| Linux ecosystem. On one hand, you can say "I don't want
| no stinkin' systemd, GNU libc, and Xorg!" and go with
| runit, musl, and Wayland if you want and _most_ things
| still work (well, mostly anyway), but on the other hand
| you run in to all sort of cases where it works and then
| doesn 't, or works on one Linux distro and not the other,
| etc.
|
| I don't think there's clean solution to any of these
| issues. Compatibility is the one of the hard problems in
| computers because there _is_ no solution that will
| satisfy everyone and there are multiple reasonable
| positions, all with their own trade-offs.
| SubjectToChange wrote:
| > 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.
|
| There are already sophisticated binary analysis tools for
| detecting ABI breakages, not to mention extensive
| guidelines.
|
| > And, the Linux/GNU world never had a commercial "customer
| is always right" culture on this topic.
|
| Vendors like Red Hat are extremely attentive towards their
| customers. But if you're not paying, then you only deserve
| whatever attention they choose to give you.
| FeepingCreature wrote:
| I think part of the problem is that by default you build
| against the newest version of symbols available on your
| system. So it's real easy when you're working with code to
| commit yourself to some symbols you may not even need;
| there's nothing like Microsoft's "target a specific version
| of the runtime".
| skybrian wrote:
| I wonder what Zig does?
| mort96 wrote:
| I really, really miss such a feature with glibc. There
| are so many times when I just want to copy a simple
| binary from one system to another and it won't work
| simply because of symbol versioning and because the
| target has a slightly older glibc. Just using Ubuntu LTS
| on a server and the interim releases on a development
| machine is a huge PITA.
| AshamedCaptain wrote:
| GNU / glibc is _hardly_ the problem regarding ABI stability.
| TFA is about a library trying to parse executable files, so
| it's kind of a corner case; hardly representative.
|
| The problem when you try to run a binary from the 90s on
| Linux is not glibc. Think e.g. one of Loki games like
| SimCity. The audio will not work (and this will be a kernel
| ABI problem...). The graphics will not work. There will be no
| desktop integration whatsoever.
| jle17 wrote:
| > Think e.g. one of Loki games like SimCity. The audio will
| not work (and this will be a kernel ABI problem...). The
| graphics will not work. There will be no desktop
| integration whatsoever.
|
| I have it running on an up to date system. There is
| definitely an issue that it's a pain to get working,
| especially for people not familiar with the cli or ldd and
| such, as it wants a few things that are not here by
| default. But once you get it the few libs it needs and ossp
| to emulate the missing oss in the kernel, there is no issue
| with gameplay, graphics or audio aside from the intro video
| that doesn't run.
|
| So I guess the issue is that the compatibility is not user
| friendly ? Not sure how that should be fixed though. Even
| if Loki had shipped all the needed lib with the program, it
| would still be an issue not to have sound due to distro
| making the choice of not building oss anymore.
| simonh wrote:
| The article seems to document ways in which it isn't. I have no
| idea personally, are these just not really practical problems?
| mort96 wrote:
| The article is talking about userland, not the kernel's ABI.
| [deleted]
| LtWorf wrote:
| Someone should invent a command to change root... we should
| call it chroot!
| MayeulC wrote:
| Sounds like you want Flatpak, Docker or Snap :)
| frozenport wrote:
| Windows installs those MSVC runtimes via windows update for the
| last decade.
|
| With Linux, ever revision of gcc has its own glibcxx, but
| distros don't keep those up to date. So that you'll find that
| code built with even an old compiler (like gcc10) isn't
| supported out of the box.
| ctoth wrote:
| I read "old compiler" and thought you meant something like
| GCC 4.8.5, not something released in 2020!
| anon291 wrote:
| Just use nix.
| dvfjsdhgfv wrote:
| 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.
| wmf wrote:
| The Linux kernel maintains userspace API/ABI compatibility
| forever but inside the kernel (e.g. modules) there is no stable
| API/ABI.
| mort96 wrote:
| 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]
| josephcsible wrote:
| The kernel absolutely does guarantee a stable userspace ABI.
| This post is entirely about other userspace libraries.
| [deleted]
| franga2000 wrote:
| 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).
| CameronNemo wrote:
| Proprietary devs should use static linking (with musl) or
| chroots/containers. What makes the author think they are the
| target audience of glibc?
| davikr wrote:
| Thanks, but I think I'll stick with Windows: their target
| audience is famously everyone and for an unlimited time.
| calvin_ wrote:
| Have fun with libGL!
| iforgotpassword wrote:
| 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 wrote:
| FWIW, targeting proton is likely the best platform target for
| future Windows compatibility too.
| LtWorf wrote:
| I've been using wine and glibc for almost 20 years now and wine
| is waaaay more unstable than glibc.
|
| Wine is nice until you try to play with sims3 after updating
| wine. Every new release of wine breaks it.
|
| Please use wine for more than a few months before commenting on
| how good it is.
|
| It's normal that every new release some game stops working.
| Which is why steam offers the option to choose which proton
| version to use. If they all worked great one could just stick
| to the last.
| Kaze404 wrote:
| > Please use wine for more than a few months before
| commenting on how good it is.
|
| I've used it for several years, and even to play Sims 2 from
| time to time, and while I've had issues the experience only
| gets better over time. It's gotten to the point where I can
| confidently install any game on my Steam library and expect
| it to run. And be right most of the time.
| LtWorf wrote:
| But not sims 3
|
| Age of empires DE will not work with proton. And it's not
| really a top notch graphics game.
| Kaze404 wrote:
| I'm not entirely sure what the point of updating Wine is
| in the first place. If you have a version that works with
| the game you're trying to play, why not pin it? Things
| definitely tend to break with Wine upgrades by nature of
| what Wine does, that's why it's common for people to have
| multiple versions of Wine installed.
| andai wrote:
| I used to say that Wine makes Linux tolerable, but after
| using it for several years I've concluded that Wine makes
| _Windows_ tolerable.
| noirbot wrote:
| As someone who's been gaming on Proton or Lutris + Raw Wine,
| I'm not sure I agree. I regularly update Proton or Wine
| without seeing major issues or regressions. It certainly
| happens sometimes, but I'm not sure it's any worse of a
| "version binding" problem than a lot of stuff in Linux is.
| Sure, sometimes you have to specifically use an older
| version, but getting "native" linux games to work on
| different GPU architectures or distros is a mess as well, and
| often involves pinning drivers or dependencies. I've had
| games not run on my Fedora laptop that run fine on my Ubuntu
| desktop, but for the most part, Wine or Proton installed
| things work the same across Linux installs, and often with
| better performance somehow.
| LtWorf wrote:
| I specifically mentioned the sims3. That one is constantly
| broken by updates.
|
| Also age of empires2 hd, after working fine with
| wine/proton for a decade, doesn't work with the latest
| proton for me.
| hot_gril wrote:
| And Aoe2 HD broke with every game update in Wine. I had
| to keep patching in different DLLs. Gave up one day. It's
| worse than the original game anyway.
| noirbot wrote:
| Sure, I'm not contesting that Wine breaks things with
| updates. So does a lot of stuff on Linux. The amount of
| times I run an apt update and some config file is now
| obsolete or just gone is a lot more often than I'd like.
|
| The advantage is that the Wine Ecosystem seems to realize
| this more than the Linux ecosystem at large, and
| specifically makes it easy to pin versions and never
| update. If it worked, why update? Or why not roll back?
| I'm already used to having to do that with every other
| part of linux gaming including my graphics drivers...
| hot_gril wrote:
| > If it worked, why update?
|
| For multiplayer games, which nowadays get updated every
| day or something, and old versions are incompatible.
| a9h74j wrote:
| > Every new release of wine breaks it.
|
| Is there any way to easily choose which Wine version you use
| for compatiblity? Multiple Wine versions without VMs etc?
| LtWorf wrote:
| Steam lets you do that, but I think it's a global setting
| and not per game.
|
| Debian normally keeps 2 versions of wine in the
| repositories, but if none of those 2 work, you're out of
| luck.
| Kaze404 wrote:
| > if none of those 2 work, you're out of luck
|
| That's not true. There are multiple tools for managing
| multiple versions of Wine and Wine-related tools for
| gaming, the oldest one being PlayOnLinux. Lutris is the
| most widely used one, and works great in my experience.
| pongo1231 wrote:
| Absolute opposite experience for me. The native versions of
| Half-Life, Cities: Skylines and a bunch of other games refuse
| to start up at all for me for a few years now. Meanwhile I've
| been on the bleeding edge of Proton and I can count the
| number of breakages with my sizeable collection of working
| Windows games within the last couple of years on one hand.
| It's been a fantastic experience for me with Proton.
| edflsafoiewq wrote:
| Mind saying what the error is? Linker problem?
| pongo1231 wrote:
| Not sure if I'm honest. Starting up steam through the
| terminal and launching the game doesn't give me anything
| indicating the reason in the logs, which is weird. I'm
| using Arch and tried both steam and steam-runtime
| already.
| LtWorf wrote:
| It works fine for me. If it was something with glibc it
| wouldn't work for me.
| LtWorf wrote:
| Half life works fine for me on latest kernel, latest glibc.
|
| Probably you have different unrelated issues.
| Aachen wrote:
| > 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 wrote:
| Wine Is Not an Emulator
| caffed wrote:
| Ha Perfect!
|
| Yes, wine is an Windows binary executor with library
| translation.
|
| https://wiki.winehq.org/FAQ#Is_Wine_an_emulator.3F_There_se
| e...
| bombcar wrote:
| 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).
| delusional wrote:
| Sure, but it's also WINdows Emulator
| ink_13 wrote:
| No, it's not, because it's not a emulator
| hot_gril wrote:
| "In computing, an emulator is hardware or software that
| enables one computer system (called the host) to behave
| like another computer system (called the guest)."
|
| Sounds like Wine.
| wvenable wrote:
| Wine isn't emulating a computer. It's another
| implementation of the Win32 API.
|
| Just like Linux isn't a Unix emulator.
| hot_gril wrote:
| There is a Linux emulator for Unix (namely FreeBSD), and
| it's one of the first examples in the Wikipedia article
| on emulation. https://www.openbsd.org/60.html shows
| OpenBSD removing "Linux emulation."
|
| Linux was never designed to be the same as Unix, just
| similar. But it's more popular now, so Unix users found
| utility in pretending to run Linux.
| gorkish wrote:
| Except sometimes on aarch64
| WarChortle wrote:
| In case you weren't aware Wine is not an emulator, it is a
| compatibility layer.
|
| The whole point of wine is to take a native Windows app, only
| compiled for Windows and translate its Windows calls to Linux
| calls.
| DiggyJohnson wrote:
| Surely you see that this is a slight semantic distinction,
| unless you consider Wine apps to be Linux native?
| Wowfunhappy wrote:
| > In case you weren't aware Wine is not an emulator, it is
| a compatibility layer.
|
| Ehhh. I know it's in the name, but I feel like the
| significance is debatable. It's not a CPU emulator, true.
| It _is_ emulating calls, which is emulation of a sort.
| xeromal wrote:
| I think most people interpret emulation as CPU emulation,
| not a compatibility layer otherwise .NET core is probably
| just one fat emulator.
| kmeisthax wrote:
| Usually when you say "emulator" people think there's an
| inherent performance hit because of a fetch-decode-
| execute interpreter loop somewhere. Reimplementations of
| things don't have that performance hit even though they
| are lumped under the same umbrella as actual interpreters
| and recompilers.
|
| Related note: if WINE is an emulator why isn't Linux or
| GNU? They both reimplement parts of UNIX, which was even
| more proprietary than Windows is today.
| shadowgovt wrote:
| Nowadays it's emulators all the way down.
|
| On most of these architectures the software eventually
| executes as x86 machine code, and the distance between
| x86 machine code and the actual processes inside a modern
| CPU implementing the x86 code set is so vast you can call
| a modern CPU an "x86 emulator built in hardware."
| Wowfunhappy wrote:
| > If WINE is an emulator why isn't Linux or GNU?
|
| I mean, it depends on the context. I don't think it would
| be wrong to say that Linux "emulates a UNIX environment"
| or some such, which is closer to what OP actually wrote
| about Wine.
|
| You've probably used a "terminal emulator" at some point
| today. ;)
| btdmaster wrote:
| UNIX source code, at least for the original versions, was
| released in 2002:
| https://slashdot.org/story/02/01/24/0146248/caldera-
| releases...
| lenkite wrote:
| By that definition, wouldn't the whole of POSIX simply be
| an "emulation layer" ;-)
| udp wrote:
| It's a reimplementation of the APIs rather than an
| emulation. Same as how Linux reimplemented UNIX APIs, but
| it's not a UNIX emulator.
| messe wrote:
| That's still emulating the underlying API, and accepted
| usage of the word. Much like the FreeBSD linux emulator
| translates linux syscalls into FreeBSD ones.
| littlestymaar wrote:
| Saying wine is an emulator is as wrong as saying docker
| (on linux) is a virual machine, even though you could say
| it allows you to run a "virtual environment" in the same
| hand-wavy way you're using the word "emulating" in your
| sentence.
| extropy wrote:
| By that logic any modern windows is an emulator of win32,
| since that is not a kernel API but a user space library
| "emulating" it.
|
| Exactly the same way as wine. Wine does not translate the
| calls, it for most part actually implements the
| underlying logic.
|
| Win32 is just a bunch of shared libraries: https://en.wik
| ipedia.org/wiki/Microsoft_Windows_library_file...
| [deleted]
| Spivak wrote:
| Is any compatibility shim an emulator?
| entropicdrifter wrote:
| This is all really just a philosophical question as to
| how you choose to use the word. It's the same as people
| who get in a twist over every game with procedural
| generation and permadeath being called a "Roguelike" even
| though that particular subgenre used to be more specific
| to turn-based RPGs with procedural generation, permadeath
| and _total loss of all progress between runs_.
|
| People who came into using the term earlier tend to think
| of it more narrowly, but colloquial use of the term has
| drifted to mean something more generic, e.g. "emulation"
| used to mean "making one piece of hardware pretend to be
| another", but now can sometimes just mean, "when one
| thing acts like another at all".
| Wowfunhappy wrote:
| In this case, however, the term "to emulate" predates
| microprocessors, so it _clearly_ can 't have ever
| referred exclusively to ISA translation!
|
| "Emulator" might be a more recent term--it would be
| interesting to see the etymology, actually--but it's
| reasonable to conclude that anything which "emulates"
| must be an "emulator". (Also, OP didn't actually use the
| word "emulator".)
|
| Edit: Nope, the word "emulator" dates back to at least
| the 1800s (although it has certainly grown in usage more
| recently): https://books.google.com/ngrams/graph?content=
| emulator&year_...
| hot_gril wrote:
| By any well-known definition of an emulator, like
| https://en.wikipedia.org/wiki/Emulator, Wine is an
| emulator. It's emulating a Windows system to Windows
| programs. It's not emulating _hardware_ is all. That WINE
| acronym, other than being a slightly annoying way to
| correct people, is wrong. Reminds me of Jimmy Neutron
| smartly calling table salt "sodium chloride" when really
| he's less correct than the layman he's talking to, since
| there are additives.
|
| WINE should simply stand for WINdows Emulator.
| messe wrote:
| One might say it _emulates_ windows library and system
| calls.
| tmccrary55 wrote:
| Much like one could say it internets Windows userland and
| system calls with Linux and its userland.
| messe wrote:
| No, not at all like that. One slight difference is that
| what you said is complete nonsense.
|
| I'm using an accepted definition of emulation:
|
| > emulate (transitive verb)
|
| > To imitate the function of (another system), as by
| modifications to hardware or software that allow the
| imitating system to accept the same data, execute the
| same programs, and achieve the same results as the
| imitated system.
|
| This usage is pretty common, for example FreeBSD has a
| linux emulation layer that takes Linux syscalls and
| translates them into FreeBSD syscalls. WINE saying it
| stands for "Wine Is Not an Emulator" is irrelevant to the
| fact that it is blatantly is one.
| rascul wrote:
| Or they might say that it _translates_ windows library
| and system calls.
| hot_gril wrote:
| Same way a CPU emulator translates instructions.
| deelowe wrote:
| A lot of high level emulation works this way as well. And,
| similarly, FPGA cores often aren't "simulating game
| hardware" either.
| randyrand wrote:
| It is not a "Windows Emulator", but it is certainly a
| "Windows Userspace Emulator"
|
| Dolphin can run Wii binaries on top of Linux, by emulating
| a Wii.
|
| Wine can run Windows binaries on top of Linux, by emulating
| Windows Userspace.
|
| Why would one be an emulator, and the other is not?
|
| Is there some distinction in what an emulator is that goes
| against common sense?
|
| This reminds of the Transpiler/Compiler "debate." They're
| both still compilers. They're both emulators (VMs &
| Compatability Layers).
|
| What the creators meant to say, IMO, is WINVM, "Wine is not
| a Virtual Machine".
| hot_gril wrote:
| The creators also would not call virtual machines
| emulators because they don't translate CPU instructions,
| which is their narrow criteria for "emulator" that nobody
| else seems to use.
| littlestymaar wrote:
| > is their narrow criteria for "emulator" that nobody
| else seems to use.
|
| Except the people actually writing or talking about real
| "emulators". You know, for things like NES or Gameboy on
| x86, x86 on WASM, etc.
|
| Sure, you can argue that VMs or Wine are emulators in the
| broadest sense, but then I could argue that your CPU is
| an emulator too since it doesn't really runs ASM, and
| with that very loose meaning almost anything computers
| related is an emulator. And in practice that's never what
| people mean when we're talking about an emulator. (Even
| this thread started with the wrong postulate that WINE
| must have incurred a performance penalty because the
| commented believed it was an emulator).
| hot_gril wrote:
| Yes, those people are writing hardware emulators. Doesn't
| mean they're the only "real" kind.
|
| As for my Intel CPU, it isn't pretending to be another
| kind of CPU. Intel makes a leading implementation of x86.
| Wine follows Microsoft's Windows implementation and
| translates to Linux calls, and the entire point is so you
| can run programs intended for Windows on Linux instead.
| You can get relative about it, but it's not really,
| they're clearly different. Either way, doesn't support
| WINE's acronym.
| extropy wrote:
| Wine is more like a re-implementation of windows Userland
| using a different kernel (and graphics libraries).
|
| Since the hardware is all the same, there is nothing to
| emulate or compile.
|
| Or from the other direction - windows NT contains a re-
| implementation of the win16 API. Is that an emulator?
| yjftsjthsd-h wrote:
| The Wii emulator is emulating the whole system including
| the CPU; WINE describes itself as not an emulator
| specifically because it's not doing anything about the
| CPU (hence not working on ARM Linux without extra work).
|
| (I'm not 100% sold on this; I think "CPU emulator" and
| "ABI emulator" are both reasonable descriptions, albeit
| of different things, but that's the distinction that the
| WINE folks are making.)
| mort96 wrote:
| Have you actually tried to run the Windows version of
| Factorio through Proton and experienced slowdowns? In my
| experience, WINE doesn't result in a noticeable slowdown
| compared to running on Windows natively (without
| "emulationware" as you call it), unless there are issues
| related to graphics API translation which is a separate
| topic.
| Kaze404 wrote:
| I'm a huge fan of Wine, but there's no reason to run
| Factorio under it. The native Linux version works
| flawlessly from my experience, and I'm even using a distro
| where problems with native binaries are common.
| [deleted]
| hot_gril wrote:
| > unless there are issues related to graphics API
| translation
|
| But there almost always are problems in that area. I've
| never had a game run with the same FPS and stability in
| Wine vs natively in Windows.
| mort96 wrote:
| My point was it's not inherent to WINE. There's a lot of
| Windows games which support Vulkan or OpenGL, those work
| excellently.
| hot_gril wrote:
| Csgo is OpenGL and doesn't work excellently in my
| experience, but yeah, in theory they should.
| littlestymaar wrote:
| Exactly the same fps, unlikely.
|
| But phoronix has tons of benchmarks showing that
| WINE/proton are in the same ballpark as the native
| windows version, sometimes a bit slower but as many times
| a bit faster as well.
| sirn wrote:
| I believe OP is referring to the fact Factorio has some
| optimization on Linux such as using fork() to autosave
| (which is copy-on-write unlike its Windows counterpart),
| which result in zero-stuttering during auto-save for large-
| SPM bases.
| [deleted]
| bayindirh wrote:
| > Developers natively porting to linux seem to be wasting their
| time.
|
| Initial port of Valve's source engine ran 20% faster without
| any special optimizations back in the day. So I don't see why
| the effort is wasted.
| DiggyJohnson wrote:
| Isn't part of the original point not just that Wine is a
| perfect (dubious, imo) compatibility layer, but that
| distributing a native port is cumbersome on the Linux
| ecosystem?
| bayindirh wrote:
| I don't buy the cumbersomeness argument for Linux games. A
| lot of games in the past and today has been distributed as
| Linux binaries. Most famously Quake and Unreal Tournament
| series had native Linux binaries on disks and they worked
| well until I migrated to 64 bit distributions. I'm sure
| they'll work equally fine if I multi-arch my installations.
|
| Many of the games bundled by HumbleBundle as downloadable
| setups have Linux binaries. Some are re-built as 64 bit
| binaries and updated long after the bundle has closed.
|
| I still play Darwinia on my 64 bit Linux system
| occasionally.
|
| Most of these games are distributed as .tar.gz archives,
| too.
|
| I can accept and respect not creating Linux builds as
| engineering (using Windows only APIs, libraries, etc.) and
| business (not enough market) decisions, but cumbersomeness
| is not an excuse, it's a result of the other related
| choices.
|
| In my book, if a company doesn't want to support Linux,
| they can tell it bluntly, but telling "we want to, but it's
| hard, and this is Linux's problem" doesn't sound sincere
| even remotely.
| LtWorf wrote:
| Basically game developers never once booted linux.
|
| They'd need to do some learning and don't want to. They
| might have superficially read something about
| distributions and think that a software cannot run on two
| different distributions.
|
| I've read this excuse time and time again. And saying it
| tells me that the person never actually tried to compile
| anything on linux.
| pjmlp wrote:
| On the contrary, they are more that used to POSIX stacks
| on macOS, iOS, PlayStation, Nintendo, Android,
| ChromeOS....
|
| Yet porting to GNU/Linux is not worthwhile.
| LtWorf wrote:
| macos? The same OS which decided no more 32bit binaries
| because of reasons? The same OS which decided no more
| opengl because of reasons? That OS?
|
| No gamer uses that OS. If you think it's hard on linux,
| it's much harder on osx.
|
| android is not posix, that is completely hidden from the
| developer.
|
| chromeos is just linux + google tracking.
|
| consoles are a complete separate world.
|
| Please let's try to have a serious conversation. Game
| developers that use frameworks such as unreal are often
| unaware of how the underlying system works.
| nomel wrote:
| > have Linux binaries
|
| In January, HumlbeBundle removed Linux support from their
| Trove [1].
|
| HumbleBundle support points out that it's not simple [2]:
|
| > While it is entirely possible to install and run games
| and programs from the Linux GUI, implementation across
| distros can be wildly different. For this reason, this
| guide will explain how to install and launch games using
| the Terminal.
|
| And, usually, only a small list of distributions are
| supported, like Ubuntu or Mint. For example, Bundle 9
| [3].
|
| All of the above seems to supports the "cumbersomeness
| argument for Linux games".
|
| 1. https://kotaku.com/latest-humble-bundle-change-leaves-
| mac-li...
|
| 2. https://support.humblebundle.com/hc/en-
| us/articles/219377857...
|
| 3. https://support.humblebundle.com/hc/en-
| us/articles/115011722...
| bayindirh wrote:
| > In January, HumlbeBundle removed Linux support from
| their Trove [1].
|
| Yet, I have downloaded all new builds for a couple of
| games for amd64 from one of their oldest bundles.
|
| It's not as clear cut as it seems.
| Animats wrote:
| 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/
|
| [2] https://acronyms.thefreedictionary.com/EOS
|
| [3]
| https://steamcommunity.com/groups/EpicGamesSucks/discussions...
|
| [4] https://wiki.winehq.org/Bugs
| skyde wrote:
| 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 wrote:
| If web browsers had any kind of stable interface we wouldn't
| have: 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.
___________________________________________________________________
(page generated 2022-08-15 23:00 UTC)