There’s a lot of releases happening.
- Next NYCBUG meeting: February 5th. I’ll post a reminder.
- Don’t forget there’s ChiBUG and SEMIBUG meetings coming up on the 11th and 18th, respectively.
- FOSDEM 2020 is happening now and there’s a BSD devroom. (reminded via)
- The MWL 2020 Asia Tour. Worth catching if you are on that side of the world; these events sound fun.
- FreeBSD quarterly status report for 2019Q4.
- “OpenBSD/arm64 on the Pinebook Pro with working wireless, USB and graphics!” (via)
- Related: Never underestimate the bandwidth of a bored open source developer. (via)
- HardenedBSD Tor Onion Service v3 Nodes.
- The Idealistic Future of HardenedBSD.
- LPE and RCE in OpenBSD OpenSMTPD. (via)
- Related: OpenSMTPD advisory dissected. (via)
- Deploy Kubernetes Cluster on FreeBSD Bhyve (CBSD). (via)
- Meet FuryBSD: A New Desktop BSD Distribution. (via)
- Thoughts on FuryBSD 12.0. (via)
- Insights into Why Hyperbola GNU/Linux is Turning into Hyperbola BSD. (via)
- FreeNAS 11.3-RELEASE Available. (via)
- Announcing the pkgsrc-2019Q4 release.
- Valuable News – 2020/01/27.
- Debugging FFS Mount Failures. On NetBSD, but FFS is everywhere.
- First release candidate for NetBSD 9.0 available!
- Clang build bot now uses two-stage builds, and other LLVM/LLDB news. NetBSD.
- GSoC 2019 Final Report: Incorporating the memory-hard Argon2 hashing scheme into NetBSD.
- Working towards LLDB on i386. NetBSD.
- Improving the ptrace(2) API and preparing for LLVM-10.0. NetBSD.
- Symlinking FreeBSD svnlite to svn.
- pppac(4) replaces tun(4) in npppd(8). OpenBSD.
- [packages] firefox 71.0: pledge configuration change. OpenBSD.
- Should you abandon Linux and switch to *BSD?
- OPNsense 19.7.10 released.
- OPNsense 20.1 “Keen Kingfisher” released.
- BSD Link Roundup 1.29.
- FreeBSD MiniConf at LCA2020 Conference Recap. (via)
- Locking down the Instance Metadata Service: Announcing imds-filterd. I like new tools for not-BSD coming from BSD-using vendor.
There are a growing number of why I switched from Linux to BSD articles. One thing this means is there are enough Linux users that some consider switching. The other seems to be a reflection of adopting the Unix philosophy and then looking for a operating system that is easier to understand.
One of the events that really pushed Linux into the mainstream happened when Donald Becker wrote the first network drivers for Linux in order to build a high-performance computing cluster at Los Alamos National Laboratory. Without networking Linux would not have become the popular system it currently is nor would it dominate the supercomputing industry.
While networking is still important, in my opinion, one of the driving technologies behind today’s computers is general purpose GPU computing. Today the GPU is not just for scientific computing, but drives a whole new class of machine learning algorithms that are universally being used to process big data. Not being able to run a convolutional neural-network in the 20s is on the same level as a computer without networking in the late 80s.
I understand CUDA is a closed proprietary software owned by NVIDIA that is difficult to port to BSD. On the other hand AMD Radeon Open Compute is open-source software. Moreover, rumor has it that AMD accelerators will be used in Frontier–likely be the first exascale supercomputer in the world. As a result the AMD ROCm GPU software is likely to obtain significantly more attention, polish and popularity.
By the mid 90s Linux had become relevant largely because of networking drivers written as part of the Beowulf project. In the 20s, it appears GPU acceleration is enjoying a widespread applicability outside of scientific computing in a similar way. With this observation I ask the following questions:
Is there an effort to port the AMD ROCm general-purpose computing GPU drivers to any BSD?
Has an analysis for DragonflyBSD been done to determine how difficult such a port would be?
Im really puzzled about those license wars. I read this hyperbola interview and was slightly amused about their approach of forking bsd to relicense under GPL V3 and rewriting ZFS etc. But then I came across the comments section… Im quite pragmatic, I love the GPL as much as I respect MIT, why can’t someone just keep the original licenses? Why do the Gnus have to GPLify BSD code? Why do the BSDs have to liberate userland by rewriting tools? Why all of a sudden everyone is proud of compiling their kernel with clang? Do I miss something out? Is dual licensing a bad idea? Is mixing licenses in a SW distribution a bad thing? Has a mono culture any advantages?
With both licenses in play, I imagine you get the worst of both worlds. You get the restrictions from the GNU license, and … well, there aren’t much restrictions from a BSD license.
I see your analogy, but I don’t think there’s anywhere the demand for GPU usage now like there was for decent network performance then.