Post B6bUs4kFoQif26o30a by a1ba@suya.place
(DIR) More posts by a1ba@suya.place
(DIR) Post #B6bT19zpSScy18INaS by whitequark@social.treehouse.systems
0 likes, 0 repeats
i think the combination of "your native software should support as many platforms as possible" and "continuous integration is a waste of time" is intellectually (and also morally) inconsistent
(DIR) Post #B6bT1AASov8OY7GsAC by a1ba@suya.place
0 likes, 0 repeats
@whitequark I don't think so. On some platforms setting up CI is straight up pain in the ass. Sure, crosscompiling is easy and it's a requirement, but running tests isn't.Speaking from experience, my game engine targets, lemme check, 17 operating systems across 9 CPU architectures. In case of operating systems it's the VM/emulator costs, in case of CPU architectures it's of course real hardware costs.
(DIR) Post #B6bT1BbnSman1B4DPE by whitequark@social.treehouse.systems
0 likes, 1 repeats
i think "it works against the specification, if the platform doesn't act like the specification says, that's not my problem" is essentially as bad as "it works on my machine, if it doesn't work on yours, that's not my problem" and for essentially the same reasons. your responsibility is to the real end user who needs to do something else, not to an abstract one who either has a platform that's perfectly written to the spec, or the time to find out what the difference is
(DIR) Post #B6bT1D1iBuurPqCQRE by whitequark@social.treehouse.systems
0 likes, 1 repeats
probably half of the complexity (and most of the testing effort) in the Amaranth language implementation is working around defects in Verilog, defects in Verilog implementations, or just toolchains doing various bonkers things that change from version to version. Amaranth more or less successfully abstracts over that, which is why it enables people who don't have the time to figure out whose fault is it that some Verilog construct doesn't work to build hardware that wouldn't exist otherwise
(DIR) Post #B6bTvMdfdkd3RbjOO8 by whitequark@social.treehouse.systems
0 likes, 0 repeats
@a1ba in my world, "it cross-compiles to platform X" is a form of build-time test; I don't think you need to run a produced artifact to qualify for calling it "CI"
(DIR) Post #B6bTvMp0xZhe0n2S4O by whitequark@social.treehouse.systems
0 likes, 0 repeats
@a1ba but also there's a big difference between "I'm not running tests because there's not enough resources to set it up but I wish I could" and "I'm not running tests because I don't think it is useful"
(DIR) Post #B6bTvMzILLvUWfqf5s by a1ba@suya.place
0 likes, 0 repeats
@whitequark but actually being able to run and test them automatically would save so much time, considering how some ports fall behind because there isn't a lot of people using them, like android on 32-bit arm
(DIR) Post #B6bU167jxIcHxfWv2m by ignaloidas@not.acu.lt
0 likes, 0 repeats
@a1ba@suya.place @whitequark@social.treehouse.systems I think this bumps into the definition of "supported" and what that meansLike sure, my Python stuff can probably run on basically anything that supports Python. But I'm not going to claim that I support Haiku without getting any CI on it.
(DIR) Post #B6bU16J5H7gsWqpyj2 by whitequark@social.treehouse.systems
0 likes, 0 repeats
@ignaloidas @a1ba yeah. running tests will never give you a 100% certainty of "it works properly", it just excludes the sources of error we considered most likely; if I can somehow ensure that I'm not likely to introduce Haiku incompatibilities without running the artifacts I could maybe claim that it's supported. it's a spectrum
(DIR) Post #B6bU16SehXLZ0XJce0 by a1ba@suya.place
0 likes, 0 repeats
@whitequark @ignaloidas actually I just realized we don't have haiku builds, but the support is here (and thanks to SDL for doing the heavy lifting)I should do something about that...
(DIR) Post #B6bUEKMILHULsGe7Zg by whitequark@social.treehouse.systems
1 likes, 0 repeats
@a1ba that sounds like we agree
(DIR) Post #B6bUMzdYknNIDJqzXU by whitequark@social.treehouse.systems
0 likes, 0 repeats
@dalias this is an unserious reply. if you've done any amount of cross-platform software development you would know that a lot of the time the interface contracts are poorly documented, wrong, or simply violated in practice (sometimes with this violation being the expected behavior). furthermore requiring people who are exposed to your lack of regular testing to be platform experts is disrespectful to their time. you could have saved them the effort and you chose not to
(DIR) Post #B6bUMzyTV26ZGBdh8i by krans@mastodon.me.uk
0 likes, 0 repeats
@whitequark Yes. Real world example: - customer insists on using an old open source window manager that handles _NET_WM_ICON_NAME, uh, unusually- so our product doesn't show expected taskbar text - customer refuses to consider fixing window manager- it's our problem now… and another very specific workaround enters the product codebaseAny environment-specific issue that a customer encounters becomes our bug, no matter how unreasonable @dalias
(DIR) Post #B6bUN0JkDx7QK9agIC by whitequark@social.treehouse.systems
1 likes, 1 repeats
@krans @dalias another consequential real world example: I inherit an OpenGL application that draws GL_LINES. on Windows it looks good. on GPU from vendor A on Linux it looks good. on GPU from vendor B on Linux it looks atrocious and the application is unusable. this is a known problem with vendor B.end result? completely rearchitecting the application to draw lines as polygons instead. who cares what the spec says if the application doesn't work and the vendor has no plans of fixing it
(DIR) Post #B6bUN0WVSVKKxjYsBU by krans@mastodon.me.uk
0 likes, 0 repeats
@whitequark Oof@dalias
(DIR) Post #B6bUN0gmqHYBTcN5Cy by whitequark@social.treehouse.systems
1 likes, 1 repeats
@krans @dalias later ended up repeating the "completely rearchitecting the codebase" step because there are environments where desktop GL isn't available, only GL ES. so much for writing to a spec!(it was also a performance issue, so that wasn't the sole motivation, but the ES requirement was a major constraint and big part of the motivation)
(DIR) Post #B6bUPw8MEe9SDXf9oO by a1ba@suya.place
0 likes, 0 repeats
@whitequark @krans @dalias oof, can relate
(DIR) Post #B6bUs4kFoQif26o30a by a1ba@suya.place
0 likes, 0 repeats
@whitequark @ignaloidas that also reminded me about recent patch on SPARC support that I got. While I'm fine with all these changes, now that we (almost) properly support big endian archs, it turned out the contributor presumably doesn't have the SPARC hardware and was playing around in an emulator. Well that to me is a complete waste of time. Emulators, once you get into details, aren't that accurate, and also absolutely don't represent the real hardware performance. I can support m68k just by spinning up qemu but none of the real hardware would be able to run the game engine at appropriate framerate I think
(DIR) Post #B6bV0U4TXBSnthH3MO by whitequark@social.treehouse.systems
0 likes, 0 repeats
@a1ba @dalias @krans and then there's various nonsense like "we would like to use geometry shaders, which are in desktop GL and GL ES 3, but we want to ship to webgl, which is GL ES 2 only". it was a massive time sink
(DIR) Post #B6bV0UF6tdyEQgFXw8 by a1ba@suya.place
0 likes, 0 repeats
@whitequark @dalias @krans IIRC webgl is es2 shaped but not really close to it.
(DIR) Post #B6bV0VMEkdGVt4akgS by whitequark@social.treehouse.systems
1 likes, 0 repeats
@a1ba @dalias @krans and then there is the problem of "Windows guarantes that DirectX drivers exist at the latest version, but OpenGL drivers will only support GL 1 unless you manually install something"we fixed this by bundling an entire copy of ANGLE with every Windows build. only added a MB or two to the binary size, and the performance was acceptable, plus if you did have GL drivers installed it'd use thatit was a huge pain
(DIR) Post #B6bV9zP4PYuXg8RJjc by a1ba@suya.place
0 likes, 0 repeats
@whitequark @dalias @krans yeah, it's Windows. Without video drivers installed the best you get is GDI software renderer.Plus, linking to opengl32.dll doesn't make sense as it doesn't expose anything than GL 1.1 and for everything else wglGetProcAddress must be used. (which is good practice for portability anyway)
(DIR) Post #B6bVVmicFmHohyyVGa by whitequark@social.treehouse.systems
0 likes, 0 repeats
@a1ba @dalias @krans if I recall the problem was that even with wglGetProcAddress you wouldn't get anything past GL 1.1 if the driver was automatically pulled from Windows Update. if they ran nvidia or whatever's installer manually then it would be fine(I think this may have also changed in the last few years)
(DIR) Post #B6bVVmvNUKUjLYwh9s by a1ba@suya.place
0 likes, 0 repeats
@whitequark @dalias @krans never heard of it, so maybe it's really not a problem anymore.There are other GL related issues on Windows though, like it's not getting tested properly and I get why Chrome devs made ANGLE. *foil hat on* As if somebody didn't want you to use OpenGL on Windows *foil hat off*
(DIR) Post #B6bWB6uw3mR7E6RWAC by a1ba@suya.place
0 likes, 0 repeats
@whitequark @dalias @krans Apple's OpenGL support meanwhile is a complete joke. They officially deprecated it yet it still exists on the system, and it's hilariously slow.The only reason engine works at somewhat reasonable framerates on all modern devices, including Apple devices, Android phones, on desktop with modern GPUs is that the hardware itself is so fast, so the emulation of OpenGL quirks and driver inefficiency doesn't matter.I wish Mesa's zink didn't had high requirements to Vulkan driver, so it could be used everywhere.
(DIR) Post #B6clQr3IVTwB7qHO8O by mirabilos@toot.mirbsd.org
0 likes, 0 repeats
@whitequark @dalias musl’s refusal to add a #define so people can test for it is bonkers, still.The rationale is just that, to develop against the spec, and musl implements the spec.But it does not work like that in practice. In practice, one has to add immense hacks so that other libcs, also in older versions, work as expected, which then break in musl, so I’d put these hacks in an #ifndef __musl__ if that existed.
(DIR) Post #B6clWANu3auEX1RzQe by glyph@mastodon.social
0 likes, 0 repeats
@whitequark @dalias yeah speaking as someone who has personally motivated fixes for major SUS violations for multiple multibillion market cap vendors as a direct result of continuous testing of “scripting language” framework code which is hypothetically doubly isolated from platform differences, this is a fairy tale about how cross platform development works, which is not and has never been true
(DIR) Post #B6clWAbjEBxtDtv1yi by glyph@mastodon.social
0 likes, 1 repeats
@whitequark @dalias like there are still existing 30-year-old reliability bugs in BSD and macOS related to write() on PTY file descriptors. at one point Linux just fully broke pipes for “efficiency”. strict specifications are totally meaningless without enforcement and the enforcement mechanisms are very weak
(DIR) Post #B6clcaZhawpRUs224m by glyph@mastodon.social
0 likes, 0 repeats
@dalias @whitequark Live your best life I guess but I just cannot imagine telling a customer to go fuck themselves because their fleet had the wrong OS version deployed
(DIR) Post #B6clcaq0cJsAJRf3Ue by mirabilos@toot.mirbsd.org
0 likes, 0 repeats
@dalias @whitequark @glyph or the vendor kernel that’s needed so that some embedded PoS even at all boots…Even if replaceable, doing so may need recertification, which is expensive and possibly unfeasible (person doing the replacement not the original body that got certified)…
(DIR) Post #B6clccNMtm9R5CHD84 by glyph@mastodon.social
0 likes, 0 repeats
@dalias @whitequark like at *some* point you have to do this if they insist on doing something like deploying HP/UX on Itanium in 2026, but every OS has defects like this or at the least disagreements about behavior.
(DIR) Post #B6clt0prj4dTZnQJbU by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark I feel like you've really made my point for me when you point out that *the most popular distro which exists* doesn't have the resources to seriously work on something as foundational as the libc. and like i said, libc is easy mode. a completely ossified library with a relatively small surface area. there's far larger and more complicated systems which applications depend on. (anything which touches a GPU, for example. + nightmares like xml libraries, dbus)
(DIR) Post #B6clt1EKG8CYnerqjI by mirabilos@toot.mirbsd.org
0 likes, 0 repeats
@pinskia @dalias @dotstdy @glyph @whitequark Ubuntu has been a pile of crap for ages now. Its popularity never had anything to do with quality. If you do anything nōn-standard on it, things will break. Ubuntu-motivated changes in Debian broke things in Debian. At this point, it would be better if it just ceased to continue, except it keeps more of the amd64/arm64-only zealots off Debian (there are enough damaging ones there already).Ubuntu is an exception, not an example, and it’s nowhere even near a good distro.
(DIR) Post #B6clt2iqi8DBQc9jwe by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark At any rate I think while it's possible to imagine a world where distros actively maintain their entire library surface area, I don't think we live in that world. I think in order to claim that it's already possible you need to do some pretty aggressive culling of what you consider to be software worth building and supporting, and what you consider a distro. I don't really vibe with that in either case.
(DIR) Post #B6cm4AyeMMpwDQr6My by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark Resilient systems are not built by relying on a magical layer which cannot fail. They're built by spreading the burden of correctness culturally across the entire system. The argument here that distro maintainers can or should be the final arbiters of who is right and good in some kind of tug of war between "platforms" and "software" really just feels like people wanting to roleplay software judge judy, rather than build things which are reliable.
(DIR) Post #B6cm4BEFQNJUzo9YgK by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark I like to rip on ubuntu as much as anyone, but if I'm making software for distribution it's gunna work on ubuntu... Likewise musl is a minor PITA but if I'm shipping software I'd make an effort to test that it actually works there. Would my world be simpler if I just decided that Intel GPUs are shit and I don't want to support them? Yes. Would a distro maintainer be qualified to patch that support back in? Extremely unlikely, and certainly not true across all.
(DIR) Post #B6cm4BTUVhVTl5HjRQ by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark I disagree that this even works for libc et al, but imagine a difficult case like shader compilers. Toolchain runs as part of the application, it needs to work across semi-arbitrary combinations of userspace driver, application version, kernel driver and hardware (including vendor, generation, and specific sku) + containers. If you think you can just "code against the spec" and have this actually function for non-trivial applications then I envy your optimism.
(DIR) Post #B6cm4BgxhcHYQraURE by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark Plus the spec is deliberately broad to deal with wildly different hardware capabilities (e.g. the "simd width" on AMD is 64 or 32, on Nvidia it's 32, on Intel it's 8, 16 or 32, on Adreno there's no guarantee but iirc 128 or 64 depending on hardware generation). All of which is sufficiently performance critical that you can't generally emulate or ignore. Plus every one has a different shader compiler (or multiple shader compilers, even within a single platform)
(DIR) Post #B6cm4BuQtX3d6dtFR2 by dotstdy@mastodon.social
0 likes, 0 repeats
@pinskia @dalias @glyph @whitequark I come from a world where we have farms of hardware running automated tests (as in farms of different kinds of hardware running the same tests) as part of CI flows, so to me the idea that you shouldn't even be *compiling* code or have CI at all is truly baffling.
(DIR) Post #B6cm4C7C85GXkDrRKK by mirabilos@toot.mirbsd.org
0 likes, 0 repeats
@pinskia @whitequark @dotstdy @dalias @glyph no, you need to coordinate with the people who are going to actually build things, and the porters. They have actual m68k, sh4, powerpc, etc. hardware and are not reliant on emulation-only, know the hardware and toolchain, and can help with portability issues, if people would just listen.
(DIR) Post #B6cmNIwAzLYgPCosAi by whitequark@social.treehouse.systems
0 likes, 0 repeats
@dalias @glyph stuff just works. forever. if you don't depend on anything but the kernel. if you don't happen to need a platform-specific interface. if your interface wasn't deprecated in the meantime, despite being well-specified. if glibc didn't break it for no reason.come on. this doesn't even qualify as good trolling. go ship something more complex than what you've done so far and then we'll talk, it's not a serious discussion until then
(DIR) Post #B6cmNJH5jaHxS4bZlw by chozu@fedi.absturztau.be
0 likes, 0 repeats
@whitequark @dalias @glyph Yeah, even in the context of just posix stuff, a lot of stuff is subtly different/incorrect/broken on different OSes to the point where you do need to invest effort. It's true you can just write to (posix) spec and if it's very common stuff then it will be fine, but if you're writing a program in the first place (i.e. the existing ones aren't useful to you) then you're likely to be using something that isn't so common, and therefore more likely to have these kind of compatibility issues. You're also more likely to need something that isn't in posix or is underspecified in posix, such that you need to care about the behaviour of specific systems. If you look at a "generic unix programming" library like skalibs you'll find a lot of what are basically compatibility hacks, and it seems like whenever I so much as breathe I have to fix something on the other side of the interface.Another thing is that, when it's something that you can't trust to be implemented correctly everywhere, it's also more likely that you will inadvertently rely on some implementation detail, and testing on lots of systems (perhaps with CI!) will help uncover that. The counter-argument is "tests aren't sufficient" but what is being advocated is still just testing, just someone else doing it, so it's not really different, you're just catching it earlier.And in general things that are "portable" in their own right (i.e. by being written to interfaces and not by effectively writing N programs to support N systems) are things like "sdl apps", "posix apps", etc, but a lot of programs have to be more than that, e.g. a browser can't be an sdl app because it needs to use more granular window system features. The same is true for posix apps and e.g. linux-specific interfaces, and the counter-argument would be "all the linux-specific interfaces are either gratuitous incompatibility or 1% performance increases that almost nobody needs" which is not really true.(also I kind of do want to make stuff that doesn't depend on anything but the kernel but mesa gets in the way on linux since you can't statically link vulkan (reasonable) and the interface implicitly brings in a lot of system stuff (kinda cringe and unnecessary))
(DIR) Post #B6cmNJWKouTwDLjkX2 by mirabilos@toot.mirbsd.org
0 likes, 0 repeats
@chozu @whitequark @glyph @dalias as shell maintainer: yes. POSIX is an illusion, and working on the actual Unicēs is what is needed.(And on some, we have reduced job control, still. If someone knows enough to fix that (without "AI"), help welcome.)
(DIR) Post #B6cmWxL09MjmJN28tE by whitequark@social.treehouse.systems
0 likes, 0 repeats
@dalias @glyph i have a responsibility to the downstream users to provide working software on whatever configuration they're stuck on. it doesn't matter what broke or why; if it broke i figure out how to fix it. if you don't do this then your relationship with your downstream users doesn't pass my bar of what's acceptable
(DIR) Post #B6cmWxZtG0eB3Y0264 by whitequark@social.treehouse.systems
0 likes, 0 repeats
@dalias @glyph there are of course cases where it's impossible to do without an unreasonable effort and then yeah I say no. but in other cases? it's not my job to tell someone that two vendors had a falling out and that's why they can't run my software, it's my job to make it run. the amount of avoidable misery in the world is supposed to decrease, not increase
(DIR) Post #B6cmWxtk4CWi37Ht2W by mirabilos@toot.mirbsd.org
0 likes, 0 repeats
@dalias @glyph @whitequark oh, I had to tell my client I needed to work on an extra workaround because the thing we wanted to use wouldn’t work due to political reasons 🤬Thankfully, they were understanding.
(DIR) Post #B6cmbZnb5tY0ksc1AW by ChuckMcManis@chaos.social
0 likes, 1 repeats
@glyph Have we ever worked together? 😆 Having been one of the original Java team "write once run anywhere!" I was often blindsided by folks who really loved that idea. I had to break it to them that we said that before we knew it wasn't possible. 😃 @whitequark @dalias
(DIR) Post #B6cmqB4vHq8qQgg8Js by arclight@oldbytes.space
0 likes, 0 repeats
@whitequark I don't understand how one expects to support multiple platforms without regularly testing on a variety of platforms to detect platform-specific problems as early as possible. Not just software bugs but problems with build automation, packaging, etc.
(DIR) Post #B6cmqBEUiFnWuN9mEq by mirabilos@toot.mirbsd.org
0 likes, 0 repeats
@arclight @whitequark the person doing one does not have to be the person doing the other, just communicating with each other.
(DIR) Post #B6cxHyBJpUPS53YqoK by dotstdy@mastodon.social
0 likes, 0 repeats
@mirabilos @pinskia @whitequark @dalias @glyph This is very focused on minor issues like CPU architecture, which is *easy mode*. Like I said earlier, it's really a matter of scope. If you want to say that only a narrow sort of software matters, and if by portability you mean "rhel but on more than one cpu architecture", you can kind of imagine the process vaguely working. But I don't have any desire to be so proscriptive of what software is or should be, or what platforms people should use.
(DIR) Post #B6cxHyMJAdCSd8hcwK by mirabilos@toot.mirbsd.org
0 likes, 0 repeats
@whitequark @pinskia @dotstdy @dalias @glyph it’s not, these were just an example for things you don’t have CI for
(DIR) Post #B6eHSw0AT0bykLoLg0 by icenowy@nightcord.de
1 likes, 0 repeats
@a1ba @dalias @krans @whitequark I was trying to lower some requirement of Zink, and the maintainer says he wants to get the code clean and free from legacy.
(DIR) Post #B6eYrWbvhmzQSTmkhE by icenowy@nightcord.de
0 likes, 0 repeats
@a1ba @dalias @krans @whitequark Maybe it's better to select ANGLE because it keeps support for multiple vendor drivers -- but it does not support desktop GL now...
(DIR) Post #B6eYrWuMbFjdNePTQe by a1ba@suya.place
0 likes, 0 repeats
@icenowy @dalias @krans @whitequark IIRC it did at some point many years ago.as for zink, I can understand they want to keep it clean, but many devices stuck at Vulkan 1.1 and will never see anything newer.Adreno somewhat lucky in that regard as it supported by the Mesa.