If this is completely non-commercial and you have an amateur license you could probably use AREDN as a backhaul instead of HaLow. We've gotten wifi going from a panel in Elysian up to Wilson on AREDN.
100w from the Verdugos should be pretty substantial. I regularly make 70cm FM contacts on 446.500 from Elysian Park down to San Diego at 5w.
LPFMs are licensed. You are responsible for everything that is broadcast and you can be held liable for FCC violations or for any criminal acts conducted on or through your station.
I would simply not feel comfortable opening the door to the station in this way. Even where we do allow remote broadcasters there is /always/ a person physically in the studio controlling the board, the automation system, and the remote host connection directly.
Finally.. one of the great joys of working in radio.. is, honestly, taking phone calls while on shift in the studio. If you're going to do a call in show it's basically required. The induced delay on digital connections is often too high to make a quality show out of. It's honestly one of the pain points of podcasts today.. watching two hosts bounce off the delay while trying to have a natural "conversation" on any level.
I would be really surprised if we are allowed to use AREDN.
We need a studio to be able to do live radio shows. Currently our hosts have to pre-record and submit through an online dashboard. The goal is to have a live studio in Shadow Hills where hosts can do their shows, bring on guests, take calls, etc.
There are many examples of Internet radio/livestreams that do all the live studio work virtually. It would be so much cheaper and more flexible as guests just need a microphone and Internet connection. Getting good audio is not terribly difficult even with a laptop or phone's built in microphones. Positioning and some isolation do wonders for voice quality.
You are technically correct but taking that approach misses out on the purpose of community radio: community.
As a terrestrial radio station our goal is to serve and be a member of our the local San Fernando Valley community. Creating a physical space for the radio station is about creating a 3rd space for community members and hosts as much as it is for recording radio shows.
I think the suggestion is to use AREDN for our backhaul from the station to the transmit site instead of 802.11ah. So it wouldn't be for broadcast per se, but I am still skeptical that is an allowed use for AREDN.
I want that to be how things work, although recent history has not been favorable when it comes to Public Key Infrastructure as applied to individuals. Inconvenience, foot-guns, required technical expertise levels, the pain of revocation lists...
In a sense, it seems Accellerando got a lot more right than not ( reputation markets in this particular case ). We may be arguing over the best way to do it, but it seems that the conclusion was already drawn.
To be fair, it was something of a marketing master stroke to adopt claw as a symbol. Admittedly, it does make me uneasy the same way Kamala's writers dressed her up in Lisa Simpson's clothes ( episode when she is a president ), but... you have a point. We are a weird mix of pop culture memes becoming so intertwined it is hard to separate them at times.
Someone here recommended Accelerando about a month ago - I’m sitting in an airport now reading it. It’s… deep. Probably one of the two deepest sci-fi novels I’ve ever read, beat only by Blindsight.
I’m not finished yet though, so that order could change :)
I read it after Prime Intellect during my AI binge. I think the initial feeling I got from it was the same as I did during first read of Snow Crash. Familiar world, and yet everything is very, very different so you feel more like an explorer than anything else.
FreeBSD has had a hard time supporting Intel Thinkpads, and they're making progress at getting better. Supporting Apple arm64 is a much heavier lift than that.
Confused is the perfect word to encapsulate how I feel about this post. Collapsing purpose built scalable services into a single server is not “going off cloud”. It’s is more like “simplifying my tech stack”
The point is it's totally possible for some artificial dyes to potentially be harmful and need to be regulated, but eliminating them all just because they're "artificial" is woo-woo nonsense on the same order as my deliberately parodic example.
Know what else is artificial? Insulin and penicillin.
>Know what else is artificial? Insulin and penicillin.
Even if they may have side effects/allergies, we tolerate them because they provide extremely large benefits to the population. You can't compare that to a chemical we use to make the colors of candies pop more.
No one is dying or getting seriously ill because their Fruit Loops had bland and unsaturated colors.
It’s not. The one who controls the null hypothesis rules the world.. Should a new dye be banned until it is proven safe, or should a new dye be banned only when it has been proven unsafe?
The answer to the above question is not a scientific one. It has to do with how we want to operate as a society, it’s a political or social issue.
The thing is, there are many chemicals which are safe to drink in reasonable amounts, and many chemicals that are not safe to drink in any amount. People deciding not to eat something because "it has chemicals in it" is a pretty ignorant take.
> People deciding not to eat something because "it has chemicals in it" is a pretty ignorant take.
When people say this they are obviously not referring the the definition of "chemical" that a chemist would use. Pretending otherwise is exactly the "nerd-snark" mentioned above which makes people distrust experts because they clearly aren't intending to use the term "chemical" in a sense that would include substances like water.
There are too many food (and personal care and clothing etc) chemical additives for the average person to remotely be able to keep up with the details of each, especially given not all products even need to disclose them–the charitable, or simply non snarky, reading of that kind of comment is more like "I don't want to eat food with unnecessary/under-studied additives in it."
Go is compiled, Python - interpreted.
Go focuses on concurrency, Python on making it easy to do things with code.
Many things that are a one-liner in Python (but itself or with a library), in Go take quite a lot of lines or boilerplate. For example, there is no built-in string templates in Go.
> Not sure if "Python 4.0" is the best comparison.
Or is it Python that is not best compared to "Python 4.0"? Python doesn't live up to the guiding principles of Python, such as preferring only one obvious way to do something. Go is, in many ways, more Python than Python.
> Many things that are a one-liner in Python
Case in point. Many of those one-liners are just as obviously expressed as multi-liners (e.g. list comprehension vs. traditional 'for' loop).
> no built-in string templates in Go.
Another good example. There is no special syntax, but the standard library provides. Special syntax would give two obvious ways to do it.
Hardly, given that it isn't as expressive as Python, that role belongs to Mojo.
The only reason so many folks leave Python for Go, is the usual problem of writing C libraries instead of finally having a proper JIT in CPython, and having PyPy being largely ignored by the community.
Go's structural typing allows for quite a lot of flexibility often otherwise only found in scripting languages (I would suspect that this was the single biggest reason as to why the TypeScript folks started to move to Go for the ported compiler rather than something like dotnet based like C#).
There is an interview with the architect and he explained that Go language maps quite nicely onto the Typescript language (e.g. garbage collector). And of course a lot faster due to concurrency and native binary. 6 times increase iirc.
After hearing the explanation about why he picked Go for the Typescript compiler I can only be more of a fan of Anders Hejlsber.
He said that Go was chosen due to its suitability for the workload, offering low-level control, optimized native code, automatic memory management, and concurrency.
And this coming from the same guy that created C#, Typescript, Delphi & Turbo Pascal shows how a real engineer takes a decision of this magnitude.
Is Go the best decision for every SW project? No, but in this case the arguments (and the tests they did during their evaluation) check out.
And no, picking F# simply because you love the language is not a mature decision.
Mono AOT has existed for quite a while, .NET Native also existed, and it isn't .NET fault if people cannot know about Native AOT.
I don't buy any of reasoning why Typescript team adopted Go, first of all the authors are more than knowledgeable about .NET AOT capabilities.
Second as Anders Hejlsberg went through his BUILD 2025 talk, turns out they had to redesign the data structures around Go's weaker type system anyway, as they couldn't easily map what they were doing with TypeScript types.
Third, Azure teams are using AI to convert C++ projects into Rust, as described by Mark Russinovich at RustConf UK 2025, which shows it is up to the challenge at hand.
All I know is that, as a user, whenever I encounter a .net project I have to put in more effort to run it versus a golang project.
This matters for these tools because they're usually distributed via npm packages and then invoked by a javascript wrapper. So you want something with a small binary that runs on pretty much every windows/mac/linux system no matter the configuration.
I don't know what you're hoping to hear, but I have no idea. All I know is that with loads of Go projects I've used I can go to the releases page, download a binary and run it.
And that for every .net project I can remember, which are far more rare, there's been some complicated installer that does a bunch of stuff. Or it fails to launch telling me I need to install some runtime separately.
The point is that when you happen to compile yourself Go projects, and CGO is used, you better have the C or C++ compiler toolchain installed that is compatible with Go, with the related dependencies they rely on, otherwise the build will break.
But you won't be blaming Go for that, rather the devs that decided to use CGO.
Likewise, when downloading some .NET project, it isn't .NET to blame, if the devs have decided they wouldn't be making use of Mono AOT, Native AOT, or single-file deployment package (with ReadyToRun).
> The point is that when you happen to compile yourself...
He made it pretty clear that he doesn't compile himself, he downloads pre-built binaries. In one case he finds that once the binary is downloaded, it just runs. In the other he finds it requires additional steps, like needing to go through an arduous installation process, before it runs.
Sure, better devs can figure out how to avoid things like the aforementioned installation process. Great devs aren't limited by their tools. But pointing out that the devs attracted to that ecosystem are not very good doesn't change much. That it requires one to be good echos the "pain" assertion. If it weren't painful, even the poor devs would do it.
I compile and distribute a Go app using CGO targeted at non-programmers. I hand them a single EXE file and they run it. They don't need to install anything else. It's so easy.
If this is completely non-commercial and you have an amateur license you could probably use AREDN as a backhaul instead of HaLow. We've gotten wifi going from a panel in Elysian up to Wilson on AREDN.
100w from the Verdugos should be pretty substantial. I regularly make 70cm FM contacts on 446.500 from Elysian Park down to San Diego at 5w.