osmsucks

> NetBSD's main claim to fame is that it runs on practically everything

That means available number of architectures. NetBSD still support some pretty esoteric stuff, but though I haven't actually counted I would expect Linux to run on a comparable number of architectures.

Now, the kernel will probably boot successfully on a given machine, but whether hardware (i.e. driver) support will be decent enough for everyday use is a completely different matter! For example, NetBSD "works" on this laptop of mine... except for Ethernet card, Wi-Fi card, touchpad, ACPI suspension, external monitors via the docking station, ... :)

I'm trying (for fun) to bridge some of these gaps, but you can see how this isn't appealing to the average user.

> For instance, what if Google never sends the source code? What if they claim that no request made it in?

That would be a violation of the license terms. All Google has done so far is, apparently, to make it hella annoying to access the source code (but not impossible).

Yeah, I agree. While this is a terrible move IMHO, from my superficial reading of the GPLv2 it doesn't really constitute a violation: the license imposes that the source be distributed to anyone who asks, potentially even charge a fee to cover its distribution costs, but it doesn't require that development happen in the open.

Opened this page in Firefox and my CPU fan started spinning like crazy. All this for a background that just renders the whole page unreadable.

Stop. Seek help.

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 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.)