This is one of the most useful web tools I've ever seen.
I work on connectors for datasources (mostly DB's. Being able to quickly test things like sorting behavior and how the same function can be emulated across DB's would have made my life so much easier.
One positive result is that you get a lot more variation in vulnerabilities. That probably sounds negative, but it isn't.
As an example, a black hat doesn't get 70% of web sites from one shared bug in PHP. They need to target specific sites, and the exploit isn't likely to work in very many other places.
I've been playing around with LLM red teaming different server stacks with known or intentionally vulns in there and seeing how much damage they can do.
The one situation where they really can't get anywhere profitable is a unikernel webapp. With no source and no shell they find the vuln but the worst they can do with it is possibly poison or exfiltrate data as a one off, or crash the server. Often they can't even figure that out. Can't even leave themselves a reliable way back in.
Of course the traditional problem with unikernels is that you have to port EVERYTHING you need yourself. But the cheapness of this is exactly what we're talking about so.
Looks like security through obscurity's back on the menu.
Obscurity as a tool in security has never left. It shouldn't be a tool you depend on by itself. Update your ssh server when there are patches available. Use strong keys or ssh certificates. Disallow old, broken key exchange methods. Having an allow list in your firewall ACLs helps. Maybe only allow ssh from your internal network and make users outside your network be on the VPN. Maybe even have dedicated bounce boxes between user networks and the production systems.
But putting ssh for those bounce boxes on a nonstandard port that doesn't even show up to a remote system within the network until they've port-knocked on another two or four ports in the proper order on top of all that does not hurt security. Using a separate internal DNS zone that nobody outside your network has access to resolve doesn't hurt. Having your firewall drop packets from invalid sources instead of rejecting them doesn't hurt.
These last few months, I have been building a capability-based language and runtime for fun based on the "port EVERYTHING" idea.
The language is restricted to permissions granted on startup and can only access the system via the runtime, which only supports a particular subset of linux syscalls. So, outside of the stdlib, whichever feature you need, you simply use an LLM to port an existing python/rust/JS/TS/Java library to the language and use it.
As the runtime has its own scheduler and GC, I have actually been wondering about the feasibility of skipping the linux kernel and making the runtime itself the "os." Given that so much modern hosting is actually done on virtual hardware, the drivers could be hosted within the runtime as well.
That's exciting! I'm interested to hear about the language design. I vibecoded a unikernel web server a few weeks ago, and I've been trying to extend it into a full capability-secure microkernel called KokalOS.
The language borrows syntax from Python (and a wee bit from Haskell) and is essentially syntactic sugar over facilities provided by the runtime:
- statically typed from end to end
- closed and open/extensible types
- closed types are immutable, open ones have two variants: immutable and mutable
- arrays have two variants: immutable and mutable
- no OOP/classes. inheritance is nominal and mainly exists to provide access to class membership (is X a Y?)
- functions operating on data
- UFCS exists to provide nice features like "apple".substr(...)
- first class functions and closures
- monomorphized generics
- tailcalls
- operator overloading
- modules and namespaces to control access
- erlang/beam style first class processes. So you `spawn` a function and communicate between processes using send/recv instead of async/await
Processes are completely isolated at the runtime level. Each has its own stack, heap, mailbox and GC.
The bytecode carries all type information. The VM will compile using AOT-on-load.
My own runtime-becomes-a-os idea is still just an idea. I haven't really pursued it with seriousness. Will probably do that once the language and runtime stabilize.
It sounds like you already have a pretty complete OS; you just don't have it running on bare metal (or on a hypervisor) yet. I hope I get a chance to see the language someday!
I started in March and have gone through nearly 300 spec revisions for the runtime and language. Thanks to LLMs, I think I will have something useful to share in 2027.
My problem is that I have ten things in the pipeline at any given moment and I switch between them as time permits. So things get delayed a bit.
Oh, Kokalos was the king in Sicily who gave Daidalos refuge after he and Ikaros fled from Minos. The Romans like to spell his name "Cocalus", but the Romans can go fuck themselves.
Obscurity in the sense that the bad guy doesn't have your code doesn't hurt, but I think the real win could be that they need to specifically target your system to find your vulnerabilities. That could be a lot of compute and time to dedicate to a single target. So that kind of obscurity changes the economics of it for them.
What sorts of vulns are they finding in unikernels? Logic bugs, that sort of thing, or are there areas where they could get that tiny scope to do anything at all?
The advantage there shouldn't be obscurity, so much as very limited attack surface in the whole exposed stack.
That sounds like a very reasonable thing to do, yes. If you ask Opus 5.5 to write you a dynamically typed interpreted language that can query a local SQL database, implicitly parse HTML form submissions, and be embedded in HTML templates interpreted by an Apache module, you'll probably have a usable alternative to PHP in 37 minutes. And if you ask it to do it in Rust with no unsafe, it won't have any memory error vulnerabilities.
No, I sincerely try to avoid sarcasm, and I try to remember to down vote it when I see it. It's tough to get tone across in a text forum though, so I understand the confusion.
Big picture, I think we should explore what's possible when software is disposable.
I was saying that you could just not have exploitable bugs, at least of the memory-safety variety that was on display in PHP2hell, not that you could mitigate the exploitability of the exploitable bugs you will inevitably have.
Which, probably, you will also have to do.
I suspect that a more effective mitigation to having exploitable bugs would be to have an LLM read all your HTTP requests and the actions the web server proposes to take in response and give a Jev-like approve/disapprove decision.
All good, but I suspect we're thinking about different aspects. If I understand correctly, you're pointing out that nobody is tied to legacy software any more - they can spend 37 minutes to re-implement from scratch in a safe(r) language.
My point is that everyone doing their own thing their own way means an attacker doesn't get the next thousand sites for free after finding a vulnerability in one site.
A few years ago, after ChatGPT but before agentic, I was asking AI for help with some projects. It kept recommending really good, well designed APIs, and gave me code snippets for them.
One small issue: they didn't exist! It had just hallucinated them!
Which was a real shame, since they were much nicer than the actual stuff I ended up finding.
I just realized, thinking about this now, that these days (and perhaps even back then), I could just say "ok now take this code and build the missing library so it actually works!"
Exactly. In almost all of those cases, the hallucinated functions absolutely should have been present in the API, and any reasonable developer would have expected them to be.
Perhaps. I just never found it useful to spend a day learning the failure modes and edge cases of a general-purpose library I could hack into my use case with enough wrapper code handling the impedence mismatch when I could spend a day building exactly what we need, with the added benefit of owning the code when requirements inevitably change. Like, I'll use numpy at least half the time for numeric code; I'm not a masochist; but most libraries just don't pull their weight.
When worldwideweb.app was first being developed an the RFCs and so forth for web servers and protocols were being discussed, one of the sticking point was what to call a URL --- the initial suggestion was "Universal Resource Locator", but the argument was made that users and writers were not librarians and that the distributed nature would preclude a given web page having a universally agreed-upon location and name, so instead the present "Uniform Resource Locator" was adopted.
What if there was a code sharing site where it was unambiguous what a given snippet of code would be named and where it would be stored, so that a user could just browse it and find a list of implementations for a given problem?
This of course runs up against one what John Ousterhout notes is one of the most difficult problems in computer science --- naming things --- in his book:
I've tried to do it on a small-scale with my own work, storing bits of (la).tex code in a single file, but on reviewing it, I'll often find that I have written a given solution a second time and given the macro a slightly different name....
The thing is, solutions related to computing techniques, are few and can be found in algorithm textbooks. Some are then put into standard libraries.
Almost everything else is domain specific where you have to understand the domain first before understanding the code. And modeling a domain is all about tradeoffs between accuracy, performance, specific vs generic,…
Instead of collecting such solutions, a better approach is to master basic data structures, and then improve your modeling capabilities. After that, it’s mostly learning domain as they come (dsp, physic modeling, operating system concepts, relational database, graph theory, 3D geometry, accounting,…)
I am currently (re)reading Niklaus Wirth's book on data structures, and trying to work through the new Knuth fascicle on Constraint Satisfaction --- the idea here was that one could have a repository which one could search through to see/compare existing solutions as an alternative to using an existing library.
Less external dependencies. I noticed Claude was vendoring (copy-pasting) Lucide icon svgs into my codebase (with proper attribution) because I was only using a small handful of them. That's awesome.
>Except when it's a license violation or in something that ends up having a security vulnerability.
What's more secure isn't so simple. If you vendor something with a vulnerability then it wont be patched. But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities. And it can cut the other way - you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks).
There is a balance that must be struck, and I think LLM's strike a better balance than people do. Dependencies are a convenience with a cost and LLM's can trivially copy or re-implement things that we cant.
> But vendoring may also mean you took the 2% of the library you need and not the 98% which reduces the surface area for vulnerabilities
If you aren't using a library function you're not vulnerable to exploits in that code: unused but imported code is inert (possible usable as a gadget if you're vulnerable elsewhere, but at that point you're screwed anyways) and most compilers/runtimes completely eliminate it.
> you may update a package that was previously good and is now vulnerable (regressions, supply chain attacks)
There are better mitigations to this than not using a library.
You still completely ignore the license violations.
Every time I try to get a npm based project running (or one of my forks of one), half the packages don't exist anymore or I need to spend hours fixing breaking changes.
It's usually more straightforward to just rebuild it from scratch — not to mention infinitely more satisfying — and that was true before AI!
Yes it does depend on the dependency, and a static asset is on one end of the extreme.
It depends on the "load bearing" code. Obviously something like crypto is not something we should implement ourselves but core business logic would be "load bearing" in another way and is probably not something you want to farm out to a dependency.
The real looking for libs often turns to be going down with potential security risks. In such cases is much preferable to not reuse unsigned and unclaimed code.
I find this concern rather misguided. Telling the LLM to integrate a "mature library" is often cheaper and faster than rebuilding (a fraction of) their features from scratch. If you really cannot be bothered with searching yourself, these days you can even tell the agent to scan pip/npm/whatever registry for you and give you options.
> Acceptance proves, of the function's translation into the calculus, that for inputs and a heap meeting their declared types it does not get stuck and does not return a value outside its result type.
TypeScript's type-checker already proves the latter bit, no?
Actually it does not: if TypeScript says string, it does not mean string.
It could be number, or something else.
TypeScript tries to cover the most common scenarios, not all.
I want to attempt an explanation as it seems a lot of folks here didn't grok the very terribly written README
"Auto Ontology" is sort of a poor name.
Here's the problem:
Your company has data scattered across multiple types of databases. People who make decisions want to ask questions about that data.
The old way is they would go to a Data Analyst, and say, "Get me a report on so and so", and it was the Analyst's job to iron out the right series of queries and one-off scripts to generate the needed info.
With a system like this, the idea is that all your database models have been introspected and stored in a central metadata catalogue.
When a question is asked like "What were the top selling items in the month of May?", the metadata catalogue tells you "Products are stored in FOO_DB" and "Product_Sales are stored in BAR DB" and so you go and fetch the right data from the right place and do whatever in-memory calculations you need to do.
What the system provides is the implementation code for:
- Introspecting each of your DB's
- Aggregating model + metadata information in a central, virtual DB (VDB)
- Generating dialect-specific SQL from natural language queries and routing them to the right DB for the underlying table
- Combining results in-memory when a natural language query requires multiple datasources
- Handling proper permissions, etc
A GOOD system for doing this also integrates with your external API sources (OpenAPI, GraphQL, gRPC, whatever) and also documentation sources (cough, I work on this, cough).
what happens when your column names dont accurately represent what data is being stored (i know i wish it did but it doesnt at my place right now) and its all esoteric knowledge held by our data scientists? my worry is now the guys above will think its answering their question without knowing that its either A. wrong or B. data they may not be able to use for legal reasons on the project they are trying to make.
Example is a transaction application with a backing database: The users conduct information interactions with the application. The application stores relatively sparse data into the transactional database. The database has just enough metadata to route data from transactions but doesn't have the full meaning.
Example database column "updated_date" with type timestamp: Without looking at the data, how do you know if this column is populated when the application first stores data in a row? How do you know the timezone of the timestamp as a user would see it?
Real world example: Patient height in app and api is SI and both note the units. Patient height in the data warehouse is US Customary with no unit notation. The app and api make elaborate conversions for the underlying transaction database's US customary storage.
I think the promise of an LLM ontology is to read application code to understand the context for any particular database column. The linked software is not that.
Something like autoontology would help with human enforced governance for "blessed" data sets. You still need the operational rigor and data maturity to build said data sets and drive the transformation to adopt them.
This is effectively a tooling and labeling layer. But it will not magically solve the messy people issues that have always been at the root of this.
Discovering ontology in complex real world large systems (involving multiple microservices) is quite hard. Best way IMO is to learn the database schema details, cross table joins etc from source code itself as it also has business context. This has worked for me quite well. But there are many other challenges like KPIs have fixed queries, cross product queries, pulling large data and getting right architecture for joining in-memory.
"seems a lot of folks here didn't grok the very terribly written README"
I tried to make it through the README and it was just unmotivated slop. Perhaps it reads better to agents. It is like the Van Halen rider story - if the authors didn't care to write a good README, what are the odds that they paid attention to the rest of the large codebase?
I ended up throwing the README at an LLM and it gave me a much simpler and clearer explanation. Copying the bits of an explanation that helped me:
> The problem it’s trying to solve is that generating valid SQL doesn’t necessarily produce the right answer. An AI might find a column called revenue, but still choose the wrong dataset or misunderstand whether that figure includes things like refunds. Auto Ontology adds information about what the data means to help it make those decisions.
and then the one paragraph summary at the end:
> My reading: it’s a database chat application built around a reusable catalogue of business meaning. The question worth testing is whether that catalogue makes answers measurably more correct—and how much human work it takes to get the definitions right.
I could have done what you did to parse and summarize the readme myself, but the point is that I don't need to spend my valuable time on a project that the author's done care enough about to give a proper readme. And semantic web/graph indexers and queriers are not new, even if there are new tools at our disposal for classifying and querying ontological structures.
If they can't do that, it's a signal they didn't care enough about the details to rely on this project, and there is more cool software than ever I can spend my finite time on.
That may not be particular fair, and it may be a great project, but the bar is just much higher now.
Sorry, yeah, I completely failed to say in my message what I was originally aiming to say. Lost sight of the message part way through writing, after I got pinged at work for something.
The fact that I had to throw an LLM at it to cut down the slop and turn it into something more succinct and comprehensible is nuts. For myself, I'd be embarrassed if I released something with that kind of README on it.
My spouse and I have a rule that if we think a discussion is going to be emotionally charged, we have it over text in different rooms.
It sounds autistic, but writing and reading allow you to be much more precise, careful, and deliberate with your words and helps reduce impulsive outbursts.
This has worked really well for us, as crazy as it sounds.
> My spouse and I have a rule that if we think a discussion is going to be emotionally charged, we have it over text in different rooms.
I've done this myself with my wife and I.
> It sounds autistic
Well, I'm autistic, and she has a very high traumatic intelligence. She reads my body language, expressions, movements more than what I say, and those are very easy to misinterpret or overinterpret. And she says things... but it's not actually what she means. By us writing/typing things out, we're able to communicate without stray signals creating noise.
If you think Seattle is Amazonville and worse in all ways than SF, it sounds like you visited South Lake Union and no other part of the city. Amazon's footprint is pretty limited outside of SLU, which is one of the least interesting neighborhoods in the city. Downtown just south of it also sucks.
Ballard, Capitol Hill, Alki, University, Sunset Hill... The list goes on. Every single one of those neighborhoods has a completely different vibe (many of them used to be different cities). Incredible restaurants if you put in the slightest amount of effort to finding them. Tons of fun and interesting activities. The city is on a hill above the ocean (JUST like SF), the views are hard to avoid. Year round running weather. It may be that you just like SF more, and that's fine.
I ran every day I was there in different directions including a 16 mile loop to the tip of discovery park, it’s not a great running city, and its views aren’t particularly great.
Sure it’s okay, not as nice for running as SF or Vancouver but yeah far better than Phoenix and SoCal cities.
Maybe I went to the wrong areas, but it sounds like I was supposed to get to the sprawling suburbs?
None of the neighborhoods I mentioned are suburban. If you don't recognize them, it sort of tips your hand at not knwoing the city at all, as much as calling the entire city "Amazonville". Discovery park isn't known for views, there are other places in the city that are. Ballard is not some sprawling suburban neighborhood, its typically one of the most recomended places in the city to visit. You get there by walking the lakefront bike path from SLU (which is actually "Amazonville"). Capitol Hill is a 20 minute walk from downtown. Alki isn't walkable from downtown, but you can take the passenger ferry. I don't know where you got the idea of "sprawling suburbs".
You are allowed to personally like one city over the other. It just seems silly to base your opinion on living in one and a few days in another, and then argue when people point out that it seems like you haven't really done or gone to the places that make a place interesting.
I would agree with you, until I asked someone who lived there how it is that people working normal jobs like Bartenders can afford to live anywhere in SF.
I was told that there are rent-subsidy programs that allow people making relatively low wages to pay e.g. $300-800/mo for a 1-bedroom apartment
My thought after hearing that is that, unless you're making north of $300-400k, it's probably better to make around $50-60k and collect subsidies + benefits. The middle income group gets shafted.
Why live somewhere and be dependent on subsidies if you can move and be independent?
I lived in the Bay Area for 17 years. Enjoyed the time but it’s “for a season”. It’s common for folks in the Bay Area to look at other locations as “lesser”. In reality, it’s about tradeoffs.
For those low wage earners, you're not going to get a large deal of independence by doing the job in Des Moines compared to San Francisco. You'll still be scraping by, possibly saving a little bit but not much.
It depends on what you mean by "low wage earners". You can own a home and save money in virtually all of the United States as a teacher or someone doing anything in tech. You could also be a single income family if one partner makes $150k.
Having done 4-AcO-DMT and Psilocybin (4-HO-DMT), I would not be able to distinguish them in a blind test.
I actually prefer 4-AcO because it's easier to get a consistent dose with (mushrooms vary in potency) and doesn't cause the nausea that consuming dried mushrooms sometimes causes.
I work on connectors for datasources (mostly DB's. Being able to quickly test things like sorting behavior and how the same function can be emulated across DB's would have made my life so much easier.
reply