I asked Claude to remove extra blank lines from a modified file. After multiple failed attempts, it reverted all the changes along with the extra blank lines and declared success. For good measure, Claude tidied up by deleting the backup of the file as well.
I only wanted to make the change in the ranges part of git diff and I got the syntax wrong on my own first attempt. Claude had been helping me with some much more complex tasks, so I thought removing white space would surely be no problem. Ha. Bad guess.
I had a similar experience with AI and open source. AI allowed me to implement features in a language and stack I didn't know well. I had wanted these features for months and no one else was volunteering to implement them. I had tried to study the stack directly myself, but found the total picture to be complex and under-documented for people getting started.
Using Warp terminal (which used Claude) I was get past those barriers and achieve results that weren't happening at all before.
I once had a desktop computer that had great uptime, but started to consistently crash when I got up and left the room to get a drink of water.
Turns out it was old building with loose floorboards. The vibrational force of standing up was enough to short out a failing power supply. As long as I sat my desk, it was fine.
But I had a co-worker who had a worse problem with getting up to get a drink of water. Once while she was kitchen, an eight foot steel lighting ballast came loose from the ceiling and felt right onto her chair.That what-if memory still haunts me.
(not disclaiming that it wasn't, but that "chair piston causes EM surge" had me driven crazy for the longest time til I was able to pinpoint the cause)
That reminds me of one. I had a PC that would fail to boot the first time every day. Second and subsequent times were fine, until the next day.
When it stopped happening in the spring, and started again in the fall, it became obvious -- my apartment was too cold. The heat from the first failed boot sufficiently heated up the system to boot the second time.
Cache headers exist for servers to communicate to clients how long it safe to cache things for. The client could be updated to add a cache layer that respects cache headers.
Because the modern web isn't reliably HTML, it's "web apps" with heavy use of JavaScript and API calls. To first display the HTML that you see in your browser, you need a user agent that runs JavaScript and makes all the backend calls that Chrome would make to put together some HTML.
Some websites may still return some static upfront that could be usefully understood without JavaScript processing, but a lot don't.
That's not to say you need an LLM, there are projects like Puppeteer that are like headless browsers that can return the rendered HTML, which can then be sent through an HTML to Markdown filter. That would be less computationally intensive.
Yes, I much prefer this more nuanced take of "here's some things I like about systemd and here's some things I don't" then the blanket "everything about systemd sucks" feedback.
I wish this project well. I hope it improves compatibility with BSDs for more projects.
"everything about systemd sucks" people generally don't understand the problems that systemd is attempting to remediate, in my experience. Just repeating dogma that they heard someone they consider cool say.
Or perhaps, we don't have the problems that systemd is trying to solve. Or systemd creates new problems that we didn't need or want. Kind of like pulseaudio.
Yeah pulseaudio was like "you need this so you can have two apps playing music at the same time" entirely ignoring the existence of sound cards with mixers or the alsa soft mixer. Similarly, systemd was hyped at the time for, among others, allowing parallel service start entirely ignoring the several init systems that were already managing parallel start quite happily.
This turned out to be entirely the right approach, though, and it was probably pretty obvious even at the time. Sound Cards with built in mixers have all but died out. Everything they did has been eaten by software,
Even at the time, few games used an API where they managed multiple channels directly; Software mixing was commonplace from the 90s. Any game that wanted to play battle sounds was not relying on the mere 6-8 channels that cards from that time could handle.
Our modern Pipewire based workflow is remarkably simple and remarkably effective, and it's significantly an evolution of PA.
No, I hate PA cause it didn't work properly to the end. (Pipewire was better day 1 than PA ever was.) I just think that "you absolutely need PA to have multiple apps playing sound" was always nonsense, and the same sort of nonsense that was used to push systemd.
Yeah, that was total nonsense. Good cards existed. And if you didn't have a good card, alsa had a soft mixer. FreeBSD added a softmixer to OSS, too, so you didn't even need alsa. Worst case, you could run the Enlightenment sound daemon without Enlightenment and it was compact and just worked (as long as you had a simple sound setup)
I'm always happy to discuss sound cards with mixers, though! As a supporter of the Bloop Museum[1], I think that the "What might have been" if we had dedicated hardware for playing dozens or hundreds of sound files at a time is an interesting question. There's a lot of experimentation in the audio space that has kind of died out, because audio is so cheap - While over in in graphics, we're still seeing interesting advancements and dead ends.
I do. systemd solves a lot of my problems, actually. Of course all of systemd could be cobbled together by combining a dozen or so independent projects, but that mess is exactly why normal people (even normal computer people) shy away from Linux.
And I don't recall a lot of software working well when Pulse isn't available, so I don't know why people still bring it up. Perhaps it's because I wasn't there at the time, but I've only seen ALSA as "that audio system you use when you have nothing else available". I still need the PulseAudio-wrapper for Pipewire to be useful for my systems, so clearly the Linux world has moved to Pulse-first.
I was referring to apps packaged for Linux which don’t work seamlessly on FreeBSD because they depend on some Linux-specific part of the systemd ecosystem.
dbus is a big player there, but that is available for FreeBSD for the packages that need it (desktop environments etc). Systemd isn't really that important in that sense. After all there are many Linux distros that don't use it and things work fine there too.
But yeah, BSD is not Linux. So obviously things are going to be different. For example for plug & play it has its own devd for USB devices, and it can be configured easily.
If you'd port over all the Linuxisms like dbus, systemd, cgroups etc, then you basically end up with... Linux. What is the point in running BSD then?
It's a bit akin to people saying that every Linux should be more standardised (e.g. standard package manager, standard desktop), otherwise "the year of linux on the desktop" will never happen. But all these quirky desktops and distros are there because people have different needs and they don't want those to be watered down. The ecosystem as a whole doesn't matter to them. The same thing goes for BSD. I'm not using an OS with a desktop marketshare of literally 0.01% because I care about it becoming a mainstream desktop :) I also super duper hate the ideology behind GNOME so I would never use that, if it were the only option then I would just have to leave.
PS: I have no issue with things like dbus being available in ports but definitely not in the core system.
Anecdote time: I did a test like this with a small hobby project of mine (c++). I ported it to rust and saw roughly a 25% speed increase because of some refactorings I was meaning to do for a long time. I then ported the rust code back to c++ and saw another 15% gain in performance. Backporting the changes to rust again yielded no significant difference.
I am no rust programmer though, and I don't think the rust code was very idiomatic.
But then again I apparently write c++ like a common lisp programmer...
What makes you think so? The Rust compiler is able to instrument LLVM a lot better and provide it with a lot more info than C++ can. The borrow checker does a lot of the work there to for example keep things on the stack or do LSE or GSE and other optimizations. It isn't just about "oh, the rewrite allowed them to restructure things and optimize the algos". It is also that Rust due to its nature is able to be absolutely damn fucking sure that it can remove or optimize certain parts, whereas C++ can't in many cases.
Additionally, some people shared that they feel more comfortable making more aggressive optimizations in their Rust code because the borrow checker has their back.
Stylo was tried twice in C++ before the Rust attempt, and it never worked out, because the threading was too hard to get right. In theory you could have done it. But in theory, theory and practice are the same, but in practice, they’re different.
Oh definitely. Refactoring in Rust is a lot safer. Sometimes a lot more cumbersome, but definitely safer. Sometimes a refactor introduces a lifetime to a structure and now a loooot of places need changing, but at least it's safer. In C++, it would be less safe, but I could compile it and test the part I am trying to change or test first. It's a pro and con on either side.
But for the end product, I err on the safety side for sure.
IIRC, you yourself commented a few years ago in a thread on HN that the Rust situation was still a lot like "because of certain guarantees Rust makes we should be able to perform tons of optimizations that C++ could never do, and we haven't even gotten around to implementing most of them yet", has that situation improved a lot since?
("a few" might be off by pre-pandemic amount of years, my memory is a bit fuzzy there)
It's progressed in the sense of like, the Unsafe Code Guidelines and opsem teams are hammering down the exact semantics still, and have made a lot of progress. I'm not aware of any actual optimization work taking place off of it yet, which would make sense given that it's not all fully hammered out yet.
I also might have been handwaving towards how restrict kept having to be turned off because it was broken, meaning very few C or C++ codebases seem to use it at all, whereas virtually every Rust reference has it on. It's been back on for a while now.
Yeah I forgot the exact context of the quote too, no worries :). EDIT: it probably had something to do with aliasing and alignment (because when aren't people sighing about C/C++ when it comes to that topic?)
Thank for the general update! I might not write any Rust code myself, but I do enjoy quite a few programs written in it, so I was hoping to hear there was more progress for the sake of the developers behind those programs. But I can also imagine that these kind of things take time to figure out properly, to avoid repeating mistakes of previous languages (and that's before we even get to the task of implementing anything).
Wish the people working on these issues all the best, and looking forward (from the sidelines) to what eventually comes out of it!
Repeating it three times and it happened. Interesting that it shows it and then changes it - almost like one is local processing, and then a "better answer" comes from somewhere else.
