upvote
Yeah, they won't have a chance to rewrite cp and mv in Rust.
reply
[flagged]
reply
"Can't even match GNU's coreutils"? Care to elaborate? Last time I checked OpenBSD is pretty much in line with Posix and there are plenty of us that consider many of the GNU extensions to be anti-features.
reply
I use a Mac, so the CLIs are the BSD versions. I don't have any opinion on which is better, but it's just annoying that it's different from GNU, so a lot of my work ends up being on a Linux VM or server instead. POSIX compliance doesn't seem to buy me anything. I like the BSD license though.
reply
The GNU versions work fine in macOS. Apple doesn’t want to distribute them, but that’s mean you can’t use them.
reply
> Apple doesn’t want to distribute them

Apple can't distribute them - coreutils is GPLv3, which is incompatible with Apple's immutable system volume.

reply
That's a brand new excuse, Apple refused to distribute GPLv3 when GPLv3 was first published, 20ish years ago. How is GPLv3 incompatible with their system volume, yet GPLv2 is still fine?
reply
GPLv3 added language which specifically requires that GPLv3 software embedded in products be distributed with "Installation Information" explaining how modified versions of that software can be installed. It is not at all clear how this would apply to software in an immutable, signed system volume. This language was not present in GPLv2.

https://www.gnu.org/licenses/gpl-3.0.en.html#section6

(There are other issues with GPLv3 which make it a dubious choice for companies like Apple, but this one is particularly problematic.)

reply
This isn't new, GPLv2 is somehow compatible. This is the entire reason Mac OS ships an old version of bash but recent git.
reply
Of course, but any script meant for Mac is going to assume Mac core utils, even assume zsh instead of bash. You don't want to be the one person on the team with a non-stock setup.
reply
> The GNU versions work fine in macOS. Apple doesn’t want to distribute them, but that’s mean you can’t use them.

We also test GNU coreutils on macOS. It is a bit tricky since the other maintainers and I don't own any macOS machines for testing. But we seem to do well enough with a shared system that Adélie Linux kindly allows the compile farm [1] to use, along with some additional CI machines.

[1] https://portal.cfarm.net/

reply
POSIX compliance doesn't buy you anything because you're trying to use GNU extensions, which aren't in POSIX.
reply
I'm not trying to. And it's not even like GNU/Linux/whatever is a superset of POSIX and I'm using the extensions. There are mutual differences in basic functionality.
reply
If you stick to POSIX, things generally work everywhere. It's not really a question of what is better, just what is portable.
reply
I don't know how compatible my Mac will really be with a Free/OpenBSD machine. Last time I tested this theory, some C code I was building on Mac clang didn't build on FreeBSD clang cause I was unknowingly using some extension enabled by default. But that was about 12 years ago.
reply
Sounds like it's Apple who's behind
reply
In some cases they are, but that's not the cause for the mismatch vs GNU.
reply
Thats exactly what I mean. I dont care about Posix or the whining about "anti-features". The BSD stuff is a clear subset that doesnt get the job done.

Posix is more an art form documenting the far gone past rather than a practical tool

reply
What are some GNU coreutil extensions that you find you can't live without?
reply
The conventions for the long parameters on the command line.
reply
Dunno, since learning Xenix in 1993, I got plenty of work done in UNIX clones.
reply
"[Doesn't] get the job done"? Well, it gets my job done. You are welcome to use whatever you subjectively prefer (I use GNU's date(1) for a few scripts, but would prefer the English date grammar parsing as a tool of its own), but if you are unable to talk about anything in concrete terms there is not point in trying to discuss in good faith and I will just roll my eyes and move on.
reply
I am not the parent commenter, but I have the same sense that the GNU ones are better.

But the only concrete example I can think of is that `cat -n a b`, if `a` doesn't end in a newline, produces something that is obviously not what the user wanted. GNU cat does it right.

I didn't report it to the openbsd people because I didn't want them to yell at me that `-n` is nonstandard anyway with no "right" behavior, so I should STFU. Which would be what I'd expect from having reported problems in the past.

reply
That's kind of like saying that the MacOS UI can't even keep up with Microsoft Windows. Who wants inconsistent GNU halfassery?
reply
I think that's a cultural thing in *BSD.
reply
There are already OSes that include LLM code (such as Linux). It's fine to have a few that don't.
reply
It is, but an already niche operating system that refuses to leverage the advantages of LLMs is only going to fall further and further behind. I say that as someone who has actively contributed to the BSDs since the 90s and would hate to see that happen.

The slop problem is very real. People are spewing reams of bad code that generates entropy faster than humans or LLMs can clean it up. LLM best practices are not yet obvious, and we're still figuring out how best to leverage them while maintaining code quality and human understanding.

... but LLMs are coming whether we want them or not. Models keep consistently improving, the slop keeps getting better, and human-only development is going to struggle to keep up.

In my day job, I'm driving an enormous number of tokens at Astra+Ultramax solving problems in Lean 4 that previously we never would have attempted simply due to the incredible human engineering cost; we review the high-level lemmas and let it prove the rest.

LLMs are the only solution I've seen over these decades that could finally close the feature/usability gap between mainstream and more niche operating systems -- software support, features, drivers, and other broad usability barriers. All of that has historically been far too much work for a much smaller developer community to reasonably undertake.

Hating AI isn't going to make it go away.

reply
What does "behind" actually mean, though?

Think about how far Linux has/hasn't come in the last 10 years. The user experience is nicer, drivers "just work" more, there's more support for more stuff...but at the end of the day, the actual computing experience is mostly the same today as when I installed Debian back in 2016. It's polish, interoperability, etc that's improved.

Maybe VR takes off and takes over the desktop, and then openBSD can't keep up with that, but I don't think that's likely. So what are they trying to "keep up" with?

reply
> What does "behind" actually mean, though?

In this case, reading the link you're replying under, it's being able to mount a disk formatted with a popular filesystem. The alternative here is waiting for a human to type this relatively "solved" problem, as a procedural requirement, more than anything.

So, it can easily mean "things won't work in this OS". But, that's to be expected with FreeBSD, for legitimately good (from the perspective of FreeBSD) reasons.

reply
As one example I can think of, there are a ton of devices that only work on Windows (or Windows and MacOS). The audio interface I have is one example: its "official drivers" are Windows and MacOS only. I know that someone is trying to make Linux drivers for it, using LLMs, because if there's one thing LLMs are very good at, it's RE and figuring out how hardware works. One of my other friends made an accessible equivalent to the Razer app for his Razer headphones because the official app is complete shit.
reply
[dead]
reply
deleted
reply
"Behind" what exactly? This isn't a race to a finish line, it's an OS being developed.
reply
openBSD is ahead. depending on what u need. If u want a PC with tons of apps and even more security issues by all means, they are far behind ;).
reply
Following that line of reasoning a turned off pc is the farthest ahead. Its extremly secure after all and has no apps ;)
reply
Yep, drivers are one of if not the biggest blocker in my experience, and that's an area AI can help immensely
reply
Then vibe up the ones you need for yourself.
reply
‘Click to write and install driver’
reply
> 'Click to write and install driver’

Theo de Raadt would spin in his grave — after the security implications of this to OpenBSD gives him a fatal aneurysm.

Either that, or he'll surprise-launch OpenLLM, a model bundled in the next OpenBSD release that produces driver code free of security bugs.

reply
honestly LLMs could probably write drivers in CompCert C or some other formally verified dialect. having AI discharge proof obligations seems like a terrific use for all this newly-developed mathematical process.

you could have the driver code prove it implements a spec, that there's no UB, that hardware invariants are maintained, that routines take a fixed time to execute.

the formal driver spec must still be written by sober, well-caffeinated humans of course.

reply
That's also assuming the device is fully documented and that hardware behaves exactly as documented.
reply
Anyone who has done any work with hardware can confirm that neither of these things is ever true. :(
reply
> Theo de Raadt would spin in his grave

Isn't he still alive?

reply
> — after the security implications of this to OpenBSD gives him a fatal aneurysm.
reply
Excellent, it will remain stable
reply
Good.
reply
Well, they were always slow. But they made a stand against AI slop, which is great. Look at how AI slop infiltrated the ruby core team. You even get slop-spammed down when you try to interact with e. g. Hiroshi Shibata, who suddenly has ... perfect english language skills. A few years ago his command over the english language was rather weak (which is fine by the way, I much prefer broken english from a real human than AI slop spam text as filter acting in between humans).
reply
Then learn Japanese. No? So you can write broken Japanese and he doesn’t have to translate his words in English for you.
reply
If you don't break the law you do indeed fall further behind people who do.

Nothing in that post is against using an LLM. It's all about copyright:

>Since every file in OpenBSD has been continually verified to ensure correct Copyright, and we've even deleted code which has incorrect Copyright, the chances of us accepting such new code with such a suspicious Copyright situation is zero.

Once the current bubble pops we're going to see a lot of litigation over copyright enfringement by LLMs. Currently no one wants to rock the boat because everyone hopes to make a trillion dollars from AI, Oracle included, once they see they can't the knives are going to come out and I wouldn't want to be Linux at that point: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America

reply
Copyright will adapt.

Also my personal opinion about copyright _in the FOSS domain_ is that I simply dont care. Copyleft as the GNU folks like to call it is just using the copyright laws to achieves certain free software objectives. If that doesnt work anymore there will be another fix

reply
Copyright adaptation literally means billion dollar lawsuits, because copyright only adapts after court decisions.

The BSD licences are not copyleft, or indeed part of the GNU copyright regime.

reply
Yeah, the billion dollar lawsuits that are coming after the trillion dollar ones that are gonna hit the AI industry any day now.

Copyright is dead.

reply
>Copyright is dead.

I remember hearing that in 1996 too.

reply
How was the LLM training scene in 1996?
reply
So long as there's big money interests around copyright, I assure you it will not die. And all the predictions about the knives coming out after the AI bubble pops are spot on.

It took a while for the DMCA to happen after Napster. But it indeed happened, and we all know the saying about history repeating itself.

reply
> It took a while for the DMCA to happen after Napster.

By the time they came for Napster technology had already moved on. I can still download entire albums and movies in minutes 2 decades later. Heck, Usenet is still a bastion of piracy and that's been around for 46 years.

reply
> my personal opinion about copyright _in the FOSS domain_ is that I simply dont care.

You may not care, but if the OS you prefer to run is the defendant in a copyright case, that's likely to impact you in a negative way.

reply
It is amusing to see this point made in a discussion that is notionally about one of the BSDs.

"Those that do not learn history" and so forth.

reply