5 ms·

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

by adekok 12y ago

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 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.

adamrt 12y ago
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.
justin66 12y ago
> 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.
- XorNot 12y ago
  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.
  - stephen_g 12y ago
    Why would you ever script password logons? You should be using key-based authentication...
    - XorNot 12y ago
      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").
      - lil_cain 12y ago
        Ansible can do this, using sshpass (and openSSH).
        XorNot 12y ago
        Under the hood SSHpass is just an expect-like wrapper for ssh. The entire login is still dependent on a non-protocol bit of text parsing.
- deleted 12y ago
  [deleted]
aggieben 12y ago
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.
angersock 12y ago
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.
weland 12y ago
> 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.

by adekok 12y ago

adamrt 12y ago

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.

justin66 12y ago

> 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.

XorNot 12y ago
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.
- stephen_g 12y ago
  Why would you ever script password logons? You should be using key-based authentication...
  - XorNot 12y ago
    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").
    - lil_cain 12y ago
      Ansible can do this, using sshpass (and openSSH).
      - XorNot 12y ago
        Under the hood SSHpass is just an expect-like wrapper for ssh. The entire login is still dependent on a non-protocol bit of text parsing.
deleted 12y ago
[deleted]

aggieben 12y ago

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.

angersock 12y ago

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.

weland 12y ago

> 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.