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.
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.
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.
"remove freenode channel from index, it lacks any form of sensible moderation."
- Are you doing docker in a Linux VM?
- Any graphical Applications other than Firefox and emacs?
I will play around with it in a few hours.
$ doas dmesg -s
-s ... This can be used to review rc(8) system startup messages.
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.
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.
Nice! I hope this will eventually be used for various signature systems like for git commits.
Don't I wish. What would be the memory test time for something like that?
Attempts to justify new init software by "it boots much faster" fall flat.
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.
Is it a reference to some pop or niche culture bit ? Is it "6.6 is almost 666, so, devils"?
I've got my 6.0 poster (probably the best one they've done) at my desk at work.
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.
syspatch(8) also assumed them to be installed IIRC.
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]"
Interesting. Sounds like work is being done to support higher network throughput rates. :)
bhyve is FreeBSD, not OpenBSD. OpenBSD has its own native hypervisor "vmm".
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
That said, I just ran a speed test on my Thinkpad and got 50Mbps.
Is gcc disabled in base on amd64? Are the OpenBSD distributions for amd64 compiled with gcc or 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.
Did clang derive from gcc?
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.
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.