Do you think that ham radio couldn't be? Or isn't? What you really want is privacy, authz/authn concerns, and decentralization, it sounds like. And TCP/IP is about as useful as a "PHY" layer for your application as is ham radio.
Plus, solutions like what you're describing require a relative ease of use - unless you only want to talk to the 17 other people in your geographical area who have similar technical backgrounds.
Yeah, I definitely think they come from an era where we all didn't have a pocket communicator that plugs us into any community at will.
When I flung packets across the bay with a friend, we used cell phones to figure out antenna positioning and alignment. violating the spirit of the intention of these rules, imo, but hard to say
Yes, but ham radio is all about being open and a community of people communicating together.
And if that's the use case you want, you should look elsewhere.... At least, that's what the people leading the ham radio community and arrl say.
I'm not sure I agree with that, but I'm not sure I disagree either. I certainly think the community aspect is less important today due to the internet, but it's probably still crucial.
It took me almost a decade to become licensed because I couldn't find any tests that weren't at 9am on a sunday, an hour drive away. Maybe that seems like a low bar, because it is!
But, I got into ham radio to do interesting things, and not communicate. After all, why bother with making sure you have line of sight to a repeater when you can just fire off a text message? I'm much more interested in telemetry, instrumentation, and remote control.
While a massive restriction, you can prevent interference (but not eavesdropping!) by signing your payloads. Maybe it's because ham radio and privacy aware people is a venn diagram with a lot of overlap, but it feels like perfect being the enemy of good.
When they are the de facto form of communication for a significant percentage of the population, it starts to go from "their rules" territory to "society's rules".
Can you imagine being cut off from the phone system 40 years ago because you were selling answering machines?
I'm not entirely convinced that fully disconnecting is necessary, although it is nice. Instead, I take an old phone without any work stuff on it, and go moto camping. Occasionally, messages will come in from friends and family, and I can respond to them.
But the most important thing, imo, is not attaching yourself to outside responsibilities for a few days.
Frankly, I don't remember. It's been a long time and using .net was a failed experiment.
>Why were you targeting mono then?
Well here's another issue with .net I ran into... really unclear guidance from numerous sources who all really wanted you to use THEIR stack and thus end up paying THEM.
I did multiple things, multiple attempts to make it work. I tried to do it "the right way" from various sources.
The reason I was targeting mono at some point was because I wanted to run a microservice, without paying windows server licenses fees, and as best I can tell, that was the root runtime I'd need to target.
Keep in mind that this was me, going in blind into a large and established ecosystem. I don't think going astray detracts from some of my bigger complaints, such as the poor quality of community open source libraries.
Ah yeah, I was using core I think. Sorry, it's been a while, I kinda glazed over the acronyms and names over time. Since it was my own project, I really was trying to do things "the modern way".
it's been about a year but it was a death by a thousand papercuts kinda thing.
I want to add that I was not an experienced python developer at the time - I'd used it for a handful of simple automation scripts. My day job was writing scala.
- targeting mono under nginx on linux, from within windows was really difficult, I could never quite get it to work
- no support for monodevelop on windows - cross platform was crucial to me and it just got so onerous. And maybe it's just me, but I was really hitting a lot of frustration with visual studio.
- i wanted to use both yamlschema (broken at the time) and jsonschema (paid)
- msbuild is abysmal with useless error messages. I struggled to run a simple shell script during the build process.
- a couple of libraries I tried were broken or unmaintained. The .net ecosystem seems to have very low quality of community maintained tools.
- no clear guidance around using DAPR without paying microsoft (which i guess is fair, but being vendor locked before I even start is a rough look)
- ... and that's all I can remember. There was more.
I fully acknowledge that some, if not all, of those complaints may be self-inflicted. I can't say that, for my first complicated project in python, it's been completely smooth sailing.
However, with python/falcon, it didn't feel like I was fighting with the ecosystem to define a package, import the package into a microservice codebase, and then get the service running with full test coverage. It didn't feel like I was fighting to bring a third party library in, verify it's actively being maintained, and start using it.
I spent as much time getting a simple microservice hello world with authz/authn validation and a reasonable packaging system, in python, set up in about time as it took me to give up on msbuild.
I've found bootstrapping python microservice development on windows to be quite well supported. I didn't find that with .net.
I started a project that I hope to maybe turn into a product (foss/community edition hybrid approach). One of the tech stacks I evaluated was mono-based, using c# and the .net libraries.
I ended up turning down that choice due to a couple of factors, but one of them was the glacial pace of .net process and development. It just didn't look or feel like a healthy ecosystem, if you weren't paying microsoft $$$$. Just a ton of small warning flags around the community, the stack, and the maintenance of core projects.
C#, .NET, and the associated ecosystem doesn't feel good to work with, out of date, and in desperate need of modernization. The alternatives (spring, flask/falcon, lightbend) all seemed much more modern and easy to work with.
I actually have a concrete example of this: one of the features of my project is that you can define yaml based configuration documents, and share them. Using something that was easy to write for small but coherent configurations was crucial - XML was right out. The .NET ecosystem's yaml support is not great, feels kinda janky, and yaml validation is a paid product! That's completely untenable for something that's still in the weekend work phase. And it wasn't just that, but tons of things I had become accustomed to in python were either incredibly immature or paid. Not to mention that the built in build system was horrific, confusing, and had weak documentation. It's probably a lot easier when you just write a check to a contractor to set up a template for your team, but I have no luxury. Sure, some of this is on me, but I wanted to get started building and the .net ecosystem repeatedly got in my way until I was forced to give up.
So, upon hearing that the .net foundation is spending all of its time generating stacks of bureaucracy and causing internal drama, I feel like I made the right choice. At this point, it's unlikely I re-evaluate .net for future projects unless I hear massively good things (like what happened with java, which took a decade).
>UK has the highest tech salaries in Europe and trade unions were buried in the 70s.
Regardless of what we may or may not disagree upon, connecting these the way that you have betrays your ignorance of how salaries, employer relations, and unions work.
Lora and other chirp based protocols are incredibly cool, and I've been playing with them