codys (u/codys) - Readit News

codys commented on Show HN: Strix - Open-source AI hackers for your apps github.com/usestrix/strix... · Posted by u/ahmedallam2

ericmcer · 6 days ago

That's a totally valid and useful way to validate an idea. After a few months of manual labor they will have a good idea of how/what to build and if it is even worth building.

codys · 6 days ago

Unless the lack of real time (or consistent time to) results drives down interest in the cloud version, or instead of driving down interest makes it appear as if people want something different than what they would want if the time to results was consistent/faster.

Still could be worth doing a bit of manual work like this, but it's worth being cautious about drawing conclusions from it.

codys commented on Walkie-Textie Wireless Communicator technoblogy.com/show?2AON... · Posted by u/chrisjj

pastorhudson · 6 days ago

To use GMRS you need a license to be compliant with fcc. It’s not expensive I think $60 for 10 years and it covers your family.

You can then use GMRS. GMRS is all the same FRS channels plus several more. GMRS can also transmit at up to 50mw on some of the non-FRS channels.

To be using GMRS in compliance you have to use an FCC Part 95E certified device. These Baofeng / Btech devices are usually not GMRS certified. So you need a HAM license to use them. . . But HAM licenses doesn’t cover GMRS frequencies. So there is no technically compliant way to use these devices and check all the boxes. Even if you have both HAM and GMRS you are using a non Part 95E certified device. You’re likely fine as long as you’re not harassing people or causing interference. Generally the FCC is pretty reasonable. They send a letter saying knock it off before they knock on your door. But if you continue to harass people or use high power that causes interference then you will get a hefty fine.

At the very least get your GMRS license. But I encourage you to get your HAM license. I have found that often HAM nerds are into a lot of other stuff I like and my local club has been a welcome place to make friends and build fun stuff.

codys · 6 days ago

Btech markets devices that are GMRS type accepted, it's actually one of their main businesses these days to take Chinese developed radios and modify them slightly and get them GMRS approved in the US.

codys commented on FFmpeg Assembly Language Lessons github.com/FFmpeg/asm-les... · Posted by u/flykespice

zahlman · 6 days ago

It'd be nice, though, to have a proper API (in the traditional sense, not SaaS) instead of having to figure out these command lines in what's practically its own programming language....

codys · 6 days ago

FFMpeg does have an API. It ships a few libraries (libavcodec, libavformat, and others) which expose a C api that is used in the ffmpeg command line tool.

They publish doxygen generated documentation for the APIs, available here: https://ffmpeg.org/doxygen/trunk/

codys commented on Rust in 2025: Targeting foundational software smallcultfollowing.com/ba... · Posted by u/wseqyrku

pron · 8 days ago

> You have to avoid abstractions and conveniences and minimizing allocations so as not to trigger the garbage collector.

That's not really how modern GCs work, and not how abstractions work when you have a good JIT. The latency impact of modern GCs is now often effectively zero (there are zero objects processed in a stop-the-world pause, and the overall CPU utilisation of the GC is a function of the ratio between the size of the resident set and the size of the heap) and a JIT can see optimisation opportunities more easily and exploit them more aggressively than an AOT compiler (thanks to speculative optimisations). The real cost is in startup/warmup time and memory overhead, as well as optimising amortised performance rather than worst-case performance. Furthermore, how much those tradeoffs actually cost can be a very different matter from what they are (e.g. 3x higher RAM footprint may translate to zero additional cost, and doing manual memory management may actually cost more), as brilliantly explored in this recent ISMM talk: https://youtu.be/mLNFVNXbw7I

> C++’s innovations in zero-cost abstractions

I think that the notion of zero-cost abstractions - i.e. the illusion of "high" [1] abstraction when reading the code with the experience of "low" abstraction when evolving it - is outdated and dates from an era (the 1980s and early '90s) when C++ believed it could be both a great high-level and great a low-level language. Since then, there's generally been a growing separation rather than unification of the two domains. The portion of software that needs to be very "elaborate" (and possibly benefit from zero-cost abstractions) and still low-level has been shrinking, and the trend, I think, is not showing any sign of reversing.

[1]: By high/low abstraction I mean the number of subroutine implementations (i.e. those that perform the same computational function) that could be done with no impact at all on the caller. High abstraction means that local changes are less likely to require changing remote code and vice-versa, and so may have an impact on maintenance/evolution costs.

codys · 8 days ago

When you say "modern GC", which particular implementation(s) of GC are you referring to?

codys commented on There is no memory safety without thread safety ralfj.de/blog/2025/07/24/... · Posted by u/tavianator

phire · a month ago

Keep in mind that the 2012 presentations dates to 10 months after Rust's first release, and its version of "Memory Safety" was collecting quite a bit of attention. I'd argue the definition was already changing by this point. It's also possible that Go was already discovering their version of "Memory Safety" just wasn't safe enough.

If you go back to the original 2009 announcement talk, "Memory Safety" is listed as an explicit goal, with no carveouts:

"Safety is critical. It's critical that the language be type-safe and that it be memory-safe."

"It is important that a program not be able to derive a bad address and just use it; That a program that compiles is type-safe and memory-safe. That is a critical part of making robust software, and that's just fundamental."

https://youtu.be/rKnDgT73v8s?t=463

codys · a month ago

That's a very good point on the timing. Thanks for adding that extra info.

codys commented on There is no memory safety without thread safety ralfj.de/blog/2025/07/24/... · Posted by u/tavianator

tptacek · a month ago

The thread you're commenting has already discussed everything this comment says.

If you've got concerns about our security page, I think you should first take them to the ISRG Prossimo project.

https://www.memorysafety.org/docs/memory-safety/

codys · a month ago

In this thread I linked the fly.io security page because it helps us establish that one can talk about _languages_ as being memory safe specifically, which is something it seems you're rejecting as a concept in the parent and other comments.

(In a separate comment about "what do people claim about Go anyhow", I linked the memorysafety.org page, but I did not expect it to help in getting you to the understanding that we can evaluate programming languages as being memory safe or not, where something from the company where someone was a founder seemed more likely to get a person to reconsider the framing of what we're examining)

codys commented on There is no memory safety without thread safety ralfj.de/blog/2025/07/24/... · Posted by u/tavianator

phire · a month ago

The definition kind of changed.

At the time Go was created, it met one common definition of "memory safety", which was essentially "have a garbage collector". And compared to c/c++, it is much safer.

codys · a month ago

That seems contrasted by Rob Pike's statement in 2012 in the linked presentation being one of the places where it's called "not purely memory safe". That would have been early, and Go is not called memory safe then. It seems like calling Go memory safe is a more recent thing rather than a historical thing.

codys commented on There is no memory safety without thread safety ralfj.de/blog/2025/07/24/... · Posted by u/tavianator

tptacek · a month ago

You need a non-contrived example of a memory-corrupting data race that gives attackers the ability to control memory, through type confusion or a memory lifecycle bug or something like it. You don't have to write the exploit but you have to be able to tell the story of how the exploit would actually work --- "I ran this code and it segfaulted" is not enough. It isn't even enough for C code!

codys · a month ago

The post is a demonstration that a class of problems: causing Go to treat a integer field as a pointer and access the memory behind that pointer without using any of Go's documented "unsafe.Pointer" (or other documented as unsafe operations).

We're talking about programming languages being memory safe (like fly.io does on it's security page [1]), not about other specific applications.

It may be helpful to think of this as talking about the security of the programming language implementation. We're talking about inputs to that implementation that are considered valid and not using "unsafe" marked bits (though I do note that the Go project itself isn't very clear on if they claim to be memory-safe). Then we want to evaluate whether the programming language implementation fulfills what people think it fulfills; ie: "being a memory safe programming language" by producing programs under some constraints (ie: no unsafe) that are themselves memory-safe.

The example we see in the OP is demonstrating a break in the expectations for the behavior of the programming language implementation if we expected the programming language implementation to produce programs that are memory safe (again under some conditions of not using "unsafe" bits).

[1]: https://fly.io/docs/security/security-at-fly-io/#application...

codys commented on There is no memory safety without thread safety ralfj.de/blog/2025/07/24/... · Posted by u/tavianator

codys · a month ago

Curiously, Go itself is unclear about its memory safety on go.dev. It has a few references to memory safety in the FAQ (https://go.dev/doc/faq#Do_Go_programs_link_with_Cpp_programs, https://go.dev/doc/faq#unions) implying that Go is memory safe, but never defines what those FAQ questions mean with their statements about "memory safety". There is a 2012 presentation by Rob Pike (https://go.dev/talks/2012/splash.slide#49) where it is stated that go is "Not purely memory safe", seeming to disagree with the more recent FAQ. What is meant by "purely memory safe" is also not defined. The Go documentation for the race detector talks about whether operations are "safe" when mutexes aren't added, but doesn't clarify what "safe" actually means (https://go.dev/doc/articles/race_detector#Unprotected_global...). The git record is similarly unclear.

In contrast to the go project itself, external users of Go frequently make strong claims about Go's memory safety. fly.io calls Go a "memory-safe programming language" in their security documentation (https://fly.io/docs/security/security-at-fly-io/#application...). They don't indicate what a "memory-safe programming language" is. The owners of "memorysafety.org" also list Go as a memory safe language (https://www.memorysafety.org/docs/memory-safety/). This later link doesn't have a concrete definition of the meaning of memory safety, but is kind enough to provide a non-exaustive list of example issues one of which ("Out of Bounds Reads and Writes") is shown by the article from this post to be something not given to us by Go, indicating memorysafety.org may wish to update their list.

It seems like at the very least Go and others could make it more clear what they mean by memory safety, and the existence of this kind of error in Go indicates that they likely should avoid calling Go memory safe without qualification.