I wonder if Nix has similar tools, as it is famous for declarative system management, which is quite suitable for server provisioning.

The other comment already answers part of it, there is no real need for it for a NixOS system as you usually either can consult the store on the machine (and recursively build a graph of a all transitive dependencies of a generation), have a system that stores the config along with the generation (option `system.copySystemConfiguration` or a flake-based system will store the config in the store itself).

A system that has neither a store nor the config (container image) not easily reconstructable as you miss too much metadata.

It's hard with nix to end up with a system without first having a config for that system

True, it's as if embedding and vector search have just come out

microlink's cards [1] I discovered years ago has similar functionality, and microlink itself [2] is much more sophisticated on leveraging a headless chrome.

[1]: https://github.com/microlinkhq/cards

[2]: https://microlink.io/

Such a great collection! I wonder how it was achieved, definitely not by LLM, was it?

Refreshing and delightful! I know how the home page looks doesn't reflect the programming itself, but this design really makes me want to try Ruby again :)

> I know how the home page looks doesn't reflect the programming itself

It does reflect what the language creators pay attention to. Way back when, when I was undecided between learning Python or Ruby, after visiting countless resources I noticed Ruby websites in general looked way nicer and clearer than Python websites, so I picked Ruby. Now, years of experience with both languages later, I have zero doubt that to me that was the right choice at the time. I would’ve been frustrated with Python to no end.

I no longer need either language regularly, but given the choice again I would not hesitate to go for Ruby.

All that said, I do agree with some other comments on the thread regarding the disappointing reliance on JavaScript here. Should just be static.

.world domain is a perfectly fit for this project, love to see more power brokers' profile joining this Jmail world

I don't even know what Graphite is. I hope acquisition announcements like this assume the reader has no prior knowledge of what is being acquired

> Preview workflows are clunky. Draft modes, toolbar toggles, account requirements just to see what your content looks like before it goes live. Having to add data attributes everywhere to connect front ends with backend fields feels unnecessary. Real friction for something that feels it should be simple.

I was happy to read this part at first, because it highlights what I hate most about Headless CMS. Hearing a company in the industry admit to this problem gave me hope that they are now going to fix it or have better solutions. But no, the rest of this article is just rambling about how 'you don't really know about CMS'. I mean, if you know better than us do, then why can't the experience of using Headless CMS be better? You are here to solve the problem, right?

Reminds me of https://news.ycombinator.com/item?id=45458455

In the AI era, the rec file seems to be a great choice for formatting text that will be feed into LLMs. Imagine converting an HTML table into a RAG file, the context will be much clearer.

How avoiding LLM's altogether and using Emacs with Recutils for instance?

https://django-ninja.dev/ should be mentioned in this discussion, it's the best thing happen to my 12 years Django career