Slashdot Mirror

[...] Maybe OpenBSD could create a section on their web site that provides documentation on the advantages of BSD over Linux as well as some advice on how to avoid common pitfalls that Linux users typically make in BSD. [...] In any event, I'm curious to see what I'll miss coming from the Linux world after spending some time in OpenBSD.
On a semi-related note: what's with replacing nginx with their own http daemon? Is the NIH syndrome spreading to OpenBSD as well?

Nope, they have explained at legnth that nginx was getting too big, and its developpers too unresponsive, for it to be a part of base anymore. That was also the case with the previous web server, which was an old version of Apache with a lot of patches.You can still install nginx from ports though and Apache is in there somewhere as well.

As far as documentation is concerned, please refer to the OpenBSD FAQ:

http://www.openbsd.org/faq/faq...

And:

http://www.openbsd.org/faq/faq...

What will you miss? Probably not much, except for the eye candy. OpenBSD is a really good and complete OS, and its quality is excellent.

[...] Maybe OpenBSD could create a section on their web site that provides documentation on the advantages of BSD over Linux as well as some advice on how to avoid common pitfalls that Linux users typically make in BSD. [...] In any event, I'm curious to see what I'll miss coming from the Linux world after spending some time in OpenBSD.
On a semi-related note: what's with replacing nginx with their own http daemon? Is the NIH syndrome spreading to OpenBSD as well?

Nope, they have explained at legnth that nginx was getting too big, and its developpers too unresponsive, for it to be a part of base anymore. That was also the case with the previous web server, which was an old version of Apache with a lot of patches.You can still install nginx from ports though and Apache is in there somewhere as well.

As far as documentation is concerned, please refer to the OpenBSD FAQ:

http://www.openbsd.org/faq/faq...

And:

http://www.openbsd.org/faq/faq...

What will you miss? Probably not much, except for the eye candy. OpenBSD is a really good and complete OS, and its quality is excellent.

Every thing I hear about SystemD, the words are mixed into this song in my head.
Blob

I just checked on openbsd.org, and I loved the FAQ section!
4.13 - Common installation problems
4.13.1 - My Compaq only recognizes 16M RAM
4.13.2 - My i386 won't boot after install ...

libressl-2.1.3.tar.gz 21-Jan-2015 2.7M. For you non Open BSD users: portability wrappers. Full Source.

"... no longer secure..."

OpenBSD is secure because it was examined carefully for vulnerabilities. Microsoft makes more money if there are vulnerabilities, and if its older products are considered likely to be insecure.

"... when it no longer boots..."

We have corporate users who do the same thing every day on computers installed in 2004. They don't want change.

"... when none of the software you use will still run on the old OS"

Yes, you and I. But some corporate users do specialized corporate work on software that ran under DOS. It does what they want. There is little call for change.

"... when you have to employ tech staff with out-of-date skills..."

The Windows command line windows are mostly just the old DOS. There is nothing out-of-date.

"... when the software is a dead do-do that nobody wants to touch..."

Lots of people do lots of things that have remained stable for decades.

"Sorry, but everything has an end-of-life."

I talked to a guy who makes a lot of money per hour maintaining Cobol programs on old mainframes. Yes, end of life. But possibly decades from now.

"When you can't log into your damn bank because it's said that IE6 is too old..."

The browsers are updated frequently, of course. And computers connected only to an internal network have no outside internet vulnerabilities, if there are no DVD drives. I talked to a woman who worked at Tektronix who could not send an email from her work computer because there was no outside access.

Should employees be allowed to explore the internet during lunch breaks? Sure, on a separate network in the lunch room.

I have the latest hardware and software, a 24-port gigabit switch, and multiple 3 Terabyte RAID drives. But that's because I make a lot more techological demands than the average person.

I don't feel conflict of interest. Unfortunately, conflict of interest is a big factor in the lives of many people who are involved with computer technology. Their minds are persuaded by what would make them more money.

OpenBSD

Peter N. M. Hansteen's PF tutorial and books are recommended reads, Peter remains involved with the developers and the information stays relevant and useful. He also ensures that readers using other BSD systems, especially with older versions of pf, can learn just as much from it.

* The Book of PF, 3rd Edition, 2014 - ISBN: 978-1593275891
* http://home.nuug.no/~peter/pf/

Michael W Lucas is another author that writes books for both the BSD and sysadmin communities, similarly, he works closely with developers and users to release these short, yet all-encompassing tomes of information, covering a wide variety of topics.

https://www.michaelwlucas.com/...
* Absolute OpenBSD, 2nd Edition, 2013 - ISBN: 978-1593274764
* SSH Mastery, 2012 - ISBN: 978-1470069711
* Sudo Master, 2013 - ISBN: 978-1493626205

And of course, official documentation is great. The effort of many people working to improve, Jason McIntyre improving readability and overall quality, Ingo Schwarze's amazing work on mandoc(1) tools. OpenBSD's FAQ, which is usually the first step people take to learn more about the system, is maintained by Nick Holland.

http://www.openbsd.org/faq/
http://www.openbsd.org/cgi-bin...

Peter N. M. Hansteen's PF tutorial and books are recommended reads, Peter remains involved with the developers and the information stays relevant and useful. He also ensures that readers using other BSD systems, especially with older versions of pf, can learn just as much from it.

* The Book of PF, 3rd Edition, 2014 - ISBN: 978-1593275891
* http://home.nuug.no/~peter/pf/

Michael W Lucas is another author that writes books for both the BSD and sysadmin communities, similarly, he works closely with developers and users to release these short, yet all-encompassing tomes of information, covering a wide variety of topics.

https://www.michaelwlucas.com/...
* Absolute OpenBSD, 2nd Edition, 2013 - ISBN: 978-1593274764
* SSH Mastery, 2012 - ISBN: 978-1470069711
* Sudo Master, 2013 - ISBN: 978-1493626205

And of course, official documentation is great. The effort of many people working to improve, Jason McIntyre improving readability and overall quality, Ingo Schwarze's amazing work on mandoc(1) tools. OpenBSD's FAQ, which is usually the first step people take to learn more about the system, is maintained by Nick Holland.

http://www.openbsd.org/faq/
http://www.openbsd.org/cgi-bin...

Then I guess he's not working on OpenBSD.
http://www.openbsd.org/errata5...

It's not a bug.

The commit log states this:

when a dns lookup fails at parse time, do not abort but try again
to resolve the hostname every 60 seconds
fixes ntpd invocations before e. g. a dialup link is established and such.
as we want ntpd to be a "fire and forget" background daemon it should
cope with such situations.
tested by many

Relevant diff: http://cvsweb.openbsd.org/cgi-...

(I'm assuming that the "bug" you found is that it's comparing the return value to -1 when the host() function can only return 0 or 1)

There's no 'host' function in parse.y

Just connect an access point to an OpenBSD box, and this crap won't happen.

Why will that prevent it from happening? Anyone that owns the access point can inspect and modify all of the traffic that passes through it.

Just connect an access point to an OpenBSD box, and this crap won't happen.

Start here.

Which is what is currently happening to Linux, too. Escape Now ...bitches!

FFS.. There is no flash plugin!

http://www.openbsd.org/faq/faq13.html#flashplugin

FreeBSD outperforms Linux only in certain scenarios. In most common cases you would hardly find any difference. Otherwise.

It is not the problem that Linux network stack sucks. The problem is that linux-netdev people believe that Linux network stack is already perfect.

AND. The biggest problem is with the certain Linus Torwalds who insists on perfect design for any net redesign.

That's why we still do not have interrupt polling/interrupt throttling or anything like pf.

That's why we have the technically perfect ip - but totally unusable to literally any human being. And the iptables with near O(n) performance.

It's basically the same story as with the sound subsystem. As long as the design is good, it doesn't matter that the end result sucks.

With FTP acting as fragile as glass in the world of NAT and firewalls...

I've built several NAT firewalls using OpenBSD and pf. They make it very easy to accommodate both FTP clients and servers behind NAT, by providing a simple-to-use ftp-proxy.

Easy to setup, works like a charm :)

Well, OpenBSD patched this in 2009 in their wget...

No, they fixed it in their implementation of the ftp program, which is a completely different application. Like the GP said, "Has nothing to do with linux. It's an application that runs in GNU/linux." If you ran wget on OpenBSD it would still have the bug, and if you ran OpenBSD's ftp program on Linux it would still be fixed.

Well, OpenBSD patched this in 2009 in their wget...

I use ports all the time, and I've never compiled my own kernel.

Seriously?

How do you apply kernel security patches such as this one?

http://ftp.openbsd.org/pub/Ope...

Yes, yes, little troll, you just demonstrated your total lack of knowledge when it comes to OpenBSD.

Straight from the horse's mouth: http://www.openbsd.org/faq/faq...

And I quote the aforementioned:

Why do I need a custom kernel?

Actually, you probably don't.

The only time you need to recompile OpenBSD kernel is when a major security issue has been found and your system is vulnerable.

Well, I was surprised by the bitbucket link as well, but a lot of developpers (OpenBSD or not) use git these days. The repo linked to seems to be a copy of the official OpenBSD CVS.

A better link could be, for instance:

http://cvsweb.openbsd.org/cgi-...

Or:

http://cvsweb.openbsd.org/cgi-...

The interesting thing is that the diff just before Ted Unangst is more than 11 years old -- which means LKMs really haven't been used for a long time in OpenBSD...

Well, I was surprised by the bitbucket link as well, but a lot of developpers (OpenBSD or not) use git these days. The repo linked to seems to be a copy of the official OpenBSD CVS.

A better link could be, for instance:

http://cvsweb.openbsd.org/cgi-...

Or:

http://cvsweb.openbsd.org/cgi-...

The interesting thing is that the diff just before Ted Unangst is more than 11 years old -- which means LKMs really haven't been used for a long time in OpenBSD...

The official changelog also says they removed LKM http://www.openbsd.org/faq/cur...

We've been waiting for you.

http://www.openbsd.org/

until the Systemd fiasco blows over.

Not going to happen.

If only there were sane and well-designed OS the developers of which actually think about the consequences of what they're doing.
Oh, wait. there are.

systemd is the greatest thing happening to Linux for a decade, and probably the biggest shake up ever.

Indeed. It shook me so hard, I fell off the Linux world.
Not looking back

...at all.

I'm aghast at the state ofdocumentation for Open Source projects

You must have missed OpenBSD, then.
I know, I know: It's an exception. I just wanted to mention the best documented Free Software I've ever seen.

"Do you know any large system where this works? The big gotcha is that of all the programs you run, you can only code a tiny % of them. And you canâ(TM)t audit everything else."

if you can't audit 7mb of code you're retarded. who has a 7 mb of code to audit it? try openbsd http://www.openbsd.org/ftp.html

even for the full iso is only 230MB. plop it on open hardware and you can audit the hardware and the software. someday get a 3d printer and an x-ray camera and you can audit the hardware to see if it followed specs or not. have a password generated to be impossible to remember and requires a hardware decrypter to reform the password but can do so in multiple ways with only the one true way remembered by you, and you're golden against attacks on your setup, which then allows you to run fast computers that maybe have backdoors that are completely blocked by your secure machine, which you know is secure because you did it yourself.

Yes. If you're using libressl and the snapshot of the source you compiled is older than Thu Jun 5 15:46:24 2014 UTC, you're affected by this, too. See: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/s3_clnt.c

So YOU'RE the guy --who is running Big-Endian AMD64 !! (*cvs)

Most of what they are ripping out is archaic, un-realistic, or poor implementations platforms. You could argue that hacked-support for too many platforms is part of the reason openssl is in the position its in today - if you can't do it right (or don't have the resources to), don't do it. Name a platform other than VMS, they've ripped out and that you need : )

I saw those slides. There were 17 levels of #ifdefs in the code. Every ifdef is a binary switch, which means 2^17 different iterations of source code.(!!!!!) That's 131072 different compiles (!!!!!!).

So, lets pretend that a config/make sequence just needs 10 minutes (unlikely, they have an oddball config script that isn't like autoconf). To hit 17 levels of ifdef, you'd need approx 910 computer-days just to do all the compiles. Do you think they tested this matrix?

I hate to beat up on a bunch of people who did hard work for free, but they really did a bad job on a lot of things.

Yes, do please contribute. And if you simply don't want to give your money to them at least go buy a CD or coffee mug. Every little bit helps!

OpenSSL doesn't listen to bug reports. They don't even accept offered patches to known bugs. It's this spirit of non-cooperation that caused the forking into LibreSSL. See the 30 day prospectus (/. coverage) from the LibreSSL project lead, which details all of the problems. Brian even says forking is ultimately a benefit, and that he "loves that they're doing it."

It seems to be that his definition of "sucks" is "has room for improvement" ... Everything has room for improvement, so apparently everything sucks.

I was referencing this specific slide http://www.openbsd.org/papers/... They clearly state their portability goal is mostly POSIX-compatible, but after a second read it is not obvious it its being used as a base reference, as you point out.

My objection is limited to these nonsense assertions usage of operating system allocator would have meaningfully mitigated heartbleed vulnerability.

OpenBSD's malloc has many security features, including use-after-free detection. OpenSSL's custom memory management nullified all that.

OpenSSL has basically wrote their own version of libc, and all the functions they've introduced differ is some very subtle ways from what appears in libc used by the rest of the world.

Rest assured, OpenBSD is no stranger to portable code. Just take a look at the number of platforms they support -- http://www.openbsd.org/plat.ht....

...until you put a typo in /etc/fstab when you're not used to plain old vi, and get to discover the joys of learning ed. Without a man page because that was in /usr too.

Some reason you can't just manually run "mount" from the command-line to mount the /usr partition, and get vi and man pages back?

And is there some reason you couldn't just visit the website to access the man pages?

http://www.openbsd.org/cgi-bin...

The BSDs use the rc init system. FreeBSD uses the newer rc.d system. Slackware uses one of these systems as well.

Is "decommitting" something that [...] OpenBSD does (search this page [by David A. Wheeler about Heartbleed countermeasures] for "munmap") and everyone else lacks?

The second link has nothing to do with the topic

In the part of that page where "munmap" is mentioned, Wheeler is talking about properly using the C standard library's own memory allocator, which may return particular pages to the operating system. Perhaps I should have linked to the post by Theo de Raadt that Wheeler quoted: "If the memoory [sic] had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys." Also try man 2 munmap.

Depends on the amonut of auditing. C has huge problems, but OpenBSD shows it can be safe.

How so? OpenBSD says they audit their operating system (which includes code that they did not write). OpenBSD was affected by Heartbleed, which means OpenBSD's audit did not catch this bug, and they were affected just like everybody else.

Also, most of the bugs on their advisory page are for typical C memory problems, such as use after free and buffer overruns.

Granted, this release does break things a bit further than most, as mentioned by post about time_t incompatibility. For example, the password database may need to be updated (by running a new version of pwd_mkdb , as mentioned by a forum post: updating past 5.4 current flag day). So, that database is a binary update that is required.

It is also true that this is a case of the operating system requiring that binary executable files to be re-compiled. However, breaking compatibility with older executable files is actually something that is pretty much always happening between OpenBSD releases. So that's not at all unusual.

Let me explain a bit about OpenBSD compatibility between versions: The operating system and pre-built ports are generally filled with dependencies of libraries, and seemingly little to no tolerance for different versions. This means that most binary executables will be designed for a specific version of the OS. Using binary executables for any other version of the OS will break things terribly.

The end of OpenBSD FAQ 5: section on OpenBSD Flavors states, “It is important to understand that OpenBSD is an Operating System, intended to be taken as a whole, not a kernel with a bunch of utilities stuck on.” The kernel and other software is meant to match. http://www.openbsd.org/faq/faq15.html#NoFun (gotta just love the name of that hyperlink anchor) is about "using a system and ports tree which are not in sync." In other words, if the "system" (e.g., the kernel) and the "ports tree" (i.e., "other software") are different versions, then you're likely doomed. Upgrading software to the "-stable" branch is generally an exception, meaning that it is okay as long as you're still within the same version number. Upgrading to a new -release involves upgrading to a new version number, and that's when hopelessness starts to seep in. Upgrading to the "snapshots" release, involving "-current" source code, is also likely to cause some incompatibilities. (Possibly not. But the likelihood increases over time, especially as soon as something common like libc ends up getting an updated version number.) The only intended and recommended way to deal with these problems is to just avoid them altogether, by upgrading absolutely everything (operating system and all the software) at once, which keeps things in sync.

This does get discussed further at ][CyberPillar][: updating OpenBSD via binaries in the subsection titled "Code sync requirement (and ramifications of this requirement)", which describes this issue more and provides additional hyperlinks.

This is why every single "port"/"package" (third party software) needs to be updated (for the easiest experience) with every applied OpenBSD version upgrade (in order to have the easiest experience). There is no "let's upgrade one piece of software today, and then upgrade another piece of software next week". It's an all-or-nothin' deal.

Did you read about the latest feature added by some piece of software? Sure, you can download a pre-built binary executable file from the "snapshots" release to try out that new software. If the software runs, great. If there's a problem with needing another library, then there's another solution using pre-built binary executables. Simply make sure to upgrade your entire friggin' operating system to the "-current" (a.k.a. unstable/testing branch), and all other software, all at the same time. That should avoid version compatibility issues.

Sound too challenging? Then break out your compiler and compile from source, and handle any dependency/version confl

Granted, this release does break things a bit further than most, as mentioned by post about time_t incompatibility. For example, the password database may need to be updated (by running a new version of pwd_mkdb , as mentioned by a forum post: updating past 5.4 current flag day). So, that database is a binary update that is required.

It is also true that this is a case of the operating system requiring that binary executable files to be re-compiled. However, breaking compatibility with older executable files is actually something that is pretty much always happening between OpenBSD releases. So that's not at all unusual.

Let me explain a bit about OpenBSD compatibility between versions: The operating system and pre-built ports are generally filled with dependencies of libraries, and seemingly little to no tolerance for different versions. This means that most binary executables will be designed for a specific version of the OS. Using binary executables for any other version of the OS will break things terribly.

The end of OpenBSD FAQ 5: section on OpenBSD Flavors states, “It is important to understand that OpenBSD is an Operating System, intended to be taken as a whole, not a kernel with a bunch of utilities stuck on.” The kernel and other software is meant to match. http://www.openbsd.org/faq/faq15.html#NoFun (gotta just love the name of that hyperlink anchor) is about "using a system and ports tree which are not in sync." In other words, if the "system" (e.g., the kernel) and the "ports tree" (i.e., "other software") are different versions, then you're likely doomed. Upgrading software to the "-stable" branch is generally an exception, meaning that it is okay as long as you're still within the same version number. Upgrading to a new -release involves upgrading to a new version number, and that's when hopelessness starts to seep in. Upgrading to the "snapshots" release, involving "-current" source code, is also likely to cause some incompatibilities. (Possibly not. But the likelihood increases over time, especially as soon as something common like libc ends up getting an updated version number.) The only intended and recommended way to deal with these problems is to just avoid them altogether, by upgrading absolutely everything (operating system and all the software) at once, which keeps things in sync.

This does get discussed further at ][CyberPillar][: updating OpenBSD via binaries in the subsection titled "Code sync requirement (and ramifications of this requirement)", which describes this issue more and provides additional hyperlinks.

This is why every single "port"/"package" (third party software) needs to be updated (for the easiest experience) with every applied OpenBSD version upgrade (in order to have the easiest experience). There is no "let's upgrade one piece of software today, and then upgrade another piece of software next week". It's an all-or-nothin' deal.

Did you read about the latest feature added by some piece of software? Sure, you can download a pre-built binary executable file from the "snapshots" release to try out that new software. If the software runs, great. If there's a problem with needing another library, then there's another solution using pre-built binary executables. Simply make sure to upgrade your entire friggin' operating system to the "-current" (a.k.a. unstable/testing branch), and all other software, all at the same time. That should avoid version compatibility issues.

Sound too challenging? Then break out your compiler and compile from source, and handle any dependency/version confl

If your comment was about booting USB installation media on an iMac:
I don't know enough about iMacs to have understood your comment. More clarity would be appreciated.

If your comment was about OpenBSD:

I'm sorry, but posting here does not satisfy the official OpenBSD bug reporting process. (Particularly, the last hyperlink on that page.)
In particular, this post (comment #46891655) seems very much like a violation of the first paragraph under OpenBSD FAQ 2: section on bugs.
Well, look on the bright side. At least you were intelligent enough, or just plain lazy enough, to post as Anonymous Coward. Hmm, given the other behavior I've observed, I suspect the latter.

If your comment was about booting USB installation media on an iMac:
I don't know enough about iMacs to have understood your comment. More clarity would be appreciated.

If your comment was about OpenBSD:

I'm sorry, but posting here does not satisfy the official OpenBSD bug reporting process. (Particularly, the last hyperlink on that page.)
In particular, this post (comment #46891655) seems very much like a violation of the first paragraph under OpenBSD FAQ 2: section on bugs.
Well, look on the bright side. At least you were intelligent enough, or just plain lazy enough, to post as Anonymous Coward. Hmm, given the other behavior I've observed, I suspect the latter.

Just an FYI, heartbleed is not fixed in 5.5 without extra (source) patches.

See http://www.openbsd.org/errata5...

  002: SECURITY FIX: April 8, 2014 All architectures
Missing bounds checking in OpenSSL's implementation of the TLS/DTLS heartbeat extension (RFC6520) which can result in a leak of memory contents.
A source code patch exists which remedies this problem.

finds out openssl is bollocks,
radically refactors and overhauls millions of lines of code.

as for the LibreSSL team, might i suggest some music?
http://www.openbsd.org/lyrics....
http://www.openbsd.org/lyrics....

finds out openssl is bollocks,
radically refactors and overhauls millions of lines of code.

as for the LibreSSL team, might i suggest some music?
http://www.openbsd.org/lyrics....
http://www.openbsd.org/lyrics....