Heya,

How trustworthy is the local-only aspect of matter-protocol smart-home devices?

I see how the device -bridge-internet approach provides a filter and it's probably better than whitelabel http devices.

But are these really better for telemetry and spyware, when the firmware is still a black box?

Thanks in advance

Heya,

I'm trying to go through Europe in Co-Maps. Particularly, I want to use offline maps to avoid aggressive roaming fees during one part of my route, as well as have a robust backup if online maps breaks. This seems to work great in preparation so far.

One thing I'd like to account for, is that driving through Switzerland is very expensive. I would rather want to detour slithly south through Austria, but I can't find a good way to communicate that to the app. I could try with some intermediary stops, but that seems like it would muddy the routing algorithm even more.

Is there a way to prefer/avoid areas or countries? Or a way to prepare a fitting route externally in advance, then reliably have it work in the app?

Thanks in advance.

Heya,

I hope that title isn't too confusing. I recently set up a custom Arch install (Niri, Noctalia, SystemD) and noticed that a lot of WMs/DEs offer to control display brightness with ddcutil. Display control protocols (HDMI-CEC, DPMS, DDC/CI) are somewhat of a topic to me, though my current monitor only speaks ddcci.

I was now wondering why there isn't a daemon, or other centralized way to turn on/off the display when appropriate? Such as boot/shutdown/sleep/resume/power-saving. I can use the D6 feature in ddc to control the power-state. I can even rig a systemd-unit to somewhat do this automatically.

But there doesn't seem to be a comprehensive framework, where I can go "this command is off, this command is on" and it places the calls in the right places. Which is strange. I get that standby exists, but I don't want to leave it in standby for long periods.

Am I missing something?

Thanks.

cross-posted from: https://discuss.tchncs.de/post/52471022

I know most people here are US, but I wanted to ask if anyone had experience with wero-wallet.eu?

On the grounds of sovereignty, it's exiting. But it's already made so many wrong turns in terms of independence.

• The app is only available in first-party app stores. Not even a closed-source direct download on their website.
• It's fully in play integrity/Apples keychain. With no statements about alternatives.
• They have openly announced that they treat custom-roms as rooting/jailbreaking and deem it unacceptably unsafe for running the app.
• This will probably keep being the blanket statement it always is. Doubt even Graphene with it's attestation will be accepted. And for some reason non-mobile clients are of course out-of-scope.

I wish there was at least a clear reasoning for what's safe/unsafe in this context. My fiat bank is blocking rooted devices, but for now tolerates all custom roms without relying on integrity API or a Google account if you don't try to use GPay. To my knowledge Paypal is completely ignorant about the runtime environment with no checks whatsoever. All the while, Wero seems to actively grasp for straws on reasons why you can't use it on any given phone. They even have special requirements for running on older devices (<A10).

I know most people here are US, but I wanted to ask if anyone had experience with wero-wallet.eu?

On the grounds of sovereignty, it's exiting. But it's already made so many wrong turns in terms of independence.

• The app is only available in first-party app stores. Not even a closed-source direct download on their website.
• It's fully in play integrity/Apples keychain. With no statements about alternatives.
• They have openly announced that they treat custom-roms as rooting/jailbreaking and deem it unacceptably unsafe for running the app.
• This will probably keep being the blanket statement it always is. Doubt even Graphene with it's attestation will be accepted. And for some reason non-mobile clients are of course out-of-scope.

I wish there was at least a clear reasoning for what's safe/unsafe in this context. My fiat bank is blocking rooted devices, but for now tolerates all custom roms without relying on integrity API or a Google account if you don't try to use GPay. To my knowledge Paypal is completely ignorant about the runtime environment with no checks whatsoever. All the while, Wero seems to actively grasp for straws on reasons why you can't use it on any given phone. They even have special requirements for running on older devices (<A10).

Hey there, I'm setting up my first custom arch install, having used Opensuse/Fedora/Tuxedo in the past with grub.

For now the arch install lives in a QEMU playground, but should eventually share an esp with Windows and Tuxedo. (I plan to shift Tuxedo from Grub to systemd-boot beforehand though)

For a this new setup, I've chosen systemd-boot and mkinitcpio with linux-lts. I've got the loader configs for sd-boot working with some trial&error. The default preset in mkinitcpio is still not doing what I want though.

Part of this is just me not understanding mountpoints in Arch. I'm used to the esp being mounted to "/boot/efi" with kernels and ramdisks living in something like "boot/efi/arch/{kernelver}-{kernelname}/kernel.img" and executables/UKIs living in "/boot/efi/EFI/Linux/arch/uki.efi". It seems that packages for kernels and ucode are hardcoded to the esp being at "/boot". Which does mess with me, but so be it. Mkinitcpio also has a disabled preset to put UKIs in "/efi", a mountpoint I have never seen used. Given that it references an "EFI"-folder in there, this seems to also want to be the esp-root.

Could someone explain the mountpoint setup in arch to me? And also, is there a point/way to bend the paths to use /boot/efi, or am I better served to just mount the esp at /boot and accept the difference?

Thanks in advance.