https://marc.info/?l=openbsd-announce&m=160303500224235&w=2
October 18, 2020.
We are pleased to announce the official release of OpenBSD 6.8. This day marks the OpenBSD project's 25th anniversary. As we celebrate our 49th release, we remain proud of OpenBSD's record of more than twenty years with only two remote holes in the default install.
As in our previous releases, 6.8 provides significant improvements, including new features, in nearly all areas of the system:
- New/extended platforms[...]
- Improvements to time measurements, mostly in the kernel[...]
- Various kernel improvements[...]
- Various new userland features[...]
- Various bugfixes and tweaks in userland[...]
- Improved hardware support and driver bugfixes, including[...]
- New or improved network hardware support[...]
- Added or improved wireless network drivers[...]
- New arm64 and armv7 hardware support and bugfixes, including[...]
- IEEE 802.11 wireless stack improvements and bugfixes[...]
- Generic network stack improvements and bugfixes[...]
- Installer improvements[...]
- Improvements in the FFS2 filesystem[...]
- Security improvements[...]
- Routing daemons and other userland network improvements[...]
- ipsec(4) (and related userland programs) improvements and bugfixes[...]
- tmux(1) improvements and bug fixes[...]
- VMM/VMD and ldom/sparc64 virtualization improvements
- OpenSMTPD 6.8.0
- LibreSSL 3.2.2
- OpenSSH 8.4
- Ports and packages
Related Stories
Consultant and author Peter N M Hansteen has written up an overview of recent and not so recent changes in OpenBSD that make life better (and may turn up elsewhere too). He covers a few decades of developments that he has found particularly useful and explains why. He covers greylisting, spam filters, OpenSSH, and of course PF.
When I found OpenBSD more than twenty years ago, my main Unix exposure was from working with Linuxes and FreeBSD. What attracted me to OpenBSD and finally had me buy an OpenBSD 2.5 CD set was the strong focus on security and code correctness. When the CD set and the classic wireframe daemon T-shirt finally arrived in the mail, I set about at first to install it on whatever spare hardware I had lying around.
[...] OpenBSD has had traffic shaping available in the ALTQ subsystem since the very early days. ALTQ was rolled into PF at some point, but the code was still marked experimental 15 years after it was written, and most people who tried to use it in anger at the time found the syntax inelegant at best, infuriating or worse at most times.
So Henning Brauer took a keen interest in the problem, and reached the conclusion that all the various traffic shaping algorithms were not in fact needed. They could all except one be reduced to mere configuration options, either as setting priorities on pass or match rules or as variations of the theme of the mother algorithm Hierarchical Fair Service Curve (HFSC for short).
Soon after, another not-small diff was making the rounds. The patch was applied early in the OpenBSD 5.5 cycle, and for the lifetime of that release older ALTQ setups were possible side by side with the new queueing system.
OpenBSD is a complete operating system and originally forked from NetBSD back in 1995 which forked from 386BSD which was ported from 4BSD. It's emphasis is on portability, standardization, correctness, proactive security, and integrated cryptography. The current release, 6.9, is its 50th release.
Previously:
(2020) Using OpenBSD Routing Tables to Segment the Home Network for Privacy
(2020) The OpenBSD Project's 25th Anniversary
(2020) WireGuard Imported Into OpenBSD
(2017) OpenBSD and the Modern Laptop
and many more...
(Score: 2) by c0lo on Monday October 19 2020, @04:30AM (1 child)
RIP [everything2.com]... errr, sorry... many happy returns.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by bart9h on Monday October 19 2020, @02:08PM
Wow! E2 still exists!!
nice
(Score: 1) by nostyle on Monday October 19 2020, @04:40AM
While I have had no need of OpenBSD in recent years, I treasure fond memories of having it "just work" for years and even decades. This world is better off with OpenBSD in it, and I'm glad the team trudges on.
(Score: 0, Troll) by Anonymous Coward on Monday October 19 2020, @05:36AM (1 child)
With linux all contaminated by systemd, backed up with IBM/Red Hat corporate backing, BSD needs to step up.
This is the chance that BSD can take significant marketshare from Linux.
Oh wait, BSD license means private vendors will simply skim off the profit. This is why BSD never established itself except as a niche OS - private vendors modified it for their needs and turned it into proprietary IP.
(Score: 3, Informative) by Rosco P. Coltrane on Monday October 19 2020, @09:35AM
You realize that Linux and BSD are kernels, right?
If you want a systemd-free Linux, have at it.
(Score: 0) by Anonymous Coward on Monday October 19 2020, @07:46AM (1 child)
Please be aware that running hw-probe without parameters implies
"-all -upload" and will upload a lot of information about your
current OS and hardware configuration to the online database.
(Score: 2) by choose another one on Monday October 19 2020, @07:57AM
Silent consent for telemetry good, Microsoft telemetry bad.
Sure it makes sense to someone.
All your data are belong to someone...
(Score: 2) by DannyB on Monday October 19 2020, @01:42PM (2 children)
25 years old, and only 2 remote holed in the default install? How did I not hear about this Linux distribution?
<no-sarcasm>
Not too long ago, Java celebrated its 25th birthday. So this is younger than Java? That doesn't sound right.
</no-sarcasm>
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 5, Informative) by TheRaven on Monday October 19 2020, @03:40PM (1 child)
OpenBSD is a fork of NetBSD, which is a fork of 386BSD, which was a port of 4BSD, which was the successor to the Berkeley patch set on AT&T UNIX. The OpenBSD project is much younger than the linear ancestors of the current OpenBSD codebase. The 386 was the first x86 CPU that could run a *NIX system without jumping through hoops and it wasn't cheap enough for most people to care about until around 1990, Linux and 386BSD (and BSD/386) came after that. Java 1.0 shipped with a JVM that ran on Windows 3.11: cooperative multitasking and no memory protection (though it did require Win32s, so needed a 386 or newer).
sudo mod me up
(Score: 4, Informative) by DannyB on Monday October 19 2020, @04:13PM
Thanks for the informative part. I knew (from Groklaw) that OpenBSD went back much further, but I didn't know the details.
Java 1.0 also shipped a JVM that ran on Classic Mac (System 8 or 9, IIRC) cooperative multitasking and no memory protection.
In those daze, JVM interpreted bytecodes from the Java language compiler. Today the JVM is one of the most sophisticated runtimes. Those bytecodes are not only JIT compiled, but by two JIT compilers. First C1 comes along and quickly compiles bytecode into straightforward machine code. Later C2 comes along and recompiles that same bytecode again, spending a lot of time optimizing globally across the entire running JVM, generating much more optimal machine code for the same function. Even better, if YOUR function A calls MY function B, and for some reason a new version of my function B were dynamically reloaded in a running JVM, your function A might have stale code that the compiler had inlined from my function B. So JVM will de-optimize both B and A, so they are being bytecode interpreted again until C1 and then later C2 come along and recompile them again.
My how things change.
Today there are other compilers that compile other languages into JVM bytecode that can be ran together in a single JVM runtime.
GraalVM takes this to the next step where all that JVM bytecode is compiled ahead of time into native code -- like a C compiler. The results are as one would expect -- it doesn't perform as well as the JVM runtime, but program start up time is much faster. Why? Startup time is much faster obviously because you don't have to wait for C1 and C2. Programs on JVM seem to "warm up" due to C1 and C2. But an ahead of time compiler that compiles code prior to the start of program execution can't match the performance of the C2 compiler inside the JVM. That C2 compiler has access to the ENTIRE program, and knows exactly what CPU instruction set it can compile for. For instance, does your CPU have this or that instruction set extensions? Then C2 can use it -- right now, today, on this machine we're running on. An ahead of time compiler can't do that. Also knowing the entire program allows cross-module optimizations that an ahead off time (before the linker) compiler cannot assume.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.