I've been in this business for a while now, and I continue to be surprised by the extent of how cloud customers are being milked by cloud platform providers. And, of course, their seemingly limitless tolerance for it.
Readit Newsc0l0 commented on Fuse is 95% cheaper and 10x faster than NFS nilesh-agarwal.com/storag... · Posted by u/agcat
c0l0 commented on Debcraft – Easiest way to modify and build Debian packages optimizedbyotto.com/post/... · Posted by u/pabs3
The article touches upon an important point that applies to all complex (software/computer) and long-lived systems: "Too much outdated and inconsistent documentation (that makes learning the numerous tools needlessly hard.)"
The Debian Wiki is a great resource for many topics, but as with all documentation for very long-running projects - at least those that do big, "finished" releases from time to time - it seems tough to strike a balance between completeness and (temporal) relevance. Sure, in some weird edge case scenario, it might be helpful to know how this-and-that behaved or could be worked around in Debian 6 "Squeeze" in 2014, but information like that piling up also makes the article on the this-and-that subject VERY tedious to sift through if you are only interested in what's recent and relevant to Debian 12 "Bookworm" in 2025.
Most people contributing to documentation efforts (me included) seem very reluctant to throw out existing content in a wiki article, even though an argument could be made that the presence is sometimes objectively unhelpful for solving today's problems.
Maybe it would be worth a shot to fork the wiki (by copying all content and have a debian.wiki.org/6/ prefix for all things Squeeze, a /7/ for Wheey, a /12/ for bookworm, etc.) for each major release and encourage people to edit and extend release-specific pages with appropriate information, so readers and editors would have to "time-travel" through the project (anmd problem/solution) history in a more conscious and hopefully less confusing way, and make it easier for editors to prune information that's not just relevant for release N+1 any more.
I'm very open to learning more about anyone's thoughts on how to solve this well: How to keep documentation in "living documents", editable not only by a small group of contributors (like many projects to with mkdocs et al. as a replacement for an actual wiki), but also keep the "historic baggage" both easily discoverable (for when it's relevant and useful, because that does happen), yet not have it stand in the way of all those who will be confused and obstructed by its presence.
c0l0 commented on Wii U SDBoot1 Exploit “paid the beak” consolebytes.com/wii-u-sd... · Posted by u/sjuut
At a social level we should know how to do this well because there are cases where it needs to be done well. Some hardware is operating in incredibly safety critical scenarios where you do want to have strong confidence that it's running the correct software[1].
Should this be shipped to consumers as a default? Fuck no. This technology needs to exist for safety, but that doesn't mean it should be used to prop up business models. Unfortunately there's no good technical mechanism to prevent technology being used in user-hostile ways, and we're left with social pressure. We should be organising around that social pressure rather than refusing to talk about the tech.
[1] and let's not even focus on the "Someone hacked it" situation - what if it accidentally shipped with an uncertified debug build? This seems implausible, but when Apple investigated the firmware they'd shipped on laptops they found that some machines had been pulled off the production line, had a debug build installed to validate something, and had then been put back on the production line without a legitimate build being installed - and if Apple can get this wrong, everyone can get this wrong
Alas, it will virtually exclusively "be shipped to consumers as a default".
I realize it's far from a perfect solution to finance the creators of the only browser I consider usable today - but I subscribed to Mozilla's VPN service some two years ago, even though I virtually never use it, and mostly to help them make a bit of a buck through me. (And still, it is nice to have the option of geoblocking circumvention at the ready, although I'd wish for them to just support "ordinary" wireguard/wq-quick as a client option).
It's mostly about your UEFI firmware coming with a set of trusted CAs to verify bootloader is built by one of the trusted parties like Microsoft or Canonical or Redhat or...
You can turn it off, or make it into trust-once and sign your own bootloader, and avoid the risk of bootkit getting installed ever, except with exploits like these.
It would be fine it were only that. The actual problem is that software vendors can and do use Secure Boot to also check if you, the machine's owner, "decided" to "trust" this set of special CAs - and if you did not (and limited your freedom to execute any code you want in any way you want it on your machine in doing so), make the software you bought/licensed from them - or any other software you would like to run on top of these vendors' platforms - refuse to work on your machine.
I haven't taken this step yet, but I have considered it. Could you recommend whether I should share the service on a list such as dnscrypt.info/public-servers?
I was not aware of such a directory existing in the first place :) I only advertise "my" service (it only implements DNS and DoT) through word of mouth in communities I participate in.
Are there any security risks with sharing it wiyh others?
Well, concerning technical risks, DNS Cache Poisoning[0] is a thing - but I keep the software implementing my recursive DNS service up to date very eagerly, so I guess the risk of falling victim to such an attack is rather low.
[0]: https://en.wikipedia.org/wiki/DNS_spoofing#Cache_poisoning_a...
I concur and generally advise against using large corporate DNS providers. Instead, consider setting up your own DNS infrastructure, such as your own recursive servers, or opt for a trustworthy DNS provider like Freifunk or CCC, rather than Google, Cloudflare, or Quad9.
The advantages of self-hosting recursive servers include complete configurability, absence of censorship, tracking, and rate limits. However, like any self-hosting solution, it requires an investment of time and money. It's also important to note that DNS lacks an authentication layer, so for access restrictions, it should be placed within a private network or VPN.
The issue of pre-configured DNS over HTTPS (DoH) in many browsers and mobile devices can be addressed through firewall rules on your router.
For creating your own DNS infrastructure, I recommend dnsdist if you have ample time, though bind and unbound are also viable options.
For the past three years, I have been running dnsdist with recursive servers on two ARM VPS instances, costing around 14 EUR per month. This setup provides me with DNS over TLS (DoT), DoH, and other features. I use them with unbound (TLS) or dnsproxy and dnscrypt-proxy across routers, servers, and other machines. For mobile devices, I utilize DoH directly.
Previously, I used bind in recursive mode without any encryption beyond SSH tunneling or VPN.
Alternatively, I can recommend ffmuc as a DNS provider.
I also run my own recursive DNS server on a VPS I rent, but I freely share it with other users of the Internet. This causes my "personal" signal of queries to authoritative servers to effectively disappear, and I also (marginally) benefit from caching effects of other users' lookups.