I don't worry about bandwidth or constant CPU use, but the one thing that will kill my mac is burning out the SSD.
The calculator gives numbers for nearly everything, but I can't obviously see how much space it needs for model storage or how many writes of temp files I should expect if I'm running flat out.
put that stuff on an external disk perhaps, it will eventually crater, but it's easier to replace than macbook internal storage (how are they doing mac minis these days?)
The linux kernel traffic control (tc) can do network emulation with qdisc to simulate bad network connections. Add latency, jitter, bandwidth limits, and settable levels of traffic loss to your network interface.
If you're testing hardware or vm's that don't support it or don't have root, you can stick your linux box transparently in the middle by bridging two interfaces, and apply your traffic mangling there. Testing wifi? Use a decent WiFi AP connected to one of these bridges and mangle your traffic once it hits the wire/after it stops being RF.
At a previous job I had a linux box set up with multiple bridges (each set with a different "testing profile" on different vlans) and trunked to a physical switch. Made it very easy for people in the office to attach physical devices through known bad network links by either using pairs of physical switchports or just dumping VMs/SSIDs into the right VLAN so they could test different things (simultaneously) without needing to reconfigure the actual mangling.
Worth noting that tc applies to egress traffic, so if you want a uniformly bad line it needs applying to both sides - but it does mean you can simulate unidirectional link problems too.
This probably isn't the point either, but I get an almost perverse level of calm knowing that for my most favourite albums, I own a physical representation of the waveform trapped in a medium.
I very rarely listen to them in that form, but I honestly like the idea that in a post-Carrington event, zombie apocalypse or mad-max style future where electricity or electronics become scarce, I can (if desperate enough) listen to them with a nail and a cone.
I've been using Win+R to paste it in the windows run box.
Amazingly still works on Win 11 and still seems to keep it local (bypassing the windows search), so I'm pleased to report consistent results for 30 ish years.
Of course, now I've mentioned it out loud, it'll be the next thing to go...
I don't know if it's just me being old and grumpy, but everything windows 8 and later (server 2003) seems like half-baked, unfinished enshittification. Trying to do something even vaguely "advanced" to a network adapter puts me back in windows 95 land along with the run box. The "manage" pane with device & disk manager and logs is from a totally bygone era yet it seems to still be the only way of getting that information. The worst bit is, I'm not complaining. All the bits that look and feel like they've been forgotten since Windows 2000 are the easiest, least infuriating bits of the system I interact with.
I don't suppose you could point to any resources on where I could get started. I have a M2 with 64gb of unified memory and it'd be nice to make it work rather than burning Github credits.
You can then get Claude to create the MCP server to talk to either. Then a CLAUDE.md that tells it to read the models you have downloaded, determine their use and when to offload. Claude will make all that for you as well.
Mainly gpt-oss-20b as the thinking mode is really good. I occasionally use granite4 as it is a very fast model. But any 4GB model should easily be used.
It works exceptionally well for Slack as we've seen over the years. Someone in your $group uses signs up for the free tier, gets people using it and then you've got to pay through the nose to access any history.
At least slack is clear upfront that this is going to happen, mattermost just did a rug pull and removed history from users who previously had access to it.
> Syncing networked clients to play audio at exactly the same time is a solved problem.
I was going to point out that with the variance in FM demodulation chips, using a pile of FM receivers probably wouldn't get you perfectly synced audio these days at all, even more so if it's going through usb/software/audio stacks.
Then I re-read the Ops comment and this actually seems to be a network of _transmitters_. I'm not sure what problem they're trying to solve, but I can't believe multiple PiFMs is ever the answer.
Commercial DAB radio does use single frequency networks (with tight timings and clever calculated offsets), and I am somewhat curious how analogue FM responds with regard to offset destructive interference, but this isn't that.
Please don't do this. For context, a car FM transmitter is limited to 250nW (in many jurisdictions). A Pi GPIO pin with the right bit of wire is potentially capable of 10mW or more. 40,000 times more powerful and a lot more noisy. One could be causing problems for people surprisingly far away.
Having been brought up on pictures of Stonehenge, I felt a little twang of confused letdown the first time I visited Thornborough. This passes quickly though, and if you're vaguely near North Yorkshire it's well worth a visit. I've had the pleasure of camping at the base of it a few times with fire and mead which makes it all the more fun.
The calculator gives numbers for nearly everything, but I can't obviously see how much space it needs for model storage or how many writes of temp files I should expect if I'm running flat out.
reply