Depending on your DE, you have a choice not to use Wayland. Like, yes, if you use GNOME then you don't get choices but that's their whole ethos, and unfortunately I've heard about KDE dropping X, but there are other options and as I type this comment in i3 I can assure you Xorg still works.
> This is part of the spec, and there are no shipped firmwares that prevents you from going through this process.
Microsoft required that users be able to enroll their own keys on x86. On ARM, they used to mandate that users could not enroll their own keys. That they later changed this does not erase the past. Also, I've anecdotally heard claims of buggy implementations that do in fact prevent users from changing secure boot settings.
And you don't seem to understand how the conversation went. I was obviously talking about my first comment, to which they answered.
> Which comments do you see doing that? Exactly?
Interestingly, those that made me write my first message were removed. Not that it was because of my message obviously, which mostly got me downvotes :-).
But the next best one would be:
"public shaming is the next best thing. I sincerely hope links to this incident will haunt him every time someone googles his name forevermore"
(after implying that ideally they should lose their job for this)
When called out, they deleted the TODOs. They didn't implement them, they didn't fix the security problems, they just tried to cover it up. So no, at this point the dishonesty is deliberate.
No, termux isn't a container, it's running directly in userspace on the host. The only weird thing is that because it's running directly on the host, it has to be built to use unusual paths, eg. /data/data/com.termux/files/usr/bin/bash instead of /usr/bin/bash. If it used containers (which IIRC it can't because Android doesn't really support it) that would actually be easier because then it could use a chroot to make the paths look normal.
Ah, well that stinks a little. I guess it makes sense, if android doesn't mandate a few kernel settings then working with containers might not be an option.
Couldn’t it implement a “fake chroot” by e.g. creating its own libc which wraps the real one but with path remapping, and then linking all its executables against that?
That would only work for things that use libc (so eg. most Go programs are probably not going to work). The main way that you can do an unprivileged fake chroot is proot, which termux does offer - see https://wiki.termux.com/wiki/PRoot - but that has a significant performance hit.
I have seen few cases where UEFI was not actually usable on non-OEM configurations.
In fact, my current ASUS laptop did not allow me to install Windows until I have performed a sophisticated dance to update/flash some sort of low-level disk-related Intel bloatware. The laptop was sold without OS and was accompanied by a small paper referencing a website with instruction how to flash the firmware to actually make the laptop usable.
Notice that, per
https://www.www3.planetcom.co.uk/devices-specification , the newest OS they ship is Android 11. I owned a Gemini and I liked the hardware, but they don't update software and I consider that a deal breaker.
Depending on your DE, you have a choice not to use Wayland. Like, yes, if you use GNOME then you don't get choices but that's their whole ethos, and unfortunately I've heard about KDE dropping X, but there are other options and as I type this comment in i3 I can assure you Xorg still works.
reply