Along this line of thought. I think the "internal tools" product category is dead. I remember trying to deploy one of these things - Tooljet, Retool.. I can't remember exactly, and thinking, maintaining the stack and the tools is not worth the effort. But then I didn't work in a big enterprise company. So maybe others had a reason or manpower to maintain them. Now I doubt anyone wants a programmable drag and drop form builder - aka no-code/low-code software factory.
He should be, right? Not fair but that’s how liability works. Gym sues the guy using AI, the guy then sues the AI company for selling him a product that does criminal things without him asking to? Like a car accident where car owner pays for the damages and after multiple accidents involving the same break-pedal, car company pays damages to owners and does a recall or faces class action?
I use an agent to author my nix config - personally I don't have the determination to have picked Nix up entirely on my own so I find it to be a godsend. I can code review config changes and keep it all in git - also makes it easy to pick up the entire config and deploy it on a different machine.
LLMs can be deterministic too! People just don't bother because the applications of this aren't widely known yet. See https://lukechampine.com/repligraphs
I was just reading Michael Lynch's posts about Sia[0] and I came across this.
Its a very curious project, but don't you end up pinning repligraph usability on model weights? Since you take indeterminism out of the equation, a repligraph's notability is as significant as the producing model's weights, and since there is no dice rolls to be made, the eyeball problem:
> Our blind spots, while not perfectly correlated, have substantial overlap
is entirely replicated. Models that are diffused from one another can have the same blind spots, the same loose statistical reality that exists with humans. This is partially addressed in steering:
> A repligraph proves that a model generated some artifact. It does not prove that the model did a good job, or that the artifact is safe.
but I think the "Peer Review" solution is inadequate, and with some jailbreaking prompts' innocuous looks considered, "the attacker just needs to find one prompt" might be much easier than it appears.
Batching seems to be a huge economic turn off for proprietary model determinism, but I think its entirely viable for consumer models. Trustless evals are brilliant and should've been our reality. Nice project, good luck on your endeavor.
Thank you for the kind words! It's funny how much staying power those blog posts have, haha. Michael has some arcane ability to consistently hit the front page of HN.
True, I expect models to be pretty correlated with each other as well. But you can at least attempt to quantify that correlation in a rigorous way, by running experiments (e.g. by pointing each model at a big project and comparing the sets of bugs they each find).
And yeah, the "double-edged sword" aspect of determinism is definitely the biggest bullet that you have to bite. For me, it's better than the alternative; without determinism, such jailbreaking attacks are still possible, just harder to detect. But I certainly would not want people to go around thinking "it's deterministic, therefore it's safe."
Deterministic systems like tracing GCs, JIT compilers, PGO data, machine learning optimising passes that vary their output, depending on program behaviours?
I am with you. For example - this post has a comparison of a recipe app from 5.6 and 6 for comparison. They look different. Now if every time I ask for a recipe, it decides to render a new UI because of either the model changing or the recipe goes from stove to oven or something, it’s going to become annoying very quickly. It just seems like he current generation of models have been tuned to create better UIs than previous one and people interested in the UI are getting hit with excitement.
Wow. This is genuinely the first time I have come across this idea. Are there Kernels build to be completely async? I understand they would be experimental. And the whole stack runs in a async environment from say the web server rendering templates - down to the kernel loading data into the cpu cache? Does it offer performance advantages? I got so many questions…
There was a Jon Stewart podcast on this a couple of weeks ago on Machine Learning and custom pricing. It was an illuminating one. It all looks like a lead up to big consumer action and lawsuit in the future. TBH, McDonald’s pricing might survive as it seems to charge the same for everyone at the same store.
Go to gnome.org, scroll down to "Developer Platform" and look at the title bar of the screenshot there. If you see a clean interface, then no reason other people give you will help.
But, if you do see the arrows there and think - why are there so many arrows and dots? It looks like bad UX. They you can see the issues others are talking about.
what an amazing example. We have on one window title bar:
- a "+"
- a down-arrow which presumably opens some sort of menu
- a hamburger menu (why is this different to the down arrow?)
- a "..." menu (err, isn't this the same as the hamburger menu and/or the down arrow?)
- A "hammer" icon next to the word "fetching". Because... Hammer Time! Also, yeah we use a hammer to fetch things. I think that's something we can all get behind.
- another two down-arrows. One probably opens out options for the "hammer" bar. The other...?
- an up and down arrow. Maybe this actually changes the options for the "hammer/fetching" bar.
- A search magnifying glass (no search field curiously).
Also, something about "Podcasts" in what is presenting as a Rust IDE. Looking more closely at the rest, I assume this is because it's the name of the project being edited, but it's still confusing. Fundamentally the title bar is being split in two, with a separate part for each main column of the window, as if it were really two windows docked together.
I currently have ~12 windows open (Win11 explorer, office, dev / terminal apps, sublime, Firefox, signal) : almost every one of them has a different top bar.
Visual studio does not look like this, because it uses text instead of icons. Which both uses less space, and is much easier to parse.
The gnome style client side decorations versus traditional menu bars is just bad. It works okay if your application has like… two buttons. Which, to be fair, is many gnome apps because they’re so feature-anemic. But once you have many functions, it becomes a mess that wastes huge amount of screen space.
Great! Now can you also optimize the memory usage please?
The blog post with all of the images, animations and embeds shows 167MB on my Firefox tab, while a plain claude.ai page is 297MB. For a text box with a few icons and some words, it a heck a lot of bloat.
For context, my Slack tab with "Threads" open is 239MB. Yup, Slack of all things is using less memory than a zero-chat Claude.ai landing page.
