aarmenaa

running apps that are mandatory to participate in modern society

This right here is why I no longer consider custom ROMs. My phone is a tool critical to my daily life and I need it to function correctly nearly 100% of the time. Custom ROMs never really reach that bar in my experience.

Also, the various forms of attestation allow corporations the power to punish me for having the temerity to modify my own property. Yet another way the tech industry has metastasized into a societal cancer.

Yeah, I am always going to interpret that sort of thing as performative. There seems to be whole corporate mythology that is absolutely sure there are a bunch of cheap, low-effort things managers can do to raise morale and get more productivity out of employees, like office birthday parties. I propose a name for adherents to this philosophy: the Pizza Party Cult.

Yes. I have a family member that has had many hospital stays over the last few years, and one of the most obnoxious things is that the staff just lets everything beep. The last time we were in the emergency room the blood pressure monitor did not work and the staff didn't notice for over an hour. Even when it does work, they're constantly in an alarm state because patient has chronic high blood pressure. They either can't or won't silence the alarms, so every room is beeping, the nurse's station is beeping, their phones are beeping, and it's all being ignored. It's the very definition of alert fatigue.

I've noticed that for some reason developers really like using logs in place of actual metrics. We use Datadog, and multiple times now I have seen devs add additional logging to an application just so they can then create a monitor that counts those log events. I think it's a path of least resistance thing; emitting logs is very easy, and counting them is also very easy. Reporting actual metrics isn't really difficult either, but unless you're already familiar with the system it's more effort to determine how to do it than just emitting a log line, so yeah.

I like most of these patterns and have used them all before, but a word of caution using UUID primary keys: performance will suffer for large tables unless you take extra care. Truly random values such as UUIDv4 result in very inefficient indexing, because values don't "cluster." For databases, the best solution is to use a combination of a timestamp and a random value, and there are multiple implementations of UUID-like formats that do this. The one I'm familiar with is ULID. It's become a common enough pattern that UUIDv7 was created, which does exactly this. I don't know if it's possible to generate UUIDv7 in Postgres yet.

Maybe some people don't remember anymore, but there was a time when Ruby was HN's favorite language. I miss those days. I kind of get why everybody leaned into Python instead, but I'm never going to be happy about it.

If you manage to avoid scope creep then sure, static YAML has advantages. But that's not usually what happens, is it? The minute you allow users to execute an outside program -- which is strictly necessary for a CI/CD system -- you've already lost. But even if we ignore that, the number of features always grows over time: you add variables so certain elements can be re-used, then you add loops and conditionals because some things need to happen multiple times, and then you add the ability to do math, string manipulation is always useful, and so on. Before you know it you're trying to solve the halting problem because your "declarative markup" is a poorly specified turing-complete language that just happens to use a YAML parser as a tokenizer. This bespoke language will be strictly worse than Python in every way.

My argument is that we should acknowledge that any CI/CD system intended for wide usage will eventually arrive here, and it's better that we go into that intentionally rather than accidentally.

FTA:

The Fix: Use a full modern programming language, with its existing testing frameworks and tooling.

I was reading the article and thinking myself "a lot of this is fixed if the pipeline is just a Python script." And really, if I was to start building a new CI/CD tool today the "user facing" portion would be a Python library that contains helper functions for interfacing with with the larger CI/CD system. Not because I like Python (I'd rather Ruby) but because it is ubiquitous and completely sufficient for describing a CI/CD pipeline.

I'm firmly of the opinion that once we start implementing "the power of real code: loops, conditionals, runtime logic, standard libraries, and more" in YAML then YAML was the wrong choice. I absolutely despise Ansible for the same reason and wish I could still write Chef cookbooks.

True. On the other hand, if you control the clients and can guarantee their behavior then DNS load balancing is highly effective. A place I used to work had internal DNS servers with hundreds of millions of records with 60 second TTLs for a bespoke internal routing system that connected incoming connections from customers with the correct resources inside our network. It was actually excellent. Changing routing was as simple as doing a DDNS update, and with NOTIFY to push changes to all child servers the average delay was less than 60 seconds for full effect. This made it easy to write more complicated tools, and I wrote a control panel that could take components from a single server to a whole data center out of service at the click of a button.

There were definitely some warts in that system but as those sorts of systems go it was fast, easy to introspect, and relatively bulletproof.

It is very difficult to misconfigure Wireguard -- there's just not that much to tune aside from MTU. We've had a 1 Gbps tunnel between AWS and OVH for years and it worked mostly fine, except for the handful of times OVH's DDOS mitigation kicked in and killed the tunnel. The issue is when you start wanting to go beyond 1 Gbps.

I think AWS will do 5 Gbps with a capable peer -- which is their limit for a single flow [1] -- but you might need to tell them first so they don't kill public networking on the instance though. I found that UDP iperf tests reliably got my instance's internet shut off, so keep that in mind. On the other hand, OVH will happily do 5-ish Gbps to/from my EC2 instance in a TCP iperf test, but won't tolerate more than 1 Gbps of inbound UDP. OVH support has indicated that this is expected, though they do not document that limitation and it seemed that both their support and network engineering people were themselves unaware of that limit until we complained. They don't seem to have the same limits on ESP, which is why I developed an interest in ipsec arcana.

[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-inst...

Sorry, I misremembered the issue. Looking at my notes the issue is they don't allow disabling their NAT-T implementation, which detects NAT scenarios and automatically forces encapsulation on port 4500/udp. The issue is that every public IP on an EC2 instance is a 1:1 NAT IP. Every packet sent to the public IP is forwarded to the private IP -- including ESP -- but it is technically NAT and looks like NAT to strongSwan.

There's an issue open for years; it will probably never be fixed:

https://wiki.strongswan.org/issues/1265

We've run Wireguard tunnels that max out at 1 Gbps in AWS for years with no issues (on the AWS side, anyways). It seems like things get hairy once you want to do more than that.

I did not. I'm not terribly familiar with it, but it doesn't look like I can do general routing with it, right? My end goal is to route between two subnets.

The retransmit-in-retransmit behavior is precisely the issue.

But you're concerned about an issue I do not have. In practice retransmits are rare between my endpoints, and if they did occur poor performance is acceptable for some period of time. I just need it to me fast most of the time. To reiterate: I do not care about what happens in non-optimal conditions.

it looks like I've just accidentally described phantun (and maybe other solutions): https://github.com/dndx/phantun

I'll definitely look into that. They specifically mention being more performant than udp2raw, so that's nice.

I've just spent the last month learning exactly why I definitely do want a TCP over TCP VPN. The short answer is almost every cloud vendor assumes you're doing TCP, and they've taken the "unreliable" part of UDP to heart. It is practically impossible run any modern VPN on most cloud providers anymore.

Over the last month, I've been attempting to set up a fast Wireguard VPN tunnel between AWS and OVH. AWS killed all internet access on the instance with zero warning and sent us an email indicating that they suspected the instance was compromised and being used as part of a DDOS attack. OVH randomly performs "DDOS mitigation" anytime the tunnel is under any load. In both cases we were able to talk to someone and have the issue addressed, but I wanna stress: this is one stream between two IPs -- there's nothing that makes this anything close to looking like a DDOS. Even after getting everything properly blessed, OVH drops all UDP traffic over 1 Gbps. It took them a month of back-and-forth troubleshooting to tell us this.

The really terrible part is "TCP over TCP is bad" is now so prevalent there's basically no good VPN options for it if you need it. Wireguard won't do it directly, but there's hacks involving udp2raw. I tried it, and wasn't able to achieve more than 100 Mbps. OpenVPN can do it, but is single-threaded and won't reasonably do more than 1 Gbps without hardware acceleration, which didn't appear to work on EC2 instances. strongSwan cannot be configured to do unencapsulated ESP anymore -- they removed the option -- so it's UDP encapsulated only. Their reasoning is UDP is necessary for NAT traversal, and of course everybody needs that. It's also thread-per-SA so also not fast. The only solution I've found than can do something not UDP is Libreswan, which can still do unencapsulated ESP (IP Protocol 50) if you ask nicely. It's also thread-per-SA, but I've managed to wring 2 - 3 Gbps out of a single core after tinkering with the configuration.

For the love of all that's good in the world, just add performant TCP support to Wireguard. I do not care about what happens in non-optimal conditions.

/rant

The documentation is atrocious, and usually won't say things like "label your program unconfined_t" because they don't want you to do that ever. Also, tutorials -- even RedHat's -- are always some variation of "here's how to use audit2allow." That is very much not what I want. I want to create a reusable policy that I can apply to many hosts via Ansible or as part of an RPM package I created. I've never been able to figure out how to do that because it is always drowned out by SEO spam that barely scratches the surface of practical usage.

It's painfully obvious to me that the people who create SELinux and its documentation live in some alternate universe where they don't do anything the way I do, so I just turn it off.

I've been considering switching from Fastmail to Proton for Mail/Calendar/Contacts, but I didn't realize their bridge didn't do CalDAV or CardDAV. Also, apparently the bridge is desktop-only -- no mobile? That's kind of a deal breaker.

I presume the uptick I've noticed of "weed is really bad, actually" articles filling my news feed and social media is a response to the imminent classification changes in the US in an attempt to sway public opinion. I can only assume this is being driven by parties with ill intent, who prefer the status quo of using the phrase "I smell weed" to end-run constitutional protections against search and seizure, allowing unequal enforcement of the law, and selling less effective but more expensive treatments for ailments cannabis is known to be effective for.

I've previously worked for a place that ran most of their production network "on-prem". They had a few thousand physical machines spread across 6 or so colocation sites on three continents. I enjoyed that job immensely; I'd jump at the chance to build something like it from the ground up. I'm not sure if that actually makes sense for very many businesses though.

Chef vs Ansible was the first example that popped into my mind. I had a very love/hate relationship with Chef when I used it, but writing cookbooks was definitely one of the good parts.

Sony's network has been compromised something like a half dozen times over the last decade or so. They can't seem to secure their systems. Bad behavior aside, it's probably not a good idea to give them any sensitive information.

I'm moving towards this for my current workplace. SSH will only be allowed via VPN, only to a bastion, and that bastion will not permit agent forwarding, or really much of anything other than ProxyJump. I'm baffled that agent forwarding is a feature when OpenSSH won't even use a key file if the permissions are wrong.

My M2 Macbook Air has been flawless about sleep, but I set "Wake for network access" to "Never" so maybe I'm just avoiding Apple's issues there. At least it can be disabled; with Windows Modern Standby it was impossible to completely prevent wakeup last I checked. And new laptops are dropping support for S3 sleep.

As for the HiDPI stuff, it's one example among many of Apple making sure basic functions work without friction. I don't even know what I traded off for that - my Macbook works with normal PPI screens just fine - but it was worth it. For another example, I recently had trouble pairing a bluetooth keyboard on Windows 11 because their new settings panel is missing functionality. In 2023, that is an absolutely wild issue to have.

OEMs like Dell could try using a MacBook and mimic the trackpad.

You know what's crazy about the trackpad situation? You can put Windows or Linux on a real live Macbook and the trackpad gets worse. Everybody except Apple just insists on being wrong about trackpads.

As bad as MacOS is the competition is generally worse. Windows and Linux laptops can't sleep/wake or power manage correctly, trackpad behavior is mediocre at best, bad HiDPI support, and so on. It's a lot easier to fix up some foibles in the desktop environment than it is to try and fix core OS issues.

Agreed. I've been using Gandi as my domain registrar of choice for years now. No complaints.

I went with this combo as well. My requirement was to sync my password database across multiple platforms (Windows, Linux, MacOS, and Android). KeePassXC works great on all the desktop OSes, and there's a couple choices for Android apps (I chose Keepass2Android).

It does have downsides, mostly around Syncthing: it's a bit of a battery hog and there's no iOS app. If either one of those ever becomes enough of a problem for me I can just switch it out for one of the more normal cloud storage providers though.

I looked into this a while back and Syncthing does not have an iOS app.

I got sucked into Satisfactory a while back. After about 100 hours in the game, I was standing at the top of a cliff looking at my creation and said to myself "I'm the worst ecological disaster this planet has ever seen."

I'm planning to start a new save soon, and I think I'm going to try playing with some self-imposed rules, like not removing vegetation. Not as much, anyways. I'm not exactly a budding architect; where I bothered with buildings at all they're mostly giant boxes filled with machines. But I've seen some pretty creative, inspiring buildings on the Satisfactory subreddit and I think the game is flexible enough that I could create a factory that incorporates the nature around it rather than just smashing everything flat.

We're moving towards dual DNS providers. We've been bit by DNS hosting failures too many times, and they're always painful because everything, including monitoring and control systems, end up dead or inaccessible. Not to mention the entire network being down is absurdly expensive if you're paying SLAs.