This reminded me of lucidrains, perhaps one of the most prolific PyTorch users and paper implementers on the Internet. His implementations were crucial references to my own ability to boostrap my paper-implementing skills. Looks like he is still around and doing really awesome stuff. https://github.com/lucidrains
I could see this being really useful for people who need VM-Sandboxed software, but also need quick and dirty bridges between host/guest. Great contribution!
If the LLM designs the circuit, it is clear "contamination" if the tool calls which wrote the RTL / Verilog are also in the same context window as the specification design.
If a windows DLL, distributed without a license that says anything regarding, is it a "clean room implementation" if there is some nonzero chance the source code was leaked into the weights at pre-train time? I guess there should be some sort of method for subpoenaing frontier labs to ask "can you grep for this code in the training set for this model", but that might not be practical or feasible.
> If the LLM designs the circuit, it is clear "contamination" if the tool calls which wrote the RTL / Verilog are also in the same context window as the specification design.
You can't ensure it properly segregates its knowledge so it's a legal risk. If you believe your LLM can generate a design from a spec without knowledge of the original, why would you take that unnecessary risk? A lot of the behavior in this area is meant to avoid the appearance of impropriety, because the appearance of impropriety forces you to defend and demonstrate there was none.
If you isolate the two behaviors (reverse engineer design to spec; convert spec to new design) then you have a legal defense. You can claim that any coincidentally too similar design elements are a consequence of standard design patterns or something, not a consequence of inherent knowledge of the original design.
This is why we separate the people into distinct roles, there's no reason not to do the same (or expect the same) with machines. If you don't want the legal cover, of course, by all means take the risk and enjoy a trillion dollar company taking you to court.
was about to hop into the thread to make a jeer about the highly compensated engineering team at Anthropic apparently not testing their website on iPhone screens.
Accessibility is important, and I find that "Reader Mode" in most browsers is quite good. Everyone should have access to the tools to consume content. Did your browser not provide that functionality?
When I was a vision engineer at a previous role back in 2022-ish, laptop-class Intel chips used in their SFF NUCs were powerful enough to run small finetuned convolutional nets by dancing across the different on the package: first decode using QSV, and then downsize using the CPU, run the images through an OpenVINO model running on the iGPU, and aggregate results and append metadata using the CPU core. You could have 50% of the hardware in today's high-end security cameras for 10% of the cost.
I have to assume that hardware advancements in the past four years have only pushed the efficiency envelope further.
My deepest conflict with Python as someone who works with it professionally is balancing "keep it simple and clean" with an acknowledgement that reality is often is complex and messy.
Synchronous, mostly functional python scripts written with the standard library and perhaps a few dependencies generally feel like the best the language has to offer, and they frequently make great prototypes (and I have put a few in production).
But I have also dealt with a lot of important stuff that felt like the wrong tool for the job:
- Airflow tasks, and durable workflows as a whole on top of a database
- async stuff, and generally the fact that you need `aiofile` to interact with the filesystem asynchronously
- "Productionized" stuff around NumPy and DataFrame APIs. I think there are genuinely fascinating uses for this stuff and its still great! JAX stood out as the the API that truly "clicked" for achieving "simplicity" despite the difficult challenges that it solves.
Typing woes appear the most when I am handed a prototype to productionize. Good static analysis of types carries you so far, it makes me frequently wonder if something even more aggressive than what TypeScript does would have been ideal. There is a great scripting language trapped underneath a mountain of adjustments that have been made to Python so it can "be used for writing large scalable software systems" and it makes me question whether that ever should have been the point of Python in the first place.
P.S. INB4 Stroustrup quote about languages people complain about vs ones they don't use and all that. You can tell Go was designed for very specific use cases and hasn't catered too much to use cases outside of that.
Something of consideration: Flock cameras were installed after discussions across the HOA and local police department, after a multiple crimes happened in an area. So long as a discussion about the lifetime of the cameras is raised eventually, this sounds like a measured and reasonable use of surveillance.
There is still something to be said about the lack of alignment between Flock the company and the HOA as to how that data is used, but the compromise was explicit, and there was at least some coordination within the community. At the heart of the issue with automatic surveillance is the lack of accountability over those who retain the data and the lack of consent of those surveilled, and measures were taken to address one of those two within your community.
I was asking around a while ago about better single-node solutions to "durable workflows" than Airflow before I was familiar with the terminology. Admittedly, Go + durable workflows in the cloud feels like the perfect marriage. Seeing the gated features makes me hesitant, unfortunately, but definitely considering this!
reply