10,542 karma · joined March 16, 2015
How so? NOT COUNTING leaks and filling, the average Olympic sized swimming pool uses 1-2 million gallons of water a year.
See EPA Commercial Pooland Spa Equipment Best Management Practices for Commercial and Institutional Facilities https://www.epa.gov/system/files/documents/2023-11/ws-commer...
I'm taking the opportunity to try adding my Mac to my nixos setup, pulling in some of my common settings like "ltra" alias for "ls -ltra" equivalent in "lsd" or "exa". Then nix-darwin to do as many of my settings via nix as possible.
Don't forget time travel: `:earlier 7d`
I'm using NixOS "latest" on my workstation, for no particularly good reason.
One success I had was with building up a custom vim setup. I had previously been using Lunar and Astro as an opionated vim distro with LSP+Treesitter and some other "table stakes" things a modern editor should have. But there wasn't a clear way to install Astro in NixOS when I tried it manually. So I just told Claude Code what plugins and settings I wanted in neovim, and now I have a single file that fully describes my vim setup. Before with Astro and Lunar the configs were spread out all over a bunch of files.
I was also able to get Claude Code to bundle up gitbutler-cli, which I wanted to try but so far have not. It builds it from source because there was no existing derivation. It takes a stunningly long time to build, but otherwise it has worked very well in my simple testing of it. Plus, I can build on my powerful laptop and then use that to seed my old, slow ThinkPad T470s and even slower chromebook that I also put my config on.
I was expecting some problems with my switch to NixOS back in June, but it's been just superb. Even things like building deb packages for my Ubuntu 26.04 machines at work have not been a problem at all.
I had dabbled with NixOS for a year or two before making the switch and had some familiarity with the nixlang and various concepts (SOPS, age, flakes). But, what really smoothed out the switch was using Claude Code to develop the NixOS configs. Everything is easy to do that way, and any issues are easy to back out.
One potential deciding point is that Claude still has a $200/mo 20x plan, where, since Sept 11, OpenAI does not and has no ETA for the return.
I downgraded my OpenAI plan 2 months ago to the $100/mo, but my usage has gone way up, but now I can no longer upgrade to the $200/mo plan ("This option is temporarily unavailable"). Thankfully I have 2 usage resets available, but I'll probably be switching back to Claude; I was super happy with Astra but I'm burning through tokens and have 4 days before my next reset.
I wanted something that required no setup, but could just push success/failure messages to as part of various cron jobs, windows tasks, and shell scripts we run throughout our organization.
StatShed server: https://github.com/statshed/statshed-server StatShed go-cli: https://github.com/statshed/statshed-gocli
The idea is kind of like "ntfy.sh", but for jobs status. You can send a "started" message at the beginning, update a "status" message periodically throughout the job, then send a "failed" message (optionally with logs) or a "success". Then a web dashboard gives you an overview with ability to drill down.
We use Icinga for monitoring and paging, but this just gives an overview for a quick look at things we don't want heavy duty monitoring on. Like my laptop backups, information about ansible runs across our fleet, etc.
As I said in my post, the rust coreutils team HAS fixed this in 0.11. It's just that Ubuntu 26.04 is stuck on the older one.
Shipping a coreutils that is version 0.8 in an LTS release seems like an interesting choice.
The issue seems to be that it is operating on partial buffers and then having to copy remainder of that 1M buffer around as part is consumed. Coreutils 0.11 solves that but 26.04 is at v0.8.
I've always used "bs=32k" because decades ago I did some testing and found that seemed to be large enough that it reduced the overhead while not being so large that it caused other problems, one of the most noticeable being scheduler issues where performance went into the toilet, especially on SD or USB thumb drives. Using this also seems to work better with rust coreutils dd.
apt install coreutils-from-gnu coreutils-from-uutils- --allow-remove-essential
And pin it so an upgrade doesn't flip it back with:
printf 'Package: coreutils-from-uutils\nPin: release a=*\nPin-Priority: -10\n' \ | sudo tee /etc/apt/preferences.d/uutils > /dev/null
The OOM killer looking at processes and seeing a giant one, using 90% of the physical memory and growing fast and deciding "Oh, that's ok because it is working hard, I'm going to go kill this little tiny thing that hasn't been used recently called sshd". Inoculating sshd against the oom killer is SOP now.
But I've found that even with no/little swap, the system can get into high memory pressure situations (even easier because it can't swap out unused pages of libraries and the like), and still go into a sort of thrashing state even though it isn't swapping.
My main workstation is a Dell XPS15 with 32GB of RAM and I had 8GB of swap on it. About every month the system load would skyrocket even though it had plenty of mem+cache+swap available. If I killed off my browser and slack, load would return to normal, and I could use the system for a few more days or a week before it happened again.
I struggled with this for a year or more, before (for reason's I don't remember), I added another 8GB of swap. Within the next day 80% of the extra swap was used right up. I decided to swapoff that new file and create a 64GB swapfile and just see what happened. It got to around 20-30GB IIRC before it leveled off. And, more importantly, over the next 100+ days I never had that thrashing happen again.
That was with Ubuntu 22.04. I just recently (May-ish) switched over to a NixOS setup with 64GB of swapfile, and it's been very stable.
I get it, sometimes it's fun to follow a story. But I also read a dozen or so paragraphs, then started scrolling, then gave up.
It's technically not a bandwidth issue, AFAIK, it is a "profile" issue. When listening to audio only you are using a different bluetooth profile than when you are using it for two way mic+speakers.
Try playing some music on your computer and then start a video call. Even before I jump into the meeting, as soon as I hit the Google meet site and it opens up the meeting "camera preview" page, the music quality goes straight into the toilet.
This also happens to my "puck" speaker+mic array that is connected via USB.
I like recording things like my kids performances with a GoPro or two, and sometimes my wife or I get some shots on our phones. Multi-cam can be fantastic when you have people walking around in front of cameras, for example.
I used to have a majorly hard time syncing the multiple cameras shots, though the last time I did it (a couple months ago) I had much better luck with the "sync using audio" feature, in the past I've had problems. But why can't we have a timecode with the video stream, in the cases of GPS cameras (I think everyt camera I have now has a GPS)?
The slightly tricky part would be managing a local NAT that blends the two networks, and also does MagicDNS to answer on those NATed IPs. If routes conflicted, I guess you'd have to pick one?
Seems very doable though.
I've been in the game for almost 40 years now, and I'll say I've never had an office paid for by my employer that is as nice as that toughshed. I've never been in a dedicated office with a door, except when working from home.
Edit: ProTip: If you are doing concrete, rent a "Mud Mixer". Me an the kids were able to pour the 8x12x5" (130 bags of 80lbs) in well under a day, probably would have been even less if we had moved the bagged concrete to the pour site before the pour happened rather than as we were pouring.
Somewhat related: a couple years ago my spouse had cancer, and the doctor could do surgery either 5 days after our insurance was changing companies, or 2 months after that, those were the next two openings. The insurance said that if we proceeded with the surgery, without the new insurance company giving us approval, but they couldn't start approving it until the insurance started, and the pre-approval from the other company didn't give us anything. We finally decided to go ahead with it and take on the risk of ~$70K if it was denied. Which we decided to do rather than my spouse spending a few months worrying. Turned out that was a really good call, because when they did the surgery it turned out that instead of the expected slow growth, it was actually growing extremely fast. That was probably the difference between it being fatal and it being treatable.
The US system is far from smooth.
Flock has had a a number of security issues where people have demonstrated that the cameras could be accessed easily by anyone because of (IIRC) the use of default passwords.
Flock have said that they weren't doing this or that (I don't recall the exact details, I think initially they may have said it was just recording license plates), but then people found out they were doing a lot more than that.
Flock and police departments have been found to have been doing way more than using the cameras to investigate crime, including stalking friends and lovers and exes, and in one case one of the guys was found to have been regularly watching a young girls gymnastics gym a lot.