The FOSDEM speakers are sent emails to review and approve the video recording (this involves rudimentary stuff like reviewing the start and end time, if the automated system didn't get it right; choosing one of the three audio channels etc). The recordings that have been reviewed and approved would be online by now.
Look forward to ye olde uncle Lennart's old-timey sales pitch.
I'm gonna summarize the Varlink talk: DBus is, and I quote, "very very very complex" and his system with JSON for low-level IPC is, in fact, the best thing since sliced bread and has no significant flaws. It works basically just like HTTP so the web people will love it. Kernel support for more great shit pending! I'm not sure where the hardon for a new IPC system with lernel (keeping that typo) support is from, but he's been trying for 15 years now. AFAICT, the service discovery problem could be solved by a user space service without much trouble. I mean if the whole thing wasn't an exercise in bad technological taste.
Varlink is based on much more conventional UNIX technology than Dbus, which is decades old: You connect to a named UNIX socket through its socket file in the filesystem (man page: unix(7)).
This is an old mechanism and it is known to work well. It does not require a broker service, it works right at system startup, and it does not require a working user database for permission checks (which would be a circular dependency for systemd in some configurations). If at all, I am surprised that systemd didn't use that earlier.
The main thing that Varlink standardizes on top of that is a JSON-based serialization format for a series of request/response pairs. But that seems like a lightweight addition.
It also does not require kernel support to work, the kernel support is already there. He mentioned in the talk that he'd like to be able to "tag" UNIX sockets that speak varlink as such, with kernel support. But that is not a prerequisite to use this at all. The service discovery -- and he said that in the talk as well -- is simply done by listing socket files in the file system, and by having a convention for where they are created.
I do not share your view of old timey sales pitch, at least for the talk about systemd nspawn OCI container support.
If anything, that talk was a tad low effort, with even dismissive answers — "Yes" and "No?" as full answers to audience questions, with no follow up?! Still very informative though!
The Varlink talk really was very salesy for a Fosdem presentation. Shouldn't be long until the recording becomes available, feel free to tell me I was wrong after watching it.
It's mainly re-hashed. I think I've seen the same talk twice before? At least once.
It's a very "I've made a cool thing. This is what I think is cool about it" type of talk. Which I don't think is uncommon for FOSDEM.
Maybe a bit uncommon for a higher profile figure like Lennart.
> It's mainly re-hashed. I think I've seen the same talk twice before? At least once.
He held a similar talk at All Systems Go I think (I missed the talk here at FOSDEM).
> It's a very "I've made a cool thing. This is what I think is cool about it" type of talk.
Varlink isn't something he just made up, he mearly "adopted it" (started making use of it). It existed before, but I don't know anything that really made use of it before.
The official-looking website at https://varlink.org doesn't give any information about who the authors are, as far as I can tell, but the screenshots show the username "kay". There's a git repo for libvarlink [1] where the first commits (from 2017) are by Kay Sievers, who is one of the systemd developers.
An announcement post [2] from later in 2017, by Harald Hoyer, says that the varlink protocol was created by Kay Sievers and Lars Karlitski in "our team", presumably referring to the systemd team.
So the systemd developers "adopted" their own thing from themselves?
While I guess you aren't wrong, I also wouldn't say you are entirely correct that Kay is a systemd developer. He use to work on udev, but hasn't been active in any meaningful way on it for 2 years before varlinks release[1]. For what it was made I can't really say, but Lennart hadn't start integrating Varlink until a while after its release (I think I remember it being like 2021 or so when he started making use of it, after another check it seems the start of varlink stuff in systemd was 2019[2]).
Kay Sievers' Wikipedia page cites a blog post by Lennart Poettering [1] which says that systemd was designed in "close cooperation" with Kay Sievers and that Harald Hoyer was also involved, so it seems pretty clear that he's on the team that develops systemd, the team that Harald Hoyer referred to as "our team". All three of them gave a talk [2] together in 2013 about what they were developing.
If Lennart Poettering "adopted" varlink, he seems to have done so from members of his own team ("our team") who created varlink and who are also fellow co-creators of systemd.
Hehe, I'm eagerly waiting for this one as well as I'd be extremely happy to replace some hack to run docker images with `systemd-nspawn` served from the nix store.
Is there a session start hook? I don't think so, unless it was added recently.
I've mostly been working on smaller projects so I never need to compact. And skills are definitely not working even on the initial prompt of a new session.
Instead of including all these instructions in CLAUDE.md, have you considered using custom Skills? I’ve implemented something similar, and Skills works really well. The only downside is that it may consume more tokens.
Yes, sometimes skills are more reliable, but not always. That is the biggest culprit to me so far. The fact that you cannot reliably trust these LLMs to follow steps or instructions makes them unsuitable for my applications.
Another thing that helps is adding a session hook that triggers on startup|resume|clear|compact to remind Claude about your custom skills. Keeps things consistent, especially when you're using it for a long time without clearing context
The matching logic for a skill is pretty strict. I wonder whether mentioning ‘git’ in the front matter and using ‘gitlab’ would give a match for a skill to get triggered.
I ended up getting ASRock X870E Taichi Lite. The main reason to get it was because it had 2 CPU x8 slots which are spaced perfectly for an Nvidia NVLink. And, they are Gen5 PCIe.
"A report was recently published by an AI-research company called Anthropic. They are the ones who notably created Claude, an AI-assistant for coding. Personally, I don’t use it but that is besides the point."
Not sure if the author has tried any other AI-assistants for coding.
People who haven't tried coding AI assistant underestimates its capabilities (though unfortunately, those who use them overestimate what they can do too). Having used Claude for some time, I find the report's assertions quite plausible.
The article doesn't talk about the implausibility of the the tool to do the stated task. It talks the report, and how it doesn't have any details to make us believe the tool did the task. Maybe the thing they are describing could happen. That doesn't mean we have any evidence that it did.
If you know what to look for, the report actually has quite a few details on how they did it. In fact, when the report came out, all it did was confirm my suspicions.
The author’s arguments explicitly don’t dispute plausibility. It accurately states that mere plausibility is a misleading basis for this report, but that the report provides nothing but plausibility, and thus is of low quality and dubious motivation.
Anthropic’s lack of any evidence for their claims doesn’t require any position on AI agent capability at all.
Yup. One recent thing I started using it for is debugging network issues (or whatever) inside actual servers. Just give it permission to SSH into the box and investigate for itself.
Super useful to see it isolate the problem using tcpdump, investigating route tables, etc.
There are lots of use cases that this is useful for, but you need to know its limits and perhaps even more importantly, be able to jump in when you see it’s going down the wrong path.
> Personally, I don’t use it but that is besides the point.
This popped out to me, too. This pattern shows up a lot on HN where commenters proudly declare that they don’t use something but then write as if they know it better than anyone else.
The pattern is common in AI threads where someone proudly declares that they don’t use any of the tools but then wants to position themselves as an expert on the tools, like this article. It happens in every thread about Apple products where people proudly declare they haven’t used Apple products in years but then try to write about how bad it is to use modern Apple products, despite having just told us they aren’t familiar with them.
I think these takes are catnip to contrarians, but I always find it unconvincing when someone tells me they’re not familiar with a topic but then also wants me to believe they have unique insights into that same topic they just told us they aren’t familiar with.
Whether the author uses any AI tools or not (to talk of using Claude specifically) is quite literally completely beside the point, which is readily apparent from actually reading the article versus going into it with your hackles raised ready to "defend AI".
You most likely know and just suffered autocorrect, but given the context of using it to point out a similar mistake I feel the need to correct you: it should be “sic”, not “sick”.
I'm not sure if it contains exactly what you're looking for, but it includes several resources and notebooks related to fine-tuning LLMs (including LoRA) that I found useful.
It's organized by room which you can find here: https://fosdem.org/2026/schedule/tracks/
reply