steelegbr

AWS may be overcharging but it's a balancing act. Going on-prem (well, shared DC) will be cheaper but comes with requirements for either jack of all trades sysadmins or a bunch of specialists. It can work well if your product is simple and scalable. A lot of places quietly achieve this.

That said, I've seen real world scenarios where complexity is up the wazoo and an opex cost focus means you're hiring under skilled staff to manage offerings built on components with low sticker prices. Throw in a bit of the old NIH mindset (DIY all the things!) and it's large blast radii with expensive service credits being dished out to customers regularly. On a human factors front your team will be seeing countless middle of the night conference calls.

While I'm not 100% happy with the AWS/Azure/GCP world, the reality is that on-prem skillsets are becoming rarer and more specialist. Hiring good people can be either really expensive or a bit of a unicorn hunt.

Just get on the road with a 3/4/5G connection on a mobile phone if you want to understand why we still need to design for "iffy" Internet. So many applications have a habit of hanging when the connection isn't formally closed but you're going through a spotty patch. Connections to cell towers with full bars and backhaul issues are surprisingly common. It's a real problem when you're dealing with streaming media (radio can be in the low kbps) or even WebSockets.

Generally yes and even today, if you've got a twisted pair, it's that down to the exchange. Though party lines were also a thing a very long time ago.

There were also specialist circuits (e.g. EPS) where you had a physical line from end to end (with a couple of amps along the way on longer runs).

OpenTherm is a cool idea but even new installations aren't always wired for it. When installing a new smart thermostat I found the installation has been wired as S Plan with the few cables running between the boiler location and valves location already consumed. Makes the job much bigger if you're not prepared for it.

As someone who's been involved with radio and occasionally podcasts for about 20 years... I'm struggling to see the benefit of this one. Yes, prep services have existed in the past and I'm sure continue to exist today. Xtrax rings a bell from years gone by.

But honestly, if you're going to be interviewing someone and the content is going to be engaging, you can't just fly from some LLM output. Talking to a politician you're going to need knowledge of their past actions, figures to challenge them on, etc. For music guests, a bit of knowledge about the band, key figures and moments throughout their story. I'd hope anyone using the LLM crib sheet is also being reactive to what their guests say (e.g. "you touched on X but when you were Chief of X...").

Interviews aren't my strength but I'd be wary of such a service. Combined with the usual AI hallucinations it could be quite the entertaining car crash.

It's worth remembering that Radio Garden is now gubbed for transatlantic listening from the UK due to music licencing issues. The same problem also impacts TuneIn.

I was on-call for over a decade, usually in roles where there was no compensation for working out of hours other than maybe TOIL. We're not talking FAANG gigs here - like £20-50k in the UK stuff. It's amazing how much having to carry an extra phone or making sure your laptop is in your car impacts your day-to-day life. Any social thing you're at could be interrupted at zero notice. Heck, I've taken calls in supermarkets and concert venues.

One place I worked had a 1 in 2 rotation. Every other week on call or weeks back to back if your colleague was on holiday. There was no front-line service screening calls which meant you could be woken several times in one night. All for £30 pcm towards broadband costs.

Most places are more sane than that example but suffer from the same core problem. Follow the sun support is incredibly expensive when compared to putting your existing staff to be on call. Here in the UK, so long as your equivalent hourly rate doesn't drop below national minimum wage and you're opted out of the working time directive (a lot of employers slip an opt-out form into your paperwork implying it's normal to sign it), then it's legal.

Unfortunately I'm yet to find anywhere that on-call operational teams have the clout to get code induced issues high up the priority list outside of cases where they've had to drag developers out of bed at 2am. In my experience that also plays out with getting anything infrastructure based into tech debt budgets. Why focus on fixing problems you don't directly suffer from when you can spend the time on a refactor, integrating a cool new library or spaffing out one more feature in the sprint?

Indeed. The few times I've encountered Rust in the wild it's been for a project that didn't need it (web or IO bound applications) and someone's "My First Rust Project". It's difficult or even at times beyond the budget of smaller organisations to then hire a seasoned Rust dev to unpick whatever mess you got in to.

Don't get me wrong, Rust has a niche where it's the right choice. But being a popular language of the day, it's getting used a lot in the wrong places.

Music rights are a bit of a mess across the Atlantic. PRS/PPL licences don't reciprocate with the American equivalents and vice versa. Either it's two sets of licences (and possibly legal entities) or you end up geo blocking. Though on the up side you can stream to parts of Europe and even Australia from the UK IIRC.

Licencing bodies are also fairly actively monitoring these things. I've had them try to chase me for royalties for services that have been shut down because they're still listed in public directories.

It's a real problem they need to get on top of as an organisation. Unceremoniously pulling the plug on services like IoT Core on tight timescales doesn't scream "reliable, sustainable platform I can pitch to my bosses".

Even with sizeable discounts and professional services funds for migration, I wouldn't consider a move to Google Cloud until they calm this down. This is coming from someone that once worked for a Google Cloud Partner.

I took the plunge and published some of my old projects over at https://github.com/steelegbr?tab=repositories

Yeah, I'm not proud of the way I wrote the code 17 years ago (historic-alldaydj-1) but it's fascinating looking so far back and comparing it what I'd deliver today. If someone finds use for it, fair play to them.

On that note, I probably ought to dig out the RoTs (tapes) from my days as a radio DJ on a long defunct station...

They are and there's old firewalls out there that report Youtube traffic as a UDP DoS attack.

> A lot of times on-call gets stuck on these folks because they're often treated as second class citizens in the softwarescape.

Sadly spot on. For anyone that’s not been the ops side of the fence, you are expected to do major works out of hours as it’ll impact developer productivity. You can also lose your public holidays, weekends and evenings to issues while others get to switch their phone off and forget about work until they return.

It does a real number on you. Glad to be fully on the dev side of the spectrum now but some of the attitudes of interviewers I had to endure to get there… And that was with a CS degree and a truckload of IaC/glue-ware experience!

Spot on. It gets messier when a failure in a T1 carrier between your CDN and a customer is causing issues. Neither of you (nor possibly even the CDN) has the power to fix it. Well, other than bypass the CDN and hope the traffic passes through different peers.

On the up side, MTR is indeed a useful tool for finding the issue.

To add another bit of anecdata, if either station has their PI mis-configured, you can get handoff without being in the AF list. 1st and 3rd character matching rings a bell.

Seen it happen in the UK with RDS and head units tuning to the higher powered (mis-configured) station.

Ooh... reminds me of a throwaway experiment I did a few years back - WebRTC for radio outside broadcasts. It never went far as we ended up going down the SIP path instead. Nice to see the idea going further though there are commerical products now that work on this basis (IPDTL is one that rings a bell).

Both approaches were a great improvment over the need for an ISDN line but you could run into problems running higher bitrates on "spotty" networks. Thankfully you didn't need more than 128/192kbps for broadcast quality most of the time and could get away with even less for voice.

Call Server: https://bitbucket.org/marcsteelesoftware/g-rtc-call-server/s... Frontend: https://bitbucket.org/marcsteelesoftware/g-rtc/src/master/

A cloud / web based radio playout system. It's a bit of a niche but it'll get rid of the desktop(s) running some web radio streams.

We operate as a "voice tracking" service but need to cater for presenters with limited hardware. First goal is to give them audio library access, then onto log editing and voice tracking. Even if the current system continues to play audio "on air" for now.

The weird bit is this is an itch I had 10-15 years ago! There's an ancient screenshot from some early cross-platform attempts I made over at https://www.dlineradio.co.uk/articles/radio-station-mobile-a... - spot the Java Swing with MSPaint icons! :P