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.
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...
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?"
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?
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.
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.
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)
> 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.
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.
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 :)
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"?
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.
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.
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.
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?
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.
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.
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):
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!
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 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
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.
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.
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.
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.
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.
