osmsucks

I'm in this quote and I don't like it.

Since it's a personal project, Linux compatibility is the only thing I care about right now. I'm testing it under WINE as well, just because I can, but I don't have access to Mac OS so I'm skipping that problem entirely for now

I feel like one of the takeaways here is that Rust protects your code as long as what your code is doing stays predictably in-process. Touching the filesystem is always ripe with runtime failures that your programming language just can't protect you from. (Or maybe it also suggests the `std::fs` API needs to be reworked to make some of these occurrences, if not impossible, at least harder.)

On a separate note: I have a private "coretools" reimplementation in Zig (not aiming to replace anything, just for fun), and I'm striving to keep it 100% Zig with no libc calls anywhere. Which may or may not turn out to be possible, we'll see. However, cross-checking uutils I noticed it does have a bunch of unsafe blocks that call into libc, e.g. https://github.com/uutils/coreutils/blob/77302dbc87bcc7caf87.... Thankfully they're pretty minimal, but every such block can reduce the safety provided by a Rust rewrite.

I noticed the performance issues too. I started using Jan recently and tried running the same model via llama.cpp vs local ollama, and the llama.cpp one was noticeably faster.

Thank you. I also found it exhausting to read so many short sentences that just assert little pieces of information without saying anything of substance.

In my university, probably because the CS department at the time was an underfunded offshoot of the faculty of Mathematics, we basically didn't have access to computers (and I didn't have a laptop of my own).

We did almost everything on paper, even exams. I admit writing MIPS assembly on paper seemed strange to me at the time, but the effort you put in to put things black on white somehow made the knowledge stick into my mind more effectively. Some of that knowledge will stay with me forever, and I'm not sure the same could be said if I had taken "shortcuts".

To us, all the profit. To you, all the risk.

So you're saying that the slop thus produced is not the responsibility of the human authoring the PR? I would assume it is, regardless of how it was produced.

This article has a weird tone. It directly criticizes the results of this AI-driven coding effort (which the author admits is of bad quality), while at the same time it tries to reassure the reader that they're not here to criticize the author of the PR.

Only of these can be true at the same time.

Helix is my default, as it's a more mature/stable editor. I fire up Flow Control from time to time to follow how it's developing and for more casual editing. They both do an excellent job overall, but my muscle memory binds me to Helix for now.

(I know Flow Control provides Helix keybindings, but I haven't tried that yet and I generally like to retain the default behavior of an editor so that my user experience is more "portable" across machines.)

I, too, mourn the death of Howl. It was a quirky yet surprisingly "comfortable" editor.

But I am now at home with Helix and Flow Control.

Okay, you go get treatment at that facility if it's working as well as you insist.

Besides, whether the facility is (partially!) operational today is besides the point. Your original post insisted that "Israel has destroyed no hospitals", while it clearly has. The picture I linked is from 2024. The fact that Al-Shifa was brought back to a partially operating state in late 2025, after months of partial ceasefire, doesn't disprove that it was destroyed in 2024. Sources like https://en.yenisafak.com/world/al-shifa-hospital-begins-reco... show that the situation is far from positive.

And, again, this is just one example of the many.

...What an odd and dishonest framing of the problem. Do you define "hospital not destroyed" as "some walls are still standing"? Because an easy counterpoint to your claim is the Al-Shifa Hospital, which you will certainly agree cannot be operational in this state and thus can be defined as "destroyed":

https://upload.wikimedia.org/wikipedia/commons/5/5a/%D9%85%D...

And this is one example out of the many: https://en.wikipedia.org/wiki/Attacks_on_health_facilities_d...

  size_t size = nullptr;

Porkin' across America! https://www.youtube.com/playlist?list=PL4NL9i-Fu15jdlr2KQf_l...

The quality of the benchmark code is... not great. This seems like Zig written by someone who doesn't know Zig or asked Claude to write it for them. Hell, actually Claude might do a better job here.

In short, I wouldn't trust these results for anything concrete. If you're evaluating which language is a better fit for your problem, craft your own benchmark tailored for that problem instead.

Great timing: I just received a Copilot spam email from GitHub. I don't remember opting in to such marketing communications, instead I generally opt-out from such communications as soon as I sign up to a service...

I came here to suggest the same! It's incredibly handy and I use it all the time at work: there's a process that runs for a very long time and I can't be sure ahead of time if the output it generates is going to be useful or not, but if it's useful I want to capture it. I usually just pipe it into `less` and then examine the contents once it's done running, and if needed I will use `s` to save it to a file.

(I suppose I could `tee`, but then I would always dump to a file even if it ends up being useless output.)

There is a C backend, so you can also compile Zig into C if you want.

There are way too many TLDs for this to be even practical: https://data.iana.org/TLD/tlds-alpha-by-domain.txt

I agree that especially larger players should be proactive and register all similar-sounding TLDs to mitigate such phishing attacks, but they can't be outright prevented this way.

Yes, practically all of my projects are private and visible only to me. Servers IIRC are located in the Netherlands. It's free to use with limitations, and financed by donations from supporters.

More:

  - Annual financial reports: https://disroot.org/annual_reports
  - Someone's review: https://proprivacy.com/email/review/disroot

For personal projects, I'm hosting them on <https://git.disroot.org/>. It's backed by Forgejo, and for my simple needs it's plenty.

In defense of Foot, I installed the corresponding Nerd Font and it worked with no extra configuration at all. Well done!

Yep, and that's all configuration I'd rather not have to spend time on. I was giving the Ghostty example to show how one of them Just Works™. (But the project goals might just be different, I'm not here to discredit Foot which is a really good terminal emulator.)

Precisely this. With OSC-52 you don't even need copy/paste keybindings under tmux.

I don't think I understand this example. There's only so many keybindings and clashes aren't uncommon.

That's precisely my point! Many terminals these days try to do too much and by default end up capturing keybindings that I want to use for something else. The terminal should allow me to do that something else, not get in the way. A simple terminal wouldn't get in my way and I could insert tmux in the more complex scenarios (even for local sessions). I know I can reconfigure most terminals, but not everything is configurable, plus everyone knows the best tools are the ones that don't require to be reconfigured to be great. :)

Thankfully my main editor is Helix and by default it doesn't clash with anything because it's a modal editor where commands are regular keystrokes and not key combinations.

Foot is a barebones solution, so that might be good for you

I'm aware of foot, and it works fine, but it doesn't correctly display the fancy icons used by foot (and other programs). For a visual comparison, here's foot on the left, Ghostty on the right: <https://v1.imgpaste.net/images/public/21baee04-b4a5-4693-8a8...>

I would mostly agree, but I like that I can use tmux locally and remotely and thus have the same interface wherever I do my work (and regardless of what terminal I use).

Then, there's the fact that some terminals capture too many keybindings and get in the way of some terminal code editors I'd like to use (e.g. recently I was again trying to use flow <https://github.com/neurocyte/flow> and its next-tab and previous-tab shortcuts clash with Ghostty's). If I had a terminal that 1) was nothing but a black box with the capability to display Unicode font glyphs and ligatures correctly, 2) works under Wayland, and 3) captures as few keybindings as possible, I'd use it locally with tmux and live happy.

JavaScript is: https://mathiasbynens.be/notes/javascript-encoding

I remember having to write XF86Config by hand.

EDIT: of course there's an xkcd for that: https://xkcd.com/963

LLMs seem to be really good at reproducing the classic Ball of Mud, that can't really be refactored or understood.

This, but but only for code. I've seen "leaders" at work suggest that we "embrace" AI, even for handling production systems and managing their complexity. That's like saying: "We've built this obscure, inscrutable system, therefore we need another obscure, inscrutable system on top of it in order to understand it!". To me, this sounds deranged, but the amount of gaslighting that's going on also makes you think you're the only to believe that...