> Debian has maintained both EOL'ed docker images and still-functioning fetchable package archives at the same URLs as 14 years ago. Debian FTW.
[deleted]
Retrobootstrapping Rust for some reason
31–40 of 54 posts
Re: Retrobootstrapping Rust for some reason
#32Can’t say I’m a fan of Nix evangelists pointing their finger at any problem and yelling how it would be solved better by using Nix, but in this case, one could pin a nixpkgs version and all the sources for llvm, gcc and ocaml, and thus have a reproducible bootstrap. Ultimately, it wouldn’t do anything different to what was done manually here, but pinning commits will save the archaelogical burden for the next bootstr…
Does re bootstrapping Rust like this actually work? How much work is it?
Lots of work, you need hundreds of steps across the snapshots, and patches for each one to get them to work. (E.g., the makefile had hardcoded -Werror for ages.) Not to mention that if you want to make it portable, you must always start with the i686 version and cross-compile from there. (Preferably leaving x86 as late as possible: the old LLVM versions are full of architecture-specific quirks.)
Re: Retrobootstrapping Rust for some reason
#33Earlier quoted context omitted.
I think we must have some software in use for which the compiler or the source code just isn’t around anymore. It probably isn’t a massive problem. There’s just a slow trickle of tech we can’t economically reproduce, but we replace it with better stuff. Or, if it was really crucial, it would become worth paying for, right?
There was a story where Microsoft patched a program for which they likely lost the source: https://www.bleepingcomputer.com/news/microsoft/microsoft-ap...
Complete speculation: They might not have had it in the first place or might not have had legal license to modify it themselves. The About Box shown in the article implies Microsoft just licensed MathType from Design Sciences, Inc. DSI got acquired by WIRIS just a few months before that in 2017 which may also have had something to do with it: https://en.wikipedia.org/wiki/MathType
Re: Retrobootstrapping Rust for some reason
#34The difficulty in reproducing builds and steps even from a time as recent as 2011 is somewhat disturbing; will technology stabilize or is this going to get even worse? At what point do we end up with something in-use that we can’t make anymore?
The telephone network was famously thought to be impossible to bootstrap even 50 years ago. We won't ever be able to "black start" our computers unless someone cares enough to put money and effort into it. (Also all technological civilisation is somewhat self-dependent e.g. do you think it would be possible to make microprocessors without running computers?). Possibly reproducible build efforts and things like Guix will make it happen.
Re: Retrobootstrapping Rust for some reason
#35Earlier quoted context omitted.
Is mrustc "simple" enough? Its purpose is as you describe, and it can bootstrap rustc to version 1.74.0. https://github.com/thepowersgang/mrustc
No it can't. Not for RISC-V/musl, so I'm sure that must be true for other platforms too.
Once you've compiled it for one platform, you've re-bootstrapped it, at which point you can use the real compiler to cross-compile for another platform.
Re: Retrobootstrapping Rust for some reason
#36Why do I have to use a VPN and pick a US server to access this article?
Re: Retrobootstrapping Rust for some reason
#37> Modern clang and gcc won't compile the LLVM used back then (C++ has changed too much) Is this due to changing default values for the standard used, and would be "fixed" by adding "std=xxx" to the CXXFLAGS? I've successfully built ~2011 era LLVM with no issues with the compiler itself (after that option change) using gcc last year - there were a couple of bugs in the llvm code though that I had to workaround (mainly…
Well, one thing I've noticed about LLVM is that it blatantly and intentionally relies on UB. The particular example I encountered probably isn't what causes the version breakage, but it's certainly a bad indicator. That said, failures in building old software are very often due to one of: * transitive headers (as you mentioned) * typedef changes (`siginfo_t` vs `struct siginfo` comes to mind) * macros with bad names…
Rather ironic it relies on UB given the extent to which Clang + LLVM insists on interpreting UB in the most creative way possible to optimize code…
Re: Retrobootstrapping Rust for some reason
#38Earlier quoted context omitted.
You're not the only one getting blocked. I emailed dreamwidth about this in the past and they say it's something their upstream network host does and they cannot even fix it if their site users wanted to fix it. They're a somewhat limited and broken host partially repackaging some other company's services. >Dreamwidth Studios Support: I'm sorry about the frustrations you're having. The "semi-randomly selected to solv…
This needs to be a catchy name, but I don't have a good one. CloudFlaritis? CloudFlareup? (CloudFlareDown?) Regardless of whether Cloudflare is the particular infra company, the company who uses them responds to blocked people: "We don't know why some users can't access our Web site, and we don't even know the percentage of users who get blocked, but we're just cargo-culting our jobs here, so sux2bu." The outsourced…
I'd say Clownflare, but that sits too close to Clown Care, who do really great work.
Re: Retrobootstrapping Rust for some reason
#39Is there, or could there be, a simple implementation of a compiler for the latest full Rust language (in C, Python, Scheme/Racket, or anything except Rust) that is greatly simplified because , although it accepts the latest full Rust language as input, it assumes the input is correct? Could this simple non-checking Rust implementation transliterate the real Rust compiler's code, to unchecked C, that is good enough fo…
To some extent, sure - but Rust leans heavily on static analysis even for "simple" code. Something as fundamental as File::open is still generic over "types that can be coerced into a &Path" - which is obviously useful, but it probably means you would need to implement a lot of the type system (+ stubbed out borrow/reference semantics?) just to get rustc's parser bootstrapped.
This is actually tenable for C, though - so maybe you could cook up some sort of C -> C++ -> LLVM -> rustc bootstrap.
Re: Retrobootstrapping Rust for some reason
#40Not sure why, but I am getting 403 Forbidden, so if you are getting the same here's an archive.is link https://archive.is/UH5fg
You're not the only one getting blocked. I emailed dreamwidth about this in the past and they say it's something their upstream network host does and they cannot even fix it if their site users wanted to fix it. They're a somewhat limited and broken host partially repackaging some other company's services. >Dreamwidth Studios Support: I'm sorry about the frustrations you're having. The "semi-randomly selected to solv…
It works just using a VPN and picking a US server. The internet is becoming one giant reverse firewall.