Hacker News new | past | comments | ask | show | jobs | submit login
OpenBSD 6.6 (openbsd.org)
224 points by liv-io 26 days ago | hide | past | web | favorite | 90 comments

I've really been enjoying using OpenBSD full time, both on my desktop (AMD Ryzen build) as well as laptops (Lenovo X230, X1 Carbon). Everything literally "just works", the documentation is impeccable, and I love being able to install a new kernel and base system with one simple command ("sysupgrade"). About the only thing I still use Linux for is a browser with U2F support and Bluetooth - both are disabled in OpenBSD for security.

> Bluetooth [is] disabled in OpenBSD for security

A clarification on that point: OpenBSD's bluetooth stack was unmaintained and removed due to code rot; it's not that bluetooth as a protocol is inherently insecure.

> it's not that bluetooth as a protocol is inherently insecure

Bluetooth is a ridiculously complex protocol. Complexity is the enemy of security. There's no fixed threshold beyond which complexity makes something "insecure", and Wi-Fi and even USB aren't exactly simple (both have had their share of implementation exploits across operating systems), but AFAIU there's a strong sentiment that Bluetooth is far too complex for the benefit it brings, which perhaps explains why OpenBSD's stack was unmaintained.

Course, now we have Bluetooth: Wired Edition with USB-C layering many different optional protocols over the base transport. I understand the rationale, but I fear it means the days of "just works" USB may be coming to an end...

Here's a list of Bluetooth security problems according to NIST: https://twitter.com/dchest/status/952981861080461312 (full PDF: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli...)

I'm not sure why U2F would be "disabled for security". I guess it's just that nobody has implemented all the required things. For the USB tokens, you need userspace USB HID access and hotplug notifications. I did that in Firefox for FreeBSD :)

When I asked in IRC, I was told U2F was not implemented in browsers on OpenBSD because, "do you really want browsers to have full access to your USB stack?"

"full access to your USB stack" is not very meaningful (and honestly sounds like a WebUSB criticism, maybe someone thought U2F required WebUSB?!)

You only have access to the devices which you have permission to access. On FreeBSD, we have a devd config that sets the u2f group on U2F tokens.

tbf, that IRC channel may not exactly be super canonical.


"remove freenode channel from index, it lacks any form of sensible moderation."

Pardon my ignorance, but why would U2F support be disabled for security? Isn't that the entire point of U2F?

This comment is really interesting to me. What wifi chip is in your X1 carbon? I would love to try a BSD on my t480s. What windowing system are you using?

Either xfce or dwm. Here's a great guide to OpenBSD on a 5th generation X1 carbon: https://jcs.org/2017/09/01/thinkpad_x1c

Very cool! What kind of software do you use on your machines?

- Are you doing docker in a Linux VM?

- Any graphical Applications other than Firefox and emacs?

I read about the "sysupgrade" tool and concluded that the upgrade to 6.7 in another 6 months will be awfully seamless... But I see from this that they backported the tool as a syspatch for 6.5! So from 6.5 we will be able to do syspatch && sysupgrade to get to 6.6. Sounds nice.

Tried on one of my machines. Seems to work fine. You still do the delete file step manually but that's minor. This is going to save a lot of effort on certain machines.

How does it handle sysmerge? Do you need to do that after it finishes? Or does it do the merges before reboot?

I will play around with it in a few hours.

Some things will get merged automatically by the first run of sysmerge(8) after upgrade, if the machine is remote you should be able to run.

    $ doas dmesg -s

    -s      ... This can be used to review rc(8) system startup messages.
That should tell you if you need to run sysmerge manually, but well, it also doesn't hurt to do that every time anyway.

You can also do sysupgrade -s to follow current snapshots, and then you get a rolling release OpenBSD without build world.

>So from 6.5 we will be able to do syspatch && sysupgrade to get to 6.6. Sounds nice.

Do note the steps before starting and the config file changes in the release notes need to be run through manually, before sysupgrade.

And after the new version boots, pkg_add -u.

You can also browse the source with the OPENBSD_6_6 tag in cvsweb.


Just keeps getting better and better every release. I wish they would add an easy encryption option in the installer. You can enable full disk encryption, but you have to mess with the bioctl settings, which potentially scares off new users.

To be fair, I've NEVER been able to configure LUKS manually for full-disk encryption, whereas I got bioctl working on the first try. It really is simple.

There's some hints they plan to do so, in the release notes.

  o Added regular expression support for the format search, match andsubstitute modifiers in tmux(1).
  o Added a -v flag to source-file in tmux(1) to show the commands and line numbers.
  o Added simple menus usable with mouse or keyboard in tmux(1).
  o Introduced the command "display-menu" to show a menu bound to the mouse on status line by default, and added menus in tree, client and buffer modes.
  o Changed the behavior of swap-window -d in tmux(1) to match swap-pane.
  o Allow panes to be empty in tmux(1), and enabling output to be piped to them with split-window or display-message -I.
  o Adjusted tmux(1) to automatically scroll when dragging to create a selection with the mouse when the cursor reaches the top or bottom line.
  o Fixed a tmux(1) crash when killing the current window, and other bugfixes.
Would love to see a demo of these cool now tmux features. (sorry, I don't really know how to format that email text for HN)

Are they new features, or new to OpenBSD?

I suspect new, since tmux (like OpenSSH) is developed as part of OpenBSD.

> ssh-keygen(1): add an experimental lightweight signature and verification ability. Signatures may be made using regular ssh keys held on disk or stored in a ssh-agent and verified against an authorized_keys-like list of allowed keys. Signatures embed a namespace that prevents confusion and attacks between different usage domains (e.g. files vs email).

Nice! I hope this will eventually be used for various signature systems like for git commits.

> Fixed support for amd64 machines with greater than 1023GB physical memory.

Don't I wish. What would be the memory test time for something like that?

I recently set up a Dell workstation with that much memory for a lab at work. The first time I booted it I was afraid that it was dead out of the box. It probably took ~5 minutes to POST and get to the Dell logo. Dells also have this weird thing where they turn on for a couple of seconds after you turn on the power, and it took me half an hour to figure out why it kept shutting down when I tried to boot it.

That's likely the memory training that every modern machine has to do when first seeing new memory (or if the training data is cleared from "CMOS"). Basically they have to discover exactly how tight the timings are for each bank so they can drive the memory efficiently and properly. Timings and latency just didn't used to be so tight compared to the good old days of EDO ram.


By linear extrapolation, about 7 minutes per terabyte on an EPYC 7402, which can handle up to 4 TB.

Attempts to justify new init software by "it boots much faster" fall flat.

OSEs aren’t limited to running on physical hardware, fast startup for VMs is still beneficial.

Of all my Linux VMs, Alpine Linux boots the fastest--practically instantaneously. Alpine Linux doesn't use systemd.

Parallel init only helps on large, multi-service systems, but those are precisely the ones that (1) rarely reboot and (2) will have relatively long boot sequences, regardless.

i've got servers just out of 5-year warranty with 768GB of RAM factory installed. they tend to take a while to boot but they aren't rebooted often enough to remember how long the POST takes.

If you support OpenBSD in spirit and love what they do, consider making a donation to help the developers out. Most devs work for free and every little bit helps :)


Love the release poster for this one.

I cannot understand the poster this time. I have actual problems identifying the elements: I see puffy at the top, a couple demonettes on the left, and a mask (?) in the bottom right, but everything else seems a mess. And I don't get what it refers to.

Is it a reference to some pop or niche culture bit ? Is it "6.6 is almost 666, so, devils"?

It is Heavy Metal music, and yes 666. Puffy is dressed as a member of the rock band KISS.

It can easily be misread as "OpenBSD la.la", though.

Is there any way to buy a print, or get a high-quality image for printing at home? The expanded version on the website is a pretty gnarly non-animated GIF.

You used to be to buy official OpenBSD t-shirts [1] and posters at conferences such as Fosdem. I think I even got one poster for free at Fosdem cause I bought a t-shirt. But that was in 2003 or so.

[1] https://www.openbsd.org/tshirts.html

Sometimes they'll also sell the posters online.

I've got my 6.0 poster (probably the best one they've done) at my desk at work.

You could try tweeting/DM'ing the artist: https://twitter.com/natazilla

It reminds me of something I'd see in Heavy Metal magazine, when that was still a thing. It's really cool.

That's pretty cool. I didn't know they made posters for each release. The one for 6.4 is also pretty cool.

They made professional quality release songs (and sold CD's) up until 6.0. A few extras showed up for 6.1-6.3 also.


The OpenBSD developers are not too thrilled to hear about these sorts of issues, but looks like sysupgrade installed sets I didn't have before (x*66.tgz, game66.tgz).

It does that. You can hack the script to only install partial sets, but you're encouraged to install all the sets. I've seen at least one mention on the mailing list about merging the sets because the recommendation is to always install all of them anyway. They're just files on disk if you're not using them.

Instead of hacking the script, you can run it with -n. You can then edit /auto_uograde.conf before reboot to instruct the installer to only install the desired sets.

As noted elsewhere, the developers recommend installing all sets. I personally prefer to avoid installing the X sets on servers.

If you hadn't seen it, you may find this recent discussion about sysupgrade informative: https://marc.info/?t=156851721400002&r=1&w=2

And yeah, you're right, even light criticism on the OpenBSD lists is met with a very strong and negative reaction. That said, I think improvement suggestions that come with a diff and a constructive attitude are generally well received.

Also sysupgrade is a pretty brief ksh script, so fairly easy to see what it's doing.

OpenBSD developers have not really made it official but basically you're supposed to install them all. Theo has hinted at merging them before.

syspatch(8) also assumed them to be installed IIRC.

for one of Theo's recent hints see: https://marc.info/?l=openbsd-misc&m=156932725121978&w=2

Why ruin it for the majority because a few doesn't known what they are doing? I know the argument is that everyone has the disk space these days, but I still don't like to install the entire X window system, compilers etc. for a small embedded system. What's next, force install of Libreoffice and Firefox because a few desktop users can't use the package manager?

The thing I realized about OpenBSD is it’s made by and for the developers. They are going to do what works for them and fits their priorities. Not what works for the widest possible audience.

Yes and I agree with 99% of all the things they do, and appreciate them, but the thing with threating to merge all file sets because the few people non-deliberately choosing the non-default case are tripping over their incorrectly tied shoelaces too much. why not just ignore those few people and not force X window system binaries on thousands of network equipment?

I suppose you could just keep posting this until they follow through with their idea of having only one set to prevent people like you from complaining about this non issue. Or do you think being passive aggressive on hacker news is going to change their collective, long held stance on this issue?

No, what will happen is that sooner rather than later “people like you” will kill my casual interest in this stuff with personal attacks.

In the 90s disks were smaller and it might have made more sense to exclude compilers or exclude X. I used to not put X on headless machines. But today disk space is big and cheap.

Why would they merge X before the text games?

I hope they're real complaints and not i.e. we need install menu changed from "install xserver [x]" to "how u liek the xserver? now[ ] never[ ] now with extra firefox, please[x]"

It is completely unimaginable for OpenBSD to have Firefox in the base system. This is a very big misunderstanding of what goes in base vs. ports tree. Even with all the sets, the OpenBSD system without any ports is small compared to, say, a typical Linux distro.

> Added mcx(4) driver for Mellanox ConnectX-4 (and later) Ethernet controllers.

Interesting. Sounds like work is being done to support higher network throughput rates. :)

Just a reminder: you still have to read the preupgrade stuff before and do the manual file deletion stuff afterwards even if you do sysupgrade. Most will need to do the pkg_add -u after all that. Here is the link (I always have to look for it):

* https://www.openbsd.org/faq/upgrade66.html

There is 'sysclean' in packages, which make that step easier.

ghc bumped to 8.6.4 and sbcl with threading support!

I still desperately want docker support. I know I can bhive and friends - but native docker support is critical to my every day, unfortunately. Heck, I'll take super decayed docker support!

> bhive

bhyve is FreeBSD, not OpenBSD. OpenBSD has its own native hypervisor "vmm".

Thank you, I stand corrected - and can't spell bhyve today apparently :(.

Can OpenBSD run Sway? Or is that only supported on FreeBSD/Linux?

It can't really (other than inside an x11 window maybe), not in its current state. I've heard that someone was working on some Wayland porting efforts, but idk about the state of that.

Looks like OpenBSD has a fairly up to date kms/drm stack now, but you also need:

- to have epoll - https://github.com/jiixyj/epoll-shim might just work

- to expose input devices from the kernel as evdev devices (good idea) or to implement support for your legacy protocol in wlroots / in other places for other compositors (terrible idea)

- to have a device enumeration and hotplug system and either have it pretending it's udev (as we do with https://github.com/FreeBSDDesktop/libudev-devd) or implement support for it in wlroots and everywhere

- direct session glue code at least e.g. https://github.com/swaywm/wlroots/blob/master/backend/sessio...

- but ideally, a working session manager that supports acquiring drm+evdev devices over d-bus e.g. https://github.com/ConsoleKit2/ConsoleKit2/pull/116 && https://github.com/swaywm/wlroots/pull/1467

Can't wait to try if this release will improve wireless performance when configured as an AP, until now I have never been able to get speeds above 10 Mbps with OpenBSD.

OpenBSD only supports 802.11n currently. From what I've read, not having direct knowledge, 802.11ac is much more complex to implement and no one is currently working on it.

That said, I just ran a speed test on my Thinkpad and got 50Mbps.

I would be more than happy if I only could get same speed as with my old Linksys WRT54GL. Currently the AP is forced to 802.11g because performance of 802.11n was much worse.

> Disabled gcc in base on armv7 and i386.

Is gcc disabled in base on amd64? Are the OpenBSD distributions for amd64 compiled with gcc or clang?

gcc is still included in base on amd64 for now, but the default system compiler on amd64 (and i386) has been clang since OpenBSD 6.2. If you use the /usr/bin/{cc,c++} symlinks, you get clang. Nothing uses the base-gcc now, but it being kept as a convenience for porters to test with as some architectures have yet to switch to clang.

The change mentioned is only that gcc4 (base-gcc) will no longer been installed alongside clang on i386 and armv7. If you need gcc, you can install ports gcc 8.3.0 from packages.

Do you know what sparked the change that uprooted gcc's "dominance"? I know the GNU libc added a lot of "opinionated" pieces, but I thought that was mainly opt-in. I'm curious why gcc "lost its crown" and clang gained all of the attention.

Did clang derive from gcc?

I don't follow, I'm sorry. OpenBSD has never used GNU libc. The BSD projects have long developed their own C libraries.

The clang compiler is a part of the LLVM collection, it is not derived from gcc at all.

As for GCC, The GNU project changed the license for their compiler sometime after the 4.2.1 release to the GPLv3. Meanwhile, up until the Clang 9.0.0 release, Clang was developed under a permissive license (NCSA). We're facing a similar problem now with LLVM/CLang, with their re-licencing to the non-permissive Apache 2.0 license.

How is Apache non-permissive? It deals with more things (like patents) and it's a bit complex, but it's not viral I'm pretty sure.

Ah. Whatever. The common meaning of "non-permissive" is "copyleft", not "has patent clauses the OpenBSD project has weird concerns about".

clang doesn't derive from gcc in any meaningful way (it does implement some gcc extensions though). There's two main reasons that LLVM and clang really got a lot of wind behind it, and that's largely Apple and the GPLv3. Apple decided that they wanted more control over their objective c and other compiler infrastructure so they threw resources at the burgeoning LLVM to start trying to get it competitive. That was driven both by the difficulty of maintaining a GCC frontend & port, and also by the license change to GPLv3 that happened. That's also why the *BSD and other projects started throwing support behind LLVM and clang, because the GPLv3 put further restrictions on them that they didn't agree with which is also why gcc 4 is the latest version of gcc to ship by default with openbsd. That's also what has kept such an old version of bash on macos/osx. Clang's more favorable (for a distributor) licensing makes it easier to deal with for shipping by default.

That's also not to discount some of the other efforts that clang made to make developer's lives easier with better error messages and for a decent amount of time, better static analysis tools (they're fairly comprable now). Those definitely helped but I don't believe that they drove nearly the same amount of time and resources compared to the above points.

EDIT: missed the bit about the libc stuff in parent comment

GNU libc and gcc are completely separate. As the sibling stated, the BSDs and other systems didn't use them and gcc doesn't require or directly use it either. There is a libgcc that gcc usually needs, that provides a bunch of boilerplate/other stuff to bring up the executable but that isn't part of either the C language or the C library. It's things like a definition of the _start() entrypoint and things to handle setting up static variables during initialization and that kind of thing. It's also got a GPL exception specifically in it's license to avoid conflicts with having to link with it. It is possible to build things with gcc without linking to that library, but you end up having to provide it all yourself. This is how gcc usually gets used on smaller embedded systems that don't need all the things it provides otherwise.

so BSDs wrote their own libc implementations, then historically (pre-clang) compiled them with `gcc` without any GNU extensions?

Basically, yes. I don't know if they avoided GNU GCC C language extensions but I'd be surprised if they did use any in any significant manner.

clang did not derive form gcc. apple gave it funding because they don't like the GPL. and then everyone else who had distaste for the GPL (BSD people) also switched over when clang/llvm were up to par.

Thanks to all the OpenBSD developers and supporters for making another amazing release!

Now that they have the amdgpu driver in, it's time to run this on my Ryzen box.

prgmr.com has an updated netboot installer: https://prgmr.com/blog/2019/10/17/openbsd.html

The release artwork gets better each time!

sysupgrade from 6.5 works amazingly!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact