What are the differences between OpenBSD and Linux?
cfenollosa.com
cfenollosa.com
Although I agree that OpenBSD can offer a cleaner experience if you are willing to compromise on the software you use, when it comes to freedom, I would not consider OpenBSD the next step on the ladder. Of course this is a very personal and philosophical question, but a very significant difference to Linux is the permissive BSD licensing used by OpenBSD. In my opinion the GNU licensing is a big reason why GNU/Linux got so successful since it pushed big companies like IBM to feed their contributions back into the GNU/Linux ecosystem.
You can end up with poorly written code generated by unqualified people that addresses short term business needs. Such code tends to be abandoned quickly by its sponsor which causes long term maintenance problems. In the Linux ecosystem, stuff tends to go bad quietly in the darkness.
There is no good motivator to produce documentation for anything in the Linux world. Giant, useful, and well written systems get dropped in and end up being more or less useless because only the originator can actually figure out how to use them.
The BSDs run off of good old fashioned ego driven software development done by people who care deeply about software. They don't care that much about how others exploit it, only that it is good. It turns out that there are upsides to getting a group of such people together to to work on OS stuff.
On the other hand, ego driven software development can also freeze technologies or development processes to what the main ego(s) want(s).
Case in point, FreeBSD, NetBSD, OpenBSD and CVS. And even they will admit CVS is sub-optimal for development, see: https://wiki.freebsd.org/VCSWhy, https://wiki.freebsd.org/VCSCvsProblems. Note: I'm not saying Git is the solution, but CVS is bad. They should at least use SVN or any of the many systems that have learned from CVS' mistakes.
TL;DR: Pick your poison regarding development practices.
DragonFly BSD, a FreeBSD 4.x fork, has also used git successfully since early 2009, I believe.
George Neville‐Neil, president of the FreeBSD foundation, recently gave the keynote at AsiaBSDCon. During his presentation he derided Sean Webb/Lattera for its focus on security (https://hardenedbsd.org/content/easy-feature-comparison), simultaneously deriding OpenBSD as “basement dwellers” (this in a talk asserting that the BSDs need to present a unified front to succeed in the world). He also made excuses for the fact that FreeBSD finally—finally!—implemented ASLR in 2019. (For reference, PaX developed ASLR in 2001, OpenBSD implemented their own in 2003, and mainstream Linux got it in 2005.) His excuse, that ASLR is “broken anyway,” was called out by the very first commenter for betraying a complete misunderstanding of what ASLR defends against (GNN trumpeted ASLR attacks on JIT engines, but executing malicious JavaScript on the host is out of ASLR’s scope and always has been). https://youtu.be/7kShjboN6ek?t=2820
I don’t know the full story between Sean Webb/Lattera and FreeBSD, but I do know FreeBSD has a poor track record when it comes to security mitigations, and if the presentation above is representative of how the president of the FreeBSD Foundation behaves at an ostensibly cross‐BSD conference, I know which side I’m immediately inclined to disfavor.
We contribute to OpenBSD because we care about the goals of the project and that motivates learning and dealing with CVS.
While we're at it, if a developer finds ed (the standard text editor) a roadblock to working on OpenBSD, they are simply not a good developer.
Why is somebody "not a good developer" if they don't want to work with tools which are an insult to the priorities and humanity of the user†, for no good reason, when they could go to Linux and have 99% of what's good about OpenBSD, without the cult of GCC 4.2-justifying, CVS masochists?
I love OpenBSD, but the self-defeating goober decisions clearly reduce the number of people willing to become the experts needed to push the project forward. So much of OpenBSD is user-friendly, as long as that user reads the manual; but CVS is among the most user-hostile version control systems any living developer remembers using, and even if you know exactly what you're doing CVS is still an inconvenience because of centralization, and because of the amount of clerical work required to get it to operate properly.
† In the context of a world full of spectacular alternatives; obviously this doesn't apply to a time when CVS was a cut above.
As for ed, even though i realize you're not serious, screen oriented editors replaced ed as soon as Unix could use them and Unix developers at AT&T used ed mainly because they lacked the hardware to use anything else.
It should be obvious that the difference between the user friendliness of a program that shows you a real time window of the text you are editing with immediate feedback and a command line interface based editor designed for slow teletypes is much greater than the difference between two slightly different sets of commands that will be the majority of one's VCS use will be.
I think that anyone who is familiar with CVS & Git and with ed & vi/emacs will agree that there is a similar leap forward in capability. The move from CVS to SVN is a bit like the move from vi to emacs, but the move from CVS to Git really is like the move from ed to vi, vim or emacs.
I suspect that this is probably another example of the Blub effect, this time applied to VCS: the CVS user looking up at Git thinks, ‘Why would I ever need that? Besides, if I ever did I’m sure that I could roll something that was good enough,’ while the Git user looking down on CVS thinks ‘There but for the grace of God go I.’
Myself, I’m crazy about local branches and rebase -i. But it’s no skin off my back if the final command I run winds up being “cvs ci”.
As far as I know there is none. People talk about moving it to git like there is no cost to doing so and that it will provide only benefits, but as far as I've seen there's been very little justification that's a motivation more than maintaining the status quo.
I mean, I personally prefer git. I've used it at work for years and I'm quite good at it. If the project is hitting its targets while on CVS, I think that's fine.
I think this is a bit of survivorship bias: CVS is working fine for the people it works fine for, but who knows? Maybe out there somewhere, there's somebody who was put off by CVS, who would otherwise have gone on to finally update the Radeon drivers for GPUs from the last five years.
Sending a patch with github seems more convenient for about the first 5 minutes, but you have to be really careful, because the pull requests aren't frozen like a patch in email would be (this could be good or bad, but it was unexpected to me)
Certainly, version control approaches make a big difference if you're committing, but to decide not to start contributing because you wouldn't like being a committer doesn't make sense to me. Chances are, you won't become a comitter.
What happens when you need to rebase? When you need to backport (or separate changesets, as may be the more common use case with OpenBSD)? Why use a tool which doesn't help you with anything and is, relatively speaking, way more complex to use than necessary?
CVS is being used effectively as rsync + changelogs, and sure, you can use git locally if you want the features, but why start with the virtually-useless format?
I think you missed the key part of the question that was asked of you. Why would _outside contributors_ care about any of that? The process is to submit a diff via email. You don't need to do any of those things to follow that process. And there's a git mirror anyway!
> CVS is being used effectively as rsync + changelogs, and sure, you can use git locally if you want the features, but why start with the virtually-useless format?
Start with? OpenBSD started in 1995. It predates Git, Mercurial and Subversion by many years. Subversion's 1.0 release wasn't even until 2004. Their process has been working extremely well for a long time.
Because not every outside contribution touches no popular code, and not every outside contribution goes directly into the upstream. Long-running external branches are common, reasonable, and easy in git; when I was trying my hand at a V8 port, I was able to keep it building against upstream V8 the whole time (2+ months, and would've been longer if I brought it to completion).
At this point you're just flaming.
I'm really confused how managing those patches is harder in git vs cvs? Or are you objecting to having ports as a collection of tarballs with local patches? Or were you trying to get v8 included in OpenBSD base for some reason?
Earlier in the thread, you were saying that CVS was a barrier to entry for contributing, but now you're saying you're not even sure you're planning to contribute. In that case, use the git mirror. Even if you are going to contribute, you can use the git mirror.
cvs up and submit a new patch?
> When you need to backport
Try to apply my patch on the relevant release branch, and carefully check that it works, or reimplement it, depending on how much changed in the area I'm patching? If it's trivial to apply to a previous release and desirable to do so, the project team is likely to do it without me.
CVS or git or SVN or tarballs or hg all do the same thing for me as an outside contributor: give me a basic tree to start from and send diffs from.
A patch against what revision?
https://www.openbsd.org/faq/faq5.html#Diff
The procedure is to email diffs to the mailing list. You only really need CVS for checkout and there's been a git mirror for 3 years now. The procedure has very little friction.
I can't really speak to the intentions of the project developers, but my assumption is that more contributors or contributions themselves are not the goal. The project wants people who are extremely motivated by the project's goals.
Care to provide an example of this? I've heard critiques of Linux's model that were basically FUD attempts by others in the past, that sound strikingly similar to this sentence. The FUD was about security holes that could be "snuck" into the code, when no one was looking.
For anyone with a cursory knowledge of the actual process, there is an understanding that this generally cannot and does not happen. The process is specifically design to keep 'poorly written code' from entering in the kernel.
You may be talking about user-space. There, the code quality is largely a function of the maintainers and their processes. No specific OSes user space is immune to this, c.f. OpenSSL.
So, put another way, I'm not buying that argument.
> The BSDs run off of good old fashioned ego driven software development done by people who care deeply about software.
This may be the most cringe-worthy statement I've seen posted on HN in a while. Ego/hero driven development is an antipattern you would like to avoid. Suppose your hero/massive ego person decides that they don't like X, being some thing that industry as a whole, has adopted. As a result, no progress is made on X, proposals to deal with X have been generally slapped down, or slow walked. Because the ego/hero involved doesn't like it.
This isn't theoretical for me, I've seen this upfront and personal recently. This attitude, combined with several co-morbid positions, lead to outcomes that no one wants.
Given the high standards I've seen Linux maintainers uphold over the years, and experience trying to write kernel code which is good enough for just my installation, I don't really tend to agree that the software is being written by "unqualified people" could push code into the kernel to "[address] short term business needs".
Not really sure what kernel you're looking at, I'm looking at the one where AMD's display configuration codebase, which they had conveniently repurposed from their proprietary cross-platform equivalent, was reviewed thoroughly and needed to be dramatically reworked to meet the standards of the kernel maintainers; business convenience be damned.
However, in the real world I think that the GNU world has long had a tendency to add feature upon feature (which is nice) and to treat each subproject in isolation (which is less nice) which can lead to fragmentation across the GNU Project as a whole (which is very much Not Nice). While Linux is of course not part of the GNU Project, it is the kernel of a GNU system, and the Linux kernel on its own is not terribly useful.
Meanwhile, the BSDs have always been integrated systems. There’s not reason inherent in the license that they are — they just are, and since they are they continue to be.
I think its contribution was that it was a palatable license for strong believers in open source. I think it was about how people felt more so than a direct impact.
People felt good about the idea that people and corps that would use the software would need to contribute back. And so they were more free in their own contributions, as well as feeling good about using the software.
Been eying it for a while, but never gotten started.
For an even better experience, try it on an old ThinkPad following this guide [0]. You might like how suspend/resume just works, how your brightness and volume hotkeys just work, how the documentation is awesome, and how all the software you need is just one pkg_add away. I’d say that, compared to Linux on the desktop, OpenBSD can be a much more cohesive experience without a desktop environment installed and without endless configuration for basic features.
Nota bene: my info is from 2010 or even earlier.
"There are very few things OpenBSD does that Linux does not. However, what they do, they do better."
But with no explanation of where it is "better", or even what "better" is, this isn't a valid argument. He even points this out himself a short while later:
"Are you telling me that the positives are intangible and the negatives mean a slower system and less software overall?"
I was always curious why we don't have a simplified kernel for desktop/laptop use. I imagine 90% of people are running their computers in almost single user mode. E.g. at the moment my Debian, except my main username, also runs programs as root, systemd*, Debian-gdm, messagebus, some of which might be merged either with root, or with my main account. All the security features of the kernel (OpenBSD or Linux) are actually not used that much, so we could in principle make software faster and battery life longer just by "optimizing" that features. Same is true for clusters, VM hosts, embedded Linux.
It seems we overkill with security, providing fake sense of protection, while giving up on important metrics: execution time, battery life, memory usage, bandwidth, etc. At the moment the biggest security concern of mine is not the services running on my laptop in background, even with open tcp/udp ports, but the fact that my browser is running under the same username, which I use to access ssh keys, ssh-agent sockets in /tmp, password manager's files, photos, etc. Browser executes arbitrary code from the unknown to me sources all the time and one day someone will break the sandbox-ing and copy my files out.
Surely using VM will give even better protection while allowing for simpler kernel, but as the compilation requires up to 16GB or RAM and may take up to 2 hours, using VM will add an overhead that I cannot afford.
[1]: https://man.openbsd.org/unveil [2]: https://www.kernel.org/doc/html/latest/admin-guide/LSM/index... [3]: https://fuchsia.googlesource.com/zircon
> The first thing to realize is that, on the surface, the changes are minimal. Both are UNIX-like. You get a terminal, X windows, Firefox, Libreoffice...
I use Sway as my WM, which uses Wayland and not X. I use Docker all the time at work. Neither is available in OpenBSD.
While I really like OpenBSD, have tried it out and have ported a small open source project to it, I don't think the differences are minimal.
I think if you port a multi-threaded application from Linux it's far from trivial (guess depends on the code last time I needed my C code to work it was just a matter of writing a good configure script - not a skill many have under their belt in 2019).
on the WM: I have been using i3 for over a year and never looked back. Also been thinking about giving Sway a spin. Is there any reason I should other than Wayland? Usually I don't notice any problems with X (the reason why I would switch to sway) unless I quickly resize an i3 "container". But maybe I get a better memory footprint from Sway compared to i3? Is Sway worth the trouble to rewrite my i3 config? I understand Sway config is compatible and even has i3-gaps like behavior but I got huge amount of non compatible things inside my setup that requires a rewrite (hence my silly question) and it's not like I need gaps (even it looks awesome, my laptop screen real estate is limited enough as is)
For me it was "Do these make little sense to you? I know, it's difficult to fully understand. Your reference is "Windows VS Linux" which are so different on many aspects, like an elephant with a sparrow. To the untrained eye, distinguishing a pigeon with a turtledove may not be so evident."
What a rooster.
At least on Linux, openntpd is unreliable - it might be secure but it fails to keep time properly unless it follows exactly one source or all sources agree perfectly (so I would assume it would equally fail on OpenBSD as well)
ntpd is indeed horrible; but chrony is the bees knees from both functionality and security standpoints - openbsd would do well to move to it.
* https://chrony.tuxfamily.org/comparison.html
"Size of stripped daemon binary in default configuration on Linux x86-64"
chrony: 210 KB
openntpd: 87 KB
I used to be one myself.
This article does not cover the actual issues you will encounter when going from Linux to OpenBSD.
The first actual issue is that the installer is in text and not very forgiving of mistakes. It's also a very simple installer that some would praise as a no-nonsense program but coming from Linux where graphical programs with support for disk encryption and multiple storage controllers are common this will be noticed.
The next difference you'll notice is packages. You're likely used to binary packages from Debian, CentOS and other distros. OpenBSD has them too but they're far fewer than any Linux distro. Simply because the number of people (package maintainers) working on the BSD ecosystem are fewer.
So get ready to compile a lot. Which is just a bad idea when it comes to lifecycle management.
The next difference you might encounter further down the line is how many user space programs act differently from Linux. Like for example route, netstat, tar and many more. You might not find some favorites like lsof and ss, instead having to learn others like fstat.
In my personal opinion the general state of these user space CLI programs is much worse in OpenBSD.
And finally, lifecycle management is generally much worse in OpenBSD than in the major distros.
Why not fault Linux for not having the same interfaces as the BSD tools? The BSD ones were there first.
The reality is that the systems are different and OpenBSD is not trying to be Linux. Faulting either one just for not being the same as the other is silly.
>> when going from Linux to OpenBSD
or you could rephrase it, when going from more popular to less popular.
He isn't finding fault, he's expressing a practical issue that is relevant to the more common viewpoint (including the author of the article, whose audience is curious linux users). Contrary to the title of the article, which is agnostic and what you are arguing for, the article is actually written from a specific POV, for a specific audience:
> This list is aimed at people who are used to Linux and are curious about OpenBSD.
And can these differences be resolved with some copy & paste so they are both up to standard?
For example, people often bring up tar as a tool with a less‐than‐intuitive interface. Compare the manual to GNU tar with OpenBSD’s tar:
https://manpages.debian.org/stretch/tar/tar.1.en.html
Not only does GNU tar have a bewildering array of options that make reading through the manual a chore, it lists (as far as I can tell) only one example, and in a section devoted to explaining the many ways to specify command‐line options to tar. OpenBSD tar has a whole section dedicated to examples (as is typical for OpenBSD); the manual as a whole is clear, concise, and complete.
Another example: GnuPG versus OpenBSD’s signify.
https://manpages.debian.org/stretch/gnupg2/gpg2.1.en.html
There’ve got to be over 100 options in there. And although it helpfully places --sign first (and --clear-sign, and --detach-sign, and --encrypt, and --symmetric, and --store, before it finally gets to --decrypt), let’s be real: anyone who’s not already comfortable with encryption software will be completely intimidated by this manual, which is 175 (!) page‐downs in a 80×24 terminal.
Contrast with signify:
https://man.openbsd.org/signify.1
The description section starts with the four major operations (sign file, verify file, verify many files, generate key), and is again followed by an examples section.
Of course, the OpenBSD tools are much less featureful than the mainstream counterparts. But the reality is that most people, and certainly I myself, need only a few features in day‐to‐day life. Even being a real terminal junkie, I’ve only needed GNU tar specifically once or twice in the last ten years; and when I did, on OpenBSD, it was a mere “pkg_add gtar” away.
OpenBSD has a great self‐contained base system, with elegant tools and useful documentation, and an extensive package collection for when that’s not adequate. I continue to use it because it serves my needs as a primary driver, and the interface is just so gosh darn pleasant to use.
OpenBSD does not like bugs :-)
The tar example is indeed much cleaner.
But it seems to be a bit old ...
"A tar archive is often stored on a magnetic tape, but can be stored equally well on a floppy, CD-ROM, or in a regular disk file"
Not that it hurts much, though.
[0] https://github.com/openbsd/src/blame/f84583fe5d7899ab1504dc1...
If you had compared the OpenBSD man page to that, it would be a more fair comparison.
In any case, the info page is far larger than the already‐large manual page, which I think only further illustrates one of my points, that the software is itself intimidatingly complex.
Raise your hand if good man pages have helped you out of a fubar situation. raises hand
Note that this isn't about it being technically impossible, you can certainly do it, but it isn't the right tool for the job - a dedicated manual reader provides a better UX here (and the failure of GNU info to provide a user friendly experience is, IMO, the reason manpages are abused so much in Linux).
BSDs (and some others) come with variously-named Handbooks. OpenBSD has the aforementioned. FreeBSD has a Handbook. So do DragonFly BSD, NetBSD, and others. They are distinct from the user manuals, which are the reference doco. They are, indeed, hyperlinked. Already.
* OpenBSD FAQ: http://openbsd.org/faq/index.html
* NetBSD Guide: https://netbsd.org/docs/guide/en/
* FreeBSD Handbook: https://freebsd.org/doc/handbook/book.html
* DragonFly BSD Handbook: https://www.dragonflybsd.org/docs/handbook/
* GhostBSD Handbook: https://wiki.ghostbsd.org/index.php/GhostBSD_User_Handbook
* MicroBSD Handbook: http://damnsmallbsd.org/MicroBSD/handbook/
* OpenIndiana Hipster Handbook: http://docs.openindiana.org/handbook/getting-started/
* old TrueOS User Guide: https://trueos.org/handbook/trueos.html
EDIT: i see some of those are authored in DocBook but still info files can in theory be written in DocBook too. The main focus of my comments here is the end user format and viewer capabilities, not the authoring format (and honestly i'm not a big fan of info format with its hardcoded text formatting).
Apache/nginx/whatever versus OpenBSD's httpd.
[a suite of various software] versus OpenBSD's relayd.
iptables vs OpenBSD's pf (that's the "pf" in "pfSense").
OpenSSL vs OpenBSD's libtls.
Here is the man page of the driver for the wireless card in my laptop https://man.openbsd.org/iwm.4
It's clear and concise, has links to the related tools that I might need to get the card working.
Is there a similar man page for Linux? I'm not sure, honestly.
Copy and paste? You'd have to copy and paste the whole driver for a start.
Yes, they are there for system calls, but also for applications -- depending on your definition of end-user applications, since some of what Linux considers "end-user" are, as TFA mentions, first-class applications that ship with OpenBSD.
I don't think the differences can be resolved with copy and paste since many Linux man pages deal with programs that are very different under the hood than those with the same or similar names in OpenBSD. I also don't think it's unfair or arrogant to consider OpenBSD's man pages to be the standard of what man pages should be, btw.
Search one or two of your favorites and see for yourself: https://man.openbsd.org
Take "ps", for example. The BSD "ps" program is fundamentally different to the Linux "ps" program. It's also, quite importantly, different to what the Linux "ps" manual erroneously claims the BSD "ps" to be.
* https://manpages.debian.org/testing/procps/ps.1.en.html
* http://netbsd.gw.com/cgi-bin/man-cgi?ps
Also, you don't need guides, etc. man(1) is enough most of the time, and the people on Freenode always lend a helping hand, if you did a bit of homework first.
Officially, "UNIX" is presently defined as a system which has been certified by The Open Group (to whom Novell gifted the Unix trademark, which Novell had bought from AT&T.) To get certification, you need to pay $$$ and pass the test suite.
According to that definition, IBM z/OS (formerly known as MVS) is a UNIX; also are AIX, Solaris, HP/UX, SCO UnixWare, SCO OpenServer, macOS. Most Linux isn't, but certain Linux distributions have been certified, in particular Huawei EulerOS (and previously also Inspur K-UX.) To my knowledge, none of the *BSDs have been certified, so officially speaking they are not "UNIX", only "UNIX-like".
What benefit would I get from UNIX versus a UNIX-like system?
Some things you can do from either the Unix shell interface or the 3270 interface, like compiling c/c++ programs, but a lot of things are much more difficult or impossible from the Unix shell.
In case anyone is wondering why z/OS has a Unix in it, from the wikipedia page [0]:
"Numerous core z/OS subsystems and applications rely on UNIX System Services, including the z/OS Management Facility, XML parsing and generation services, OpenSSH, the IBM HTTP Server for z/OS, the z/OS SDK for Java, and some z/OS PKI services as examples"
There is a company called Rocket Software that ports tools to z/OS Unix, including Python (2.6 and 2.7), Vim, Perl, Git, and Bash[1][2].
I think IBM actually pays them to do a lot of these ports to make Unix on z/OS suck less.
[0] https://en.wikipedia.org/wiki/UNIX_System_Services
[1] https://www.rocketsoftware.com/zos-open-source/tools
[2] https://www.rocketsoftware.com/zos-open-source/languages
zCX is much more WSL-like, in that it actually runs z/Linux Docker containers under z/OS, as opposed to the mere partial source-level compatibility of UNIX System Services.
(I'd love to know how zCX is actually implemented? The information IBM has released publicly so far seems rather light on technical detail.)
In contrast beyond the obvious technical differences OpenBSD is largely a self-service operating system in that the community expects people to self-educate before posting to misc and asking for help. I jokingly call it a full contact OS for this reason. A reasonably technical person can read the docs and figure out how to install and use OpenBSD. But there is no training wheels distribution to ease you in.
I would have been running OpenBSD for a long time on my Thinkpads if they would not be so actively hostile towards the GPL, the FSF, and GNU.
Their pufferfish is indeed a well-chosen mascot.
It's a BSD licensed kernel / project, so making parts of it GPL-licensed would be incompatible with that.
You can install GPL'ed code on the system without issues though.
> What other hurdles remain in replacing GPL-licensed programs in OpenBSD?
> TdR: But that's never really been the agenda, see. Some people think we hate GNU code. But the thing is we hate large code, and buggy code that upstream does not maintain. That's the real problem... gcc gets about 5-6% slower every release, has new bugs, generates crappy code, and drives us nuts. This is just an attempt to see if something better can show up.
(End result: the PCC effort stalled, but OpenBSD has now switched to LLVM on most platforms.)
When it comes to the BSD-licensed kernel, the only issues i've seen is when, e.g., Linux or other OSes reuse parts of it, improve that, and then want to upstream their changes, but try to do so using a GPL license (e.g. because the changes were applied to the linux copy of the source).
That's unacceptable as an OpenBSD contribution. So in some sense the GPL is as bad to OpenBSD, as "private companies reusing open-source code and not contributing back their changes" is to open-source. That sucks (and is quite ironic TBH), but the attitude towards it from OpenBSD is just "sorry, but that license is unacceptable", not "hostility".
"you are a power-misusing hypocritical liar"
"you are being the usual slimy hypocritical asshole"
And that was just the OpenBSD project leader...
So I'm completely locked into a single vendor.