OpenBSD foundation raised around ~380 thousand IIRC.
By creating OpenSSH and the fact all fortune 500 companies use it, I would say every year, the foundation should be bringing in around 1 or 2 million. It is time these companies really give back.
And while I am here, hardware vendors should open up their source, looking directly an Nvidia.
It's not the foundation that does the work but developers. With that kind of budget, the foundation is just administrative support. They aren't employing a lot of developers. Many developers are employed of course. Partially by those same fortune 500 companies that you mention.
Open source is a pragmatic arrangement where developers embedded in the industry can collaborate and share code; often explicitly supported by the companies they work for. It has worked very well for decades and there's no urgent reason to change anything.
For example, Damien Miller, who puts in a lot of time on OpenSSH, is employed by Google. Employing key contributors is how the industry supports OSS.
Your second paragraph is explaining perfectly why open source doesn't work and how its economics don't add up.
I would also add that it indirectly kills the vast majority of programming jobs - nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg. Nobody is ever get paid to write a new kernel as everyone can just use Linux. Very few people are going to get paid to work on a new database as you can just use Postgres...
Once there's a good enough open source solution in a field, in the long run it will out-compete commercial offerings, even it's overall a worse package, as it's some guy's free time project and is created on a $0 budget.
Programmers work for free, end users get a worse product, companies make trillions.
> I would also add that it indirectly kills the vast majority of programming jobs - nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg
Looked at another way, open source means that instead of a bunch of programmers getting paid to write multiple implementations of the same thing over and over, so the programmers that otherwise would be doing that can instead work on new innovative things.
In an ideal world, all software would be open source, and programmers would spend all their time improving said software for everyone. The problem is I don't know how those programmers would be compensated for their work. In many ways, open source software is a public good, since anyone can benefit from it[1], so an argument could be made that OSS should be publicly funded (i.e. paid for by government grants). However, I am doubtful that the government could do a good job of allocating resources to open source projects. Then again, I don't think the private sector is doing a great job of that either. Just look at how many resources are put into showing people ads.
[1]: And it has the interesting property, that unlike most public goods, the cost does not scale with the number of people who use it, or have a limit on the number of people who use it.
Isn't the solution to have much shorter copyright terms? Software could be closed source at first, its implementation costs recouped, then opened by default when its copyright term lapses. New releases could still be closed, so income could continue. Set the term at 5-10 years, rather than >70.
This doesn't really work for projects that want to be closed source, as they can just not publish the source. After the 10 years, people can copy the binary, but that doesn't really give you a whole lot of benefit.
And if a project does want to be open source eventually, they can already license their code that way.
> It's an extremely successful model organizationally and technically.
There are technically impressive open source projects - e.g. Linux, and most of them have people paid to work on them full time. Those are the exception, not the rule. Most open source projects are some guy's hobby, done for free in their free time. Hobbyists solve problems they find interesting, and often ignore a lot of the "gruntwork" required to make a technically sound package.
> Anyway, are we short of programming jobs?
Yes. Especially good ones.
> Efficiencies create new, higher-value possibilities than, for example, JPEG decoders.
I don't see it - a large portion of programming jobs have devolved to gluing together a bunch of open-source libraries, doing the boring gruntwork to actually make them work, and dealing with the inevitable hell, caused by using 500 components that were never designed to work together.
> Those are the exception, not the rule. Most open source projects are some guy's hobby, done for free in their free time.
And most proprietary software becomes completely unavailable when the company making it goes out of business. At least with the open source software, if there is interest in it, someone else can pick it up, if the original creator stops maintaining it.
> a large portion of programming jobs have devolved to gluing together a bunch of open-source libraries, doing the boring gruntwork to actually make them work, and dealing with the inevitable hell, caused by using 500 components that were never designed to work together.
And you think that would be any different without open source? A large portion of programming would still be gluing together a bunch of components, but instead of open source libraries you would have proprietary libraries, where if the documentation is inadequate or wrong, you have no option of looking at the source code to see what it actually does. Or in-house libraries that were designed for some specific purpose that doesn't match yours at all, and are very low quality, because they were made under a tight deadline, and no one ever went back to pay the tech debt after the MVP was released. Or maybe instead of a library you make API calls to some SaaS with no SLA and barely any documentation.
> Hobbyists solve problems they find interesting, and often ignore a lot of the "gruntwork" required to make a technically sound package.
OTOH some commercial software only solve problems that make money, and ignore the technically sound part unless it makes money. E.g. the enshittification of Google, Windows or Facebook, and friends, from a product that worked to a product that nobody asked for. All the technicality spent in tracking users, more ads, etc.
These are a lot of commercial software that are not much more than a repackaging of open source software and a UI layer (ffmpeg, for example).
> nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg.
if there's no technical reason why libjpeg isn't suitable, I'd consider it a huge waste of human life to create another. if there is a good technical reason to build a new one, then somebody will do it for free or somebody will pay for it to be made.
> Your second paragraph is explaining perfectly why open source doesn't work
> some guy's free time project and is created on a $0 budget.
> Programmers work for free
You seem to be completely out of touch with what FOSS is.
The amount of relevant FOSS hacked by some teenager for free in moms basement is negligible. The largest contributors to the Linux kernel are IBM, Intel and Oracle. Nobody there works for free.
Because it costs down their own development costs, doing more with less.
How much upstream do you think BSD gets from Sony and Apple, besides a few crumbs?
clang was sponsored exactly to allow Google and Apple to take a compiler and not be legally obliged to upstream their sauce.
Nowadays clang has mostly replaced most proprietary compilers on surviving UNIXes, and embedded OSes, how much of those downstream changes land on upstream clang? It is mostly volunteer work improving ISO C and ISO C++ compliance, despite all the money being made by those folks.
I wouldn't be a good way to spend money and resources to rewrite things like jpeg decoders again and again. It would not help to make the final product any better, but just siphon the money off from more worthwhile purposes.
Companies make billions? Good. It's time to tax them and use the money for the benefit of everyone.
> Nobody is ever get paid to write a new kernel as everyone can just use Linux
Not that it negates your point in any way, but lots of people are paid lots of money to write Zircon (Google Fuschia's kernel) which is intended to replace Linux in many scenarios.
If we had to write every single piece of code over and over(or pay for them), computer science would have barely evolved and would not be so mainstream
No, writing them over and over is literally what evolves computer science. Not having to write them over and over is what improves software. They’re different.
OpenBSD has supported 11ac for several years, and has the iwx(4) driver for modern Intel WiFi cards. There's also support for Broadcom FullMAC, bwfm(4), which is on e.g: Apple Silicon machines.
HaikuOS also has a port of OpenBSD's iwm/iwx drivers.
FreeBSD just recently announced they've started porting the OpenBSD iwx driver.. from Haiku.
Not OP, but they've raised $4,974,668 since 2014 (done by adding up all the thermometers at https://github.com/bob-beck/foundation-web), and I'm excluding anything prior.
It's not as bad as it used to be, but one moat some companies had was "excellent support for Linux/Unix/BSD". Until CUDA no one in their right mind would buy Nvidia for their Linux workstation, just like you'd avoid certain Broadcom wireless chips.
Hardware companies need their devices supported by as many operating systems as possible, especially if those devices can be used in servers, desktops less so. Apple is pretty much the exception.
When you give freely and generously to the community you should do so with no expectation of getting anything in return. Sometimes that expectation is fulfilled.
They are not talking about OpenBSD's expectations, it's about the ethics (!) of the companies using things on the back of the generosity without giving back.
I see this mindset more and more, and to me it seems against the ethos of open-source software. There's something philosophically odd about saying "you are free to use, change, redistribute, or sell this with basically no restrictions" while simultaneously maintaining that users incur unstated ethical debts by accepting. It could even be seen as a kind of bait-and-switch.
Contributions and reciprocity are praiseworthy of course, and we should all aspire to this. But that doesn't mean someone is ethically wrong for choosing to accept a gift freely given without giving one in return.
You are legally free to use. Your ethical obligations will depend on your particular worldview, and are likely to vary substantially by culture.
All cultures I'm familiar with recognize that someone who is well off taking advantage of a tragedy of the commons is unethical. The particulars vary by locale but my impression is that it is universal that the degree of condemnation increases the wealthier the person exploiting the system is.
The thing about the tragedy of the commons is that you are actively hurting everyone else by depleting a non-rivalrous good.
When I accept a friend's hospitality and don't reciprocate, I am taking their time and resources. When I take five free samples at the store, I ruin it for others who come later.
When I download an open source GitHub repo, I am burning 1¢ of Microsoft's money.
The cost of software is not the cost of distribution, it's the cost of maintenance, support, and implementation. When you clone a repo, this has little impact by itself, but the work to create that repository in the first place, to maintain it and ensure it is free of bugs, and to provide documentation and support so that people understand how to use it - that all has a cost.
If nobody pays for that cost, then the work will never get done in the first place, and we won't have these resources.
> When I download an open source GitHub repo, I am burning 1¢ of Microsoft's money.
While the other examples seem good for illustrating the point, this one has it backwards I think. Microsoft worked very hard to be in this position. They did this on purpose and this aspect is essential to their success:
- GitHub did everything they could to capture the market by being free to use and by leveraging the network effect
- Microsoft bought GitHub at a point where it was already widely successful in this aspect, so they fully knew what they were buying
Capturing the whole open source market is part of their business model. I don't like they've done this and I don't get to choose where authors host their code. Even the authors themselves might not have felt free to choose something else because of the network effect. It's only fair Microsoft pays for the privilege. GitHub being free is a feature for Microsoft.
> When I accept a friend's hospitality and don't reciprocate
I came to realize that you don't need to return the favor specifically to the person who helped you. Things work as long as you help anybody. The loop will be closed by someone who will eventually help the person who helped you (or has in the past). Actually, it doesn't events need to be a loop. This is very powerful and quite relaxing because you can be chill both for helping and for receiving help, and it has the potential of working very well and be very enjoyable.
In short: take (from anybody) as long as yougive (to anybody)
(Of course, in a friendship, some reciprocity is necessary, if things only go one way, it doesn't work)
I'm not sure I see the point in distinguishing between something beneficial being reduced in value actively versus passively. Whether it's individuals taking negative action or individuals failing to take positive action, the end result is the same at the end of the day. Something beneficial is reduced in value by collective greedy (in)action. The world at large is made worse for it over time.
Perhaps my definition is off? If so I would appreciate a pointer about the correct terminology.
I suppose it might be different in the case of a one-time fork. It still seems like there's an ethical obligation to contribute back if you are well off and you benefit from something. I think there's a meta, societal level tragedy of the commons to be found there. But if you aren't actively benefiting from maintenance efforts then perhaps it doesn't qualify as a direct tragedy of the commons.
> But that doesn't mean someone is ethically wrong for choosing to accept a gift freely given without giving one in return
Many cultures do in fact work that way. And while modern American culture views the idea of taking everything you can and only giving back what you are contractually forced to in a more positive light, the term freeloader still has negative connotations.
If you're a maintainer and reciprocity is an important value to you, and you think that people who don't give back are freeloading, then why did you specifically choose not to use a GPL license for your project?
Your point about the gap between the words of a license and an ethical expectation is well taken. But why put that gap there at all? It's going out of your way to make sure that people have the choice to screw you.
> There's something philosophically odd about saying "you are free to use, change, redistribute, or sell this with basically no restrictions" while simultaneously maintaining that users incur unstated ethical debts by accepting
Not users, companies that make bilions. We call that shameless.
If you make it about ethics, it's not going to work. Your C-suite folks wont be on board.
You need to make it about utility. Open sourcing some package or contributions to an existing package is giving you returns far beyond your investment. A community will help maintaining, improving, growing your code. Perhaps even competitors will chip in. (If they don't, well, their loss..) It's going to be a net positive.
This is incorrect. Companies form for numerous different reasons, including a group of people needing a legal structure for investments, or to protect against liability, or for particular ventures.
One of the primary outcomes that people want from corporate structures is profit, but that is not the structure's "sole purpose", either in law or practise.
Corporate structures can't have ethics because they are not people (legal constructions of "person" vs "natural person" notwithstanding).
I don’t think OpenBSD is clamoring for code contributions from the companies with proprietary SSH forks. Just money to support continued development.
> Use GPLv3 or AGPL then. If you want companies to "give back" when they use your code, put it in the licence.
Seems like a poor choice given that projects like MongoDB try out AGPL for this reason and then later switch to nonfree licenses like SSPL. OpenBSD is not interested in that—whether its attempts to raise funds through goodwill work out or not, OpenBSD will always be free software.
That's the excuse, but society only works if people behave ethically and not entirely in their self-interest. I don't see why that doesn't apply to people working in businesses, and it never has: Businesses have always contributed to their communities in many ways.
A moral people could operate communism successfully. Unfortunately, most people are not even remotely moral. Pragmatically moral (in plain view, but not behind closed doors), for sure, but innately good -- definitely not.
As European we are lucky to already enjoy minimum wage and unions, across many
countries, still money has to flow from somewhere, namely taxes.
Yet people still need to work somehow, and UBI is more of an ideal that will never happen in capitalism society driven by profits of few shareholders at the expense of everyone else.
Now the current trend is replacing people with self service machines, they aren't getting UBI, they are being shown the street.
The license says use it however you want with nothing in return. They usually get nothing in return. It's a license best used when you want maximum uptake by users, including proprietary products. It's also good for people who enjoy knowing others enjoy using what they build. Whereas, it's one of the worst licenses if a supplier wants money.
Lets assume goals like OpenBSD's. If one also wants money, they can make the software paid, free for many categories of users, source-available, and derivatives (mods) allowed. The paid part can be regular payments or one-time per release. Probably an exception to mods allowed saying they can't backport paid features from new versions to old versions but independent creation is allowed. From there, companies will pay to support it or they'll determine it has no market value.
There are proprietary, source-available RTOS's on the market for real-time and secure use. One source said, but I haven't verified, that INTEGRITY RTOS royalty-free was around $17,000 minimum per product or company. Another said LynxOS with communications middleware was around $50,000. A number of small vendors exist showing one can generate sales if their product is marketable. Tons of companies selling firewalls, load balancers, etc like OpenBSD is often used in.
So, if money is important, they can change their terms to demand money some or all of the time. If the license says "free giveaway!," expect most people to treat it that way. I imagine quite a few of the developers have exactly that expectation. They are motivated by the joy of writing great code, not money.
Capitalism is based on the exploitation of workers who are directly hired by a company, now imagine if a company would pay someone who it doesn't have to
OpenBSD is thoughtfully designed because it is one of the best examples of "design by dictator" (Theo) - and a small core team - as opposed to design by committee like every other OS out there. Look me in the eye and tell me 90% of changes and unnecessary features in macOS aren't there because some team needs to justify their existence.
While much of this document is openly disdainful, there are areas like the malloc implementation[1] and features like the atexit hardening[2] where OpenBSD is unambiguously excellent, and it says as much, noting that the latter is a "pretty cool mitigation".
I used to do some OpenBSD ports work, and even got a tiny patch into the base system. I love OpenBSD! I don't have an axe to grind here! But it is not above reproach, and I think this site is overall harsh but fair.
The author neither complains about it, nor says they are bothered by it. “This website was done because studying mitigations is fun, not to get involved in a huge flamewars or endless bike-shedding on mailing lists”. Misrepresentation is a poor showing. Perhaps we should take everything you write with a grain of salt, hmm?
Fun fact, Hacker News also has guidelines for conduct.
Yeah I was worried for a second jcs might have something interesting to say about backward- and forward- edge CFI, but then I remembered he's woke and closed the tab before the mind virus could get me.
It might! But unless jcs changed his appearance and his accent since I last met up with him in Chicago, this is one of the millions of other people named Stein.
OK, no idea. I've been in the same room with him too, but I didn't look very carefully at the CCC presentation. An awfully big coincidence, given jcs's OpenBSD involvement! But totally possible. Neither here nor there to my point about this page as a resource, if you can, somehow, look past the code of conduct concerns.
I don’t care one bit about the code of conduct conversation you’re having. Just found it funny that you’ve been attributing this site to jcs for years based just on a common surname.
Can’t find anything from “years ago,” though. So maybe my search skills are weak, or maybe I confabulated the memory of finding others, so I’ll withdraw that. Either way, I hope you agree that this thread (now rightfully behind a flag) is all played out.
Sorry, but it is difficult to take someone 100% seriously if they inject personal feelings into debate.
It makes you wonder if they have ulterior motive for presentation of the data. It is okay to question this. Why else mention such a petty thing? Where is it documented in history that code of conduct has improved security?
The onus is always on you to figure out what information is and is not reliable. People who haven't stated their feelings still have them. They might still be pursuing an agenda other than being informative. If anything, someone stating their reservations should make you feel more comfortable, because it gives you a better lens to view their statements through and judge what parts you trust more or less.
Personally, what makes me discount a source as unreliable is when they don't state clearly what their problems are but instead make it known through vague insinuations or by a litany of tangential complaints. When someone says "I'm uncomfortable with X" I respect their candor, regardless of how I feel about X.
Someone stating their reservations when those are directly relevant to the subject at hand, sure. If they aren't directly relevant to the subject under discussion but are directly related to a negative impact on the person while they were performing the relevant work then I get that as well.
But someone who isn't mature enough to separate their irrelevant personal views from the task at hand when communicating with an audience, not so much. It calls into question their ability to be objective.
Note that I apply this equally, even to those who interject pet topics that I strongly support.
Granted. However, the quote at issue doesn't come out of left field. It is natural to consider the internal politics of an open source project when writing a wide ranging, in depth critique of the project. Plenty of projects don't have a CoC, it is idiosyncratic to be "proud" not to have one, and that does reflect on the project (I leave it to you to decide if it's for better or worse).
CoC are the homeowners associations of the free software world. Some think they're essential to keep undesirables out; others won't have anything to do with them.
Not to mention that in the general case it seems desirable that a community can exist without needing a CoC. Being disappointed that some community out there is doing just fine without CoC is a /really weird/ point to make in a marketing piece evangelizing how secure OpenBSD is as a technology. To the extent that it feels out of place and yes detracts. Some would even go so far as to argue that OpenBSD is second to none in security because they don’t give a shit about politics and tone in their community. They swiftly dismiss the wasted cycles spent on those in other communities, instead spending their precious time focusing on just being really good. The author sorta misses the plot point there.
That's only if you take CoC enjoyers at their word. It makes perfect sense when you realize it's not about advancing project or community, but rather controlfreak ideology.
a.) They found it off-putting that OpenBSD was "proud" not to have a CoC, in the context of whether they would choose to work with them or to host the website themselves. Consider taking a moment to read the passage in question: https://isopenbsdsecu.re/about/
This idea they were surprised a project succeeded without having a CoC is an artefact of this particular discussion, not something the author ever said or implied. It was in the same category as de Raadt swearing at people over email - they didn't anticipate a productive exchange if they reached out. That's it.
If someone declares they reserve the right to treat people however they please, and then you observe them treating people in a way you don't want to be treated, and your conclusion is, "I don't think emailing this person is a good use of my time, I'm just going to host this website myself" - I find it hard to understand how anyone would find that objectionable, that seems simple, common sense, and largely neutral.
b.) Whenever you have a large group of people collaborating for an extended period of time, you have incidents. There's drama. There's inappropriate behavior. It's just how it goes. It's a Murphy's Law thing.
Eventually people sit down and say, "we've gotta set some ground rules." You probably signed a code of conduct at every school you attended and every job you've accepted. I know I have.
You can disagree with that without viewing it as a conspiracy. It's a predictable result of being in a large community, and about as ideological as traffic lights.
Position-Independent Executables (and ASLR) were used by AmigaOS back in 1985. It had to, since the Amiga lacked an MMU, and had very little memory, so anything that was loaded had to be placed at whatever ram was available.
It didn't need the executable to end up in a single block either, every individual section could end up in a different location. Compilers produced large numbers of sections to facilitate this process.
That's not what's meant by PIE though. It means the code can appear at any address and still be valid.
Amigas could, of course, have position-independent code. Use BSR and BRA rather than JSR and JMP; use LEA label(pc),A0 / MOVE.L (A0),D0 instead of MOVE.L label,D0 .. but the limits for PC-relative addressing are +/- 32k so you need to get creative to reach code or data further than that.
More commonly, Amiga executables had relocs, a list of fixups to apply. The code on disk in each hunk was written as if all hunks were loaded at address 0. There was then a list of relocations at the end of each hunk, saying what offsets in that hunk need the base address of another hunk (including themselves) added there, to fixup the absolute address reference.
This is relocatable code, but not position independent code. If I used an MMU to make that relocated code appear at another address, all its absolute addressing would be wrong at that new address.
Position-independent code can be shared by multiple proceeses, and appear anywhere in their address space, while only existing once in memory
In addition to work pioneering privdrop/privsep design for network daemons, and the almost ubiquitous adoption of pledge(2)/unveil(2) across the base system, I think people are missing out on much more recent mitigation work, such as mimmutable (which Linux is just beginning to land with mseal), on OpenBSD, most of a programs static address space (.text/ld.so's .text/.bss/main stack) is now automatically immutable.
There's also execute-only memory and BTI/IBT on modern Intel/AMD, and ARM machines, enabled by default. Including a significant amount of ports development work to make the larger software ecosystem ready for this.
Why? OpenBSD seems to think execute-only in userland is important. We've had SMAP on x86 for many years, it helped fixed bugs early, these bugs are rare now, so why is everyone concerned about kernel accesses that aren't using copyin(9)?
EPAN is already supported, hardware is now arriving, it's used if available, but the idea that execute-only was less important than PAN was probably misguided.
> Random-data memory: the ability to specify that a variable should be initialized at load time with random byte values (placed into a new ELF .openbsd.randomdata section) was implemented in OpenBSD 5.3 by Matthew Dempsky.
What's the use case for this?
EDIT: further down is one example:
> RETGUARD is a replacement for the stack-protector which uses a per-function random cookie (located in the read-only ELF .openbsd.randomdata section) to consistency-check the return address on the stack. Implemented for amd64 and arm64 by Todd Mortimer in OpenBSD 6.4, for mips64 in OpenBSD 6.7, and powerpc/powerpc64 in OpenBSD 6.9. amd64 system call stubs also protected in OpenBSD 7.3.
I suppose: Sometimes things work fine with the implicit default value that you end up with. So this will cause problems when you forget to initialize values to expected sane defaults.
Everything I've read about pledge and unveil really admire the approach and the results but it didn't seem to have a big impact outside of OpenBSD. It took ~20 years for OpenBSD's CSPRNG to be re-implemented everywhere else maybe we're operating on a similar timeline here.
Maybe I'm not getting something here, but I find the pledge/unveil approach confusing.
Why should I expect a program to set allowed syscalls/filesystem paths? Why would I trust that it will set itself the right permissions? What is allowed should be set externally from the program, similarly how I can map filesystem volumes and add capabilities to a Docker container [1].
I'm not familiar with BSD and I only used it a couple times out of curiosity. What am I missing?
The threat vector is not that you don't trust the program, pledge/unveil is completely unsuitable for that. but that you worry the program will be compromised while it is running.
so the observation is that programs tend to have a startup state where they need access to files and a run state where they don't. so pledge/unveil is a mechanism for a program to inform the os that it no longer needs access to files/syscalls and any future access should be considered a hostile takeover. please kill me.
> Why should I expect a program to set allowed syscalls/filesystem paths? Why would I trust that it will set itself the right permissions?
Because the admin or owner will know FAR less about what a complex program needs at all times, and when it will be safe to drop privs. A database might be tested for a week and then it has a special snapshot thing done for the monthly backup and you did not foresee this, whereas the coders would know what perms are needed in order to do these dumps. Hence, you can't set perms just once before starting, and as a user of said software, you can't expect to just make a quick test and then design a fully working harness for it either.
Incredible. I wonder what's the debugging experience for userland developers with all these security features enabled (especially the memory randomization ones).
Can't you launch the debugger as root and attach to the process? Which is to say, I'd expect the experience to be approximately the same.
Alternatively, debug in a VM where the security features are disabled.
> especially the memory randomization ones
I have never once relied on memory addresses being reproducible between program runs. In an era of ASLR that seems like a really bad plan. Plus multithreading breaks that for malloc'd stuff anyway.
I am guaranteed to get grief on this but an anti-Innovation in OpenBSD (so obsessed it is about security) is to use an unsafe language like C everywhere in kernel and user space.
The implementation of OpenBSD predates many safer systems languages but I think OpenBSD should now start moving to a checked variant of C or a safer language like Rust/OCaml/Odin/Zig/Something else.
The conversion can start with some OpenBSD user space programs. I notice a steady stream of C related security fixes in the OpenBSD changelog. Many of these could have been probably avoided if the implementation language was more “safe” by default.
I doubt that this is going to happen but I think it is fair to point out that using C does give you some additional security headaches by default.
Theo has addressed this directly. I cannot find the video at the moment - it is somewhere on YouTube - but his response essentially is okay, so where is 'cat'? Where is 'grep'? Where is Korn Shell?
Everyone is busy jumping up and down and bitching about reinventing the wheel in Rust but no one has even taken the time to rewrite the simplest of Unix tools in Rust.
Not to mention OpenBSD has a rule that "base builds base" and the Rust compiler is a bloated monster that would fail that most basic task.
The worst part is when you come across something advertised as a replacement and it does something like 80% to 90% of what the original does with a WONTFIX for the rest. That can certainly be a valid choice in some cases, but for core tooling it's not realistic to expect widespread replacement to happen in that scenario.
>no one has even taken the time to rewrite the simplest of Unix tools in Rust.
"The uutils project reimplements ubiquitous command line utilities in Rust. Our goal is to modernize the utils, while retaining full compatibility with the existing utilities."
"We are planning to replace all essential Linux tools."
It would be nice if they commit to replacing more than just Linux tools. There are numerous quirks/additions to the GNU utils that the BSDs don't want or need.
Someone is “putting up”, just need someone to merge uutils and the OpenBSD kernel to see what it starts to look like.
Maybe this is the next part of the “put up or shut up” mantra- but we’re getting closer.
The parents irony is not lost though. C and perl are both quite dangerous in their own ways, lots of implicit assumptions; its ironic that a safety focused operating system would lean in on those languages.
Of alternatives, I think Zig is closest to what they like. It's small, easy to maintain, has great tooling for C, and already used for high-reliability (TigerBeetle). I don't know if its portability is as good as they like, though.
Worth mentioning lack of Bluetooth is only because they felt the existing BT stack was not up their standards and ripped it out rather than let it rot like most software.
Not having developers to work on it seems pretty valid. It's a matter of opinion, but I feel like it's better to have no Bluetooth, compared to having a half-broken and unsupported implementation. Again you could also view is as having a semi-functional Bluetooth is better than none and then hopefully attract developer wanting to fix it.
It's pretty easy to avoid Bluetooth, and it'a a complex stack and having code quality standards means sometimes you have to remove features because the code quality isn't there, and nobody had time/interest/motivation to do the work to make an implementation with the proper amount of quality.
If you have a 'must have' device for your desktop environment that's bluetooth, then yes, it makes OpenBSD unviable for you; but OpenBSD isn't viable for every use case.
I’d prefer not to have something than to have a bad something.
Yeah, it was annoying when I tried to pair my mouse- but you know… a wired mouse isn’t that big of a deal.
One thing that brings me the most displeasure about internet discourse about operating systems is this idea that they all have to do all the same things.
Thats homogeny by another name; the point of different operating systems is different trade-offs.
Small usb bluetooth dongles work, they show up as a regular audio device. I use one and sndiod can set set to automatically switch back and forth to it.
I run openbsd on my laptop, a thinkpad x260 with an ssd, and it works great.
It depends on what you need for your daily use, OpenBSD has ports of common desktop environments, KDE Plasma, GNOME. In fact, thanks to KDE and GNOME port maintainers, Rafael Sadowski, and Antoine Jacoutot, respectively, OpenBSD 7.6 -current has the latest versions of both (KDE Plasma Desktop 6.3.1, GNOME 47).
I recently checked out KDE 6 for the first time last year, it really is as easy running as 'pkg_add kde kde-plasma kde-plasma-extras' and then reading through the local pkg-readme file, that said if you're not familiar with OpenBSD it won't be like other systems where it comes preinstalled and preconfigured.
There's many popular window mangers and applications you can install using the package tools, as you'd expect, including Chromium and Firefox, but you can quickly search here: https://openbsd.app/
It was a few years ago, but I ran OpenBSD for about a year in college (on a Thinkpad). It worked because I rarely needed anything more than Firefox, code editors, and a shell with ssh. Most of my time was spent reading, writing papers, writing emails, and writing code.
It works quite well. The OOB experience is very complete and hardware gets picked up without issue. However you’re limited in the amount of apps and it’s also incredibly slow, so you’ll need to really use minimal, fast cli apps.
I left it ultimately because it had way worse battery life than Linux on my T480s and I also wanted to play some games with steam.
Disk I/O is notably slower than e.g. Linux or Windows and executional performance is generally a tiny bit slower, but nothing about it is "incredibly slow".
You will want to enable GPU-accelerated rendering for Firefox and Chromium to get a smoother experience when scrolling pages and for certain video playback, because that's disabled by default. Besides that they load and parse pages and act on input pretty much as fast as they do on Linux.
well, SMT/hyper-threading is disabled by default[0] , not sure if there are other reasons though. It's not that bad, but yeah OpenBSD is probably not your optimal gaming OS :P
Common misconception. It is not. The kernel is XNU, and the OS base is Darwin which has some BSD parts in it, and some of the userland came directly from FreeBSD (though heavily modified).
You’re not actually disagreeing with the OPs statement though. And they’re technically right too.
The problem is that all the user facing stuff in macOS isn’t BSD. It’s Apples proprietary APIs. So while macOS was originally and technically based on BSD, almost none of that is exposed to their users.
So they’re technically correct that macOS / Next was based on BSD. But also completely wrong to recommend macOS as a comparison to OpenBSD.
I'm pretty sure I've even read about FreeBSD code in the Windows networking stack. Is Windows now based on BSD? Open source code, especially when it's permissively licensed, ends up absolutely everywhere.
Windows is very much based on NT, which has its influences from a few different OS, most notably being VMS.
AFAIK there isn’t any BSD code in Windows however the original TCP/IP stack in Windows was a port from BSD. But we are talking about the early 90s here and it’s long since been rewritten by Microsoft (or so they say, but I have no reason to disbelieve Microsoft)
True. The capitalisation rules for releases kills me every time too. Not just with OpenStep but with Next too. I now don’t even bother trying to get the capitalisation correct.
Considering how obsessed with UX that Jobs was, I don’t get how he thought the naming conventions were a good idea.
Have they implemented ISO C11 _Thread_local yet? It's been the number one annoyance¹ with porting software to OpenBSD. It is (was?) the only mainline OS without support for native thread-local storage.
A LOT of those innovations were first present in grsecurity/PaX. Back when it was freely available to everyone as well.
I guess the arguments is the OpenBSD has them by default with needing a 3rd party patch, that's why they're claiming them as their innovations?
Yup! The idea behind Pledge/Unveil was first in Landlock also.
> that's why they're claiming them as their innovations?
I think they are just listing their specific implementations as innovations, their particular approach. Too many of what they list was definitely not an original idea, so they can't possible be suggesting otherwise. At least, I would hope not.
> The idea behind Pledge/Unveil was first in Landlock also.
This is so plainly, and verifiably untrue, that it's almost funny. The patch series and kernel commit adding Landlock to the Linux kernel even references OpenBSD pledge(2)/unveil(2) as a source of inspiration.
> This is so plainly, and verifiably untrue, that it's almost funny.
I just found that email and the talk for the project myself and noted the author referenced pledge in another comment, but thought that could be due to the earlier OpenBSD release having gotten press, making it useful as a point of comparison.
I had honestly thought the landlock website or an earlier talk had pre-dated the release of OpenBSD 5.9, but I appear to have been wrong about that.
Linux 5.13 was the first kernel release with Landlock incorporated, but the Landlock project is from 2016 also.
I found the announcement email for Landlock posted to the lkml[1] where the author compares the project to Pledge. There's also his talk[2] from 2016 if you're interested. I was certain landlock predated pledge, as I thought the website or earliest talk was from late 2015, but I am less certain now, indeed I seem to have been wrong in my claim.
As for either being the first, at the very least Seatbelt from Apple has a paper dated 2011[3] and was released with macOS 10.5.
OpenBSD's pledge(2) was first talked about publicly as tame(2), and was presented in at FSec 2015, it was renamed pledge(2) as mentioned on the OpenBSD 5.9 page.
I thought I had remembered something from Landlock from 2015 also, but can't find anything supporting that. The first version referenced is v7 or v0.7, so it's possible there was a talk for v0.1 or something that isn't online anywhere.
I'll concede that's less likely and I'm probably just wrong and misremembering though.
It does the job great with the default install as long as you're comfortable with the console but if you're talking something with a web interface like what pfsense/opnsense on freebsd, there was one out of Sweden I think it was for a while that fizzled out called securityrouter. Nowadays these are what I've seen (But not tested):
Perhaps one day the OpenBSD folks will figure out how to completely prevent user programs from making syscalls. It seems they are mostly there but still not quite. Please don't mention WASM in your replies.
OpenBSD foundation raised around ~380 thousand IIRC.
By creating OpenSSH and the fact all fortune 500 companies use it, I would say every year, the foundation should be bringing in around 1 or 2 million. It is time these companies really give back.
And while I am here, hardware vendors should open up their source, looking directly an Nvidia.
It's not the foundation that does the work but developers. With that kind of budget, the foundation is just administrative support. They aren't employing a lot of developers. Many developers are employed of course. Partially by those same fortune 500 companies that you mention.
Open source is a pragmatic arrangement where developers embedded in the industry can collaborate and share code; often explicitly supported by the companies they work for. It has worked very well for decades and there's no urgent reason to change anything.
For example, Damien Miller, who puts in a lot of time on OpenSSH, is employed by Google. Employing key contributors is how the industry supports OSS.
Your second paragraph is explaining perfectly why open source doesn't work and how its economics don't add up.
I would also add that it indirectly kills the vast majority of programming jobs - nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg. Nobody is ever get paid to write a new kernel as everyone can just use Linux. Very few people are going to get paid to work on a new database as you can just use Postgres...
Once there's a good enough open source solution in a field, in the long run it will out-compete commercial offerings, even it's overall a worse package, as it's some guy's free time project and is created on a $0 budget.
Programmers work for free, end users get a worse product, companies make trillions.
> I would also add that it indirectly kills the vast majority of programming jobs - nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg
Looked at another way, open source means that instead of a bunch of programmers getting paid to write multiple implementations of the same thing over and over, so the programmers that otherwise would be doing that can instead work on new innovative things.
In an ideal world, all software would be open source, and programmers would spend all their time improving said software for everyone. The problem is I don't know how those programmers would be compensated for their work. In many ways, open source software is a public good, since anyone can benefit from it[1], so an argument could be made that OSS should be publicly funded (i.e. paid for by government grants). However, I am doubtful that the government could do a good job of allocating resources to open source projects. Then again, I don't think the private sector is doing a great job of that either. Just look at how many resources are put into showing people ads.
[1]: And it has the interesting property, that unlike most public goods, the cost does not scale with the number of people who use it, or have a limit on the number of people who use it.
Isn't the solution to have much shorter copyright terms? Software could be closed source at first, its implementation costs recouped, then opened by default when its copyright term lapses. New releases could still be closed, so income could continue. Set the term at 5-10 years, rather than >70.
This doesn't really work for projects that want to be closed source, as they can just not publish the source. After the 10 years, people can copy the binary, but that doesn't really give you a whole lot of benefit.
And if a project does want to be open source eventually, they can already license their code that way.
> open source doesn't work
What could you mean by that? It's an extremely successful model organizationally and technically.
> it indirectly kills the vast majority of programming jobs
All software kills the vast majority of jobs - think of all the jobs there would be if we had no software. Anyway, are we short of programming jobs?
Efficiencies create new, higher-value possibilities than, for example, JPEG decoders.
> Those are the exception, not the rule. Most open source projects are some guy's hobby, done for free in their free time.
And most proprietary software becomes completely unavailable when the company making it goes out of business. At least with the open source software, if there is interest in it, someone else can pick it up, if the original creator stops maintaining it.
> a large portion of programming jobs have devolved to gluing together a bunch of open-source libraries, doing the boring gruntwork to actually make them work, and dealing with the inevitable hell, caused by using 500 components that were never designed to work together.
And you think that would be any different without open source? A large portion of programming would still be gluing together a bunch of components, but instead of open source libraries you would have proprietary libraries, where if the documentation is inadequate or wrong, you have no option of looking at the source code to see what it actually does. Or in-house libraries that were designed for some specific purpose that doesn't match yours at all, and are very low quality, because they were made under a tight deadline, and no one ever went back to pay the tech debt after the MVP was released. Or maybe instead of a library you make API calls to some SaaS with no SLA and barely any documentation.
> Most open source projects are some guy's hobby, done for free in their free time.
E.g. exactly how Linux was created? ;)
> Hobbyists solve problems they find interesting, and often ignore a lot of the "gruntwork" required to make a technically sound package.
OTOH some commercial software only solve problems that make money, and ignore the technically sound part unless it makes money. E.g. the enshittification of Google, Windows or Facebook, and friends, from a product that worked to a product that nobody asked for. All the technicality spent in tracking users, more ads, etc.
These are a lot of commercial software that are not much more than a repackaging of open source software and a UI layer (ffmpeg, for example).
> Those are the exception, not the rule. Most open source projects are some guy's hobby, done for free in their free time.
It also applies to proprietary software.
> nobody is ever going to get paid to create a JPEG decoder as everyone can just use libjpeg.
if there's no technical reason why libjpeg isn't suitable, I'd consider it a huge waste of human life to create another. if there is a good technical reason to build a new one, then somebody will do it for free or somebody will pay for it to be made.
I think the system is working.
> Your second paragraph is explaining perfectly why open source doesn't work
> some guy's free time project and is created on a $0 budget.
> Programmers work for free
You seem to be completely out of touch with what FOSS is.
The amount of relevant FOSS hacked by some teenager for free in moms basement is negligible. The largest contributors to the Linux kernel are IBM, Intel and Oracle. Nobody there works for free.
Because it costs down their own development costs, doing more with less.
How much upstream do you think BSD gets from Sony and Apple, besides a few crumbs?
clang was sponsored exactly to allow Google and Apple to take a compiler and not be legally obliged to upstream their sauce.
Nowadays clang has mostly replaced most proprietary compilers on surviving UNIXes, and embedded OSes, how much of those downstream changes land on upstream clang? It is mostly volunteer work improving ISO C and ISO C++ compliance, despite all the money being made by those folks.
I wouldn't be a good way to spend money and resources to rewrite things like jpeg decoders again and again. It would not help to make the final product any better, but just siphon the money off from more worthwhile purposes.
Companies make billions? Good. It's time to tax them and use the money for the benefit of everyone.
> Nobody is ever get paid to write a new kernel as everyone can just use Linux
Not that it negates your point in any way, but lots of people are paid lots of money to write Zircon (Google Fuschia's kernel) which is intended to replace Linux in many scenarios.
Sadly it went nowhere, it remains to be seen how long it will take to join Android Things, Tango, and other Google OS related projects.
Yes I am aware it is shipping on Nest Hub.
So they are paid to write a useless toy. While people who write the useful code are not paid.
If we had to write every single piece of code over and over(or pay for them), computer science would have barely evolved and would not be so mainstream
No, writing them over and over is literally what evolves computer science. Not having to write them over and over is what improves software. They’re different.
> No, writing them over and over is literally what evolves computer science.
If this is the way computer science evolves, it is safe to say that it evolves at the same pace as life.
[dead]
> Programmers work for free, end users get a worse product, companies make trillions.
I bet you didn't use any Microsoft product. /s
The openbsd foundation raised around 5 million, half of which has been spent. Curiously they aren't as transparent as they once were.
You mention nvidia support, others are hopeful for a better filesystem and wifi as well.
> .. wifi as well.
OpenBSD has supported 11ac for several years, and has the iwx(4) driver for modern Intel WiFi cards. There's also support for Broadcom FullMAC, bwfm(4), which is on e.g: Apple Silicon machines.
HaikuOS also has a port of OpenBSD's iwm/iwx drivers.
FreeBSD just recently announced they've started porting the OpenBSD iwx driver.. from Haiku.
https://freebsdfoundation.org/blog/laptop-support-and-usabil...
> The openbsd foundation raised around 5 million, half of which has been spent.
Citation needed, they've raised nowhere near that amount.
https://github.com/bob-beck/foundation-web/commit/483266cece...
https://www.openbsdfoundation.org/campaign2024.html
Not OP, but they've raised $4,974,668 since 2014 (done by adding up all the thermometers at https://github.com/bob-beck/foundation-web), and I'm excluding anything prior.
That's certainly what they meant ;)
Thanks, very misleading..
"hardware vendors should open up their source"
this doesn't make sense, how can you expect hardware companies to do this, where the moat???
It's not as bad as it used to be, but one moat some companies had was "excellent support for Linux/Unix/BSD". Until CUDA no one in their right mind would buy Nvidia for their Linux workstation, just like you'd avoid certain Broadcom wireless chips.
Hardware companies need their devices supported by as many operating systems as possible, especially if those devices can be used in servers, desktops less so. Apple is pretty much the exception.
having support for linux != open source their shit
You can still support linux while still having closed source
When you give freely and generously to the community you should do so with no expectation of getting anything in return. Sometimes that expectation is fulfilled.
They are not talking about OpenBSD's expectations, it's about the ethics (!) of the companies using things on the back of the generosity without giving back.
I see this mindset more and more, and to me it seems against the ethos of open-source software. There's something philosophically odd about saying "you are free to use, change, redistribute, or sell this with basically no restrictions" while simultaneously maintaining that users incur unstated ethical debts by accepting. It could even be seen as a kind of bait-and-switch.
Contributions and reciprocity are praiseworthy of course, and we should all aspire to this. But that doesn't mean someone is ethically wrong for choosing to accept a gift freely given without giving one in return.
You are legally free to use. Your ethical obligations will depend on your particular worldview, and are likely to vary substantially by culture.
All cultures I'm familiar with recognize that someone who is well off taking advantage of a tragedy of the commons is unethical. The particulars vary by locale but my impression is that it is universal that the degree of condemnation increases the wealthier the person exploiting the system is.
The thing about the tragedy of the commons is that you are actively hurting everyone else by depleting a non-rivalrous good.
When I accept a friend's hospitality and don't reciprocate, I am taking their time and resources. When I take five free samples at the store, I ruin it for others who come later.
When I download an open source GitHub repo, I am burning 1¢ of Microsoft's money.
The cost of software is not the cost of distribution, it's the cost of maintenance, support, and implementation. When you clone a repo, this has little impact by itself, but the work to create that repository in the first place, to maintain it and ensure it is free of bugs, and to provide documentation and support so that people understand how to use it - that all has a cost.
If nobody pays for that cost, then the work will never get done in the first place, and we won't have these resources.
> When I download an open source GitHub repo, I am burning 1¢ of Microsoft's money.
While the other examples seem good for illustrating the point, this one has it backwards I think. Microsoft worked very hard to be in this position. They did this on purpose and this aspect is essential to their success:
- GitHub did everything they could to capture the market by being free to use and by leveraging the network effect
- Microsoft bought GitHub at a point where it was already widely successful in this aspect, so they fully knew what they were buying
Capturing the whole open source market is part of their business model. I don't like they've done this and I don't get to choose where authors host their code. Even the authors themselves might not have felt free to choose something else because of the network effect. It's only fair Microsoft pays for the privilege. GitHub being free is a feature for Microsoft.
> When I accept a friend's hospitality and don't reciprocate
I came to realize that you don't need to return the favor specifically to the person who helped you. Things work as long as you help anybody. The loop will be closed by someone who will eventually help the person who helped you (or has in the past). Actually, it doesn't events need to be a loop. This is very powerful and quite relaxing because you can be chill both for helping and for receiving help, and it has the potential of working very well and be very enjoyable.
In short: take (from anybody) as long as yougive (to anybody)
(Of course, in a friendship, some reciprocity is necessary, if things only go one way, it doesn't work)
I'm not sure I see the point in distinguishing between something beneficial being reduced in value actively versus passively. Whether it's individuals taking negative action or individuals failing to take positive action, the end result is the same at the end of the day. Something beneficial is reduced in value by collective greedy (in)action. The world at large is made worse for it over time.
Perhaps my definition is off? If so I would appreciate a pointer about the correct terminology.
I suppose it might be different in the case of a one-time fork. It still seems like there's an ethical obligation to contribute back if you are well off and you benefit from something. I think there's a meta, societal level tragedy of the commons to be found there. But if you aren't actively benefiting from maintenance efforts then perhaps it doesn't qualify as a direct tragedy of the commons.
> But that doesn't mean someone is ethically wrong for choosing to accept a gift freely given without giving one in return
Many cultures do in fact work that way. And while modern American culture views the idea of taking everything you can and only giving back what you are contractually forced to in a more positive light, the term freeloader still has negative connotations.
If you're a maintainer and reciprocity is an important value to you, and you think that people who don't give back are freeloading, then why did you specifically choose not to use a GPL license for your project?
Your point about the gap between the words of a license and an ethical expectation is well taken. But why put that gap there at all? It's going out of your way to make sure that people have the choice to screw you.
If you've never maintained a project you don't know just how unthankful and demanding it is.
Because of the endless amount of expectations.
> There's something philosophically odd about saying "you are free to use, change, redistribute, or sell this with basically no restrictions" while simultaneously maintaining that users incur unstated ethical debts by accepting
Not users, companies that make bilions. We call that shameless.
People choose BSD licenses precisely because they don't want to impose any ethics on anybody.
If you make it about ethics, it's not going to work. Your C-suite folks wont be on board.
You need to make it about utility. Open sourcing some package or contributions to an existing package is giving you returns far beyond your investment. A community will help maintaining, improving, growing your code. Perhaps even competitors will chip in. (If they don't, well, their loss..) It's going to be a net positive.
>it's about the ethics (!) of the companies
A company doesn't have ethics. It's sole purpose is to make a profit.
Nope, a companies purpose is to fulfill it's charter. Profit is generally a goal of for profit companies, but they usually have others too.
https://www.nytimes.com/roomfordebate/2015/04/16/what-are-co...
This is incorrect. Companies form for numerous different reasons, including a group of people needing a legal structure for investments, or to protect against liability, or for particular ventures.
One of the primary outcomes that people want from corporate structures is profit, but that is not the structure's "sole purpose", either in law or practise.
Corporate structures can't have ethics because they are not people (legal constructions of "person" vs "natural person" notwithstanding).
Use GPLv3 or AGPL then. If you want companies to "give back" when they use your code, put it in the licence.
Or you can charge money for your product.
I don’t think OpenBSD is clamoring for code contributions from the companies with proprietary SSH forks. Just money to support continued development.
> Use GPLv3 or AGPL then. If you want companies to "give back" when they use your code, put it in the licence.
Seems like a poor choice given that projects like MongoDB try out AGPL for this reason and then later switch to nonfree licenses like SSPL. OpenBSD is not interested in that—whether its attempts to raise funds through goodwill work out or not, OpenBSD will always be free software.
Ethics does not belong to capitalism. Money is the central part of it, not ethics.
That's the excuse, but society only works if people behave ethically and not entirely in their self-interest. I don't see why that doesn't apply to people working in businesses, and it never has: Businesses have always contributed to their communities in many ways.
Any system of economics may be abused.
A moral people could operate communism successfully. Unfortunately, most people are not even remotely moral. Pragmatically moral (in plain view, but not behind closed doors), for sure, but innately good -- definitely not.
I would really like that the supermarket, my landlord, electricity and water company would equally be so generous.
Sounds like you're in favor of UBI.
As European we are lucky to already enjoy minimum wage and unions, across many countries, still money has to flow from somewhere, namely taxes.
Yet people still need to work somehow, and UBI is more of an ideal that will never happen in capitalism society driven by profits of few shareholders at the expense of everyone else.
Now the current trend is replacing people with self service machines, they aren't getting UBI, they are being shown the street.
The license says use it however you want with nothing in return. They usually get nothing in return. It's a license best used when you want maximum uptake by users, including proprietary products. It's also good for people who enjoy knowing others enjoy using what they build. Whereas, it's one of the worst licenses if a supplier wants money.
Lets assume goals like OpenBSD's. If one also wants money, they can make the software paid, free for many categories of users, source-available, and derivatives (mods) allowed. The paid part can be regular payments or one-time per release. Probably an exception to mods allowed saying they can't backport paid features from new versions to old versions but independent creation is allowed. From there, companies will pay to support it or they'll determine it has no market value.
There are proprietary, source-available RTOS's on the market for real-time and secure use. One source said, but I haven't verified, that INTEGRITY RTOS royalty-free was around $17,000 minimum per product or company. Another said LynxOS with communications middleware was around $50,000. A number of small vendors exist showing one can generate sales if their product is marketable. Tons of companies selling firewalls, load balancers, etc like OpenBSD is often used in.
https://en.wikipedia.org/wiki/Comparison_of_real-time_operat...
So, if money is important, they can change their terms to demand money some or all of the time. If the license says "free giveaway!," expect most people to treat it that way. I imagine quite a few of the developers have exactly that expectation. They are motivated by the joy of writing great code, not money.
Capitalism is based on the exploitation of workers who are directly hired by a company, now imagine if a company would pay someone who it doesn't have to
I'd change "workers" to "persons with little capital".
Your comment having a negative score tells us how good our overlords are at propaganda.
They could easily raise a few million if they bothered working on sales, but they don't.
Its not really a for profit project and I prefer it stays that way. Projects that raise money tend to get "corrupted" by the greed.
Not that there is anything wrong with raising money, but the ideology behind openBSD don't really fit if they go for profit
a) they shouldn't have to
b) part of what makes it great is that they don't
They have a sales team of online enthusiasts who work for free. Unfortunately, they got what they paid for.
> Unfortunately, they got what they paid for.
Industry wide adoption?
We’re happy; they’re happy. But the sales team works on commission.
A phenomenal resource on the same subject:
https://isopenbsdsecu.re/mitigations/
This looks quite concerning: https://isopenbsdsecu.re/mitigations/packages/
Outdated FUD, OpenBSD's Mozilla port maintainer regularly updates and backports non-ESR Firefox to the -stable tree.
https://freshbsd.org/openbsd/ports?q=firefox
Tor browser bundle is also being updated consistently.
https://freshbsd.org/openbsd/ports?q=tor-browser
I like this -- despite the clown nose logo, it's actually fair to my eye and is respectful to parts of OpenBSD that are thoughtfully designed.
OpenBSD is thoughtfully designed because it is one of the best examples of "design by dictator" (Theo) - and a small core team - as opposed to design by committee like every other OS out there. Look me in the eye and tell me 90% of changes and unnecessary features in macOS aren't there because some team needs to justify their existence.
What features in macOS are you referring to?
I'm not OP but renaming IOMasterPort to IOMainPort for the sake of renaming alone drove home what a bunch of backwards-incompatible clowns Apple are
I assume you meant to write "disrespectful"?
While much of this document is openly disdainful, there are areas like the malloc implementation[1] and features like the atexit hardening[2] where OpenBSD is unambiguously excellent, and it says as much, noting that the latter is a "pretty cool mitigation".
I used to do some OpenBSD ports work, and even got a tiny patch into the base system. I love OpenBSD! I don't have an axe to grind here! But it is not above reproach, and I think this site is overall harsh but fair.
[1]: https://isopenbsdsecu.re/mitigations/malloc/
[2]: https://isopenbsdsecu.re/mitigations/atexit_hardening/
Besides the clown nose on puffy it's honestly just realistic and not all just talking bad like I've seen some people do:
https://isopenbsdsecu.re/mitigations/pledge/
One of the author's complaints is it bothers him OpenBSD is "proud of not having a code of conduct".
Based on that alone, I take everything else with a grain of salt.
The author neither complains about it, nor says they are bothered by it. “This website was done because studying mitigations is fun, not to get involved in a huge flamewars or endless bike-shedding on mailing lists”. Misrepresentation is a poor showing. Perhaps we should take everything you write with a grain of salt, hmm?
Fun fact, Hacker News also has guidelines for conduct.
But openbsd does have a code of conduct. you can find it here.
https://www.openbsd.org/mail.html#Netiquette
Yeah I was worried for a second jcs might have something interesting to say about backward- and forward- edge CFI, but then I remembered he's woke and closed the tab before the mind virus could get me.
This is “stein”:
https://media.ccc.de/v/36c3-10519-a_systematic_evaluation_of...
Doesn’t look like jcs to me.
Might stein's first name be................
It might! But unless jcs changed his appearance and his accent since I last met up with him in Chicago, this is one of the millions of other people named Stein.
OK, no idea. I've been in the same room with him too, but I didn't look very carefully at the CCC presentation. An awfully big coincidence, given jcs's OpenBSD involvement! But totally possible. Neither here nor there to my point about this page as a resource, if you can, somehow, look past the code of conduct concerns.
I don’t care one bit about the code of conduct conversation you’re having. Just found it funny that you’ve been attributing this site to jcs for years based just on a common surname.
Hey! (a) Not just that and (b) How many times have I ever attributed this site? I just like the site, is all.
> How many times have I ever attributed this site [to jcs]?
I don’t keep track of people’s HN comments—but I noticed one time some months back, and figured someone should point it out next time. :)
[edit: struck “found several”]
For the record this thread appears to be the first time I've ever mentioned jcs outside of a thread long, long ago about why Lobsters happened.
Last year:
https://news.ycombinator.com/item?id=40032473
Can’t find anything from “years ago,” though. So maybe my search skills are weak, or maybe I confabulated the memory of finding others, so I’ll withdraw that. Either way, I hope you agree that this thread (now rightfully behind a flag) is all played out.
Sorry, but it is difficult to take someone 100% seriously if they inject personal feelings into debate.
It makes you wonder if they have ulterior motive for presentation of the data. It is okay to question this. Why else mention such a petty thing? Where is it documented in history that code of conduct has improved security?
The onus is always on you to figure out what information is and is not reliable. People who haven't stated their feelings still have them. They might still be pursuing an agenda other than being informative. If anything, someone stating their reservations should make you feel more comfortable, because it gives you a better lens to view their statements through and judge what parts you trust more or less.
Personally, what makes me discount a source as unreliable is when they don't state clearly what their problems are but instead make it known through vague insinuations or by a litany of tangential complaints. When someone says "I'm uncomfortable with X" I respect their candor, regardless of how I feel about X.
Someone stating their reservations when those are directly relevant to the subject at hand, sure. If they aren't directly relevant to the subject under discussion but are directly related to a negative impact on the person while they were performing the relevant work then I get that as well.
But someone who isn't mature enough to separate their irrelevant personal views from the task at hand when communicating with an audience, not so much. It calls into question their ability to be objective.
Note that I apply this equally, even to those who interject pet topics that I strongly support.
Granted. However, the quote at issue doesn't come out of left field. It is natural to consider the internal politics of an open source project when writing a wide ranging, in depth critique of the project. Plenty of projects don't have a CoC, it is idiosyncratic to be "proud" not to have one, and that does reflect on the project (I leave it to you to decide if it's for better or worse).
CoC are the homeowners associations of the free software world. Some think they're essential to keep undesirables out; others won't have anything to do with them.
Both are often the source of petty disagreements.
Not to mention that in the general case it seems desirable that a community can exist without needing a CoC. Being disappointed that some community out there is doing just fine without CoC is a /really weird/ point to make in a marketing piece evangelizing how secure OpenBSD is as a technology. To the extent that it feels out of place and yes detracts. Some would even go so far as to argue that OpenBSD is second to none in security because they don’t give a shit about politics and tone in their community. They swiftly dismiss the wasted cycles spent on those in other communities, instead spending their precious time focusing on just being really good. The author sorta misses the plot point there.
> /really weird/
That's only if you take CoC enjoyers at their word. It makes perfect sense when you realize it's not about advancing project or community, but rather controlfreak ideology.
a.) They found it off-putting that OpenBSD was "proud" not to have a CoC, in the context of whether they would choose to work with them or to host the website themselves. Consider taking a moment to read the passage in question: https://isopenbsdsecu.re/about/
This idea they were surprised a project succeeded without having a CoC is an artefact of this particular discussion, not something the author ever said or implied. It was in the same category as de Raadt swearing at people over email - they didn't anticipate a productive exchange if they reached out. That's it.
If someone declares they reserve the right to treat people however they please, and then you observe them treating people in a way you don't want to be treated, and your conclusion is, "I don't think emailing this person is a good use of my time, I'm just going to host this website myself" - I find it hard to understand how anyone would find that objectionable, that seems simple, common sense, and largely neutral.
b.) Whenever you have a large group of people collaborating for an extended period of time, you have incidents. There's drama. There's inappropriate behavior. It's just how it goes. It's a Murphy's Law thing.
Eventually people sit down and say, "we've gotta set some ground rules." You probably signed a code of conduct at every school you attended and every job you've accepted. I know I have.
You can disagree with that without viewing it as a conspiracy. It's a predictable result of being in a large community, and about as ideological as traffic lights.
For someone who’s interested in getting into any *BSD, which should I go with? OpenBSD or FreeBSD?
What's your use case?
(FWIW, there several other *BSD's.)
Position-Independent Executables (and ASLR) were used by AmigaOS back in 1985. It had to, since the Amiga lacked an MMU, and had very little memory, so anything that was loaded had to be placed at whatever ram was available.
It didn't need the executable to end up in a single block either, every individual section could end up in a different location. Compilers produced large numbers of sections to facilitate this process.
That's not what's meant by PIE though. It means the code can appear at any address and still be valid.
Amigas could, of course, have position-independent code. Use BSR and BRA rather than JSR and JMP; use LEA label(pc),A0 / MOVE.L (A0),D0 instead of MOVE.L label,D0 .. but the limits for PC-relative addressing are +/- 32k so you need to get creative to reach code or data further than that.
More commonly, Amiga executables had relocs, a list of fixups to apply. The code on disk in each hunk was written as if all hunks were loaded at address 0. There was then a list of relocations at the end of each hunk, saying what offsets in that hunk need the base address of another hunk (including themselves) added there, to fixup the absolute address reference.
This is relocatable code, but not position independent code. If I used an MMU to make that relocated code appear at another address, all its absolute addressing would be wrong at that new address.
Position-independent code can be shared by multiple proceeses, and appear anywhere in their address space, while only existing once in memory
In addition to work pioneering privdrop/privsep design for network daemons, and the almost ubiquitous adoption of pledge(2)/unveil(2) across the base system, I think people are missing out on much more recent mitigation work, such as mimmutable (which Linux is just beginning to land with mseal), on OpenBSD, most of a programs static address space (.text/ld.so's .text/.bss/main stack) is now automatically immutable.
There's also execute-only memory and BTI/IBT on modern Intel/AMD, and ARM machines, enabled by default. Including a significant amount of ports development work to make the larger software ecosystem ready for this.
Execute-only memory on ARM is a footgun (bypasses PAN); Linux and macOS both block it. OpenBSD probably should too.
Why? OpenBSD seems to think execute-only in userland is important. We've had SMAP on x86 for many years, it helped fixed bugs early, these bugs are rare now, so why is everyone concerned about kernel accesses that aren't using copyin(9)?
EPAN is already supported, hardware is now arriving, it's used if available, but the idea that execute-only was less important than PAN was probably misguided.
For those interested in actually supporting some of this work:
https://www.openbsdfoundation.org/donations.html
https://www.openbsd.org/donations.html
> Random-data memory: the ability to specify that a variable should be initialized at load time with random byte values (placed into a new ELF .openbsd.randomdata section) was implemented in OpenBSD 5.3 by Matthew Dempsky.
What's the use case for this?
EDIT: further down is one example:
> RETGUARD is a replacement for the stack-protector which uses a per-function random cookie (located in the read-only ELF .openbsd.randomdata section) to consistency-check the return address on the stack. Implemented for amd64 and arm64 by Todd Mortimer in OpenBSD 6.4, for mips64 in OpenBSD 6.7, and powerpc/powerpc64 in OpenBSD 6.9. amd64 system call stubs also protected in OpenBSD 7.3.
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib...
Many things, retguard uses this for per-function random cookies, for instance.
The bootloader uses this mechanism to pass data to the kernel.
https://www.openbsd.org/papers/hackfest2014-arc4random/mgp00...
I suppose: Sometimes things work fine with the implicit default value that you end up with. So this will cause problems when you forget to initialize values to expected sane defaults.
Really surprised that pledge / unveil isn't featured more prominently on this page.
Everything I've read about pledge and unveil really admire the approach and the results but it didn't seem to have a big impact outside of OpenBSD. It took ~20 years for OpenBSD's CSPRNG to be re-implemented everywhere else maybe we're operating on a similar timeline here.
https://justine.lol/pledge/
While not the same, this is a SECCOMP-based Linux alternative (and it can even be used to restrict pre-compiled binaries).
We definitely took inspiration and implemented in the nanos unikernel cause we think it's a great idea:
https://nanovms.com/dev/tutorials/applying-sandbox-security-...
This is generally how modern systems do sandboxing.
Maybe I'm not getting something here, but I find the pledge/unveil approach confusing.
Why should I expect a program to set allowed syscalls/filesystem paths? Why would I trust that it will set itself the right permissions? What is allowed should be set externally from the program, similarly how I can map filesystem volumes and add capabilities to a Docker container [1].
I'm not familiar with BSD and I only used it a couple times out of curiosity. What am I missing?
[1] https://docs.docker.com/engine/security/#linux-kernel-capabi...
The threat vector is not that you don't trust the program, pledge/unveil is completely unsuitable for that. but that you worry the program will be compromised while it is running.
so the observation is that programs tend to have a startup state where they need access to files and a run state where they don't. so pledge/unveil is a mechanism for a program to inform the os that it no longer needs access to files/syscalls and any future access should be considered a hostile takeover. please kill me.
> Why should I expect a program to set allowed syscalls/filesystem paths? Why would I trust that it will set itself the right permissions?
Because the admin or owner will know FAR less about what a complex program needs at all times, and when it will be safe to drop privs. A database might be tested for a week and then it has a special snapshot thing done for the monthly backup and you did not foresee this, whereas the coders would know what perms are needed in order to do these dumps. Hence, you can't set perms just once before starting, and as a user of said software, you can't expect to just make a quick test and then design a fully working harness for it either.
Well, it's in date order. But they could do with a line or so of explanation
Incredible. I wonder what's the debugging experience for userland developers with all these security features enabled (especially the memory randomization ones).
My general experience has been that it’s great at turning rare crashes into frequent crashes, which are much easier to fix.
Can't you launch the debugger as root and attach to the process? Which is to say, I'd expect the experience to be approximately the same.
Alternatively, debug in a VM where the security features are disabled.
> especially the memory randomization ones
I have never once relied on memory addresses being reproducible between program runs. In an era of ASLR that seems like a really bad plan. Plus multithreading breaks that for malloc'd stuff anyway.
I am guaranteed to get grief on this but an anti-Innovation in OpenBSD (so obsessed it is about security) is to use an unsafe language like C everywhere in kernel and user space.
The implementation of OpenBSD predates many safer systems languages but I think OpenBSD should now start moving to a checked variant of C or a safer language like Rust/OCaml/Odin/Zig/Something else.
The conversion can start with some OpenBSD user space programs. I notice a steady stream of C related security fixes in the OpenBSD changelog. Many of these could have been probably avoided if the implementation language was more “safe” by default.
I doubt that this is going to happen but I think it is fair to point out that using C does give you some additional security headaches by default.
Theo has addressed this directly. I cannot find the video at the moment - it is somewhere on YouTube - but his response essentially is okay, so where is 'cat'? Where is 'grep'? Where is Korn Shell?
Everyone is busy jumping up and down and bitching about reinventing the wheel in Rust but no one has even taken the time to rewrite the simplest of Unix tools in Rust.
Not to mention OpenBSD has a rule that "base builds base" and the Rust compiler is a bloated monster that would fail that most basic task.
So where is the benefit?
It will not be Rust, since this has not happened after so many years of Rust existing. It will be some other language.
The worst part is when you come across something advertised as a replacement and it does something like 80% to 90% of what the original does with a WONTFIX for the rest. That can certainly be a valid choice in some cases, but for core tooling it's not realistic to expect widespread replacement to happen in that scenario.
>no one has even taken the time to rewrite the simplest of Unix tools in Rust.
"The uutils project reimplements ubiquitous command line utilities in Rust. Our goal is to modernize the utils, while retaining full compatibility with the existing utilities."
https://uutils.github.io/
https://github.com/uutils/coreutils
"We are planning to replace all essential Linux tools."
It would be nice if they commit to replacing more than just Linux tools. There are numerous quirks/additions to the GNU utils that the BSDs don't want or need.
https://github.com/uutils/coreutils
Parent wasn't about rust specifically. Just something safer than C
> uutils
Under development for longer than a decade and still unstable
“put up or shut up” is a valid response.
Someone is “putting up”, just need someone to merge uutils and the OpenBSD kernel to see what it starts to look like.
Maybe this is the next part of the “put up or shut up” mantra- but we’re getting closer.
The parents irony is not lost though. C and perl are both quite dangerous in their own ways, lots of implicit assumptions; its ironic that a safety focused operating system would lean in on those languages.
The website says "production ready" for their coreutils.
Maybe catching up to 40+ years of development takes a little bit of time?
> Maybe catching up to 40+ years of development takes a little bit of time?
Sure. But that's not OpenBSD's problem, is it?
lol? These have been rewritten several times by various people, it's almost a meme at this point to make "x utility but in Rust".
Well Rust has the most momentum, but going from C to Rust is quite a jump.
Zig isn't even 1.0. Odin,DasBetterC have not much uptake.
OCaml has a GC which is a non-starter for kernel, it could be used in user space sure.
While I totally agree, OpenBSD has a goal to run on some legacy & esoteric hardware.
Hardware that isn’t supported by many of these “newer & safer” languages.
Of alternatives, I think Zig is closest to what they like. It's small, easy to maintain, has great tooling for C, and already used for high-reliability (TigerBeetle). I don't know if its portability is as good as they like, though.
Big respect to OpenBSD. Now all it needs is a FS with ZFS's core capabilities and it'll be almost perfect.
Also a great resource:
https://why-openbsd.rocks/
Is OpenBSD suitable for daily use on a laptop?
Does anyone have such experience? Is it ok?
The developers often use ThinkPads, and so consequently it works quite well on ThinkPads.
Your experience will be a lot more variable on any other laptop.
Worth remembering that OpenBSD has no support for bluetooth, which many users often require on a laptop.
Worth mentioning lack of Bluetooth is only because they felt the existing BT stack was not up their standards and ripped it out rather than let it rot like most software.
There are a grand total of zero valid reasons for not including bluetooth in a desktop OS.
Not having developers to work on it seems pretty valid. It's a matter of opinion, but I feel like it's better to have no Bluetooth, compared to having a half-broken and unsupported implementation. Again you could also view is as having a semi-functional Bluetooth is better than none and then hopefully attract developer wanting to fix it.
It's pretty easy to avoid Bluetooth, and it'a a complex stack and having code quality standards means sometimes you have to remove features because the code quality isn't there, and nobody had time/interest/motivation to do the work to make an implementation with the proper amount of quality.
If you have a 'must have' device for your desktop environment that's bluetooth, then yes, it makes OpenBSD unviable for you; but OpenBSD isn't viable for every use case.
> isn't viable for every use case
Yes, and desktop, especially laptop, is an example.
I’d prefer not to have something than to have a bad something.
Yeah, it was annoying when I tried to pair my mouse- but you know… a wired mouse isn’t that big of a deal.
One thing that brings me the most displeasure about internet discourse about operating systems is this idea that they all have to do all the same things.
Thats homogeny by another name; the point of different operating systems is different trade-offs.
Small usb bluetooth dongles work, they show up as a regular audio device. I use one and sndiod can set set to automatically switch back and forth to it.
I run openbsd on my laptop, a thinkpad x260 with an ssd, and it works great.
It depends on what you need for your daily use, OpenBSD has ports of common desktop environments, KDE Plasma, GNOME. In fact, thanks to KDE and GNOME port maintainers, Rafael Sadowski, and Antoine Jacoutot, respectively, OpenBSD 7.6 -current has the latest versions of both (KDE Plasma Desktop 6.3.1, GNOME 47).
I recently checked out KDE 6 for the first time last year, it really is as easy running as 'pkg_add kde kde-plasma kde-plasma-extras' and then reading through the local pkg-readme file, that said if you're not familiar with OpenBSD it won't be like other systems where it comes preinstalled and preconfigured.
https://brynet.ca/article-l13gen2.html
There's many popular window mangers and applications you can install using the package tools, as you'd expect, including Chromium and Firefox, but you can quickly search here: https://openbsd.app/
https://jcs.org/openbsd-laptops
It was a few years ago, but I ran OpenBSD for about a year in college (on a Thinkpad). It worked because I rarely needed anything more than Firefox, code editors, and a shell with ssh. Most of my time was spent reading, writing papers, writing emails, and writing code.
It works quite well. The OOB experience is very complete and hardware gets picked up without issue. However you’re limited in the amount of apps and it’s also incredibly slow, so you’ll need to really use minimal, fast cli apps.
I left it ultimately because it had way worse battery life than Linux on my T480s and I also wanted to play some games with steam.
> it’s also incredibly slow
I never used OpenBSD. Why is it incredibly slow?
Disk I/O is notably slower than e.g. Linux or Windows and executional performance is generally a tiny bit slower, but nothing about it is "incredibly slow".
browsers are exceptionally slow in my experience.
You will want to enable GPU-accelerated rendering for Firefox and Chromium to get a smoother experience when scrolling pages and for certain video playback, because that's disabled by default. Besides that they load and parse pages and act on input pretty much as fast as they do on Linux.
well, SMT/hyper-threading is disabled by default[0] , not sure if there are other reasons though. It's not that bad, but yeah OpenBSD is probably not your optimal gaming OS :P
[0] https://www.mail-archive.com/source-changes@openbsd.org/msg9...
SMT being disabled is not a reason for anything to be incredibly slow, or even tangibly slower, unless the CPU has a single core.
You could probably get close to the same experience by running your BSD in a VM when you need it?
Yes but depends on the laptop.
Get a Mac laptop. OS X is based on BSD.
OpenBSD is as different from macOS as Windows 11 is from OpenVMS.
Common misconception. It is not. The kernel is XNU, and the OS base is Darwin which has some BSD parts in it, and some of the userland came directly from FreeBSD (though heavily modified).
You’re not actually disagreeing with the OPs statement though. And they’re technically right too.
The problem is that all the user facing stuff in macOS isn’t BSD. It’s Apples proprietary APIs. So while macOS was originally and technically based on BSD, almost none of that is exposed to their users.
So they’re technically correct that macOS / Next was based on BSD. But also completely wrong to recommend macOS as a comparison to OpenBSD.
macOS was originally based on OPENSTEP. OPENSTEP was based on NeXTSTEP which was based on 4.3 and later 4.4.
BSD stuff has a complicated history due to the lawsuits in the 1990s.
NetBSD and FreeBSD were based on 386BSD. OpenBSD was a fork of NetBSD by one of the NetBSD founders (Theo deRaadt)...
It’s not even as clear cut as that because there’s FreeBSD and NetBSD code in XNU too.
Also OpenStep is an API rather than an OS. So macOS contains both NextStep and OpenStep code.
I'm pretty sure I've even read about FreeBSD code in the Windows networking stack. Is Windows now based on BSD? Open source code, especially when it's permissively licensed, ends up absolutely everywhere.
Windows is very much based on NT, which has its influences from a few different OS, most notably being VMS.
AFAIK there isn’t any BSD code in Windows however the original TCP/IP stack in Windows was a port from BSD. But we are talking about the early 90s here and it’s long since been rewritten by Microsoft (or so they say, but I have no reason to disbelieve Microsoft)
OPENSTEP is the OS, OpenStep is the framework.
After NeXTSTEP 3.3 there was OPENSTEP 4.0.
OPENSTEP 4.2 is the last operating system release prior to Rhapsody.
Yes it’s confusing.
True. The capitalisation rules for releases kills me every time too. Not just with OpenStep but with Next too. I now don’t even bother trying to get the capitalisation correct.
Considering how obsessed with UX that Jobs was, I don’t get how he thought the naming conventions were a good idea.
I believe it all came after Paul Rand did the logo.
NeXT looks good in the logo, and they spent $100,000 on it.
FWIW, I like it but it is confusing and made harder by the fact they also didn’t stick to their own conventions much of the time.
Have they implemented ISO C11 _Thread_local yet? It's been the number one annoyance¹ with porting software to OpenBSD. It is (was?) the only mainline OS without support for native thread-local storage.
¹ e.g. https://github.com/FRRouting/frr/blob/3f290c97e8325bd9db9363...
I believe their system clang support it with -femulated-tls.
Pretty sure we tried that and it didn't work, but that was at least 2 years ago... time to retry I guess.
Emulated TLS isn't particularly great though in any case :/
A LOT of those innovations were first present in grsecurity/PaX. Back when it was freely available to everyone as well. I guess the arguments is the OpenBSD has them by default with needing a 3rd party patch, that's why they're claiming them as their innovations?
Yup! The idea behind Pledge/Unveil was first in Landlock also.
> that's why they're claiming them as their innovations?
I think they are just listing their specific implementations as innovations, their particular approach. Too many of what they list was definitely not an original idea, so they can't possible be suggesting otherwise. At least, I would hope not.
> The idea behind Pledge/Unveil was first in Landlock also.
This is so plainly, and verifiably untrue, that it's almost funny. The patch series and kernel commit adding Landlock to the Linux kernel even references OpenBSD pledge(2)/unveil(2) as a source of inspiration.
https://github.com/torvalds/linux/commit/17ae69aba89dbfa2139...
https://lore.kernel.org/linux-security-module/20210422154123...
> This is so plainly, and verifiably untrue, that it's almost funny.
I just found that email and the talk for the project myself and noted the author referenced pledge in another comment, but thought that could be due to the earlier OpenBSD release having gotten press, making it useful as a point of comparison.
I had honestly thought the landlock website or an earlier talk had pre-dated the release of OpenBSD 5.9, but I appear to have been wrong about that.
> Yup! The idea behind Pledge/Unveil was first in Landlock also.
Landlock was released in Linux 5.13, in 2021. Pledge was released in OpenBSD 5.9, in 2016. As far as I'm aware, Pledge is the first of its kind.
Linux 5.13 was the first kernel release with Landlock incorporated, but the Landlock project is from 2016 also.
I found the announcement email for Landlock posted to the lkml[1] where the author compares the project to Pledge. There's also his talk[2] from 2016 if you're interested. I was certain landlock predated pledge, as I thought the website or earliest talk was from late 2015, but I am less certain now, indeed I seem to have been wrong in my claim.
As for either being the first, at the very least Seatbelt from Apple has a paper dated 2011[3] and was released with macOS 10.5.
[1] https://lwn.net/Articles/700607/
[2] https://archives.kernel-recipes.org/document/landlock-lsm-un...
[3] https://www.ise.io/wp-content/uploads/2017/07/apple-sandbox....
OpenBSD's pledge(2) was first talked about publicly as tame(2), and was presented in at FSec 2015, it was renamed pledge(2) as mentioned on the OpenBSD 5.9 page.
https://www.openbsd.org/papers/tame-fsec2015/
https://man.openbsd.org/OpenBSD-5.8/tame
https://www.openbsd.org/59.html
I thought I had remembered something from Landlock from 2015 also, but can't find anything supporting that. The first version referenced is v7 or v0.7, so it's possible there was a talk for v0.1 or something that isn't online anywhere.
I'll concede that's less likely and I'm probably just wrong and misremembering though.
Thanks for posting this, I think in our industry provenance is an underrated piece of knowledge.
carp is one of my favorite things to come out of OpenBSD. It's awesome combined with HAProxy. I really enjoyed managing that system.
I also like OpenBSD's release art/songs.
"Hello, I'd like to by a CARP license please."[0]
[0] https://www.openbsd.org/lyrics.html#35
Does OpenBSD still have a giant lock?
Genuinely curious, and it’s been years since I’ve looked at it.
Most of that is gone and the performance upswing is very noticable. A little bit of work remains.
I still see spl references so I think so?
I wonder if we could get router based on OpenBSD.
It does the job great with the default install as long as you're comfortable with the console but if you're talking something with a web interface like what pfsense/opnsense on freebsd, there was one out of Sweden I think it was for a while that fizzled out called securityrouter. Nowadays these are what I've seen (But not tested):
https://github.com/sonertari/PFFW
https://github.com/sonertari/UTMFW
yes we can - https://www.openbsd.org/faq/pf/example1.html
It also leads the BSDs in RISC-V support.
I am hopeful for got (game of trees).
OpenBSD still uses CVS, and I suspect its development will benefit greatly (actually accelerate) from the switch, once it eventually happens.
wow, 25+ years later and ipv6 is still not fully integrated
OpenBSD was the first system with an IPv6 stack.
What? I think you misread. The IPv6 stack was "almost fully operational [already] by june 1996".
Perhaps one day the OpenBSD folks will figure out how to completely prevent user programs from making syscalls. It seems they are mostly there but still not quite. Please don't mention WASM in your replies.
It's rather hard to do anything useful if you disable i/o.
Are you referring to their only allowing syscalls from libc? Because AFAIK that's fully functional already?
Or if you're trying to solve a problem, what are you doing that pledge() doesn't cover? For that matter WASM.... would do that, so why not use it?