jrgd

It does depend on the connection type, but the general rule is not completely, barring some connection types like DSL. Given it sounds like you have Fiber, DOCSIS, or similar; you likely fall under the general rule. That said, you can absolutely tune and test above the typical 10-15% safety margin many guides start with without actually incurring any noticeable bufferbloat. The 10-15% is usually a good value for ISPs that fluctuate heavily in available babdwidth to the customer, but for more consistent connections (or for those that overrate high enough that the bandwidth fluctuations sit out of range for what the customer is actually paying for), you can absolutely get much closer to your rated connection speed, if not meeting or even passing it.

The general process is to tune one value at the time (starting with the bandwidth allocations for your pipes), apply the changes, noting the previous value, and performing a bufferbloat test with Waveform’s or others’ testing tools. Optionally, (this will drastically slow down the process, but can be worth it) one should actually hammer the network with actual load for a good few hours while testing some real-world applications that are sensitive to bufferbloat. Doing this between tweaked values will help expose how stable or unstable your ISP’s connection truly is over time.

Yeah, not having cake sqm is the one thing that will probably kill Opnsense as a choice for some people. That’s not to say you cannot get excellent results with fq_codel, because you absolutely can (I actively use both OpenWRT and OPNSense on different network applications personally). It is definitely more work to get good results though. OPNSense’s wireguard support has been excellent for a number of years now, and it’s exclusively what I use for tunneling in a VPC I rent.

If you’re particularly constricted on host hardware and need a lightweight router to manage multiple other VMs on said host, I could definitely see the benefits of running a minimal OpenWRT over OPNSense in that case.

I mean, the mini PCs don’t come with a managed switch, and often without good wireless connectivity that most home routers will come equipped with. So in total with Wi-Fi APs and a decent switch, definitely more than €100 in total.

Also unrelated, but if you’re running a x86 system with gigabytes of RAM, why not run Opnsense at that point?

Looking up the router, it was allegedly produced in 2024, according to the OpenWRT wiki. Barring any outliers, OpenWRT generally only sunsets hardware when a new version has higher hardware requirements than is provided by a device. The supported devices page lists out the hard requirements as well as recommendations. Currently 8 MiB flash storage is the minimum, with 16+ MiB recommended (for additional functions, user addons, etc.). 64 MiB is the minimum RAM target, with 128+ MiB recommended. According to the router’s wiki page, your chosen router exceeds both recommended requirements. Overall, the router should be suitable for a good while not barring any severe hardware or bootloader-level exploitable vulnerabilities are discovered with the device. There is no explicit date of when your router will no longer be supported, but you can check the history of the supported devices page to get the general trend of when OpenWRT bumps up the minimum requirements. For instance, it was just 4/8+ MiB flash storage and 32/64+ MiB RAM in early 2017.

Depending on what you want to do with the router, getting something with more RAM and a stronger CPU could be beneficial for various tasks (e.g. adblock-fast, cake sqm, etc.). Definitely do research on what you want your router to do though before choosing to go with higher specs or not.

With LosslessCut, I’ve had good success with doing keyframe cuts with h.264 footage in MKV containers. Frame cuts end up in broken outputs pretty much every time. There’s also Avidemux, which might be worth a try. More than likely though, if you want frame-precision in your cuts, you’ll have to re-encode, at which point you could use something as minimal as Handbrake or a full NLE editor like Kdenlive.

In reference to the article we’re discussing, I am not entirely talking about vulnerabilities in the implementations, but specifically about the lack of standard security features allegedly not present by design in D-Bus. Namely things like namespace reservation, access controls, and fully-defined transport encryption implementations.

In an environment where desktop security is starting to be taken seriously (see Wayland, freedesktop protocols), D-Bus is lacking by comparison. Pulling from the article, any userland application that implements its own access to the user D-Bus can just dump the contents of your keychain (browser-stored passwords, Signal encryption keys, user contacts, manually stored secrets, etc.). I’d argue that for any untrustworthy application (deliberately run or not), shouldn’t be able to do something like that or otherwise tamper with any application it may feel like.

Flatpak does seem to have ways to limit what applications can access through D-Bus, though I am not entirely sure of the extent of what limits are enforceable. I’ll have to read more into Flatpak’s D-Bus filtering to know exactly what it can and cannot do.

Additionally, D-Bus policies are indeed a form of access control. Unfortunately there are limitations. The first is that they are statically defined config files. If an application desires D-Bus access restriction, the only way for that to happen is if a D-Bus policy file is installed via package manager with the software. Applications are not allowed control over access to their endpoints through D-Bus. Applications can absolutely build an authentication or access control layer on top of their D-Bus endpoints, though without a defined standard this quickly gets into the ‘vendor-specific behavior is encouraged’. (To note, KDE Wallet does this exact thing with an optional access control panel with snitching ability when applications access the user keyring.)

As for the default user session policy (where applications like the user keyring are accessed), things aren’t looking that great. At least on OpenSUSE Leap 16, the session policy is left completely open with zero restrictions by default. This does mean that instead of being standard, every application that wants to use D-Bus is largely left to fend for themselves, which I have no doubt meaning that the level of security afforded can vary wildly between application sets (GNOME, KDE, Hyprland, COSMIC, Cinnamon, etc.). I’d argue this shouldn’t be the case and applications developers shouldn’t have to work around D-Bus in the goal of securely interfacing with it.

To be fair, D-Bus is a protocol. Proper documentation and standards is half of implementation. Without any well-defined standards, a protocol is essentially useless and/or lawless. While not every case of non-compliance is the fault of D-Bus, the general lax nature of how endpoints are intended to be defined as well as the incompleteness for the actual standards applications should adhere to is a significant factor for why many applications are the way they are. In addition to the severe security flaws in D-Bus, this could be written with extensions to the protocol, becoming a new standard. Though if the problems are as deeply rooted as they are, it’s not entirely out of the question to create another standard that isn’t D-Bus.

Revolt rebranded as Stoat and does have voice chat with discord-style hotseat channels available in beta. I still wouldn’t recommend it yet due to client bugs, but it’s getting there.

Realistically, any LTS distro from a netinstaller or minimal image that can use a kiosk compositor like cage. So, the usual suspects of Debian, OpenSUSE, AlmaLinux, RockyLinux (or a derivative of one if the native distro doesn’t support Raspberry Pi). Then you just have cage open the browser of choice on startup (e.g. chromium --kiosk <url>) and you have a lightweight and relatively secure web kiosk.

You’re likely looking for this docs section for Caddy. The failure is the automated request to populate Caddy’s root CA cert to the host system, but obviously failed as it doesn’t have root permissions. As the docs state, if you intend to use the local HTTPS functionality of Caddy, you can manually run caddy trust privileged in order to populate the Caddy root CA cert manually. If you intend to disable the local HTTPS functionality (such as if you’re running Caddy behind a http reverse proxy), you can ignore the mail message.

Certainly glad I had my suspicions of Bitnami rugpulling when constructing my Kubernetes cluster and preemptively stripped out as much as possible from helm charts that relied on anything Bitnami. This is going to suck for a lot of people and organizations given that images like rabbitmq, postgres, oauth2-proxy, minio among many others are affected.

It’s not a full rugpull yet, but not being able to pin versions for the newer security-hardened images is already a huge issue for many pieces of software. Especially for things like not being able to pin to a major version of postgres will cause major problems over time for cluster admins and helm chart developers alike if they don’t migrate to other solutions.

Who knows if (when) Bitnami decides to go further in restricting their images, charts from being free and open. I do wish in the future that more helm chart developers would know the caution that should be taken when trusting anything touched by Broadcom of all companies. Maybe this is the necessary warning sign for many.