Invented by OpenBSD(tedunangst.com)
tedunangst.com
Invented by OpenBSD
http://www.tedunangst.com/flak/post/invented-by-openbsd
10 comments
I've never understood why anyone wouldn't just use OpenBSD if you're going to use a BSD. I'm sure there are reasons, there must be, but OpenBSD has a long history of having really great source code that's useful just about everywhere (hint: you're using OpenSSH almost assuredly on every linux box ever, and it's fantastic). To me, as a developer I get the whole NIH thing. I really do. I just don't get why you'd choose "here" to be somewhere that doesn't include all the amenities in the first place.
Some main differences:
- LLVM/Clang (it's a matter of taste, but it's also the feature :-) )
- FreeBSD Jails and Mac (These are extremely strong security features if implemented correctly. Especially jails are really undervalued/misunderstood IMHO.)
- State-of-art network stack (faster than any other BSD or Linux. Supports technologies like NetMap)
- ZFS support (important for both desktops/servers)
- PF version runs on multiple cpus (OpenBSD's version is more advanced though)
- DTrace (although not mature enough IMHO)
- Better hardware support (e.g. wifi cards)
- BHyve (virtualisation)
- Capsicum (security)
Other little things like:
- Unmapped VMIO buffers - Variable symlinks (used under jails)
Now generally speaking, choosing an operating system due to bigotry and what-not is stupid. Most of the times, engineers go with what they need: If you need a secure bastion, OpenBSD gives you more although FreeBSD can be turned virtually impenetrable as can Linux. OpenBSD comes with more bells and whistles on this particular area though.
So all in all, it boils to what you need. The major reason why people choose FreeBSD over OpenBSD is because the 'security level' of the OS is more than acceptable while retaining a much better hardware support.
- LLVM/Clang (it's a matter of taste, but it's also the feature :-) )
- FreeBSD Jails and Mac (These are extremely strong security features if implemented correctly. Especially jails are really undervalued/misunderstood IMHO.)
- State-of-art network stack (faster than any other BSD or Linux. Supports technologies like NetMap)
- ZFS support (important for both desktops/servers)
- PF version runs on multiple cpus (OpenBSD's version is more advanced though)
- DTrace (although not mature enough IMHO)
- Better hardware support (e.g. wifi cards)
- BHyve (virtualisation)
- Capsicum (security)
Other little things like:
- Unmapped VMIO buffers - Variable symlinks (used under jails)
Now generally speaking, choosing an operating system due to bigotry and what-not is stupid. Most of the times, engineers go with what they need: If you need a secure bastion, OpenBSD gives you more although FreeBSD can be turned virtually impenetrable as can Linux. OpenBSD comes with more bells and whistles on this particular area though.
So all in all, it boils to what you need. The major reason why people choose FreeBSD over OpenBSD is because the 'security level' of the OS is more than acceptable while retaining a much better hardware support.
Don't forget that only FreeBSD has the nVidia binary drivers, too. (Neither have nouveau anymore.) So if you have such a card, OpenBSD defaults to the "nv" driver, which somehow manages to be about 20x slower than the VESA driver, before MTRR write-combine tweaking (side tangent: OpenBSD also lacks an MTRR tweaking tool, like memcontrol.) Moving a window literally locks up your desktop for 30-90 seconds as you see it slowly redrawing its way along. How they managed that one I will never know, but they did.
I'm all for open source all the way, especially on a secure system, but OpenBSD+nVidia is basically unusable on the desktop. And that's a huge class of systems. You can't buy Intel PCIe cards; and AMD drivers are always a buggy mess.
> PF version runs on multiple cpus (OpenBSD's version is more advanced though)
I really hate the trade-off of FreeBSD SMP support, or OpenBSD queuing support. (yes, you can compile a FreeBSD kernel with ALTQ, but it's said to be buggy with SMP.)
I'm all for open source all the way, especially on a secure system, but OpenBSD+nVidia is basically unusable on the desktop. And that's a huge class of systems. You can't buy Intel PCIe cards; and AMD drivers are always a buggy mess.
> PF version runs on multiple cpus (OpenBSD's version is more advanced though)
I really hate the trade-off of FreeBSD SMP support, or OpenBSD queuing support. (yes, you can compile a FreeBSD kernel with ALTQ, but it's said to be buggy with SMP.)
> PF version runs on multiple cpus (OpenBSD's version is more advanced though)
What is "more advanced" about it?
> (yes, you can compile a FreeBSD kernel with ALTQ, but it's said to be buggy with SMP.)
not that we've seen in 300,000 installs.
What is "more advanced" about it?
> (yes, you can compile a FreeBSD kernel with ALTQ, but it's said to be buggy with SMP.)
not that we've seen in 300,000 installs.
I will admit to not having tried it. This is what I read when I was researching why it wasn't enabled by default.
Any thoughts on why they leave it off out of the box, then? I know it's not crazy hard to build a kernel (used to have to do it to get sound support in the 4.x series), but I'd rather not build kernels if I don't have to =)
Any thoughts on why they leave it off out of the box, then? I know it's not crazy hard to build a kernel (used to have to do it to get sound support in the 4.x series), but I'd rather not build kernels if I don't have to =)
ATLQ slows down throughput and ads CPU overhead, that's why is disabled by default... Because most users don't need it anyway.
dmm(3)
Can't argue with that, although:
> - FreeBSD Jails and Mac (These are extremely strong security features if implemented correctly. Especially jails are really undervalued/misunderstood IMHO.)
Aren't these are only necessary if you let people you don't trust into your system?
> - PF version runs on multiple cpus (OpenBSD's version is more advanced though)
Personally I dislike running PF on FreeBSD as it requires me to resort to old docs and use old syntaxes.
> - Capsicum (security)
Isn't this being ported as we speak?
> - FreeBSD Jails and Mac (These are extremely strong security features if implemented correctly. Especially jails are really undervalued/misunderstood IMHO.)
Aren't these are only necessary if you let people you don't trust into your system?
> - PF version runs on multiple cpus (OpenBSD's version is more advanced though)
Personally I dislike running PF on FreeBSD as it requires me to resort to old docs and use old syntaxes.
> - Capsicum (security)
Isn't this being ported as we speak?
Jails also have resource limits, so you can have a group of processes that are related, but not started from the same executable, be held to a certain amount of CPU, memory, etc usage. They're also useful in testing/debug situations; coupled with ZFS' copy on write features, they let you quickly create identical environments which can be real helpful in trouble isolation.
Jails provide some protection to the base OS even if the network exposed service running in the jail is compromised. It for much more than local exploits.
> Aren't these are only necessary if you let people you don't trust into your system?
They also provide an additional layer of protection if you're running server software which gets exploited.
They also provide an additional layer of protection if you're running server software which gets exploited.
Also, and this is perhaps weird to non-users, but true, FreeBSD has a well supported base AMI in AWS EC2. It's an edge case, but it's a big reason I rely on FreeBSD over OpenBSD.
you're right on quite a few things, but bhyve is no where near production quality -- alpha at best. and openbsd has a wider and stronger support of wifi cards.
Does FreeBSD have system-wide ASLR nowadays?
I think FreeBSD 11 will have it. See this - http://www.bsdcan.org/2014/schedule/attachments/259_introduc...
> - BHyve (virtualisation)
For me, not being able to run a current kernel-accelerated qemu is a real problem. Is there anything preventing this work from being done, or is it just a matter of bhyve having the momentum so nobody's bothering?
For me, not being able to run a current kernel-accelerated qemu is a real problem. Is there anything preventing this work from being done, or is it just a matter of bhyve having the momentum so nobody's bothering?
> - DTrace (although not mature enough IMHO)
Can you be more specific about that comment?
Can you be more specific about that comment?
Because it's kernel-side SMP support is basically from the 80s
Because getting commercial support for it is hard
Because getting drivers for it is hard
Because ..
Lots of reasons, nothing to do with feel-good or whatever else. OpenBSD's focus on security is commendable, but it's not the only reason you'd pick an operating system.
Because getting commercial support for it is hard
Because getting drivers for it is hard
Because ..
Lots of reasons, nothing to do with feel-good or whatever else. OpenBSD's focus on security is commendable, but it's not the only reason you'd pick an operating system.
I use OpenBSD for most everything, but I do use FreeBSD for our file servers just because of ZFS. I will probably look at DragonFly BSD once HAMMER2 is done. If someone ports HAMMER2 over to OpenBSD (one can dream), then I am probably back to one chosen OS[1].
I have found OpenBSD to be pretty easy to install and I really prefer the hier over FreeBSD's.
1) This does not include the obvious "must run on" for certain software packages. We have Windows Server, OS X, Red Hat, and an AS/400 (iSeries) because of vendor / government requirements.
I have found OpenBSD to be pretty easy to install and I really prefer the hier over FreeBSD's.
1) This does not include the obvious "must run on" for certain software packages. We have Windows Server, OS X, Red Hat, and an AS/400 (iSeries) because of vendor / government requirements.
OpenBSD is the secure one, FreeBSD is the fast/featureful one (outside of security anyway) and NetBSD is the portable/ported one.
You forgot DragonflyBSD with its HAMMER filesystem, virtual kernels, etc.
Can DragonflyBSD be good for using it as a desktop for programming and such? I've tried to google if BSD OSs are good for that purpose, but it seems like they might be better suited as servers and such, and you're better off using something like Linux for programming. Do you have an opinion on that?
Basically FreeBSD and NetBSD are better as long as you don't connect them to Internet.
In particular FreeBSD security is so abysmal, once you plug it to the internet you can't really say is your computer anymore.
Edit: Downvote this: Windows Vista had ASLR and latest FreeBSD 10 does not.
In particular FreeBSD security is so abysmal, once you plug it to the internet you can't really say is your computer anymore.
Edit: Downvote this: Windows Vista had ASLR and latest FreeBSD 10 does not.
Yes, it's impossible to hack an OS if it has ASLR /s
OpenBSD has the most secure marketing message of all the BSDs. It begins and ends there. Stop banging drums, fanboys.
edit: why can't we all just get along?
OpenBSD has the most secure marketing message of all the BSDs. It begins and ends there. Stop banging drums, fanboys.
edit: why can't we all just get along?
Extraordinary claims require extraordinary proof. Where is yours?
Check any CTF or hacking contest (like Defcon CTF) They use FreeBSD as a playground.
The last time I saw FreeBSD used in a CTF, it was FreeBSD 6, back in the Kenshoto days. FreeBSD has come a long way since then.
Nowadays, other than the odd ARM problem, or esoteric reversing challenge, everything is Linux. It doesn't matter anyway, though, since CTFs are designed with the express purpose of being insecure.
I'm as big a fan of OpenBSD as anyone, but there's no reason someone couldn't intentionally cripple OpenBSD to use as a platform for CTFs.
Nowadays, other than the odd ARM problem, or esoteric reversing challenge, everything is Linux. It doesn't matter anyway, though, since CTFs are designed with the express purpose of being insecure.
I'm as big a fan of OpenBSD as anyone, but there's no reason someone couldn't intentionally cripple OpenBSD to use as a platform for CTFs.
I've only been playing CTFs for 2 years (iCTF 2013), but I don't think I've seen FreeBSD there once. In my experience, it's 99% Linux, with some occasional Windows and Android. Then there was last ruCTFe making a point of using some more obscure systems - Minix, OpenIndiana, etc.
The team that won the Collegiate Cyber Defense Nationals last year did so with a firewall based on freebsd (pfSense).
https://hackucf.org/blog/pfsense-at-hackucf/
https://hackucf.org/blog/pfsense-at-hackucf/
[deleted]
I use FreeBSD for two reasons:
1. The documentation is unmatched.
2. The community is very nice.
I don't know if 1 applies to OpenBSD or not, but 2 doesn't.
1. The documentation is unmatched.
2. The community is very nice.
I don't know if 1 applies to OpenBSD or not, but 2 doesn't.
I'd definitely be using it if there were a modern GHC port. Sticking with linux until I can see if I can get dragonfly working on my laptop. Man I want HAMMER.
1) Ports are difficult to come by. Furthermore, installing ports kind of destroys the black security box an openssl install implies.
2) Non-security updates are slow.
3) The mailing list is hostile.
Furthermore, netbsd and freebsd offer substantial improvements: netbsd will run on anything, freebsd will offer you some pretty ridiculous tools and a huge base of ports and support.
Furthermore, netbsd and freebsd offer substantial improvements: netbsd will run on anything, freebsd will offer you some pretty ridiculous tools and a huge base of ports and support.
Running a FreeBSD machine for various services (otherwise I'm a Windows dev by day, Linux guy during the night). Why?
When I - not quite a year ago - looked into possible setups for this thing I found pkg-ng (and poudriere) both a lot more comfortable and familiar. More powerful. Sold.
When I - not quite a year ago - looked into possible setups for this thing I found pkg-ng (and poudriere) both a lot more comfortable and familiar. More powerful. Sold.
If you need the ability to run 32-bit binaries on an amd64 install or have Linux binary compatibility, FreeBSD has options to provide these while OpenBSD does not.
I run OpenBSD on one of my laptops, but if performance or compatibility are important factors, you might look at other tools for the job -- the different BSDs have different strengths.
I run OpenBSD on one of my laptops, but if performance or compatibility are important factors, you might look at other tools for the job -- the different BSDs have different strengths.
OpenBSD focuses on security.
NetBSD focuses on engineering and architecture.
Having used both, I'd say the security focus of OpenBSD means it's often lacking consistency and "polish". NetBSD's focus on engineering means it's consistent, clean, etc.
What other operating system has a build.sh?
https://www.netbsd.org/docs/guide/en/chap-build.html
You can build identical binaries for NetBSD on any *NIX host OS. That's impressive.
NetBSD focuses on engineering and architecture.
Having used both, I'd say the security focus of OpenBSD means it's often lacking consistency and "polish". NetBSD's focus on engineering means it's consistent, clean, etc.
What other operating system has a build.sh?
https://www.netbsd.org/docs/guide/en/chap-build.html
You can build identical binaries for NetBSD on any *NIX host OS. That's impressive.
Having once been a close follower of OpenBSD, I eventually just kind of lost interest because Linux (and other BSDs) were just moving so much faster on features that mattered more to me. Multiprocessor support was the big one for me at the time; I have no idea where that currently stands.
My recollection was that OpenBSD code was actually quite polished, and even elegant in lots of places. They also produced what I think were easily the best and most complete manpages out there. It was actually enjoyable to read both the code and manpages, and pretty easy to understand (assuming proficiency in C and basic machine architecture, of course).
What was not enjoyable, for me, was the constant hostility on the mailing list and frequent lashing out at others in various OSS communities (...as demonstrated in the OP). I know there there were others for whom that played no small part in their loss of interest in the project.
My recollection was that OpenBSD code was actually quite polished, and even elegant in lots of places. They also produced what I think were easily the best and most complete manpages out there. It was actually enjoyable to read both the code and manpages, and pretty easy to understand (assuming proficiency in C and basic machine architecture, of course).
What was not enjoyable, for me, was the constant hostility on the mailing list and frequent lashing out at others in various OSS communities (...as demonstrated in the OP). I know there there were others for whom that played no small part in their loss of interest in the project.
> Having used both, I'd say the security focus of OpenBSD means it's often lacking consistency and "polish".
I wonder why you think so. I've only ever used OpenBSD and NetBSD on PCs and Unix workstations. I have never, ever, in any domain found NetBSD to have more "polish" than OpenBSD.
From the initial installation where OpenBSD helps you with everything and NetBSD, well, doesn't, to reading and using documentation (OpenBSD's man pages are the best around, with the possible oddball exception of some old Open Group pages which include code examples), OpenBSD seems to be miles ahead.
So I just wonder what you're talking about specifically.
I wonder why you think so. I've only ever used OpenBSD and NetBSD on PCs and Unix workstations. I have never, ever, in any domain found NetBSD to have more "polish" than OpenBSD.
From the initial installation where OpenBSD helps you with everything and NetBSD, well, doesn't, to reading and using documentation (OpenBSD's man pages are the best around, with the possible oddball exception of some old Open Group pages which include code examples), OpenBSD seems to be miles ahead.
So I just wonder what you're talking about specifically.
[deleted]
ssh has persistently gotten more and more annoying to use over the years especially with it's non-sensical error messages when it's checking file permissions.
It is simply bad design to keep adding un-toggleable "security" mechanisms, like being unable to directly script password logins and the like.
It is simply bad design to keep adding un-toggleable "security" mechanisms, like being unable to directly script password logins and the like.
Why would you ever script password logons? You should be using key-based authentication...
Someone hands me a list of servers, user accounts and passwords to get a bunch of files from.
This is a standard task which comes up all the damn time in any level of sysadmin work. I'm never going to connect to these machines again, and can't get anyone to cooperate about them. Which means, I'm going to need to feed that list to ssh or rsync with password authentication.
Your current options to do this are jump through ridiculous hoops with expect, or switch to something else entirely (like paramiko, which is awesome but doesn't solve the rsync case cleanly).
Yet all this could be solved by just having a damn --read-password-from prompt which would do it automatically. It would also be nice to have --skip-permissions-checks (and actual error messages which specified which permissions, on what file, are missing rather then current silent failure).
Which I think I'm going to code up for the next time I end up doing something like this (probably alongside "use JSON for remote rsync file specifications").
This is a standard task which comes up all the damn time in any level of sysadmin work. I'm never going to connect to these machines again, and can't get anyone to cooperate about them. Which means, I'm going to need to feed that list to ssh or rsync with password authentication.
Your current options to do this are jump through ridiculous hoops with expect, or switch to something else entirely (like paramiko, which is awesome but doesn't solve the rsync case cleanly).
Yet all this could be solved by just having a damn --read-password-from prompt which would do it automatically. It would also be nice to have --skip-permissions-checks (and actual error messages which specified which permissions, on what file, are missing rather then current silent failure).
Which I think I'm going to code up for the next time I end up doing something like this (probably alongside "use JSON for remote rsync file specifications").
> Having used both, I'd say the security focus of OpenBSD means it's often lacking consistency and "polish". NetBSD's focus on engineering means it's consistent, clean, etc.
Having seen NetBSD's source code more than once, "clean" is not exactly the thought that always comes to mind. Au contraire, OpenBSD has a simplicity-driven approach that's one of the cornerstones of most of the awesome stuff that they achieved.
That being said, NetBSD's build system is very good. OpenBSD's doesn't help too much in the portability department.
Having seen NetBSD's source code more than once, "clean" is not exactly the thought that always comes to mind. Au contraire, OpenBSD has a simplicity-driven approach that's one of the cornerstones of most of the awesome stuff that they achieved.
That being said, NetBSD's build system is very good. OpenBSD's doesn't help too much in the portability department.
Would you mind giving a few examples where OpenBSD is lacking consistency or polish?
I was a huge NetBSD fan for many years, but I moved to OpenBSD about 6-7 years ago because I felt it actually had more consistency and polish. It's been so long now though that I don't remember specifics.
I was a huge NetBSD fan for many years, but I moved to OpenBSD about 6-7 years ago because I felt it actually had more consistency and polish. It's been so long now though that I don't remember specifics.
I'd be interested in some elaboration on that point of security vs. engineering and architecture.
Form what little I've seen of the OpenBSD folks, having sound engineering and architecture is exactly how they attack security.
Form what little I've seen of the OpenBSD folks, having sound engineering and architecture is exactly how they attack security.
"[NetBSD's] reallocarray was [just] fixed to behave like OpenBSD. Now it’s a 13 line replacement for a 10 line function. But at least it doesn’t have any code written by an OpenBSD developer."
The post on executable memory is a hundred times more interesting than this: http://www.tedunangst.com/flak/post/now-or-never-exec
The article missed:
1) W^X protections
2) ASLR
3) Stack canaries
4) strlcpy
5) OpenSSH!
6) Heap guard pages
7) Software NX
8) Etc.
Maybe project PAX invented some of those, but massive deployment was in OpenBSD first. Well if you can call them massive..
1) W^X protections
2) ASLR
3) Stack canaries
4) strlcpy
5) OpenSSH!
6) Heap guard pages
7) Software NX
8) Etc.
Maybe project PAX invented some of those, but massive deployment was in OpenBSD first. Well if you can call them massive..
OpenSSH is a fork of the original SSHv1 written by a Finnish guy.
Because the license changed and said guy started expecting to be able to extort money out of people.
While the OpenBSD guys can be obnoxious twats at times, they were definitely in the right when they forked the OpenSSH code.
While the OpenBSD guys can be obnoxious twats at times, they were definitely in the right when they forked the OpenSSH code.
Actually someone else forked the code, and openbsd forked that because they wanted to rush out a release.
http://www.openssh.com/history.html
http://www.openssh.com/history.html
The changes introduced are potentially extremely damaging. Take for example:
https://github.com/libressl-portable/openbsd/search?utf8=%E2...
https://github.com/libressl-portable/openbsd/search?utf8=%E2...
What's damaging about reallocarray?
Did you read the article?
NetBSD's implementation, specifically with regard to how it handles deallocation, diverges from OpenBSDs - though its documentation is wrong.
LibreSSL (for example) will compile just fine on NetBSD, but as the logic of the two implementations differ so too will correct memory management in LibreSSL. This is just one example of how a port of secure code can be made insecure.
So it doesn't have to do with reallocarray specifically. It has to do with drawing out the security implications of the article under discussion.
NetBSD's implementation, specifically with regard to how it handles deallocation, diverges from OpenBSDs - though its documentation is wrong.
LibreSSL (for example) will compile just fine on NetBSD, but as the logic of the two implementations differ so too will correct memory management in LibreSSL. This is just one example of how a port of secure code can be made insecure.
So it doesn't have to do with reallocarray specifically. It has to do with drawing out the security implications of the article under discussion.
NetBSD's strtoi and strtoimax seem like the better alternative to strtonum.
1. It is defined for intmax_t instead of long long.
2. It supports various bases. (At least I regularly need hex or base36)
3. It can deal with trailing characters.
4. There are matching strtou and strtoumax operations
It's of course bad if NetBSD introduces an strtonum, which behaves differently from the OpenBSD one. But maybe the OpenBSD folks should look into strtoi and strtoimax instead of blindly following their "invented here" principle...
1. It is defined for intmax_t instead of long long.
2. It supports various bases. (At least I regularly need hex or base36)
3. It can deal with trailing characters.
4. There are matching strtou and strtoumax operations
It's of course bad if NetBSD introduces an strtonum, which behaves differently from the OpenBSD one. But maybe the OpenBSD folks should look into strtoi and strtoimax instead of blindly following their "invented here" principle...
That's basically all mentioned in his post about the design [1] from 2011 and he seems to dismiss all these cases.
Is that reasonable? No clue, I don't write/know/do C..
1: http://www.tedunangst.com/flak/post/the-design-of-strtonum
Is that reasonable? No clue, I don't write/know/do C..
1: http://www.tedunangst.com/flak/post/the-design-of-strtonum
I don't think it's reasonable. The way they implemented strtonum might match their particular use case in OpenSSH/LibreSSL. But if they want to make it a libc function and popularise it then they should concern themselves with other use cases and opinions, especially when they pick a bold name as strtonum. It's not a surprising outcome that others are reluctant to follow them and they have clashes in behaviour or naming.
Why do people use NetBSD over OpenBSD? Serious question.
Besides portability, NetBSD does have a lot of attractive technical features, including a cross-platform source-based packaging system, the rump kernel concept where drivers can be run in both monolithic and microkernel-esque fashions, an extensive kernel-level authorization system through kauth(9), a very intelligently designed driver framework with lots of low-level components abstracted into machine-independent interfaces (which OpenBSD and FreeBSD later integrated themselves), and so on.
NetBSD has also been the first to introduce new features like reforming the rc boot scripts into the more modern rc.d system.
Lots of people (esp. Linux users) have this impression that all Unix-likes besides Linux are hulking dinosaurs stuck in the old ages, but this couldn't be further from the truth.
NetBSD has also been the first to introduce new features like reforming the rc boot scripts into the more modern rc.d system.
Lots of people (esp. Linux users) have this impression that all Unix-likes besides Linux are hulking dinosaurs stuck in the old ages, but this couldn't be further from the truth.
Performance for one. OpenBSD's awesome security features do come at a cost regarding speed. Feature sets is another; NetBSD has some features, like Rump Kernels [1], which OpenBSD doesn't have, and has shown some hostility to in the past. Like any architecture decision, it comes down to researching who has the best solution set for your problem and working from there.
[1] http://rumpkernel.org/
[1] http://rumpkernel.org/
NetBSD supports many more platforms and architectures than OpenBSD (I ran NetBSD on MIPS and 68k years ago).
NetBSD can be used as a rump kernel: http://wiki.netbsd.org/rumpkernel/
NetBSD is normally the first choice for embedded products in the BSD family, I'm aware of some large companies used NetBSD in their routers and printers.
Also worth noting that NetBSD can run Xen dom0.
FreeBSD may have that by FreeBSD 11
And related, why do people choose *BSD over Linux? (I'm genuinely interested, and not trying to start a flame war). I've used both OpenBSD and Linux on my personal computers, but only Linux for servers (mainly due to ease of setup). My understanding is that Linux has marginally better performance than any of the BSDs.
I initially went back to it over the way systemd was handled on Linux. Nowadays, I've really grown to appreciate the minimalism and the slower, more thorough pace of advancements. I find that being too cutting edge just tends to lead to more problems in production. I also really like the development model, and most design differences I read about (one quick example: /dev/random behavior) more in the BSDs. Lastly, lots of features I like a lot more. ZFS over btrfs, pf over iptables, etc.
I always heard good things about the BSD's and I was forced to use pf in my previous company..
but it was systemd that pushed me towards it, I'm not bound by random binaries that do random things with little documentation- everything is very clearly understandable and I can even guess what things will be doing with a large degree of accuracy.
the whole thing seems much more "sane", but- Linux is a better desktop in my opinion.
but it was systemd that pushed me towards it, I'm not bound by random binaries that do random things with little documentation- everything is very clearly understandable and I can even guess what things will be doing with a large degree of accuracy.
the whole thing seems much more "sane", but- Linux is a better desktop in my opinion.
I choose BSD (as a router/firewall) because pf is more intuitive than iptables and tc. Go check out some manpages for tc and it's extended functionalities... awful documentation. I still use Linux as my desktop OS though.
ZFS and Dtrace. Full stop.
And I got completely tired of "distributionitis" on Linux--"Oh, you can't upgrade that particular package without upgrading every other package on the system."
And I got completely tired of "distributionitis" on Linux--"Oh, you can't upgrade that particular package without upgrading every other package on the system."
well, FreeBSD is like that too...
If you understand the potential consequences you can do what you wish with the ports tree as an advanced user.
pkg upgrade apache22
If you understand the potential consequences you can do what you wish with the ports tree as an advanced user.
I would have picked OpenBSD over Linux for our production environment, if we didn't need the additional performance.
Modern Linux distros are messy and complex. I'm sure it's for good reason, they provider a ton of feature and tools for running very large installations. I just don't need that, we don't have more servers than you could reasonably manage manually.
I miss the consistency and simplicity of OpenBSD every time I log into one of our servers.
Modern Linux distros are messy and complex. I'm sure it's for good reason, they provider a ton of feature and tools for running very large installations. I just don't need that, we don't have more servers than you could reasonably manage manually.
I miss the consistency and simplicity of OpenBSD every time I log into one of our servers.
OpenBSD does a damn good job as a stand in for crazily priced network equipment. Being able to run redundant firewalls with fail-over firewall state, IPSEC state, and IP addresses all supported natively with awesome documentation is a killer feature. I haven't had to do so in 5-6 years though, so maybe others have caught up.
I like them both and go back and forth between them. Right now, i have NetBSD installed and I am playing with Veriexec.
I don't understand how one can claim to "invent" reallocarray. Glib has had g_realloc_n() since 2010, but its not something being touted as a huge invention. Its a tiny helper. Very useful, but quite obvious.
I think the Author is saying that people often use BSD code or ideas and reimplement them to be fundamentally incompatible yet using the same name.
this means that, as a developer, when calling these functions you can't be sure of if you're calling it in a safe way.. openBSD makes code deliberately designed to be portable, and other BSD's make it non-portable by altering it in odd ways, yielding dangerous consequences by reusing the namespace.
this means that, as a developer, when calling these functions you can't be sure of if you're calling it in a safe way.. openBSD makes code deliberately designed to be portable, and other BSD's make it non-portable by altering it in odd ways, yielding dangerous consequences by reusing the namespace.
except the 0 behavior has been restored
Today. Timestamped almost right with this article. I'm sure it is correlated and not causal, but I'm also pretty sure the root cause for both is the same.
I'm not sure what your supposition about the root cause might mean.
NetBSD very recently imported these functions (reallocarray and strtonum) to libc after much objection (over several years actually) to their poor APIs, yet finding that they crop up time and again in code used in base (and then multiple copies exist, in out of the way places). So, as a pragmatic solution they are now available from libc if _OPENBSD_SOURCE is defined. Cleaner API functions were proposed, with wrappers which would provide equivalent functionality for the OpenBSD functions. Some difference was noted, and recently fixed in these wrappers.
The root cause for the NetBSD changes then, seems to be that these functions keep cropping up, and the job of libc is to provide commonly used functions.
I believe the intention is, that the cleaner API is proposed to replace the original OpenBSD ones, which are not properly portable (strtonum for instance, returns hard coded english error strings in ASCII)
The root cause for the blog entry by Ted Unangst is probably that he is an OpenBSD developer and was involved in creating these functions, which are now being criticised.
These root causes don't seem the same to me.
NetBSD very recently imported these functions (reallocarray and strtonum) to libc after much objection (over several years actually) to their poor APIs, yet finding that they crop up time and again in code used in base (and then multiple copies exist, in out of the way places). So, as a pragmatic solution they are now available from libc if _OPENBSD_SOURCE is defined. Cleaner API functions were proposed, with wrappers which would provide equivalent functionality for the OpenBSD functions. Some difference was noted, and recently fixed in these wrappers.
The root cause for the NetBSD changes then, seems to be that these functions keep cropping up, and the job of libc is to provide commonly used functions.
I believe the intention is, that the cleaner API is proposed to replace the original OpenBSD ones, which are not properly portable (strtonum for instance, returns hard coded english error strings in ASCII)
The root cause for the blog entry by Ted Unangst is probably that he is an OpenBSD developer and was involved in creating these functions, which are now being criticised.
These root causes don't seem the same to me.
Eh, I'm no conspiracy theorist nor am I supposing foul play or pithiness or anything. I'm merely noting they're likely influenced by background conversation nobody's really paying attention to but the related folks. Tech is always a small crowd of people doing things in specific areas, and I'm not dumb enough to think they don't talk or read each other's stuff or whatnot. Probably read something on a mailing list or in IRC or something, similar sparks happened, they led down the chain, then we end up here, that sort of thing.
It's not bad, just human behavior in small groups. The politics behind it aren't interesting to me, I'm just noting that it's not likely as completely quarantined from each other as they might complain, even if they don't realize such. That's totally cool with me, even if my supposition (again, unfounded even if it is how such things often occur) is completely incorrect in this particular instance. =c)
It's not bad, just human behavior in small groups. The politics behind it aren't interesting to me, I'm just noting that it's not likely as completely quarantined from each other as they might complain, even if they don't realize such. That's totally cool with me, even if my supposition (again, unfounded even if it is how such things often occur) is completely incorrect in this particular instance. =c)
You seem to have a much better understanding of the situation than I do. The remark about the hard coded error strings was interesting though, so I looked at the implementation [1].
I .. am not sure why that would be considered not portable? Admitted, I'm neither into C nor do I have experience in the field, but .. that seems to be easy to read, contains clear/concise error messages _on top_ of clear error codes.
1) Any consumer can ignore the string and map the error code to a message in Klingon or whatever else, no?
2) The function name is in ASCII/English. So are the parameter names. Most of your C code is probably reading ~somewhat~ like english, and usually is restricted to ASCII? Is it really a problem that this method returns both a well-defined number and a simple string in case of an error?
Back to the first line: I .. am certainly clueless here and just watching from the sidelines. But I'm kinda serious about the questions and genuinely curious why you object to that part of the implementation?
1: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib...
I .. am not sure why that would be considered not portable? Admitted, I'm neither into C nor do I have experience in the field, but .. that seems to be easy to read, contains clear/concise error messages _on top_ of clear error codes.
1) Any consumer can ignore the string and map the error code to a message in Klingon or whatever else, no?
2) The function name is in ASCII/English. So are the parameter names. Most of your C code is probably reading ~somewhat~ like english, and usually is restricted to ASCII? Is it really a problem that this method returns both a well-defined number and a simple string in case of an error?
Back to the first line: I .. am certainly clueless here and just watching from the sidelines. But I'm kinda serious about the questions and genuinely curious why you object to that part of the implementation?
1: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib...
for 1, the consumer is properly the user not the programmer.. and the user cannot ignore the error string in favour of the number if the programmer provided only that. Since the documentation specifies the error strings,
for 2, the function can be called (as can any C function) from a source character set other than ASCII, as the compiler should handle that. The name is technically english its true and programmer needs to know some english, perhaps.. but the user does not need to know that
if the error code is used, then the error string is superfluous, and C library functions are not in the habit of providing superfluous information. C is pretty low level after all.
Here is more reading about the objections the NetBSD folk had with strtonum(3)
for 2, the function can be called (as can any C function) from a source character set other than ASCII, as the compiler should handle that. The name is technically english its true and programmer needs to know some english, perhaps.. but the user does not need to know that
if the error code is used, then the error string is superfluous, and C library functions are not in the habit of providing superfluous information. C is pretty low level after all.
Here is more reading about the objections the NetBSD folk had with strtonum(3)
http://mailing.netbsd.tech.userlevel.narkive.com/mZ37nlai/strtonum-3-from-openbsdStill confused.
What is a user in your reply? I mean, an end user / my mom isn't going to call strtonum? Some developer does. And said developer can absolutely ignore the string's content?
Test for success: errno is 0, errstrp is NULL Handle error: Use errno or errstrp - the latter gives you a bit more information (reports a different error for invalid ranges, too small vs. too large).
But if you don't care, errno is fine, no? And we're still talking about the programmer here, as far as I'm concerned.
Ted has a description of his intentions here [1]. I guess I'm confused why there's a fuzz about it, because technically this method should be good enough? I do have to shake my head at the "Even if intmax_t probably would have been a better choice, I think we’re sticking with long long just because it frustrates people unwilling to admit it doesn’t make a difference." remark, but .. other than that? Does it .. matter?
1: http://www.tedunangst.com/flak/post/the-design-of-strtonum
What is a user in your reply? I mean, an end user / my mom isn't going to call strtonum? Some developer does. And said developer can absolutely ignore the string's content?
Test for success: errno is 0, errstrp is NULL Handle error: Use errno or errstrp - the latter gives you a bit more information (reports a different error for invalid ranges, too small vs. too large).
But if you don't care, errno is fine, no? And we're still talking about the programmer here, as far as I'm concerned.
Ted has a description of his intentions here [1]. I guess I'm confused why there's a fuzz about it, because technically this method should be good enough? I do have to shake my head at the "Even if intmax_t probably would have been a better choice, I think we’re sticking with long long just because it frustrates people unwilling to admit it doesn’t make a difference." remark, but .. other than that? Does it .. matter?
1: http://www.tedunangst.com/flak/post/the-design-of-strtonum
Yes, the user is the person who runs the program that they didn't write. They don't know that they called strtonum()
testing for errno == 0 is not actually useful, since errno is not set except on error (that is by design of errno, it is always an indication of what the last error was, not that there was an error)
and errstrp doesn't give the Klingon user you mentioned any information at all, since they can't read English.
fafner said it better than I in https://news.ycombinator.com/item?id=9184734
and yes it does matter, for a standard libc function, because if you don't take care about setting standards, then your standards will be a mess.
testing for errno == 0 is not actually useful, since errno is not set except on error (that is by design of errno, it is always an indication of what the last error was, not that there was an error)
and errstrp doesn't give the Klingon user you mentioned any information at all, since they can't read English.
fafner said it better than I in https://news.ycombinator.com/item?id=9184734
and yes it does matter, for a standard libc function, because if you don't take care about setting standards, then your standards will be a mess.