- It is definitely getting stretchy at this point, but there is the point to be made that a lot of roads are built in a way which not only enables but encourages driving much faster than may be desired in the area where they're located. This, among other things, makes these roads more interesting as getaway routes for bank robbers.
If these roads had been designed differently, to naturally enforce the desired speeds, it would be a safer road in general and as a side effect be a less desirable getaway route.
Again I agree we're really stretching here, but there is a real common problem where badly designed roads don't just enable but encourage illegal and potentially unsafe driving. Wide, straight, flat roads are fast roads, no matter what the posted speed limit is. If you want low traffic speeds you need roads to be designed to be hostile to high speeds.
- > I feel like it's easier to just have Ethernet and a strict HW firewall with the admin interfaces totally disabled (have to full reset to get back in).
Easier? Maybe, for certain values of easy, but as others have noted it's not hard to build a data diode setup using fiber ethernet and from there you just have to hardcode some ARP data and maybe a route entry to allow UDP to flow.
The thing is that with your solution as long as the firewall works properly data shouldn't be able to leak in the wrong direction. With a proper data diode, as long as physics continues to function more or less how we understand it you can prove that data can not leak in the wrong direction. That's a huge difference, especially when it comes to explaining what you're doing to non-technical higher ups, auditors, lawyers, etc.
- > 2. If you are an end user reading an XHTML file, it's not your file, it's not your fault if there are bugs, and there's jack shit you can do to fix it. You just want the browser to do its best to show you something reasonable so you can read the page and get on with your life.
Here's the thing though, if all XHTML clients are strict about it then that means the content is broken for EVERYONE which presumably means it gets noticed pretty quickly as long as the site is being maintained by anyone.
Compare that to HTML where if a page is doing something wrong but in a way that happens to work in Webkit/Blink while it barfs all over the place in Gecko it could go ignored for ages. Those of us who are old enough remember an era where a huge number of web sites only targeted Trident and didn't care in the slightest whether it worked in any other engine.
There has to be an opposite to Postel's Law that acknowledges it's better in some cases to ensure that breakage for anybody becomes breakage for everybody because that means the breakage can't be ignored.
- The "No IT Department" part of your marketing immediately turns me off because that's actively encouraging "shadow IT".
We all get that sometimes companies have IT policies which are outdated and get in the way, but that's a problem for someone up the chain to solve. A team or department deciding to just start doing their own thing with something like this which isn't managed by or even known about by the official company IT is at best a path to future problems if not an immediate compliance problem.
- > Modern fire trucks, and police cars usually, are built to be able to push vehicles out of the way.
Not so much police cars, anymore.
Back in the time of the B-Body Caprice and the Crown Vic, sure. These days with the exception of the Tahoe the most common police vehicles are all unibody platforms. Charger, Durango, Explorer, Taurus, and the rare Australian Caprice
You can still bolt a push bumper to them and most departments do, but they have to be used with a lot more caution and a lot less aggression to avoid damaging the vehicle than in the days of body-on-frame sedans.
Fire trucks on the other hand, yeah they're basically the opposite in that there might be a couple of Explorers or Durangos in the fleet but most everything else is a medium duty truck or a custom chassis specifically for fire service.
- > Don’t blame your provider when they deploy CG-NAT, embrace IPv6 and global routing instead.
In theory this makes sense, but in practice my personal experience is that not a single wireline ISP I've ever seen deploy CG-NAT offered IPv6 service at all, nor did any of them indicate any intent or even interest when asked about it.
The mobile providers on the other hand have almost entirely gone IPv6-first, using 6>4 transition methods as the default form of v4 access which I fully support.
4>4 CG-NAT should never have existed and providers who deploy it without offering fully functional v6 should be shamed.
- > (Even for a fully self-hosted system you'd still have to figure out how to interface the certificate renewal mechanism with your DNS provider, so not as easy to set up as individual certificates for each subdomain.)
That's exactly what the new DNS-PERSIST-01 challenge is for, being able to authorize a specific system or set of systems to request certs for a given FQDN and optionally subdomains without having to give that system direct control over your DNS as the existing DNS-01 challenge requires.
- > I'm talking about managing two certificates so I can share a static site with a handful of friends. Each one takes about 10 minutes a year to update.
The personal site I started with is one certificate for a static site that I use for basically the same thing. It took me 10 minutes to set up in 2016 and I haven't thought about it for a second since then. It just works.
> Adding automation means I have to set up a process that I have to check up on at least once every 6.5 weeks to make sure it's still working.
Assuming you're using a common automation package and not rolling your own it should be included. I personally use acme.sh which can be configured to use email, XMPP, or HTTP(S) requests with prebuilt templates for most popular webhooks, as well as supporting fully custom notification scripts. I get an email every time it attempts a renewal that tells me if it succeeded or failed. Again one-time setup, easy, did it once literally almost a decade ago and haven't had to think about it since. As I pointed out in my previous post I did once have two of my systems fail to renew, I was notified, and I fixed it within a few minutes of seeing the emails.
Let's Encrypt also used to send their own emails if a cert was expiring but they stopped doing that this year for a variety of reasons: https://letsencrypt.org/2025/01/22/ending-expiration-emails
Now that I'm actually thinking about the topic, these days for my work systems I have a platform that monitors for periodic updates and alerts me if they don't come in so I should probably reconfigure my notifications to use that instead of email and clean up my team's inboxes a bit by no longer needing to receive a couple dozen "everything's OK" mails every couple of months (or soon, couple of weeks).
- As someone who also grew up on PC speaker, I think it sounds significantly worse than Wolfenstein 3D's PC speaker sound where it of course would be expected to be better than Wolf3D in every way.
I think they could have made something a lot better by, like Wolf, dropping music entirely from the PC speaker implementation. Focus on the sounds that matter.
- For the same reasons as forcing companies to do it.
1. Revocation is a clusterfuck. Microsoft is currently failing to revoke tens of thousands of defective certificates for over seven months (the Baseline Requirements state that they should have been revoked within five days). Entrust was distrusted over repeated failures to revoke. Many TLS clients don't even bother to check revocation lists, or if they do they do it in a "fail-open" manner where inability to load the list does not prevent access which largely defeats the purpose. Short certificate lifetimes make revocation less important as both defective and compromised certificates age out rapidly, but without automation any meaningful reduction in lifetime directly translates to an increase in required effort which makes it a balancing act. With automation, however, reducing lifetimes is effectively free.
2. Automation is mostly a one-time cost. Manual renewal is a repeating cost. I started using LE to add HTTPS to my personal site when it first became available to the public in 2016 and then started using it for my work systems when our GoDaddy certs came up for renewal a bit less than a year later. Since then out of roughly 50 systems pulling around 70 certs I've had to "babysit" two of them once each, both because they were using wildcard certs which I was a very early adopter of and something about how I had set them up was technically wrong but worked in the initial version. Compare this to the "old world" where every couple of years I had to generally engage vendor support on both our server platforms and our CA because it had been long enough that things had changed on both sides so doing things manually required learning new things. Mandating short lifetimes is good for everyone. This is part of why LE has used a short lifetime since the beginning, to strongly encourage people to not try to do it without automation.
3. It's super easy. Lots of platforms have ACME support built in. For those that don't, packages like acme.sh are damn close to universal. If your system is able to expose a web server on port 80 it's basically trivial. If it's not, it's slightly harder. There's just not a good reason not to do it other than stubborn insistence. "Handcrafted TLS Certificates" just don't matter.
- > For this specific regulation, it's illegal to prevent someone who passes physical security screening and has paid their fare from boarding a plane.
Cite? Not that I'm doubting, just never heard this mentioned during the last news cycle around REAL ID when it "went in to effect" months ago. I didn't really look in to it any further as I've had a compliant ID for long enough it expires next year plus a passport so it didn't affect me.
- About six months ago I had a Dell Optiplex motherboard fail and they attempted to schedule a tech to come out the following day. I was not available for that and scheduled it a few days later but they did make as full of an effort as can be reasonably expected to make it happen within one business day.
The default warranty on at least the Optiplex line is one year of next business day service and upgrading to three years is cheap. I've never had a situation where same day service was worth the extra cost but it is an option.
- I have always hated "m." domains for exactly this reason. They almost exclusively go one-way, mobile users get redirected to the mobile domain but desktop users never get redirected back, and all too often not only was the mobile version of the site objectively worse from the perspective of a desktop user but even the link to go back manually was either hard to find or nonexistent.
Wikipedia was one of the worst offenders, but lots of sites screwed this up in exactly the same way, and I feel it was a predecessor to modern "mobile first" web platforms that either treat desktop as second-class users or actively don't want desktop users.
- > Wouldn't that only matter if the bug has no affect on little endian?
I don't know whether this logic applies to this specific sort of bug, but there is a long history of bugs that "don't matter" combining with other bugs to become something that matters. Therac-25 was a bug that didn't matter on the hardware it was developed for, but then the software that "worked fine" got repurposed for another hardware platform and people died. If there's an easy way to identify an entire class of bugs it seems like a good idea to do it.
- > None of that matters for the kind of creative work the grand parent likely had in mind.
Some of that did, at least for how that creative work was almost exclusively delivered to the world. Those bugs were not just excessive resource usage and instability, they were incredibly often exploitable security flaws that were regularly weaponized against a huge swath of internet users. The ubiquity of the Flash browser plugin was simultaneously one of the greatest strengths of Flash as a creative platform and one of the greatest risks to the average person browsing the web in the 2000s.
The plugin needed to die. Unfortunately the Flash community was so firmly built around the web plugin as their distribution method of choice (presumably because many of us were browsing animations and playing games at work/school where we couldn't necessarily download and run arbitrary .exes) that the plugin was more or less a diseased conjoined twin, and when it died the community didn't have long left.
Compare this to Java where the death of the browser plugin caused a number of badly designed banking sites to have to be redesigned in a less stupid (but quite often still very stupid) way but the community as a whole continued on without huge disruption. The browser plugin was just one of many places Java existed, it wasn't the dominant focus of the community.
- There are very few cases where there's a good reason for a printer of any kind to be on WiFi and even less for a receipt printer. If it's being used in a portable application with a laptop or mobile device that's what USB or Bluetooth are for. If it's sitting on a checkout counter and needs to be shared between multiple PCs that's what ethernet is for.
I'm not saying that there are absolutely no situations where WiFi is actually beneficial in a printer, but most of the time that a printer is connected to WiFi it's just making the printer less reliable than it could be if it was connected another way for no reason other than the user not liking wires.
A universal truth of networking: If it can be practically wired it should be wired. Wireless is for things that move and things that need to be put in weird spots it doesn't make sense to ever wire.
- On DOCSIS and PON networks my experience has been that dynamic IPs are generally stable as long as your DHCP lease is active, so my IP generally wouldn't change unless I changed equipment or there was an extended outage that kept me offline during the entire time it would normally have renewed.
On DSL networks it's been the opposite, if the PPPoE session was lost I was definitely going to get a new IP address, and on some providers the session would be reset every 1-7 days so the IP would change at exactly the same time of day which almost always ended up being in the middle of a work day corresponding with whenever the equipment was last rebooted due to some other problem. I got in the habit of setting up my equipment to restart on its own terms in the middle of the night on those providers, but this came with its own downsides when something would go wrong and it'd fail to negotiate.
- Something I'd be very interested in seeing summarized is the current state of fully open source software on SoCs and SBCs. I hate how common the situation described in the nVidia section where SoCs that require vendor kernels get abandoned on ancient software, so it would be very useful to know what SoCs are supported to a useful level by mainline kernels.
I feel like there are three tiers of support that most people would be interested in:
1. Usable for headless appliances (serial console or unaccelerated graphics, wired networking, storage, USB)
2. Usable for interactive use (accelerated graphics, WiFi/BT)
3. Fully supported (all major hardware works)
- Or without an OS installed at all, or with a broken OS.
I do VoIP phone systems for a living and this is why I deploy Supermicro mini-ITX servers, so even if something goes totally sideways as long as the client's IT is competent enough to get me remoted in to their voice network in some way I can troubleshoot it fully and in many cases fix it without leaving my desk possibly half way across the country. If it's an actual hardware problem and I can't fix it remotely I still then know for sure what's wrong and whoever's going on site can be properly equipped for the actual problem rather than having to bring everything.
- > Why bother logging them at all? What is this doing for you?
Logging both successful and failed requests is important for troubleshooting my systems, especially the client-facing ones (a subset of which are the only ones that are accessible to the open internet), and failed authentication attempts are just one sort of request failure. Sometimes those failures are legitimate client systems where someone misconfigured something, and the logs allow me to troubleshoot that after the fact. That it can also be fed to fail2ban to block attackers is just another benefit.
> You can't meaningfully characterize attacker traffic this way. They'll come from any AS they want to.
Obviously in a world full of botted computers, IoT devices, etc. it's true that an attacker can hypothetically come from anywhere, but in practice at least from the perspective of a small service provider I just don't see that happen. I'm aware that you are involved with much larger scale operations than I'm likely to ever touch so perhaps that's where our experiences differ. No one's targeting my services specifically, they're just scanning the internet for whatever's out there and occasionally happen to stumble upon one of my systems that needs to be accessible to wherever my clients happen to bring their devices.
Sure, I see random domestic residential ISP addresses get banned from individual servers from time to time, but I never see the organized attacks I see which are usually coming from small hosting providers half way around the world from my clients. I have on multiple occasions seen fail2ban fire off rapidly sequential IP addresses like xxx.xxx.xxx.1 followed by xxx.xxx.xxx.2 then xxx.xxx.xxx.3, or in other cases a series of semi-random addresses all in the same subnet, which then triggers my network block and magically they're stopped instead of just moving on to another network. If I were to be packet sniffing on the outside of the relevant firewall I'm sure I'd see another address in the blocked network trying to do its thing but I've never looked.
- I'm with you on the automatic lock/unlock and full-touch controls, I don't like either of those design choices in cars and I don't want them in a bike either.
That said a GPS locator is great on an e-bike. They're high value theft targets, anything that makes them harder to steal, easier to track, or otherwise reduces the appeal of stealing one is a good thing.
Hydraulic disc brakes are a great thing even on non-electronic bikes. I won't buy another bike without them. My hardtail mountain bike, gravel bike, and e-cruiser are all hydraulic discs.
- They can't get in but they can still fill my logs up, so fail2ban cuts them off after a few failures.
Also by collecting data on the IP addresses that are triggering fail2ban I can identify networks and/or ASes that disproportionally host malicious traffic and block them at a global level.
It's not exactly rocket science to add a "browser app" to the Steam system to use certain web sites in an appliance-ish mode, but it's not great for general purpose browsing.
A slightly more advanced browser frontend that offered an experience comparable to Edge on Xbox would be very nice.