If you are talking about the addition of microG, that indeed seems like it hasn't been mentioned on the blog, although I'd argue very likely due to an oversight.
I can find internal conversations that it deserves to be announced in a more prominent way than on the "Sunsetting LineageOS 18.1" post, was left as "to be added to the LineageOS 22.x" blog post, and then just never made the initial draft. Whoops.
If you are talking about the rules on the subreddit (or the other social platforms), that one indeed has been discussed a lot on the platform itself (and which we usually keep available).
> They stopped that malpractice a while ago (last year?).
By now it has actually been almost two and a half years.
> But they really hurt their credibility with the prior stance, and that their subreddit still has rules forbidding almost all discussions [...].
While I'm not looking to turn this into an off-platform meta discussion, pretty much all of those rules have their very good reasons to be there.
As an example, you would be surprised how many people install a Magisk module to strip away LineageOS-specific build version properties, and then end up in our support platforms asking why the Updater can't search for new updates (of course while not mentioning that they have modified their system).
microG I don't even see listed as a part of any rule anymore, it was removed when upstream support for microG was merged.
Every system and package manager will be affected if it cannot download source code to build a package.
NixOS less so, because pretty much all source downloads that are not restricted by license are a separate output that will therefore be stored on (and downloadable from) NixOS cache servers.
I'm not sure what your expectation for this is in general, nobody can just wish into existence data that is just gone.
It's unfortunate that he uploaded this without notable commit history, it would be interesting to see how long it takes a programmer of his caliber to bring up a project like this.
That said, judging by the license file this was based on QuickJS anyway, making it a moot comparison.
> I can't even fathom what the build system is doing in order to require this amount of storage.
A large number of 17 year old repositories, prebuilt toolchains, and the fact that you otherwise have every little bit of source code, intermediary results, and output to create a full operating system all in the same place.
As for the memory, the very first step (that basically already is the benchmark for the most memory usage) is loading the entire build tree and generating build steps. Yes, that takes 32GB of RAM, if not 64GB nowadays.
> What's wrong with asking to expedite the removal process, considering the process is detailed in the guidelines?
Asking is one thing, the other thing is not accepting the decision of a maintainer on a topic that is at the maintainers discretion and instead taking it to social media [1] [2] for it to be brigaded.
Addendum: It additionally appears that this was filed before the browser was even launched, if the Wayback Machine and their social media posts are anything to go by.
Just so that nobody ends up confused: This is the same topic as posted here [1] a week ago, but presented in a blog post series format instead of as a slide deck.
> Screwing up EFI vars doesn't make most systems unbootable. I have corrupted my EFI vars quite a few times trying to do funny things. UEFI implementations do tend to be buggy, but not all of them are that catastrophically bad.
For what it's worth, I have a laptop here that can be irrevocably (short of having a flash memory dump on-hand that can be flashed back) bricked just by messing around with EFI variables through fully intentional operations (i.e. operations that would be available to any program with Administrator privileges on Windows, or the root user on Linux).
> It's already a basically bleeding edge C++. Why is it so much to ask for developers to use a more mature and established iteration so I don't need a brand new compiler?
Because C++ got better and better in recent versions?
You are essentially asking to forego large amounts of improvements that allow for writing more maintainable code, just because you are too lazy to install a compiler that has been released 1 year and 10 months ago (in the case of GCC 13) or 1 year and 5 months (in the case of Clang 17).
I can find internal conversations that it deserves to be announced in a more prominent way than on the "Sunsetting LineageOS 18.1" post, was left as "to be added to the LineageOS 22.x" blog post, and then just never made the initial draft. Whoops.
If you are talking about the rules on the subreddit (or the other social platforms), that one indeed has been discussed a lot on the platform itself (and which we usually keep available).