Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 19:21 UTC (Mon) by JoeBuck (subscriber, #2330)
Parent article: Woodruff: Weird architectures weren't supported to begin with

The way to fix this issue, for free software that depends on Rust, is to port Rust to GCC so that its cross-compilation abilities can be used. There's a serious effort under way. Those interested in architectures that LLVM doesn't support could contribute to that effort.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 21:38 UTC (Mon) by rodgerd (guest, #58896) [Link] (9 responses)

You've managed to miss the most important point of the article: that these architectures have been providing security theatre by purporting to run software that just compiles, maybe runs semi-reliably, and certainly has no particular guarantee that it actually runs as intended.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 22:13 UTC (Mon) by pizza (subscriber, #46) [Link] (7 responses)

> that these architectures have been providing security theatre by purporting to run software that just compiles, maybe runs semi-reliably, and certainly has no particular guarantee that it actually runs as intended.

Uh.... can't the same be said for pretty much every other architecture? (Or indeed, for anything other than the specific system that the upstream CI system used to run their tests, if any?)

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 22:22 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

Basically, yes. Folks have been asking us to provide Python wheels for Linux/aarch64 for a while, but we have no way of testing it, so I don't want to put out an official wheel without some actual trust that it has a hope of working. Instructions for making your own wheel are available for those with the gumption to do that, but the thing is that any bug submitted is basically untestable by me.

*Especially* in a project full of C and C++ code that does low-level file I/O (especially binary), hardware interaction, or anything like that, anything not tested regularly is not trustworthy to the level people would like or even probably think it is.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 7, 2021 13:50 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

> Basically, yes. Folks have been asking us to provide Python wheels for Linux/aarch64 for a while, but we have no way of testing it

Um... aarch64 boxes literally cost a few quid at this point, now that a lot of the SBCs are aarch64. Surely it's easy to get a way of testing things there?

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 7, 2021 15:25 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (1 responses)

Our software needs OpenGL tested and generally need hefty hardware to do builds in a reasonable timeframe. We've gotten a few for other projects but we haven't gotten them for this one yet. First up is more macOS and Windows cycles since those machines already aren't keeping up.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 15, 2021 14:52 UTC (Mon) by nix (subscriber, #2304) [Link]

I'm sure you know this already, but the way one does this is to cross-build (or, since that is often difficult, build atop an ARM chroot with binfmt_misc set up to redirect things to qemu-user-arm): this works fine unless your build process requires something like extensive multithreading that qemu-user still does badly (so, 99% of build processes are fine). Then tests, and only tests, are run via ssh to an SBC which shares that chrooted filesystem with the host (and it's not as though OpenGL-capable SBCs are hard to find or costly, though if you want one with open source drivers that might be harder). This is not even slightly new in the embedded world: DejaGNU has long supported this model via its "remote board" concept.

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 22:35 UTC (Mon) by roc (subscriber, #30627) [Link] (2 responses)

Yes. Rust at least supports several platforms as "tier 1" where tests are run and work is gated on tests passing. https://doc.rust-lang.org/nightly/rustc/platform-support....

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 23:15 UTC (Mon) by pizza (subscriber, #46) [Link] (1 responses)

Rust isn't saying that "we support on any random x86_64 Linux system" -- instead they are saying "we test on x86_64-unknown-linux-gnu 64-bit Linux (kernel 2.6.32+, glibc 2.11+)" with the unspoken implication of "if you're not using this, you're on your own."

In other words, deviate from that very-under-specified platform definition and you'll end up in a position where Rust "just compiles, maybe runs semi-reliably, and certainly has no particular guarantee that it actually runs as intended."

Given that most Linux users get their Rust toolchain from their distribution instead of upstream, they're all in the "no particular guarantee" territory since the distro build hosts are not configured identically to the upstream rust CI systems.

Mind you, that's not a bad thing in of itself, and it affects pretty much all distributed-as-source software [1] There's no particular guarantee that it worked on anything other than the original developer's system. Heck, even that's not guaranteed, if one reads the actual license text.

If upstream supplies a test suite then that can be used to build confidence that the software will "run as intended" on relatively random systems, but otherwise, caveat emptor.

[1] Granted, Rust is unusual in that it actually does need to know about the underlying CPU architecture and operating system/syscall interface..

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 23:45 UTC (Mon) by pizza (subscriber, #46) [Link]

Oh, I should clarify -- I'm not saying that Rust is somehow deficient here; quite the opposite! They make it very clear what they consider "supported" and provide a test suite that anyone can use to (reasonably) guarantee that things can still be expected to work if you deviate from the supported platform configurations.

This is the same situation where most F/OSS projects arguably fall; the authors only "guarantee" it works on the platforms they use for development, with some sort of test suite that is used to build confidence that can be expected to work on a relatively random system that still meets the minimum requirements.

But that doesn't somehow make compiling and using this software on relatively obsolete platforms "security theater".

Woodruff: Weird architectures weren't supported to begin with

Posted Mar 1, 2021 22:24 UTC (Mon) by JoeBuck (subscriber, #2330) [Link]

No, I didn't miss it, not after decades of participating in gcc development back when many more active architectures were in use than currently, because it was the height of the Unix wars then (I 'm no longer active in gcc and haven't been for some time). Often bugs would only show up on some platforms. If there's an issue that only shows up on one platform, it might be an invalid assumption, it might be a compiler bug. Bugs on the minor platforms didn't hold up releases; upstream cannot promise that ports will work and can't pretend to. The major platforms had organizations willing to support developers using those platforms, the minority platforms were on their own. That was always understood. But embedded platforms are more likely to have unusual processors.

Pretty much the entire reason for the fight the author's rant is responding to has to do with lack of Rust support on some platforms. The point is that this is a fixable issue.