> 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).
As far as I know virtually all of the EFI vars will be stored on battery-backed NVRAM, so the usual solution is to just clear that, by removing the CMOS battery. I am pretty sure the only solution are things you definitely can not read or write from the host OS (e.g. BIOS passwords.) Does require partially disassembling the laptop though, and I know there's at least a couple random models of laptop that actually stop working if you clear the NVRAM (lol)
> 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.
Correct if you don’t have your phone, you’re doomed. This can happen for a variety of reasons and is not an uncommon use case. Theft, damage, upgrades, etc.
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.
Is the kennel driver code not available for the Community to take over the process of mainlining? If that gets done then surely the user-side code will work with all future kennels that contain the driver?
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.
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.
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.
Anyway ... I'd totally encourage everybody to donate to opensource projects and/or its maintainers. Whatever the effect may be, but I think that's just simply appropriate.
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.
tim, this is hackernews, everybody here makes six digits! jokes aside - when donating one should of course consider one's paycheck size. you don't have much, give a little; you have more, give a lot.
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).
reply