trangus_1985

Trying to avoid proprietary things, where possible. Especially at the protocol/application layer.

Lora and other chirp based protocols are incredibly cool, and I've been playing with them

> the channels are controlled and watched

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.

> illegal to transmit encrypted data over the air

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.

I said 40 years for a reason ;) But yes, those laws were horrible, and stifled innovation.

> Fine, whatever, their house their rules

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?

But you can "buy less stuff" in general. And that will reduce your impact.

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.

>I think the only time I've found people this far off the main track is users that only know C#/mono coming from Unity Engine.

Damn, almost direct hit. I was a game developer for a year or so about 10 years ago. We were using xna.

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".

Yes, I quite like C#, the language. That's why I put so much effort into trying to make it work - it's become one of my favorite languages!

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).

Correct. These vaccines are pretty safe, but we're at the part of the cycle where we're able to shave off .1% of risk, and thus are doing so.

For what it's worth, this guy is also known as "Tron Guy", one of the first widespread famous internet meme/personalities.

https://en.wikipedia.org/wiki/Jay_Maynard#/media/File:Trongu...

>I have been an employer, an employee, a contractor.

Curious, what are you right now?

>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.

Car accidents resulting in fatality are relatively uncommon, thanks to modern safety standards, and Tesla FSD doesn't have nearly as many miles as it needs.

Your sample size is way too small to be implying that FSD is safe - given a year or so, with millions more miles, we'll see what the score is.

By the way, and this is anecdotal, I was personally given a FSD demonstration a few weeks ago. The car immediately did an unsafe lane change in the middle of an intersection. Albeit, that was one of the pilot program beta versions.

> scroll back a few days

I did and I'm not sure what I'm looking for. Could you do it and post here so that I can verify what you're talking about?

>Sure you document such stuff before releasing it?

These are all likely documented internally - the process of cleaning it up is probably something they only care to do once a year. Very little of this affects most developers, and the stuff that does is available in the dev docs.

I can't go too into details, but now that the AOP is doing cryptographical operations and key escrow, the internal bus is likely to show up in future documents. Maybe not the AOP but certainly the mechanisms it uses to interact with the find my network. It may also be a separate find my network whitepaper.

"who hates HN"

This site, and this community, is great in my opinion. But it's not without valid criticism, especially considering the impact it can and has made in the industry and tech society.

"naively uninformed tantrum"

I'm unable to find the posts you're talking about.

They do yearly updates, the 2022 doc will very likely have more information. Regardless, the 2021 doc has some key foundations of the technology that are worth knowing.

The contract tracing docs _should_ be almost the same technology, and knowing how that works _should_ be a good start. At least, from my eyeing the OP's article as a lay person.

If you're not familiar with it, their platform security team releases a whitepaper about the technical details of their security. Regardless of how you feel about Apple, these documents are incredibly well done and interesting to read. The Find My section may have more information, as will their contract tracing docs (which use a riff of the same technology)

https://covid19.apple.com/contacttracing

I highly recommend anyone interested in security or privacy to read this from start to finish:

https://manuals.info.apple.com/MANUALS/1000/MA1902/en_US/app...

They had an agreement pre-established. I think he was just being polite. Versus "yo we agreed not to do this".

I made a coworker really uncomfortable by offering to smoke him out after work when he was visiting our site. But there really wasn't any recourse - he was conservative visiting from a conservative area (where it was "understood" that pot is a hard drug). I'm from the Bay Area: I'd been smoking weed since I was 16.

I've always been cognizant of differing understandings around the drug, but I definitely think it still takes some discretion.

By the way, the key difference between a drink at lunch and some pot is that im pretty useful around 2p with a drink - stoned, I might as well go home for the day. (Of course, everyone's different).

So, I think this discussion is worth having in a respectful manner - it's new rules.

I don't think HN was ever about just "technical" stuff. There is Lobsters for that kind of thing.

Out of curiosity, I brought up HN from 10 years ago on archive.org. I counted - 10 of the top 20 links were things that I wouldn't consider to be "technical".