tcdent

Seriously. This idea that humanity has not spent millennia analyzing these concepts is pervasive in the modern world, and the only thing I can think to attribute it to is a lack of education. Not because I want to be insensitive, but because as soon as you start absorbing material and integrating the real timeline, you can't unsee it.

Not that they didn't start their research and development with a bipedal robot, but you can notice that over time they went from more abstract leg concepts to far more humanoid leg concepts.

That tells us that the latter (for their intended use) is a superior design.

I don't understand why this is considered a security incident. Human behavior incident, sure, but this is not a vulnerability.

Exactly. Being able to organize your code in a way that provides distinct responsibilities per crate is just good practice.

And then the ability to enforce a formalized layer between crates and the way that they assemble into your application (i.e. the public API) is powerful for comprehension and maintainability. I go as far as documenting each crate with its own README that presents it as a standalone component with usage instructions, much like an open source library, even if it's only ever used in a single system.

I recently used it for a Rust profiler which writes Parquet files, so DuckDB then gives an easy SQL interface for things like summarization, analysis, and joins across runs.

Aren't you really just talking about the level of abstraction being applied? If there are infinite possibilities between zero and one, then it's just our way of relating to it that imposes the perception of a limitation.

The easier and more secure way is to just inject sensitive credentials through a proxy service that ideally lives outside of the box in which the agent runs.

Because even if you're doing this in-memory replacement, the content still lives in they system's memory. So, it makes it less obvious to leak a credential, but it certainly doesn't prevent it.

Synthetic data, distilled data, etc., does not necessarily mean data coming from outside of an organization. When we see performance increases with models like Haiku, it is because they are able to leverage the knowledge of larger architectures.

I fully expect that we will see increased performance from smaller architectures (to a point) simply because they are refined using larger ones.

> The problem is if we can pack a Fable in Qwen 4 27B who will pay subscription prices?

This is available to everyone developing these systems. Prices per relative unit of intelligence will continue to decrease. And market economics will continue to drive the cost down.

I agree with you with one caveat. Professionally, your obligation is to be qualified for your job and ship work that you stand behind. Complete comprehension is absolutely necessary.

Personally, with side projects and tooling, go nuts. There's no reason to read all of that code.

The recent DeepSeek release used Opus 5 as a reference point as well. I don't understand it. It's not like they're referencing superseded releases of other open models.

CSRs that seemed like they had to be handled and approved by humans, and thousands of dollars in fees. We have come a long way.

What does it mean to "go into" math?

I'm all about the concepts you're presenting, but care to elaborate on how you think the corals relate?

Nobody's saying it should take care of the entire process, but the idea of banning it from all parts of your process is an emotionally charged, short-sighted decision.

Meta did this from the very beginning with the original Llama's. Open weights, but you have to use an account with them and agree to an EULA.

Traditionally, computing and especially the web has used structured formats to designate placement of how information is interpreted, and even the level of trust which is given to it. But as we see with things like HTTP headers in this article, when an LLM interprets content, it's all just text.

Cabinetry stuff is still rough, but here's an example of the methodology applied to PCB layout: https://github.com/tcdent/netspec

To me, this sounds like it's less about the technology, whether it's open source or not, and more about the people in the room that are influencing the design, direction, and implementation of it. All of which are very likely to have previous positions at major companies responsible for the products mentioned.

Perhaps if there is any ambiguity, it's intentional on the part of caution around intellectual property provenance.

For realizing designs in physical space, I create a Python library with a DSL that allows us to express all of the components and how they relate with each other. The most important thing this provides is a deterministic way to test the assembly. Then, you take the parameterized relationships between the components and export them into things like three-dimensional views or cut lists, rather than trying to manipulate three-dimensional software as your source of truth. (Although Claude is pretty effective at driving Blender via Python, too.)

You're talking about Starshield, which is operated by the US Government via services contracted, not personally regulated by Musk himself.

Starlink, the commercial product, was always off limits for military operations (the type that require connectivity at 100+ MPH).

So, no, this is not one person dictating the usage.

Starlink’s Acceptable Use Policy explicitly prohibits:

- Remotely controlling or piloting any aerial drone or unmanned vehicle (unless otherwise contractually permitted by SpaceX).

- Engaging in any military activity other than approved morale/welfare/recreation programs for service members.

I particularly enjoy the narrative around video game decompilation because it's a continuation of what we see in the emulation communities. People that are passionate about certain experiences and want to learn more about the way they're implemented underneath and how it relates to hardware they have access to.

It traditionally involves investing incredible amounts of time and effort and intelligence, but what I think AI does most encouragingly is allows people to access more complex, more modern, more high-performance technologies and interact with them in the same creative and explorational way.

Over the weekend, I was curious about the state of open source touch-based HID support as it compares to the state of proprietary market leaders. I tasked an agent with decompiling and analyzing firmware blobs from the systems I was interested in, and now I have an early alpha version of the most robust source-available multi touch implementation.

There are obviously some legal and perhaps even ethical considerations worth reviewing before considering publishing anything like this, but we have reached the point that proprietary software is essentially open source.

Hadn't seen this one yet, but that's exactly the type of sensibility I personally prefer in a monospace (Menlo has remained my daily driver for years).

What a nice thing to say! Peace!

> ... a chatbot account associated with Alfozan’s spouse (which shared multiple identifiers and attributes with Alfozan’s own chatbot account) submitted prompts between Sept. 24 and Sept. 30 related to building, customizing, installing, audio recording, testing, obfuscating, and remote accessing a device, including inquiries about “build[ing] a continuous audio recorder,” “customiz[ing] Wi-Fi . . . connectivity,” “improv[ing] audio and live listening,” and “encrypt[ing] the SD card,” among other things. The same chatbot account also submitted prompts specifically related to Recording Device 1, including its custom header and unique MAC address, between Sept. 27 and Sept. 28.

The justice.gov article doesn't specifically say it was an OpenAI account, but I think, based on the fact that they have logs including MAC address of the device, that we could probably assume that. The alternative is that other chatbot account providers are collaborating.

Regardless, doing a string search on a MAC address for a device you find inside your property doesn't strike me as an abuse of the data that is also your property.

I think the article would tend to agree with you, given its position on the reluctance of open sourcing and/or sharing the actual Scion software stack.

There's so much intricacy and subtlety in each organization and even individuals' environment being incorporated into tooling that expecting these tools to generalize at this point is perhaps an expired ethos.

I even see this in the tooling that I run in my own personal stack. Many projects are candidates for sharing, and I have nothing against it, but they incorporate such specificity toward my own environment, including things like hardware, that creating shareable and more generalizable projects from them adds more to the maintenance surface than I would care to support.

<50GB/s bit stream? What a waste of time. Buy more DRAM.

To clarify, the main claim I'm making is that the labs want to observe behaviors like this, and that anyone arguing that this is somehow negligence or a lack of intelligence is missing the point. The labs are documenting and publishing the behaviors of emergent systems, not running a course on how to prevent these actions (yet).

But I will still stand behind the fact that this is not a solved problem and that our systems are not as hardened as we say they are. Any news coming out around computer security currently and over at least the next 6-18 months will back that up.

> Yes, that's why all users are root. We built MACs like SELinux just for funsies.

OK gimme an ssh key into your box then.

> L7 DPI firewall policy.

It's a start, but now you're just pushing the fallibility up into extensive policy writing. You have to fully audit and trust every endpoint that's been granted access. And if an endpoint contains a vulnerability which allows RCE, then you haven't secured anything at all.

Before you all start screaming negligence and irresponsibility and how-could-they-be-so-dumb, let's think about what we're observing.

These are relatively brand new systems that process an incredible amount of data to form their "world view". The word non-deterministic gets thrown around a lot, but you have to understand that there's absolutely nothing deterministic about these architectures. The only way to know that certain qualities could emerge is to observe the qualities emerging.

Giving an agent instructions that, for example, instruct it to only perform GET requests, and then observing that the agent does not always respect that request, is not a failure of security or configuration: it's data being gathered.

Yeah, we're going to become more diligent about the protections that we put in place beyond any level of protection that we've ever employed before. You can say that we have decades of security research and experience, but we're watching all of that fall more and more day by day, finally putting a real delta on how secure we thought we were versus how secure we actually are [1]. Additionally, adversaries have never existed inside of the systems that we hoped to secure in the first place.

So go ahead, enumerate all of the ways in which you think that you can lock down these systems, but do realize that nobody has actually solved this problem adequately yet.

[1] https://x.com/PaulosYibelo/status/2106378929158135903

> No GPU support is a hard sell these days.

No GPU support is a hard sell for people who latch onto buzzwords and media narratives without actually understanding technology. CPUs are not going anywhere.