Only an LLM could liken a first-grader to a scholar: "In a stratified society where the imperial family sat at the symbolic center, that gesture mattered. The randoseru moved, almost overnight, from battlefield to classroom, from soldier’s kit to scholar’s gear." This is an interesting topic, but this kind of AI writing gets very, very grating. Additionally, though this is somewhat unrelated, I feel like LLMs tend to argue points through gaslighting, rather than actual argumentation; they prefer to stack a bunch of tangential, or parallel, evidence and then assert that it proves their point when, in reality, it does not have any logical coherence—unless, perhaps, one reads it at 2am, in which case it might make sense.
It's not even close! It's nearly two orders of magnitude higher for Linux.
This isn't anecdotal or “vague opinion” CVEs are facts.
You can ask the follow-up question: Why is that?
And there are many reasons.
It could just be that Linux having more users/eyes means more bugs are surfaced ...
But you need to dig deeper to understand why OpenBSD is so much more secure,
the core team of OpenBSD proactively reviews the security of other OSes and when they learn something, they rapidly implement the feature/fix in OpenBSD.
Again, read: https://en.wikipedia.org/wiki/OpenBSD_security_features
Many of the proactive security features OpenBSD has are not implemented by other OSes. And in the case of kernel-level Crypto, they won't ever be because US export restrictions.
> And there are many reasons. It could just be that Linux having more users/eyes means more bugs are surfaced
You really brushed that one off, uh? The ratio of linux devices to openbsd is quite literally a million to one. The ratio of tech companies invested in linux to companies invested in openbsd is roughly 50,000 to 1. The ratio of professional security researchers paid to find flaws in Linux vs OpenBSD is harder to quantify at the moment, but I think we can guess a trend here.
I can agree to a degree that OpenBSD takes security more seriously, and they have made very interesting design decisions to enforce their security model. But I entirely disagree that the number of "CVEs are facts" to back your opinion that it is superior.
> This isn't anecdotal or “vague opinion” CVEs are facts
No they aren't, they're data. Your source shows the amount of Linux CVEs in 2024 are an order of magnitude higher than the amount of Linux CVEs in 2023. Does that mean Linux became way more insecure in 2024? You imply it does, but that's obviously not true. What happened is that Linux changed how they report CVEs [0].
Just like your source doesn't say anything useful about the difference in CVEs in Linux, it doesn't say anything about the difference in CVEs between Linux and OpenBSD.
This announcement thread really isn’t the place to discuss or debate the data.
The OP stated they couldn’t find any data to compare the relative security of Linux vs. OpenBSD.
CVEs are independently, objectively verifiable and provable data. This is the dictionary definition of a verified “fact”. It’s not anyone’s opinion.
You don’t have to like it or me.
Going by CVEs, Haiku is more secure than OpenBSD. Linux has had strong kernel-level crypto enabled by default on major distributions for years, see AF_ALG or LUKS.
On the wiki page you provided, the only thing that really stands out at the kernel level is KARL, which has a dubious utility: https://isopenbsdsecu.re/mitigations/karl/ It is not even up to date: strlcpy(3) and strlcat(3) were implemented in glibc 3 years ago.
> I would be in favour to say that out of the box OpenBSD is more secure than Linux.
Also important to remember that diversity builds strength. Just as in biology, if all organisms are the same, they all succumb to the same virus.
I have a multi-layered firewall approach where some are Linux, some are OpenBSD, some are commercial. They'll all have bugs, but unlikely they all have the same bug.
You are correct; OpenBSD is secure by default. And it's not subjective at all.
The homepage of https://www.openbsd.org proudly states "Only two remote holes in the default install, in a heck of a long time!" if they didn't have the evidence to support the statement, the internet would have forced them to remove it by now. ;-)
Remote (exploitable) holes are the ones we all care about.
The key (and not saying it's bad, mind you) is that the default install has very few services installed, let alone running or open.
So even if Debian and OpenBSD ship the exact same web server, but Debian has it defaulted installed and on, but OpenBSD does not, then a remote exploit won't count against OpenBSD.
All OpenBSD services, including HTTP (httpd), SMTP (smtpd), and DNS (nsd, unbound, unwind), use privilege separation and sandbox themselves with pledge and either unveil or chroot. There's no extra configuration. And the developers dog-food these services; it's why they're in the base system.
How many Linux services use seccomp? Or chroot, mount namespaces, or landlock? If they do at all, it's usually imposed externally by systemd or docker, in which case they usually run with overly broad permissions because there's no integration with the specific application code, thus the AF_ALG exploits in containers. On OpenBSD services continue to narrow their privileges after starting up so by the time an external request is serviced they have only minimal access to syscalls and the filesystem, often only read/write/send/recv syscalls, and if open is allowed only the specific files and directories needed to service requests. Typically even the network-facing daemon accepting TLS connections doesn't have access to the private key--you simply can't do that by running a vanilla service application in docker.
Does OpenBSD have bugs? Of course. The question is, which environment has more trustworthy backstops? The Linux kernel provides all the facilities, but they're not used effectively, for many reasons.
Isn't that a good thing for certain use cases ? If you are building an appliance type thing (say a storage or networking device) then you would want something minimalist you can add only the necessary services on. And arent those the types of devices the BSD (in general) are used for ?
Less attack surface always equals less potential for bugs/flaws/exploits regardless of how good red teaming tools and workflows get.
Now obviously for other use cases Linux could be a much better option.
There was a time when Linux distributions shipped lots of things on by default; OpenBSD bucked the trend and did not. This is less of an issue nowadays.
> This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings.
I'm saying you don't even need Mythos to find bugs in OpenBSD. GPT 5.5 is SO much better than humans at finding these things.
The fact that we don't even need Mythos, or $20k (I just pay $24/month and this was one of my MANY uses), to find bugs in OpenBSD shatters the dream that there exists any human who can write C properly with enough expertise, dedication, and time.
As I mentioned in the post, I only did a brief exploration of OpenBSD in order to cheer myself up. I took some findings, confirmed them being true bugs, and ended there.
As I said in the out of bounds null termination write patch, I don't believe it's exploitable. I would have gotten a CVE, website, and logo then (kidding!). But it was UB. And one-byte overflows have in the past been exploitable by better sploit authors than me.
In any case, I reported that since I felt it was clear that OpenBSD folks would obviously care about it, exploitable or not.
Confirming these findings take time, even though I found GPT to almost always be correct. I will NOT report upstream until I understand the bug. I ain't no slop reporter. As I said in the post OpenBSD (and all other code bases) need a larger effort. The Mythos/Glasswing effort focusing on actually exploitable ones may be a good method for getting them fixed, without overwhelming projects with patches, even when the patches are correct.
I did confirm at least one more UB, and did consider whether to report that OpenBSD `find` reads `status` via `WIFEXITED(status)` without checking `waitpid()` for errors. This is UB since `status` is uninitialized.
(https://github.com/openbsd/src/blob/ae684bfaed6cae797cd90e27...)
The reason is my previous experience with OpenBSD where the reply may be "<some standard> is wrong in this regard", and because they control their whole system, they don't care. E.g. in this case they may go "we build with GCC x.y.z exactly, and we know what actually happens in this controlled domain". This may be a bit unfair to them, but not by much.
GPT also flagged the extremely surprising behavior of running `cat -n file1 file2` if file1 doesn't end with a newline. And that `find /etc/passwd -execdir[…]` doesn't run the command. But maybe that's how they want it? I don't want to go through the whole thing for them to go "yeah we won't do that" again. So I think this project is for them. GPT is as available to them as it is to me.
Tangent: in running GPT against `cat` I learned that not only is `cat -n` not standardized, but it also behaves COMPLETELY differently than on Linux, if you provide more than one file.
It's not meaningfully more secure than e.g. Debian.
Their claim to fame ("only two remote holes in the default install in X number of years") is definitionally only valid for the default install in its default configuration which means: no httpd, no smtpd, no unbound, etc. etc. etc.
The default install isn't very useful, because it doesn't do a lot, and so "only two remote holes" or whatever isn't really saying much.
Linux has more CVEs because it's orders of magnitude more popular. OpenBSD has appalling performance, and more or less nobody uses it, so there just isn't a large focus on auditing and fixing it.
It's a great research project, but I would not run it on my personal devices. Not because it's "insecure" but because the putative security benefits do not merit the shockingly poor performance.
> The default install isn't very useful, because it doesn't do a lot, and so "only two remote holes" or whatever isn't really saying much.
Thats not really true. Comes with spamd, pf, httpd, OpenSMTPD and others. Its actually one of the open source unix-like systems that packs more functionality out of the box.
Great firewall and VPN server. You can setup wireguard with just ifconfig.
I get your point, but GP is right: You said "Default install", not enabled by default.
The default install is actually very useful, and includes a lot, like parent said. Having run OpenBSD in the past, I found the their versions of things were often superior, at least for small setups (and some of them for large installs as well.. probably : )
I use it on my ~10 year old desktop as my everyday OS. Performance may be measurably worse on benchmarks, but I never notice it doing regular stuff as a user. It's fine.
Easy to install and upgrade, sane defaults, good documentation, lack of waffleburgers of complexity, so I'm not sure why anyone wouldn't run OpenBSD in the first place. Granted I put Windows in the unusable bin and it's been there for decades now and sounds like it is getting worse, what passes for Mac OS X these days is not so good given that you have to disable some security thing to properly kill the annoying and disruptive notification system, among other annoyances still being fueded with, and I gave up on Linux after trying to support that waffleburger in production for a year or two.
With due mention to FreeBSD's jails, BSD's security image developed mostly from OpenBSD which is said to have gained its security focus due to NetBSD being so insecure that the NetBSD folks were able to hack into DeRaadt's forked OpenBSD.
Android's Bionic was based on or heavily influenced by OpenBSD's libc iirc, though.
No, not really. Linux has better options available and is significantly stronger when configured correctly. The OpenBSD approach ls largely based around eliminating bugs in the first place, but isn't as strong at limiting an attacker that successfully exploited a bug they missed or weren't responsible for.
These are the operative words. With OpenBSD, you get this out of the box and everything just works. With other operating systems, you have to do a lot of the legwork that's already been done for you with OpenBSD and make sure you didn't break things with your configuration.
These are words that when applied equally to Linux and OpenBSD, has Linux coming out ahead.
> With OpenBSD, you get this out of the box and everything just works.
With OpenBSD, out of the box you get a blank slate that really can't do anything, that you have to configure to do what you want, and currently can't be configured to be as secure as linux can be.
Sorry but that's simply not true. There are various cases where vulnerabilities didn't affect OpenBSD due to defense in-depth in OpenBSD.
OpenBSD has a pretty long history of eg. limiting attacks through compile time mitigations while making them more usable for every day use compared to specialized "high security" Linux distributions. This can also be seen in patches of third party software (in the ports (packages) system) that often have patches so the code can live with these limitations.
One example of such a mitigation is W^X. Implemented in OpenBSD in 2003, copied later by Windows, Linux and the other BSDs (incl. macOS).
More recently of course pledge and unveil were also added.
Also in 2003 OpenBSD was also the first mainstream (no research or test OS) that implemented strong ASLR that in 2005 was supported in Linux through third party patch sets.
It really is true. OpenBSD focuses on auditing. In many cases they were not affected because of mitigations, but because they were just using a different stack. OpenBSD wasn't affected by regreSSHion for example, for basically the same reason Alpine wasn't.
OpenBSD didn't invent the concept behind W^X, and if you want to talk of 'copying', which I think is kind of silly personally, then PAX was first.
I'm familiar with the list of OpenBSD innovations, and in turn I would point you to https://https://isopenbsdsecu.re/ for a breakdown of their claims and marketing.
To this date OpenBSD doesn't have anything as simple as a proper ACL, let alone any type of MAC. They claim such systems are too complex, which is of course nonsense.
It's like I said - they focus a lot on preventing an attacker gaining access, but have little available to constrain attackers who DO get access.
> there are numerous other things that are done for mitigation outside of this.
Sure, and I think they are mostly great, main problem being they just don't go far enough. Where's the namespace level isolation, ACL or MAC support? Is there a way to give a user append only ability for one file, while having write but not delete access to another, and delete to yet another? What's the maximum extent to which OpenBSD could have limited an attacker, had they been vulnerable to regreSSHion?
Don't make the perfect be the enemy of the good. Just because they didn't stop escape via dirtyfrag doesn't make them useless let alone a joke. pledge and unveil are nice, but exactly how effective do you expect them to be against an ssh/sftp server? Maybe you have ssh configured so it can't manipulate user and/or system files, but that isn't typically common usage.
At this scale, that kind of thing is not really a problem; you just dump all of the data you can find into the model (pre-training)1. Of course, the pre-training data influences the model, but the reinforcement learning is really what determines the model’s writing style and, in general, how it “thinks” (post-training).
Yeah I flat out don't believe the 2% thing. It's possible that I was the 1 out of 50 who checked the page and saw that Claude code was removed... but it really seems like everyone I shared it with saw the same thing which is incredibly unlikely. Also I am an existing subscriber and checked the price page while logged in, so I shouldn't be counted in "2% of new subscribers" at all...
I have a Claude Pro tier subscription; Claude Code, as of right now, is still functional for me. If Anthropic does boot Pro-tier users off Claude Code, I will be cancelling my subscription.
They would probably grandfather existing users in for at least a year or something, you have to imagine. Even if this "test" goes very well and points to removal
This test makes perfect sense with their actions the last few weeks, they think they've done enough to transition into the general public and away from devs and our goodwill no longer is something they should be concerned with.
Its funny that openai, who in my eyes went for the general public rather than devs initially, seems to be semi pivoting and catching all the fallout from anthropic's recent behavior.
It is a massive bummer, up until those few weeks ago, i was hard pulling for anthropic for quite some time, now i just dont care and hope something dope emerges quickly that signals i wont ever have to consider either of them.
I was part of a team researching MS at a university a while ago. It truly is an endlessly fascinating disease. Most evidence currently points to MS being caused by a combination of Epstein-Barr infection and genetic factors [0,1]. It is hypothesized that Epstein-Barr triggers autoimmunity which results in the prototypical demyelination [2].
Theoretically, you can’t benchmaxx ARC-AGI, but I too am suspect of such a large improvement, especially since the improvement on other benchmarks is not of the same order.
It's a sort of arbitrary pattern matching thing that can't be trained on in the sense that the MMLU can be, but you can definitely generate billions of examples of this kind of task and train on it, and it will not make the model better on any other task. So in that sense, it absolutely can be.
I think it's been harder to solve because it's a visual puzzle, and we know how well today's vision encoders actually work https://arxiv.org/html/2407.06581v1
The real question is: Why are people designing benchmarks that, if a model is trained on them, it won't improve the performance of the model at any real-world tasks? Why would anyone care about such benchmarks?
reply