NOTES

This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Headlines

NetBSD 10 on a Pinebook Pro

OpenBSD extreme privacy setup

News Roundup

Version 256 of systemd boasts '42% less Unix philosophy'

Posix.1 2024 is out

Blocking Access From or to Specific Countries Using FreeBSD and Pf

Beastie Bits

• BSD User Group Düsseldorf Juli 2024
• Another cool UNIX workstation, that was never released

Tarsnap

This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

Feedback/Questions

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

• Join us and other BSD Fans in our BSD Now Telegram channel

NOTES

This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Headlines

Open Source Software: The $9 Trillion Resource Companies Take for Granted

Tinkering with Manjaro and NetBSD on the Pinebook Pro: a crumbs-in-the-forest tutorial & review

News Roundup

OpenSMTPD 7.5.0p0 Released

OpenBSD 7.5 locks down with improved disk encryption support and syscall limitations

Book 8088

Custom Prometheus dashboards using Console templates

FreeBSD Foundation March 2024 Partnerships Update

Ray tracing made possible on 42-year-old ZX Spectrum: 'reasonably fast, if you consider 17 hours per frame to be reasonably fast'

Tarsnap

This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

• Join us and other BSD Fans in our BSD Now Telegram channel

NOTES
This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Headlines

The complete idiot's guide to OpenBSD on the Pinebook Pro

FreeBSD Periodic Scripts

News Roundup

The history (sort of) of service management in Unix

My journey from macOS to FreeBSD

A nice story about Unix processes "infecting" each other

Navidrome music server on FreeBSD

Tarsnap

• This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

Feedback/Questions

• Tyler - Is this enough for VMs
• Kevin - BSD from RAMdisk
• Malcolm - wired headset in FreeBSD

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

NOTES
This episode of BSDNow is brought to you by Tarsnap

Headlines

Chasing a bad commit

While working on a big project where multiple teams merge their feature branches frequently into a release Git branch, developers often run into situations where they find that some of their work have been either removed, modified or affected by someone else's work accidentally. It can happen in smaller teams as well. Two features could have been working perfectly fine until they got merged together and broke something. That's a highly possible case. There are many other cases which could cause such hard to understand and subtle bugs which even continuous integration (CI) systems running the entire test suite of our projects couldn't catch.
We are not going to discuss how such subtle bugs can get into our release branch because that's just a wild territory out there. Instead, we can definitely discuss about how to find a commit that deviated from an expected outcome of a certain feature. The deviation could be any behaviour of our code that we can measure distinctively — either good or bad in general.

New FreeBSD Core Team Elected

The FreeBSD Project is pleased to announce the completion of the 2020 Core Team election. Active committers to the project have elected your Eleventh FreeBSD Core Team.!

• Baptiste Daroussin (bapt)
• Ed Maste (emaste)
• George V. Neville-Neil (gnn)
• Hiroki Sato (hrs)
• Kyle Evans (kevans)
• Mark Johnston (markj)
• Scott Long (scottl)
• Sean Chittenden (seanc)
• Warner Losh (imp) ***

News Roundup

Getting Started with NetBSD on the Pinebook Pro

If you buy a Pinebook Pro now, it comes with Manjaro Linux on the internal eMMC storage. Let’s install NetBSD instead!
The easiest way to get started is to buy a decent micro-SD card (what sort of markings it should have is a science of its own, by the way) and install NetBSD on that. On a warm boot (i.e. when rebooting a running system), the micro-SD card has priority compared to the eMMC, so the system will boot from there.

• A FreeBSD developer has borrowed some of the NetBSD code to get audio working on RockPro64 and Pinebook Pro: https://twitter.com/kernelnomicon/status/1282790609778905088 ***

FreeBSD on the Intel 10th Gen i3 NUC

I have ended up with some 10th Gen i3 NUC's (NUC10i3FNH to be specific) to put to work in my testbed. These are quite new devices, the build date on the boxes is 13APR2020. Before I figure out what their true role is (one of them might have to run linux) I need to install FreeBSD -CURRENT and see how performance and hardware support is.

pf table size check and change

Did you know there’s a default size limit to pf’s state table? I did not, but it makes sense that there is one. If for some reason you bump into this limit (difficult for home use, I’d think), here’s how you change it
There is a table-entries limit specified, you can see current settings with
'pfctl -s all'. You can adjust the limits in the /etc/pf.conf file
containing the rules with a line like this near the top:
set limit table-entries 100000

• In the original mail thread, there is mention of the FreeBSD sysctl net.pf.request_maxcount, which controls the maximum number of entries that can be sent as a single ioctl(). This allows the user to adjust the memory limit for how big of a list the kernel is willing to allocate memory for. ***

Beastie Bits

• tmux and bhyve
• Azure and FreeBSD
• Groff Tutorial *** ###Tarsnap
• This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups. Tarsnap Mastery

Feedback/Questions

• Chris - ZFS Question
• Patrick - Tarsnap
• Pin - pkgsrc ***
• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

NOTES
This episode of BSDNow is brought to you by Tarsnap

Headlines

FreeBSD 11.4-RC2 Now Available

The second RC build of the 11.4-RELEASE release cycle is now available.

• 11.4-RELEASE notes (still in progress at the time of recording) ***

Install OpenBSD 6.7-current on a PineBook Pro 64

This document is work in progress and I'll update the date above once I change something. If you have something to add, remarks, etc please contact me. Preferably via Mastodon but other means of communication are also fine.

---

News Roundup

Understanding How OpenZFS Keeps Your Data Safe

Veteran technology writer Jim Salter wrote an excellent guide on the ZFS file system’s features and performance that we absolutely had to share. There’s plenty of information in the article for ZFS newbies and advanced users alike. Be sure to check out the article over at Ars Technica to learn more about ZFS concepts including pools, vdevs, datasets, snapshots, and replication, just to name a few.

---

Bringing FreeBSD to ec2

Colin is the founder of Tarsnap, a secure online backup service which combines the flexibility and scriptability of the standard UNIX "tar" utility with strong encryption, deduplication, and the reliability of Amazon S3 storage. Having started work on Tarsnap in 2006, Colin is among the first generation of users of Amazon Web Services, and has written dozens of articles about his experiences with AWS on his blog.

---

FreeBSD 2020 Community Survey

The FreeBSD Core Team invites you to complete the 2020 FreeBSD Community Survey. The purpose of this survey is to collect quantitative data from the public in order to help guide the project’s priorities and efforts. This is only the second time a survey has been conducted by the FreeBSD Project and your input is valued.
The survey will remain open for 14 days and will close on June 16th at 17:00 UTC (Tuesday 10am PDT).

---

Beastie Bits

• FreeBSD Project Proposals
• TJ Hacking
• Scotland Open Source podcast
• Next FreeBSD Office Hours on June 24, 2020 ***

Feedback/Questions

• Tom - Writing for LPIrstudio
• Luke - rstudio
• Matt - Vlans and Jails

• Morgan - Can I get some commentary on this issue

  ---

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

  ---

Sponsored By:

• Tarsnap Promo Code: bsdnow

Headlines

The UNIX Philosophy in 2019

Today, Linux and open source rules the world, and the UNIX philosophy is widely considered compulsory. Organizations are striving to build small, focused applications that work collaboratively in a cloud and microservices environment. We rely on the network, as well as HTTP (text) APIs for storing and referencing data. Moreover, nearly all configuration is stored and communicated using text (e.g. YAML, JSON or XML). And while the UNIX philosophy has changed dramatically over the past 5 decades, it hasn’t strayed too far from Ken Thompson’s original definition in 1973:

• We write programs that do one thing and do it well
• We write programs to work together
• And we write programs that handle text streams, because that is a universal interface

Why Use Package Managers?

Valuable research is often hindered or outright prevented by the inability to install software. This need not be the case.

Since I began supporting research computing in 1999, I’ve frequently seen researchers struggle for days or weeks trying to install a single open source application. In most cases, they ultimately failed.

In many cases, they could have easily installed the software in seconds with one simple command, using a package manager such as Debian packages, FreeBSD ports, MacPorts, or Pkgsrc, just to name a few.

Developer websites often contain poorly written instructions for doing “caveman installs”; manually downloading, unpacking, patching, and building the software. The same laborious process must often be followed for other software packages on which it depends, which can sometimes number in the dozens. Many researchers are simply unaware that there are easier ways to install the software they need. Caveman installs are a colossal waste of man-hours. If 1000 people around the globe spend an average of 20 hours each trying to install the same program that could have been installed with a package manager (this is not uncommon), then 20,000 man-hours have been lost that could have gone toward science. How many important discoveries are delayed by this?

The elite research institutions have ample funding and dozens of IT staff dedicated to research computing. They can churn out publications even if their operation is inefficient. Most institutions, however, have few or no IT staff dedicated to research, and cannot afford to squander precious man-hours on temporary, one-off software installs. The wise approach for those of us in that situation is to collaborate on making software deployment easier for everyone. If we do so, then even the smallest research groups can leverage that work to be more productive and make more frequent contributions to science.

Fortunately, the vast majority of open source software installs can be made trivial for anyone to do for themselves. Modern package managers perform all the same steps as a caveman install, but automatically. Package managers also install dependencies for us automatically.

News Roundup

Touchpad, Interrupted

For two years I've been driving myself crazy trying to figure out the source of a driver problem on OpenBSD: interrupts never arrived for certain touchpad devices. A couple weeks ago, I put out a public plea asking for help in case any non-OpenBSD developers recognized the problem, but while debugging an unrelated issue over the weekend, I finally solved it.

It's been a long journey and it's a technical tale, but here it is.

Porting wine to amd64 on NetBSD, second evaluation report

• Summary

Presently, Wine on amd64 is in test phase. It seems to work fine with caveats like LD_LIBRARY_PATH which has to be set as 32-bit Xorg libs don't have ${PREFIX}/emul/netbsd32/lib in its rpath section. The latter is due to us extracting 32-bit libs from tarballs in lieu of building 32-bit Xorg on amd64. As previously stated, pkgsrc doesn't search for pkgconfig files in ${PREFIX}/emul/netbsd32/lib which might have inadvertent effects that I am unaware of as of now. I shall be working on these issues during the final coding period. I would like to thank @leot, @maya and @christos for saving me from shooting myself in the foot many a time. I, admittedly, have had times when multiple approaches, which all seemed right at that time, perplexed me. I believe those are times when having a mentor counts, and I have been lucky enough to have really good ones. Once again, thanks to Google for this wonderful opportunity.

Enhancing Syzkaller Support for NetBSD, Part 2

As a part of Google Summer of Code’19, I am working on improving the support for Syzkaller kernel fuzzer. Syzkaller is an unsupervised coverage-guided kernel fuzzer, that supports a variety of operating systems including NetBSD. This report details the work done during the second coding period.

You can also take a look at the first report to learn more about the initial support that we added. : https://blog.netbsd.org/tnf/entry/enhancing_syzkaller_support_for_netbsd

July Update: All about the Pinebook Pro

"So I said I won’t be talking about the BSDs, but I feel like I should at the very least give you a general overview of the RK3399 *BSD functionality. I’ll make it quick. I’ve spoken to *BSD devs whom worked on the RockPro64 and from what I’ve gathered (despite the different *BSDs having varying degree of support for the RK3399 SOC) many of the core features are already supported, which bodes well for *BSD on the Pro. That said, some of the things you’d require on a functional laptop – such as the LCD (using eDP) for instance – will not work on the Pinebook Pro using *BSD as of today. So clearly a degree of work is yet needed for a BSD to run on the device. However, keep in mind that *BSD developers will be receiving their units soon and by the time you receive yours some basic functionality may be available."

Killing a process and all of its descendants

Killing processes in a Unix-like system can be trickier than expected. Last week I was debugging an odd issue related to job stopping on Semaphore. More specifically, an issue related to the killing of a running process in a job. Here are the highlights of what I learned:

Unix-like operating systems have sophisticated process relationships. Parent-child, process groups, sessions, and session leaders. However, the details are not uniform across operating systems like Linux and macOS. POSIX compliant operating systems support sending signals to process groups with a negative PID number.

Sending signals to all processes in a session is not trivial with syscalls.

Child processes started with exec inherit their parent signal configuration. If the parent process is ignoring the SIGHUP signal, for example, this configuration is propagated to the children.

The answer to the “What happens with orphaned process groups” question is not trivial.

Fast Software, the Best Software

I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.

Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.

But why is slow bad? Fast software is not always good software, but slow software is rarely able to rise to greatness. Fast software gives the user a chance to “meld” with its toolset. That is, not break flow. When the nerds upon Nerd Hill fight to the death over Vi and Emacs, it’s partly because they have such a strong affinity for the flow of the application and its meldiness. They have invested. The Tool Is Good, so they feel. Not breaking flow is an axiom of great tools.

A typewriter is an excellent tool because, even though it’s slow in a relative sense, every aspect of the machine itself operates as quickly as the user can move. It is focused. There are no delays when making a new line or slamming a key into the paper. Yes, you have to put a new sheet of paper into the machine at the end of a page, but that action becomes part of the flow of using the machine, and the accumulation of paper a visual indication of work completed. It is not wasted work. There are no fundamental mechanical delays in using the machine. The best software inches ever closer to the physical directness of something like a typewriter. (The machine may break down, of course, ribbons need to be changed — but this is maintenance and separate from the use of the tool. I’d be delighted to “maintain” Photoshop if it would lighten it up.)

Beastie Bits

• Register for vBSDCon 2019, Sept 5-7 in Reston VA
• Register for EuroBSDCon 2019, Sept 19-22 in Lillehammer, Norway

Feedback/Questions

• Paulo - FreeNAS Question
• Marc - Changing VT without function keys?
• Caleb - Patch, update, and upgrade management

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv