Also, the range is entirely the point of using LoRaWAN for some of us. All other IoT protocols have an abysmally short range, making them impractical for anything other than single building applications. Maybe most don't need a mile of range, but the fact that it can reach across a couple of acres enables a lot of applications.

That said, it seems like Smelt is far too early in development to be practically used at this point. Some basic table stakes that I didn't see:

- Test weighting. Having a way to specify a relative repeat counts per test is essential when using constrained random tests like we do in the ASIC world.

- Some form of tagging to identify a test as belonging to multiple different groups. When combined with a way to intersect and join groups when specifying the tests to run.

- Control over the random seed for an entire test run. I was glad to see some support for test seeds. However when invoking smelt to run multiple tests, it would be nice to be able to reproducibly seed the generation of each individual test seed. Maybe this is outside the scope of this project?

Great things to see:

- Procedural test generation is a key feature.

- Extendable command invocation

- SLURM support is in the roadmap, also an important feature for groups that use SLURM.

I have one of these scopes, with exactly this issue after a long period in storage. When I was looking into it a few years ago the failure mode was known but I couldn't find a recovery procedure. I'll need to give this a try when I get a few hours. I have been putting off getting a new scope in hopes that I could repair this issue.

Started a couple years ago, but I don't have as much time to write as I'd like. The majority of topics relate to ASIC design and verification, since that is my day job, but with some other side projects mixed in.

Comments URL: https://news.ycombinator.com/item?id=36137743

Points: 2

# Comments: 0

The picture frame secretly ran Android under the hood. Which meant I could replace the app which showed pictures pulled from the manufacturers server, with one which pulls photos from the NASA website. Fortunately they left ADB enabled with root permissions, so it was trivial to replace their startup app with my own. All the source code is public here: https://gitlab.com/prbs23/mars-photo-stream

The owner, the Frank Morton who was mentioned in article, is the original breeder of both Gildenstern and Dazzling Blue (and they probably grew the seed being sold by Fedco). All the varieties he bread (of which there are many) are released as OSSI varieties, plus they sell other OSSI varieties as well.

Additionally, if you are running inside an operating system, handling an interrupt usually incurs a trip through the kernel, which would add extra overhead every time an overflow did happen. Since there's a lot of software which depends on integers overflowing, this overhead on each overflow could significantly impact legacy software.

https://prbs23.com/blog/posts/getting-started-with-a-private...

LoRaWAN is definitely an interesting mix of open source implementations and open specifications, and proprietary poorly documented hardware. Unfortunately I haven't had time lately to actually use my network for anything real.

Quite the opposite, it inhibits effective communication.

Giving someone a one sentence summary of why you need to talk enables them to be prepared for the discussion you want to have. This lets you get to the point faster, and reduces miscommunication.

I don't get why this is such a burden for you to be clear in your communication.

Maybe you could cut a year off of those and still have something that is good enough but not state of the art.

The fact is that modern processors/computers are so complex that it's simply not practical to build one without some kind of initialization and management processor or other programmable device. Intel, AMD, ARM, it doesn't matter. Any processor of this size will have at least one if not more management processors.

Maybe these companies could do better and release the source code of what runs on these management engines, and I would argue they should. But unless we want to go back 10 years in processor complexity and performance, the "Backdoors" as you call them aren't going anywhere.

Fundamentally I think that the useful kind of software or system diagrams are always abstractions of the actual code. Figuring out the correct abstraction for the intended purpose requires either experience or a lot of trial and error. It may be possible for very specific applications, but I kind of doubt there is an algorithm to generate the content for a useful system diagram from the raw code.

Then there is the problem of rendering and layout out the diagram automatically. We have Graphviz and Mermaid, and probably others I haven't heard of, and while these do an okay job, I've never found their layout algorithms to be particularly great.

Overall, I don't think anything is going to be as useful as a manually drawn diagram, made with a specific intent in mind.

If someone tells me something in a one on one or small group conversation, my default assumption is that I should not share that with anyone else. The idea that I would have to tell someone to not share details of a private conversation is crazy to me. Unless stated otherwise, respect people's privacy.

Obviously there are people that gossip, which is kind of the same thing, but also is very much frowned upon.

I keep telling myself I need to dig into their source code and start fixing problems, but going from user to developer on these kinds of tools is a big jump.