> that's just when plugging in a USB 3 device into a USB 2 port
Dell XPS laptops (and some others) can also warn if the charger isn't providing the full wattage the laptop is rated for. This warning is an option that can be turned off in the BIOS settings.
I usually turn it off because I sometimes intentionally do day trips with a smaller/lighter portable charger which delivers 45w to my laptop which can need up to 65w due to having a discrete GPU. However, 45w is more than sufficient to charge the laptop during normal use on the Balanced power plan with iGPU. I only need more than 45w when gaming with the discrete GPU active.
Just this morning, my old Latitude failed to boot with a “this charger is only giving 20W and that’s not enough to boot this laptop” error. (I was testing a new USB-C charger that’s obviously going back.)
Weirdest part was it was 100% charged, so could have booted with 0 Watts of charger but decided not to boot with 20 Watts more.
Oh, refusing to boot at all is evil. I've never seen that.
Sure, you or I would just unplug the charger and run on battery but bad UX decisions like that generate a support call to me from my 95 yr old mom. It should not only warn and continue to boot, it should use whatever power is on offer to reduce the rate of battery drain.
My wife's work laptop gives this stupid warning anytime any USBC charger is plugged in, other than the Dell brick. So even a dock delivering 100w would get a complaint. The Dell brick offers non-standard charging at 140w, which can't get replaced by standards compliant, smaller chargers.
With https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.
`openat` has basically solved that since 2.6.16 (which came out in 2006). There are still some uncommon APIs have been slow to gain `at` variants but there's usually a workaround (for example, `getxattrat` and family were only added in 6.13 (this January), but can be implemented in terms of `openat` + `fgetxattr`)
This is good because the current directory conceptually process wide for the user as well. If your program isn't a shell or performs a similar function then you probably should not change the working directory at all.
If you need thread-specific local paths just use one of the *at() variants that let you explicitly specify a directory handle that your path is relative to.
Technically, it's true, as far as I am aware. Android has low level functions which themselves then directly call Linux, but you are not allowed to make a direct Linux call.
In the Android-y part of Android, yes, they use ART, which is abstracted.
But, they also give app authors the NDK. How do you think Android knows whether it's libc or your app making a syscall from native code?
It doesn't - you're allowed access to full Linux-land. The syscall numbers and userland EABI for Android are the same as for any other Linux. They use a different `libc` from most GNU/Linux (one of a few places this wonderful turn of phrase actually makes sense) flavors, but this is no different from Alpine Linux using `musl` instead of `glibc` for example.
As such, you can use `musl`, `glibc`, or non-libc based environments (Rust, Zig) on Android without issue. You can run any C you want, either by porting it to `bionic` (most termux apps, although they support glibc now), statically linking your own runtime (Rust, Zig, etc.), or abusing the dynamic linker into making glibc work (termux-glibc, I think).
Yes, but there are strict SELinux policies forbidding you from accessing certain "dangerous" stuff like execve(), which may end up killing native terminal emulators like Termux (despite Android not forbidding dynamic code execution elsewhere, Play Store policies aside).
Sure, and this VM solution is the exact path forward for “install stuff in a box” solutions as Android move towards trying to enforce w^x, which is probably why they chose a full Linux VM as their demo app. Emulators and games and apps with embedded JIT will be harder to deal with.
What do you imagine happens when you call fopen()? At some point there's a transition from user mode into kernel mode. What can the system do to prevent normal "app" code from making the transition but not "low level" code, when it's all user mode stuff running in the same process?
What exactly is it you're "right" about? How do you think any libc wrapper or direct syscall works? Syscalls are filtered for security reasons on many platforms, including Android. I mean, a syscall is literally an API itself to get a kernel's internals to do something for you.
What you're suggesting is, as someone else said, non-sensical. Phrased without invincible ignorance, it's equivalent to saying, "Android prevents you from creating a new OS kernel to supplant its own control over hardware access," which is true of basically any OS. How helpful or secure would it be if you could make 0 guarantees about how your hardware is used?
You can do direct hardware access through drivers that are integrated/interfaced with the kernel somehow, but this still is not an entirely arbitrary access, and is still going through the kernel in a way.
1 - Core system firmware data/host platform configuration; typically contains serial and model numbers
2 - Extended or pluggable executable code; includes option ROMs on pluggable hardware
3 - Extended or pluggable firmware data; includes information about pluggable hardware
4 - Boot loader and additional drivers; binaries and extensions loaded by the boot loader
7 - SecureBoot state
8 - Commands and kernel command line
9 - All files read (including kernel image)
Now the problem is, 8 and 9 I would argue are the most important (since technically 7 probably covers everything else in that list?), whereas my kernel and initrd are not encrypted and my command line can just be edited (but normally wouldn't need to be). But I can't find anyway to get grub, from a booted system, to simulate the output of those values so I can pre-seal the LUKS volume with the new values.
So in practice, I just always need to remember my password (bad) which means there's no way to make a reasonable assessment of system integrity on boot if I get prompted (I'd argue also the UI experience here isn't good: if I'm being prompted for a password, that clevis boot script should output what changed at what level - i.e. if secure boot got turned off, or my UEFI firmware changed on me when I'm staying in a hotel, maybe I shouldn't unlock that disk).
> You can mitigate this by including PCRs that sign the kernel and initrd.
No, that's not an effective mitigation. The signed kernel+initrd would still boot into the impersonated root.
> however it means whenever you update you need to unlock manually. On Redhat-based distros this can be done with PCRs 8 and 9, though IIRC this may change on other distros.
> Also AFAIK there is no standard way to guess the new PCRs on reboot so you can't pre-update them before rebooting. So you either need to unlock manually or use a network decryption like dracut-sshd.
For multiple users on the same server it was IMO well designed. Everyone had their ~ and could place whatever libraries/binaries/etc. in there and do whatever they wanted.
Package managers are way more modern than that and their design does by itself not require root (see pip). You can in fact run most package managers without root, you just won't be able to modify system files. You can use them to install a chroot as regular user, e.g. `zypper --installroot ~/tw install bash`.
FUSE doesn't really relate to single vs. multi-user AFAICT.
Users are perfectly sandboxed if you configure the system that way. Depending on the distribution that's even the default.
This is largely a package manager problem. There is a way to run Homebrew (the package manager widely used on macOS) on Linux in a rootless mode, and it will install packages into your home directory no problem.
It’s a good trick to have in your back pocket if you’re given an unprivileged user on a compute node and want to make use of modern tools.
> You can in fact run most package managers without root
It is very clear from the context that dehrmann was talking about Linux distro package managers (Apt, Yum, Dnf, Apk, etc.) and as far as I know they all require root, or at least I have never once seen someone use them without root.
I figured most package managers (brew, pip, nix, npm, etc.) are not actually one of the few Linux distro package managers. You listed them almost exhaustively after all (excepting pacman).
Right but as I said from the context it was clear he was talking about distro package managers, not language package managers.
Nix requires root (at least by default). Brew I'll give you - I didn't know you can use it on Linux. Do people actually do that enough that it works reliably?
> We love to praise Unix, but it wasn't built for modern multi-user use. FUSE was an after-thought. So were package managers, and they got added, but they require root.
reply