> But think about what attracted you to Linux in the first place. [...] It was probably a sense of freedom, the promise of a more robust, more secure, more private system.
OpenBSD is just the next step on that ladder
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.
The downside to the GPL in the case of Linux is that it really works well ... which is an odd thing to say. It has become a giant software cooperative with, as you say, lots of software contributions from lots of companies. As a result the Linux ecosystem suffers from the downsides of commercially driven software development.
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.
> 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.
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.
I suspect that the difference in quality & simplicity between OpenBSD & Linux is less a matter of license than historical accident. Given two identical projects with identical contributor profiles, differing only in license, I don’t expect that you’d see any difference in quality.
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.
> The BSDs run off of good old fashioned ego driven software development done by people who care deeply about software.
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.
The biggest problem in CVS is the lack of integrity checking. A repository can have individual files go bad and have it be non-obvious for some time. Long ago, it was desired to preserve all history for a CVS->Subversion move I was involved with, and it turned out there was corruption that meant that one file could not be accessed before a certain point in the history. We wound up just doing a repository scrape instead.
Something can be harmful to the project without totally sinking it. "Disease may be 'bad,' but it's clearly working for humans and the population continues to skyrocket exponentially like clockwork."
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.
The cost is in opportunity. I know a number of competent developers who wanted to add something to OpenBSD (and had a good chance of succeeding), but were so put off by CVS (which is especially inconvenient if you're not already an OpenBSD maintainer) that they either stopped right there, or didn't continue after getting CVS "working". It's not that people can't use CVS, it's that nobody in their right mind would willingly suffer the personal insult of being required to use CVS, because it has basically nothing going for it, and there are so many other options.
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.
Honestly, I don't see how choice of VCS matters to outside contributors. The process is almost universally get a recent checkout, make modifications and test them, then send a patch.
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.
> Honestly, I don't see how choice of VCS matters to outside contributors. The process is almost universally get a recent checkout, make modifications and test them, then send a patch.
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?
> 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?
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.
> Why would _outside contributors_ care about any of that?
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).
If OpenBSD's port system is anything like FreeBSD's, a v8 port to OpenBSD would have been in the ports tree, where the final product is expected to be a stub makefile that more or less is expected to download an upstream release tarball, apply some patches and then build it, right? (Like https://github.com/openbsd/ports/tree/master/lang/erlang/21 but for v8 instead)
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.
I was not talking about an OpenBSD package, but porting V8 to a new ISA. And yes, I have no plans of contributing to OpenBSD right now, because it works fine for the machines I can use it with, and it doesn't support my workstation hardware at all (which is what I'd be likely to contribute for).
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.
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.
Things can go on for very long periods of time until they suddenly burst. What happens when the current developers retire? I doubt there's any software dev born in 1990 and later that wants to touch CVS, especially for a hobby project.
You make it sound like CVS kills children. People worked with CVS just fine for decades and OpenBSD has made their own tools for CVS to improve their development experience and, frankly, if a developer - regardless of age, lets not get into age discrimination here - finds CVS a roadblock to working on OpenBSD, they are simply not a good developer.
> If a developer - regardless of age, lets not get into age discrimination here - finds CVS a roadblock to working on OpenBSD, they are simply not a good developer.
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.
User friendliness is not binary but a spectrum and CVS is way above being "usable", even if it isn't the most user friendly VCS out there (hint: git isn't either). It certainly is not "insult to whatever of the user".
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.
> 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.’
You’re still missing what’s been stated elsewhere in the thread: that OpenBSD’s review process is VCS‐agnostic, that the project officially mirrors to GitHub, and that many developers and external contributors use the Git mirror for their work (just look on the tech@ list for how many mails have “diff --git” in the patch).
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”.
I think you'd be wrong here as personally i have used Git a lot more than CVS as i suspect would any developer nowadays who has at least a couple of years under their belt. And i think it is the exact opposite of what you are talking about that is happening: people already know Git and want to use it for everything - you see, after all, that the common response isn't something like "why would i use CVS again?", it is something like "why would i/some new developer learn CVS?", implying familiarity with Git and dislike towards learning a different tool.
I'd refrain from using this person as any indication on what's happening in FreeBSD - he's known to be openly hostile against FreeBSD and making many repetitive false statements about it, after feeling hurt by the project rejecting his low quality and poorly written 'security' patches.
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.
Very recently (last few days) the FreeBSD project formed an internal group with a task of reevaluating, planning and testing the migration from SVN to Git.
Changing from CVS to something else would mean updating a lot of documentation ... which perhaps is an example of a downside to the BSD way of doing things (the way things are built from source I mean, actually having documentation is good).
> You can end up with poorly written code generated by unqualified people that addresses short term business needs.
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.
I think that the GPL did contribute in a major way to Linux’ success, but for different reasons.
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.
OpenBSD is a sum of its parts. The individual differences between it and Linux seem minute, but together they provide such a remarkably saner experience. I can't imagine using anything else these days.
So for someone who used * linux as main OS for 6 years (and now macOS for 10 years), as well as * linux for servers for just as long, what’s the best way to get started with OpenBSD for servers?
Been eying it for a while, but never gotten started.
This gentleman -> https://twitter.com/romanzolotarev is very passionate about OpenBSD and has some handy guides on his site. A good read and interesting to follow.
Any cloud VPS service that provides ISO upload will allow you to use OpenBSD. Vultr has OpenBSD 6.4 and 6.5 images pre-configured that you can get installed on a VPS (I’m using a $3.50/mo one).
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.
If you stick to a tried and true linux release, like OpenSuse, you can have this in Linux. I get excellent hardware support, zypper package management, and an excellent KDE environment.
You can certainly get the it-just-works with a big fat desktop environment like KDE, but if you don’t want that (I personally don’t like it that way), OpenBSD with a plain window manager Just Works better than the equivalent with Linux.
And related to this, how's the multi threading story? Once upon a time the folklore was that Linux was doing well, FreeBSD was also good, but the other BSDs were lagging.
I’m no expert on the internals, but with an appropriately configured set of resource limits for your user class, OpenBSD is not much slower than Linux for multithreaded tasks like web browsing. I think they disabled hyperthreading by default for security but I don’t have a device with those capabilities anyway. Firefox spawns many threads on all four cores of my desktop machine and performance is plenty good.
Yes, but I’m not sure if we’re talking about hardware “threads”, the OS concept of a “thread”, or what Firefox calls a “thread”. Maybe someone who knows more about what they’re talking about could clear it up?
This is, unfortunately, not a very good argument in favor of OpenBSD. It all boils down to this one bit near the bottom of the post:
"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?"
Speaking of "better", the author mentioned that his laptop works less from battery in OpenBSD than on Linux (3.5 hours vs 5 hours) and applications run slower. Unless there is a problem with OpenBSD drivers or CPU governing profiles, for me it means "worse" actually.
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.
Are you arguing in favour of MAC-frameworks or capability-based kernels?
Because if you'd like MAC both Linux and OpenBSD have them. The post mentions the unveil[1] syscall, Linux has the Security Modules[2].
If you'd like capability-based kernels instead, then you're wishing for Zircon[3] to get traction.
I use containers on my development machine to limit the damage that can be done when I fall victim to malware stuffed into development package. Surely it will not stop a targeted attack. But a generic malware does not bother yet to try to escape from containers. So it does give some protection.
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.
> 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.
docker sounds like a show stopper if you need it for work.
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."
The user experience of docker-via-VM on the BSDs (well, FreeBSD at least) is really sub-par compared to Macs or Windows, and all three are pretty rough in some areas compared to native linux.
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.
"Size of stripped daemon binary in default configuration on Linux x86-64"
chrony: 210 KB
openntpd: 87 KB
I admit to feeling a little amusement at the complete horror expressed by timekeeping geeks when they discover how openntpd handles leap seconds. It doesn't and the developers don't care. The time just slews to the new time at no particular rate. Openntpd ends up being a political protest against the insanity of leap seconds...
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.
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.
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.
> Why not fault Linux for not having the same interfaces as the BSD tools? The BSD ones were there first.
>> 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.
Are there some good examples comparing man pages on OpenBSD and man pages on Linux where the former is clearly better? Are we talking about man pages for end-user applications rather than, say, for system calls?
And can these differences be resolved with some copy & paste so they are both up to standard?
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.
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.
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.
It’s slightly disingenuous of you to compare the GNU man page to the OpenBSD man page, since while the OpenBSD man page is the official documentation, the GNU man page is not. As clearly stated in the GNU man page for tar: “This manpage is a short description of GNU tar. For a detailed discussion, including examples and usage recommendations, refer to the GNU Tar Manual […]”, and it gives a link to it: https://www.gnu.org/software/tar/manual/tar.html#SEC1
If you had compared the OpenBSD man page to that, it would be a more fair comparison.
“Disingenous” suggests malice. That is both unkind and untrue. I had simply forgotten.
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.
Seems that OpenBSD folks understand what the page in manpage means. Too bad they do not have something similar to info for full manuals (yes, you hate the default GNU info viewer, i know, my point is about the hypertext format with indexing and working as an ebook file that takes advantage of the fact that computers are interactive and does not try to simulate dead trees).
OpenBSD manpages are written in a semantic format, -mdoc, that readily converts to HTML with inter‐ and intra‐document hyperlinks, and facilitates searching and hyperlinking even from within the terminal (via more(1)’s tags support).
I know, but writing a coherent manual is a different task than writing a short reference page, especially if you want to include more content than just a reference (e.g. user guides or tutorial sections) and writing text that assumes inline hyperlinking is always available.
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).
You're talking about the grossly-misnamed (since large portions of it do not contain any questions) OpenBSD FAQ, which is where guide and tutorial stuff is to be found.
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.
I'm not talking about any specific guides or manuals, but yes the OpenBSD FAQ, FreeBSD Handbook, etc are the sort of manuals i am talking about. But those are not made in manpage format and at least the OpenBSD FAQ HTML pages seem to be edited by hand. And since those are in HTML (at least the OpenBSD one, i didn't look into the others) they lack the indexing and ebook-like reading features that something like info provides (e.g. there are no browsing links - there used to be a pseudostandard with special <link> tags, but it was only ever supported by classic Mozilla/SeaMonkey and it never caught on).
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).
Since I got frustrated with linux man pages a lot, I am glad to see OpenBSD does it different. (one of the reasons why I finally want to give it a try)
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"
Good examples are critical. Examples are not a substitute for a thorough explanation, but they can make utilities so much easier to understand. If you're writing technical documentation, please include some examples starting with the simplest use cases.
I don't know anyone who relies on man pages for Linux. I know a lot of people who use man pages almost exclusively for OpenBSD.
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.
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.
How do you define "actual UNIX OS" vs. "UNIX-like"?
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".
z/OS Unix is interesting, it feels kind of like the Windows Subsystem for Linux.
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.
I wonder what the future for UNIX System Services will be, given the introduction of z/OS Container Extensions (zCX)?
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.)
The main page https://www.openbsd.org/ describes OpenBSD as UNIX-like. If OpenBSD is UNIX, it’s in the ship of Theseus sense: the outcome of the BSDi lawsuit demonstrated that almost the whole operating system had in fact been rewritten by that time.
That itself is not a significant difference. I think *BSDs are great because they have a saner design (man hier for example) and in many regards superior software, like pf. The do not have the millions of dollars spent on development though, meaning less features and less available guides, help online etc.
Less available guides is not bad in itself. It also means less bullshit and bad advice. Because of Linux's prevalence for instance, I can't easily find a technologic-neutral guide to build my own mail server on FreeBSD.
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.
Kudos to Linux distributions that make user-friendly installers, windows-like/mac-like UIs and otherwise paper over Linux to make it mainstream-ready. Anything to get people onto arguably safer operating systems than Windows is to be lauded.
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.
Theo, commenting on OpenBSD’s attempted move from GCC to the BSD‐licensed PCC:
> 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.)
I don't see that as hostile. I've never seen anything against including GPL programs/utilities in OpenBSD.
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".
An example would be that when a member of the Free Software community asked for clarifications on the OpenBSD mailing list, because someone had recommended the OpenBSD distribution to them, the response produced gems such as:
"you are a power-misusing hypocritical liar"
"you are being the usual slimy hypocritical asshole"
Looks like the article assumes the use case of a developer's laptop/desktop machine.
I've used Win/Linux before and have settled eventually with the Mac - for me it's a sane Linux for the desktop.
I'd rather see a comparison for different kinds of server workloads and purposes.
I'd actually like to use OpenBSD, but then I have to use Airplay with Apple TVs every day, itunes for the tablet/phone, photoshop, illustrator, nvidia graphics cards and CUDA, Docker, etc.
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.