@niconiconi@whitequark Wait until one actually starts compiling. This is why I have stopped building AOSP on my daily computer and instead do that on my NAS / home server.
@whitequark 153 GB of source tree is something I can hardly wrap my head around... I mean, there's lot of stuff in Android but how can there be so much of it?
(now I feel the need to do a checkout myself and run filelight on it... luckily probably I don't have enough free space for that)
@whitequark I remember building ChromeOS a few years ago and while it did require a huge amount of disk space and the build took forever, it was at least straightforward.
just discovered that my OS was configured to cap the CPU frequency multiplier to 23x, effectively preventing it from boosting up. i wonder why! i removed that and it boosted up to 31x before being thermally limited at 29x
i have no idea why i capped the multiplier. i suppose if the machine crashes i will learn
on careful examination, this laptop's cooling system lets it consistently boost all 16 cores up to no more than 28x, at which point they all sit at a comfortable 90-95 degC without getting noticeably thermally limited, so maybe i should just leave it at that
@whitequark That seems just a tad excessive.
I used to compile kernels on a system with 4MB of RAM.
Then again, the kernel is probably more than 4,000 times as big as it was back then.
I kind of understand the rationale behind adding more features that need more RAM, but I can't get my head around that scale.
@everythingalsocan but you didn't use LTO, did you? that's kind of the important thing here. even ThinLTO requires a fraction of the ~24 GB of memory that a full LTO build of Linux requires
@everythingalsocan usually this is done to get anywhere between 5-20% of performance, but in Android's case, it wants to build a table of every legitimate indirect call to prevent kernel exploits from making indirect calls that weren't supposed to be done; so while I could turn this off, I didn't, it's a rather useful mitigation
@whitequark I was disappointed the Rosetta-on-Ubuntu thing didn't work for the Android build process (somehow, but lol not surprised), bc my MacBook is the first machine I've had w/ 64GiB :(
i love seeing "TypeError: cannot use a string pattern on a bytes-like object" at the end of a 15 minute long process that I can't restart except from the beginning
astonishingly, the firmware i just built not only boots and functions, but it even has Verified Boot with my own keys in it working; I relocked the bootloader and it's now in the YELLOW status (as it should be)
@whitequark i still think that we, as a field, have never invested enough in build systems. Even less build systems and compilers adapted to infrastructure projects like the linux kernel, android, c compilers themselves, virtual machines and interpreters like ghc, beam or various jvm, etc
It always feel like we are still in the 80s and using the same tools. And the only people trying to "work on it" generate... Well. points to Bazel and Nix
@whitequark and don't even start me on the lack of observability and debuggability of build systems.
I have to frigging patch make heavily just to get a graph of the targets that ran. And then run a broken, unmaintained, massive python script on top of it to get something useable. And then use a function tracing graph visualizer to observe it, not adapted to what I need but far better than anything else than exist.
@whitequark and i would love to work on it, i know some of the problem enough and i have some ideas we could experiment with.
But no-one will ever fund me. We already got lucky that Mozilla, of all improbable one, funded Rust for a decade to the point it became useable before firing everyone.
Otherwise even our compilers would still be in the 80s.
@whitequark We need an intervention at the infra level with a 10 to 20 years vision quickly. It would not even be that expensive. Like 10M per year divided over 10 to 20 projects for 10 years would probably double productivity in software. If not also purely eliminate most of our security problems and reduce the entry cost of building a good software product.
@whitequark do you mind if I use your thread about rebuilding Android as a starting point and example for a blogpost? Basically just a rant on how broken it is as shown here, how it costs so much hours especially to FOSS weekend warriors and how we need help for it instead of random "we need to know who you are" infosec supply chain stuff?
@whitequark wow it's like building LLVM on steroids... I was like "I didn't ever think I'd get to thrashing on a machine with 32 GB of RAM, yet here we are"
@whitequark the urge to say "hey lld don't sweat it too much, I'm OK just with compile time optimizations" but then I fear it would be sad to be sidelined and just left to copy bytes around.
@tedmielczarek@whitequark it definitely gets easier, the moment you become a Google partner and get their support.
Besides, this whole mess is a good motivation, to change as little as possible, given that everything else will lead to unimaginable pain.
@mxk@whitequark yeah, I understand the motivation. Much like innumerable other architectural changes I've seen in other software projects—even when well-intentioned, they can have huge knock-on effects in the ecosystem.
@tedmielczarek@whitequark I still hope, Google eventually replaces Linux with Fuchsia under Androids hood, making every single vendor modification obsolete 😬.
Add comment