Hacker Newsnew | past | comments | ask | show | jobs | submit | champtar's commentslogin

Good news that it was found and fixed, but 140 days response time seems rather slow for such a critical vulnerability

probably due to low exposure

Curious what are the main benefits ? (I've only ever used DD-WRT and OpenWrt)


I use Tomato too, but I wouldn't say it offers many benefits over OpenWrt. The main thing is that routers based on Broadcom chipsets often only work with very old Linux kernels (such as 2.6.xx kernels), as the drivers are closed source. For these routers, the primary third-party router OS choice is to use Tomato.


In OpenWrt there is ujail, you give it an ELF (or multiple) to run, it'll parse them to find all the libraries they need, then it creates a tmpfs and mount bind read only the required files. https://github.com/openwrt/procd/blob/dafdf98b03bfa6014cd94f...


2 big address block that have few chances of conflict:

- CGNAT 100.64.0.0/10

- "Benchmark" 198.18.0.0/15


CGNAT is used by Tailscale and presumably in the wild for its intended purpose.


And `100.115.92.0/23` is used by ChromeOS for PatchPanel: https://chromium.googlesource.com/chromiumos/platform2/+/mai...


You can easily keep the current naming behavior with the 'net.naming_scheme=' kargs


I already have systems that use net.ifnames=0. My question is about whether this new behavior can affect them.


It'll not, the new behavior is just a new naming scheme, and you just choose not to use any, which is totally fine if you have a single NIC.


Hopefully the last breaking change.

enoX should always stay stable, as it's the BIOS (in some ACPI table) telling that this device/port has this ID.

ensX means the NIC in PCIe slot X, but in your PCIe tree you can have PCIe bridges, so technically you could have multiple NIC in the same slot (what the BIOS declare as a slot), so there was a lot of breaking NIC naming changes over the years in systemd to figure out the right heuristics that are safe, enabling/disabling slot naming if there is a PCIe bridge, but just in some cases.

Also for historical reasons the PCIe slot number was read indirectly leading to some conflicts in some cases (this was fixed in systemd 257)


>Hopefully the last breaking change.

Every year's cope with systemd.


I once had to maintain a CalDAV server that was developed in house, computing the "free busy" with recurring events, exceptions, different timezone than the organizer + some DST is a bug source that keeps on giving.


https://github.com/rustic-rs/rustic?tab=readme-ov-file#stabi...

rustic currently is in beta state and misses regression tests. It is not recommended to use it for production backups, yet.


If you want to use some object storage instead of local disk, rclone can be a restic server: https://rclone.org/commands/rclone_serve_restic/


I remember when contactless was introduced in France, someone from the CB bank card group (https://en.m.wikipedia.org/wiki/CB_Bank_Card_Group) said that contactless was secure because you are insured. At that time France was already using chip+pin for a while.

At the end of the day the money only goes from one bank account to another, account can be frozen, charge reversed, ... So you just need to secure the POS enough that user feel safe to use it and there is a low number of people that can hack them and are willing to risk prison.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: