timschumi

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.

For a slightly more manageable list, the 590 of those that are or were supported officially are also listed on the LineageOS wiki [1].

[1] https://wiki.lineageos.org/devices/

Not sure where CalyxOS came up in this?

And it doesn't seem like anything newer than ARMv9.2 is available either, no matter the price point.

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.

LineageOS was one of the OG de-googled Android ROMs, renamed a few years after Android Jellybean IIRC.

Existing since 2009 as CyanogenMod and since 2016 as LineageOS, that would have been around the time where Android 7 (Nougat) was current.

PS: Not that we are in any way degoogled, other than what we are forced to by the license.

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.

That's... cool, I guess?

Not for the ones on the receiving end.

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.

There is a guide on how to set up LineageOS for libvirt (i.e. QEMU) [1], but there exist no prebuilt images at this point in time.

[1] https://wiki.lineageos.org/libvirt-qemu

As far as I have heard they have not actually secured partner access for themselves, they just got someone who has access to break their NDA.

:^)

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.

[1] https://x.com/uwukko/status/1970161297783238905 [2] https://x.com/theo/status/1970266199469810127

Couldn't try to (together with Theo / t3) bully the Homebrew developers into a forced takeover of a package [1] if it were a conflict-free name.

[1] https://github.com/Homebrew/homebrew-cask/pull/229061

My main complain by far to LineageOS is the necessity to wipe everything for major releases on my S10. That's not possible every year.

Are you sure that you are not just misinterpreting the upgrade instructions?

For the S10 a mandatory wipe-on-upgrade has last been the case when upgrading from versions _older than LineageOS 21.0_.

During the time where LineageOS 20 was the current version there was no requirement to wipe listed at all, so presumably it didn't exist then.

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.

[1] https://news.ycombinator.com/item?id=44498614

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).

But that's still not a circular dependency then, that's just the normal case for "I lost all my verification options" and it's exactly what the last option is for.

If I create an account via e-mail and password at a random service, destroy the password and delete the e-mail account, then it's not a circular dependency. In fact, the service has nothing to do with it, it can not know that you don't have access to either the e-mail or the password.

There is no circular dependency.

Notifications and prompts are going to show up on your old iPhone, and you got some 2FA backup codes when enabling your 2FA authenticator.

Prebuilts of various LineageOS apps are available here: https://www.sebaubuntu.dev/lineageapps.html

The user-side will work with all kernels that contain the matching driver, but the user-side will not necessarily work on future Android versions without modification.

The kernel side of drivers is already published under a FLOSS license, it's just that the code quality is usually subpar and the important changes are crammed into a tarball together with (sometimes) millions of other lines of changed code.

The sources for the matching userspace binaries (which are usually the issue for Android version bumps) are usually under NDA by the component manufacturer and can not be released by the OEM independently.

There also is an updated version with fixes that never got merged into upstream Heimdall: https://git.sr.ht/~grimler/Heimdall

GrapheneOS only supports devices that are still supported by the OEM, and they generally seem to have very few modifications that touch on frequently-changed parts of AOSP. In short, they can be relatively certain that nothing will break when they rebase, Google does the work for them.

On the other hand, LineageOS runs a lot of devices at the very (lower) edge of compatibility, which means that (with Google pushing large changes quarterly instead of yearly) the build roster has to be reevaluated quarterly instead of yearly as well. This was not anticipated properly for the Android 14 (LineageOS 21) cycle, which resulted in 19 devices not being able to be built on a previously supported major version (and therefore dropping from the roster completely).

In addition, the components that have been causing rebase conflicts each year now have the opportunity to cause rebase conflicts multiple times a year.

Yes, donations are cool, without them there probably wouldn't be as many build servers (among other things).

However, if donating means that you have to consider your current paycheck size, then it might be more appropriate to put that idea on the back-burner for a while.

If you don't have to make that consideration and/or you feel strongly obligated to donate, then by all means, please do so.

To quote from somewhere else:

Just to emphasize this for anyone else who is reading this: Please do not feel obligated to donate.

Yes, it is greatly appreciated, since it keeps the lights on a little while longer and allows us to provide builds and host continued development. However, we regard donations as having no strings attached, and the same applies for using the builds that we provide.

We will be fine, at the very least for a while. Please think of yourself first.

Apart from the fact that this probably isn't common knowledge, this article is from 2021 (which the OP failed to disclose).

Why not be mad at IEEE for a change? They apparently only managed to ban use of the image in April of 2024.