oakpond

Nooooo. :(

Turns out part of the appeal for me is that it appears to be handmade.

Yes, it's not stable. Once you have a working config, think twice before updating. I wish they would improve on regression testing.

>To support further research, we open-source the KDA kernel and vLLM implementations, and release the pre-trained and instruction-tuned model checkpoints.

This is just awesome.

Shouldn't the energy instead be focused on creating a standardized eIDAS driver API that OS vendors are required to implement?

I notice this kind of "Sent from iPhone"-type spam with other AI tools too. It's awful.

This is a fp16 model. That's 54G in weights. I can load it only with fp8 quantization enabled (>= 128k context). I run into this error during generation though: https://github.com/vllm-project/vllm/issues/36350. Looks like an issue with the flash attention backend. But yeah, if you are OK with fp8 quantization on this model, it fits. I expect with 64G VRAM it will fit without quantization

Running dual Pro B60 on Debian stable mostly for AI coding.

I was initially confused what packages were needed (backports kernel + ubuntu kobuk team ppa worksforme). After getting that right I'm now running vllm mostly without issues (though I don't run it 24/7).

At first had major issues with model quality but the vllm xpu guys fixed it fast.

Software capability not as good as nvidia yet (i.e. no fp8 kv cache support last I checked) but with this price difference I don't care. I can basically run a small fp8 local model with almost 100k token context and that's what I wanted.

Working for what? Can you show some complex systems that are built with it? Their site only mentions a kanban board app and a photo album. I can believe it works for that.

I build with LLMs all the time but I generally don't do vibe coding unless it's something small I don't really care about.

When I look at SpecKit, I see a kind of vibe coding fantasy: "code is no longer king", stop writing "undifferentiated code." There is no code on the site, just a bunch of prompts and commands.

On the other hand, what you are describing above is bringing specs closer to the codebase, while not replacing the code itself. Like I said I have no problems using natural language as a guide (even as a primary guide). I also completely agree that it helps with documentation.

My main point is: if you want to maintain a complex system, you also need to have an accurate description of the system behavior in some kind of formalism.

This kind of description reflects the true system behavior better. It's more helpful when you need to predict the impact of changes and also during debugging.

In my experience, when you sell expensive complex systems, customers are very worried about any differences in system behavior as a result of software updates.

When you implement a new feature with these tools, how do you convince yourself that existing system behavior remains unchanged?

When you have the code in front of you, atleast you can reason about the full system behavior before and after because code is unambiguous like that.

With spec driven development, the LLM can rewrite anything as long as it meets the spec. That's a problem if your customer relies on behavior that's written down ambiguously (or omitted entirely).

So, I think this is only going to work if you write specs with mathematical precision.. at which point you probably want to write them using a mathematical language.

I think natural language leaves too much room for ambiguities. If you treat it as code I expect you will run into frequent bugs and unintended side effects of LLM-authored changes as your software evolves. So I'm skeptical about this approach.

A formal language helps in this regard because it makes visible the inconsistencies that are hidden in the specifications.

Coding is difficult sometimes because it turns out the problem you are trying to solve is more difficult than expected (not because it's difficult to code).

Sort of agreed. Natural language specs don't scale. They can't be used to accurately model and verify the behavior of complex systems. But they can be used as a guide to create formal language specs that can be used for that purpose. As long as the formal spec is considered to be the ground truth, I think it can scale. But yeah, that means some kind of code will be required.. :)

probably yes. considering that even some of their non-ocr models can recognize my shitty handwritten math

It makes sense to me as long as you're not vibe coding the PBTs.

You do. Even the latest models still frequently write really weird code. The problem is some developers now just submit code for review that they didn't bother to read. You can tell. Code review is more important than ever imho.

Hardly anything substantial about how well this works in practice. It's a hiring ad.

> There's a new programmable layer of abstraction to master (in addition to the usual layers below) involving agents, subagents, their prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, IDE integrations, and a need to build an all-encompassing mental model for strengths and pitfalls of fundamentally stochastic, fallible, unintelligible and changing entities suddenly intermingled with what used to be good old fashioned engineering.

Slop-oriented programming

The first two problems can be solved in a straightforward way with more custom exception types. For the "bigger problem", catch(...) can be used to prevent your code from crashing. If you really want to handle each case explicitly you could also use enums in combination with compiler flags that enable exhaustive checking.

I recommend trying to implement your own Forth in assembly. It's a great educational experience. However, I would not choose to use it in production. It's not a readable syntax. I doubt it will ever catch on for that reason.

I'm on Sway and Debian. Debian has a separate package for KDE Connect: https://packages.debian.org/trixie/kdeconnect

I've been using KDE Connect without KDE for a while now. Works for me (tm)

What makes you think they will? What makes you think regulators don't also want this?

Goodbye Android.

This simply must happen. I don't think there is another sustainable solution to the network-effect problem.

You're not the only one. LLMs are hardly intelligent anyway.

I'm also not bullish on this. In the sense that I don't think LLMs are going to get 10x better, but they are useful for what they can do already.

If I see what Copilot suggests most of the time, I would be very uncomfortable using it for vibe coding though. I think it's going to be... entertaining watching this trend take off. I don't really fear I'm going to lose my job soon.

I'm skeptical that you can build a business on a calculator that's wrong 10% of the time when you're using it 24/7. You're gonna need a human who can do the math.

You don't understand, "open" stands for "open your wallet."

Birth of the AI spokesperson?

It's incredibly hypocritical too. They have become rich by training on valuable data produced by others. Yet others are not allowed to train on valuable data produced by them.

Me too. This looks to me like a holiday PR stunt. Get everybody to talk about AI during the Christmas parties.