Announcing HyperbolaBSD, IPFW In-Kernel NAT setup on FreeBSD, Wayland and WebRTC enabled for NetBSD 9/Linux, LLDB Threading support ready for mainline, OpenSSH U2F/FIDO support in base, Dragonfly drm/i915: Update, and more.
Due to the Linux kernel rapidly proceeding down an unstable path, we are planning on implementing a completely new OS derived from several BSD implementations.
This was not an easy decision to make, but we wish to use our time and resources to create a viable alternative to the current operating system trends which are actively seeking to undermine user choice and freedom.
This will not be a "distro", but a hard fork of the OpenBSD kernel and userspace including new code written under GPLv3 and LGPLv3 to replace GPL-incompatible parts and non-free ones.
- Reasons for this include:
- Linux kernel forcing adaption of DRM, including HDCP.
- Linux kernel proposed usage of Rust (which contains freedom flaws and a centralized code repository that is more prone to cyber attack and generally requires internet access to use.)
- Linux kernel being written without security and in mind. (KSPP is basically a dead project and Grsec is no longer free software)
- Many GNU userspace and core utils are all forcing adaption of features without build time options to disable them. E.g. (PulseAudio / SystemD / Rust / Java as forced dependencies)
- As such, we will continue to support the Milky Way branch until 2022 when our legacy Linux-libre kernel reaches End of Life.
Future versions of Hyperbola will be using HyperbolaBSD which will have the new kernel, userspace and not be ABI compatible with previous versions.
HyperbolaBSD is intended to be modular and minimalist so other projects will be able to re-use the code under free license.
After graduating college, I am moving from Brooklyn, NY to Redmond, WA (guess where I got a job). I always wanted to re-do my OPNsense firewall (currently a HP T730) with stock FreeBSD and IPFW’s in-kernel NAT.
Why IPFW? Benchmarks have shown IPFW to be faster which is especially good for my Tor relay, and because I can! However, one downside of IPFW is less documentation vs PF, even less without natd (which we’re not using), and this took me time to figure this out.
But since my T730 is already packed, I am testing this on a old PC with two NICs, and my laptop  as a client with an USB-to-Ethernet adapter.
This is just a heads up that the Wayland option is now turned on by
default for NetBSD 9 and Linux in cases where it peacefully coexists
- Right now, this effects the following packages:
The WebRTC option has also been enabled by default on NetBSD 9 for two Firefox versions: www/firefox, www/firefox68
Please keep me informed of any fallout. Hopefully, there will be none.
If you want to try out Wayland-related things on NetBSD 9, wm/velox/MESSAGE may be interesting for you.
Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages.
In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support, extending NetBSD's ptrace interface to cover more register types and fix compat32 issues and fixing watchpoint support. Then, I've started working on improving thread support which is taking longer than expected. You can read more about that in my September 2019 report.
So far the number of issues uncovered while enabling proper threading support has stopped me from merging the work-in-progress patches. However, I've finally reached the point where I believe that the current work can be merged and the remaining problems can be resolved afterwards. More on that and other LLVM-related events happening during the last month in this report.
Hardware backed keys can be generated using "ssh-keygen -t ecdsa-sk" (or "ed25519-sk" if your token supports it). Many tokens require to be touched/tapped to confirm this step.
You'll get a public/private keypair back as usual, except in this case, the private key file does not contain a highly-sensitive private key but instead holds a "key handle" that is used by the security key to derive the real private key at signing time.
So, stealing a copy of the private key file without also stealing your security key (or access to it) should not give the attacker anything.
- drm/i915: Update to Linux 4.8.17
- Broxton, Valleyview and Cherryview support improvements
- Broadwell and Gen9/Skylake support improvements
- Broadwell brightness fixes from OpenBSD
- Atomic modesetting improvements
- Various bug fixes and performance enhancements
- Visual Studio Code port for FreeBSD
- OpenBSD syscall call-from verification
- Peertube on OpenBSD
- Fuzzing Filesystems on NetBSD via AFL+KCOV by Maciej Grochowski
- Twitter Bot for Prop65
- Interactive vim tutorial
- First BSD user group meeting in Hamilton, February 11, 2020 18:30 - 21:00, Boston Pizza on Upper James St ***
- Send questions, comments, show ideas/topics, or stories you want mentioned on the show to email@example.com