Podcasts about FreeBSD

video: https://youtu.be/CVkZvrh7qpw Ubuntu is shipping a kernel that can make certain AMD workloads up to 42 times slower. Linus Torvalds is drawing clearer boundaries around AI-generated code in the kernel. Secure Boot just passed a major certificate expiration deadline. COSMIC Desktop 1.3 brings a polished new Frosted Glass design. And one developer decided to add another place and that's a Sega Genesis from 1994. All of this and more on This Week in Linux. Now let's jump right into Your Source for Linux GNews! Download as MP3 Support the Show Become a Patron = tuxdigital.com/membership Store = tuxdigital.com/store Chapters: 00:00 Intro 00:44 Ubuntu publishes Update that introduces regression for AMD users 03:52 Linus Torvalds talks on AI Code in Linux 07:12 Secure Boot Linux Certificates Expired? 09:27 COSMIC 1.3 with Frosted Glass 11:33 AppManager for AppImages 14:51 FreeBSD Removes All GPL Code 17:16 Rapid Fire Lightning Round 17:40 stillOS 10.2 Released 18:32 Blender 5.2 LTS Released 19:00 Clonezilla Live 3.3.3 Released 19:31 Linux on Sega Genesis and 32X Addon 20:26 Outro Links: Ubuntu publishes Update that introduces regression for AMD users https://discourse.ubuntu.com/t/amdgpu-performance-regression-in-kernel-7-0-0-28-28/85237 Linus Torvalds talks on AI Code in Linux https://lore.kernel.org/linux-media/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/ https://www.phoronix.com/news/Linux-Is-Not-Anti-AI https://www.gamingonlinux.com/2026/07/linux-creator-linus-torvalds-puts-foot-down-on-anti-ai-comments/ https://itsfoss.com/news/linus-torvalds-on-ai/ Secure Boot Linux Certificates Expired? https://lwn.net/Articles/1079808/ https://almalinux.org/blog/2026-07-14-secure-boot-2023-certificates/ https://linuxiac.com/debian-13-6-released-with-120-security-fixes-and-124-stability-updates/ COSMIC 1.3 with Frosted Glass https://9to5linux.com/cosmic-1-3-desktop-environment-released-with-frosted-glass-effect https://www.phoronix.com/news/COSMIC-Epoch-1.3 AppManager for AppImages https://github.com/kem-a/AppManager https://www.omgubuntu.co.uk/2026/07/appmanager-appimage-installer-linux https://github.com/VHSgunzo/uruntime FreeBSD Removes All GPL Code https://www.phoronix.com/news/FreeBSD-16-Goes-GPL-Free https://fossforce.com/2026/07/freebsd-16-cleans-house-no-gpl-left-in-the-base-system/ https://www.phoronix.com/news/FreeBSD-Intern-AMD-ROCm https://www.phoronix.com/news/FreeBSD-Laptops-June-2026 https://www.phoronix.com/news/FreeBSD-Desktop-Install-NVIDIA stillOS 10.2 Released https://stillhq.io/stillos-gets-gnome-49-a-better-first-boot-and-major-swai-improvements/ Blender 5.2 LTS Released https://www.blender.org/download/releases/5-2/ Clonezilla Live 3.3.3 Released https://clonezilla.org/downloads/stable/release-notes.php Linux on Sega Genesis and 32X Addon https://cakehonolulu.github.io/linux-on-32x/ https://github.com/LinuxMD/linuxmd https://www.tomshardware.com/software/linux/developer-successfully-ports-linux-to-1994-sega-32x-genesis-and-megadrive-expansion-runs-open-source-os-on-paltry-23mhz-processors-and-256kb-of-ram Support the show https://tuxdigital.com/membership https://store.tuxdigital.com/

Unix Pipes under Load, Powering up a IBM Calculator from 1948, FreeBSD AI assisted Vulnerability Discovery Project, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Unix Pipes Under Load: Streaming, Barriers, Backpressure, and Bottlenecks Powering up a module from the IBM 604: an electronic calculator from 1948 News Roundup FreeBSD AI-assisted Vulnerability Discovery Project launch Sometimes it actually is the network: a war story FreeBSD Tribal Knowledge: Boot Enviroment Management Beastie Bits OpenSSH 10.4/10.4p1 released! OpenBSD/amd64 kernel virtual address space is now 512GB OpenBSD's pledge(2) and unveil(2) are developer-friendly, study finds 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

The 40 Most Rage-Inducing Problems in Tech, ZFS vs Cep, Detecting and removing dangerous secrets on dev workstations before Shai-Hulud does and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines The 40 Most Rage-Inducing Problems in Tech ZFS vs Ceph: Do You Actually Need Ceph? News Roundup Detecting and removing dangerous secrets on dev workstations before Shai-Hulud does FreeBSD sh for MacOS syslogd(8) privileged and non-privileged parts now separate binaries Getting Victoria Logs running 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 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

This show has been flagged as Clean by the host. 01 Introduction In this episode I will describe how to calculate elapsed time in bash or other shell scripts. While this may sound like a very simple and basic thing to do, there is a slightly more complex aspect to it if you wish to calculate elapsed time to a higher resolution than one second. 02 There are many reasons for calculating elapsed time in a shell script. For example you may wish to simply report how long an operation took to run. Another reason may be that you are trying to speed up a script and need to calculate benchmark data to see how different alternative methods perform. 03 What may seem like a simple task gets a bit more complicated if you want to do it for multiple different operating systems even if they are all unix related, as we shall see. -------------------- 04 Operating Systems Tested For the purposes of this episode, I ran tests on the current version of the following operating systems. Alma Alpine Debian FreeBSD OpenBSD RaspberryPi OpenSuse Ubuntu 2604 Alma is a close copy of Red Hat that we can take as representing Red Hat style distros. -------------------- 05 Simple Low Resolution Timing I will start with the simple and obvious method before describing the less obvious ones. This uses the date command to get the current time in seconds since the unix epoch. This is simply date '+%s' 06 Save this to a variable using whatever method you prefer. For example. starttime=$(date '+%s') 07 Next, do whatever operations it is you wish to time. Use the date command to get the current time again. endtime=$(date '+%s') 08 Now simply subtract the start time from the end time using shell arithmetic. This should be very obvious and basic. -------------------- 09 Higher Resolution Timing However, suppose we wish to measure time to greater than one second of precision. We need to do two things. The first is to obtain the current time at a higher degree of precision. The second is to conduct the calculations to a higher degree of precision. 10 Unfortunately, the standard time precision for POSIX shells seems to be 1 second. Some shells offer a higher precision, but others do not. Furthermore, standard shell arithmatic uses integer, which limits calculations to 1 second of precision. -------------------- 11 Bash High Resolution Shell Variable Fortunately, bash is one that does offer a high precision date. If you are using bash 5.0 or newer, there is a shell variable called EPOCHREALTIME which offers time since the the unix epoch (that is, since the first of January 1970, at 00:00:00 UTC) in seconds to 6 decimals of precision. 12 Example echo $EPOCHREALTIME 1779634800.184926 13 This is related to the similar bash variable known as EPOCHSECONDS which gives the number of seconds since the unix epoch. 14 Example echo $EPOCHSECONDS 1779634800 15 So if you are using bash, measuring time is very simple. -------------------- 16 But is it Really Bash? Is your script however actually using bash? Debian and derivatives actually have two shells. The first, the interactive shell is bash. The second, the non-interactive shell is dash, which stands for "debian almquist shell". 17 If you open a terminal, you get bash. If your script starts with a "bin/bash" shebang line, you get bash. However, if your script starts with a "bin/sh" shebang line, you get dash. Some people find themselves getting caught out by this one when they try something out in a terminal but find that it doesn't work in their script which started with "bin/sh". 18 Many other, but not all, Linux distros use bash for both the interactive and non-interactive shells, so "bin/sh" and "bin/bash" work the same with those ones. So if you intend to use bash, make sure your script calls for bash in the first line. -------------------- 19 The SHELL Variable So how can a script tell what shell it is running under? There is a shell variable called "SHELL" which will tell you the name of the shell. Well, sort of. 20 On Debian and derivatives "SHELL" will say "bash" regardless of whether the actual shell is bash or dash. On some other operating systems "SHELL" will simply say "sh" even if it is something else entirely. So we need to do some additional levels of checking to see what we have. 21 To start with though, here's what each of the test distros reports for SHELL. Alma : bash Alpine : sh Debian : bash FreeBSD : sh OpenBSD : ksh Raspberry-Pi : bash Suse : bash ubuntu2604 : bash -------------------- 22 Bash Versus Dash First, let's try to see which ones are bash and which ones are dash. The first thing we can check is for the shell variable BASH_VERSION. 23 Example echo $BASH_VERSION If the shell is bash, then it will report a version string. If the shell is not bash, then it will return an empty value. 24 Using this test, we can see that Alma and Opensuse are indeed using bash. We however need to check Debian, Raspberry Pi, and Ubuntu when running in an "sh" script. To check this we can use the "which" command to see what "sh" actually is. 25 Example echo $( ls -l $(which sh ) | rev | cut -d" " -f1 | cut -d/ -f1 | rev ) 26 "which sh" shows us the path to "sh" However, that is a link so we need to use "ls -l" to find the actual executable. "rev" reverses the string. 27 "cut" takes the first element separated by spaces. The second "cut" takes the first element separated by the "/" characters. The final "rev" takes that string and reverses it again to get it in the correct order. 28 In the case of Debian, Raspberry Pi, and Ubuntu it tells us that this is "dash". -------------------- 29 Openbsd Openbsd reports its shell as "ksh", which stands for Korn Shell. It is indeed Korn Shell, so we simply leave that one as is. -------------------- 30 Alpine and Freebsd Next we have Alpine Linux and Freebsd, which both report as "sh". In the case Freebsd there doesn't appear to be any further we can go that I am aware of. It's simple "sh". It is a basic POSIX shell which seems to be similar to the original unix shell, the Bourne Shell. Older versions of Freebsd used a different shell known as tsch (the C shell), but I haven't tested that so I will ignore that here. 31 With Alpine Linux however, we can get the actual shell using the same method that we used for Debian Linux. This reports as being "busybox". 32 Busybox is a limited shell intended for use in embedded systems. Alpine was originally an embedded distro, but some people started using it for containers. Alpine is Linux, but it is not GNU/Linux, and there are a number of areas which can trip you up if you are not aware of them. So, be extra careful if you are using it for anything, and test everything. -------------------- 33 Summary of Actual Shells Here is our revised list with the actual shell used when asking for "sh", so far as we can determine. Alma : bash Alpine : busybox Debian : dash FreeBSD : sh OpenBSD : ksh Raspberry-Pi : dash Suse : bash ubuntu2604 : dash 34 There are other shells, but none of them are the default shell for any of the distros on our list, so I haven't tested them. -------------------- 35 Solutions for Measuring Time Now we need to find solutions for bash, dash, ksh, sh, and busybox. -------------------- 36 Bash For bash, we can simply use EPOCHREALTIME, as mentioned above. -------------------- 37 Dash For dash, we can use the date command. This is a very conventional method, and is probably the first answer that anyone would give for this situation. However, while it will work in most cases, it will not work in all cases, so it is not a universal solution. 38 To use date we simply call it with the correct format string. This uses %s to get seconds since the epoch, and %N to get nanoseconds of the current second. If you put a decimal separator between the two it will appear in the output. You can use the correct decimal separator for your locale, but I won't go into that here. Instead I will just assume a period or dot. 39 Example date '+%s.%N' 1779634800.358916385 -------------------- 40 Problems with Date on Alpine and Openbsd Date will work for bash, dash, and sh on Freebsd. However it will not work for ksh on Openbsd, or for busybox on Alpine. 41 With busybox on Alpine, it simply ignores the %N format specifier and prints out the epoch in seconds only followed by the decimal separator. = Example date '+%s.%N' 1779634800. 42 With ksh on Openbsd it prints the epoch in seconds followed by the decimal separator and then the %N as a literal N. date '+%s.%N' 1779634800.N 43 Fortunately we have alternatives for these two cases. -------------------- 44 Openbsd Openbsd has the "ts" or timestamp utility installed by default. ts prints a time stamp in front of every line it receives from standard input. I won't go into details on all aspects of ts here, I'll leave that to someone else. Instead I will focus on how to use it for our specific purposes here. 45 We need to provide a format specifier to ts, which in this case is "%.s" We also need to provide something for standard input, or otherwise ts will simply sit there and wait for input. So what we need to do is to echo nothing through a pipe to ts while also giving ts the proper format specifier. 46 Example echo | ts "%.s" 47 This will output the epoch time in seconds to six decimals of precision. ts is installed in Openbsd and Freebsd by default and can be used in either. It can also be installed in many other distros. -------------------- 48 Busybox on Alpine None of the methods discussed so far will work for busybox on Alpine though. However there is a way, but it's a bit non obvious and somewhat hacky. 49 Busybox includes a command called "adjtimex". This is normally used to adjust the time hardware. However if it is run without arguments, it will report the current settings. 50 These include the current epoch time in seconds , and in another field the time in microseconds. These are reported as key value pairs. So what we need to do is to do the following 51 Run adjtimex Capture the output. Grep for "time.tv_sec" Grep for "time.tv_usec" Use cut to extract the time value in each case. Use tr to get rid of excess spaces in each case. Combine the two in a string with a decimal separator between them. 52 This takes a total of 4 lines of shell script. I will just describe them breifly here, see the show notes for details. 53 First we want to capture the output of adjtimex in a single operation. Run adjtimex and pipe the output through grep to capture lines containing "time.tv_" and save this to a variable. # Extract the current high resolution time from adjtimex. # We want two key value pairs, identified by time.tv_sec and time.tv_usec. tvals=$( adjtimex | grep "time.tv_" ) 54 Next echo the contents of this variable and pipe it through grep, cut, and tr to get first the seconds and then the microseconds while also removing excess spaces. Save these to two separate variables. "time.tv_sec" is the time in seconds since the epoch. "time.tv_usec" is the number of microseconds in the current second. # Get the time since the unix epoch in seconds and micro-seconds. timesec=$( echo "$tvals" | grep "time.tv_sec" | cut -d: -f2 | tr -d " " ) timeusec=$( echo "$tvals" | grep "time.tv_usec" | cut -d: -f2 | tr -d " " ) 55 Adjtimex does not zero pad the microsecond time value to provide leading zeros, so we need to take care of this using printf before we can append it to the seconds value. We didn't need to do this with date where the %N format character does this automatically. In this instance, the printf format string is '%06d' padusec=$( printf '%06d' $timeusec ) Now, combine these into a single number with a decimal separator by using simple string concatenation. # Combine them into a single number. timehires="$timesec"".""$padusec" -------------------- 56 Summary of Methods Let's summarize where we are so far in terms of methods we can use to get the current time as a high resolution number. Alma : use EPOCHREALTIME or date Debian (bash) : use EPOCHREALTIME or date Raspberry-Pi (bash) : use EPOCHREALTIME or date ubuntu2604 (bash) : use EPOCHREALTIME or date Suse : use EPOCHREALTIME or date Debian (dash) : use date Raspberry-Pi (dash) : use date ubuntu2604 (dash) : use date Alpine : use adjtimex and parse the output FreeBSD : use date or ts OpenBSD : use ts -------------------- 57 Other alternatives There are a few alternatives that we haven't discussed yet. 58 Bash with Dash In the case of Debian, Raspberry Pi, and Ubuntu running dash, since bash is available it is possible to write a separate bash script which simply echos EPOCHREALTIME and then call it from the dash script and capture the output. While this would work, there's probably not a lot of point to it. If you can rely on bash being there, then just change the first line of the script and make it a bash script. 59 Adding Packages to Alpine The ts or timestamp utility is a common unix utility that can be installed if it is not present by default. This does produce high resolution timestamps on Alpine. On Alpine Linux this comes as part of the "moreutils" package. To add the package, use the following sudo apk add moreutils echo | ts "%.s" 1779634800.959948 60 You can also add the GNU coreutils, which will provide a high resolution date command which works like in the other examples. To add the package use the following sudo apk add coreutils date '+%s.%N' 1779634800.212897332 61 If you can install more packages into your Alpine system, either of the above two is probably going to be preferable to parsing the output of adjtimex. 62 Custom Timestamp Programs You can also write a very short program in python, perl, tcl, or some other language and have it output the current epoch time. I won't discuss that here though. -------------------- 63 Calculating Time Differences Shell arithmetic is integer only. If we wish to use high resolution timing data, we need to do something so we don't lose the precision we have worked so hard to get. There are several possible solutions. 64 Change the Time Base One method is to change the time base from seconds to milli, micro, or nanoseconds. This can be done by simply multiplying the time values by the appropriate amount (e.g. 1000, 1,000,000, etc.) before subtracting them. This allows for integer arithmetic on high resolution values without losing precision. 65 Use the Shell bc Arbitrary Precision Calculator The bc command line calculator will perform calculations using real numbers and is easy to use in scripts. It is present by default in most distros. echo "scale=9; $endtime - $starttime" | bc where endtime and starttime are variables containing time values. 66 However, for some inexplicable reason, neither Debian nor Opensuse install it by default. It is present in Ubuntu and Raspberry Pi which are Debian derivatives, and it can be added to distros which lack it. 67 Use awk awk can also perform calculations using real numbers and it is present in nearly all distros including in all of the ones we tested here. echo "$endtime $starttime" | awk '{printf "%.6fn", $1 - $2}' -------------------- 68 Benchmarks And of course no comparative evaluation would be complete without benchmarks where we see how each method compares to another in terms of speed. In the benchmark test I ran each method in a loop through multiple iterations, measured the elapsed time, subtracted out the time for an empty loop, and then compared it to alternate methods. For anything other than EPOCHREALTIME, the empty loop time is negligible and has no real effect on the results. 69 Rather interestingly I came across a bug which caused date to run very slowly if called immediately after using EPOCHREALTIME in bash. The effect of the bug was to make the date benchmark test roughly 24 times slower. This has been fixed in newer releases, but if you are using an older distro release then beware of this bug. I was able to get around it either putting a sleep delay between benchmarking EPOCHREALTIME and benchmarking date, or by simply testing date before testing EPOCHREALTIME. 70 To be able to conduct additional tests I installed ts in Ubuntu and Alpine, and the GNU version of date in Alpine. 71 EPOCHREALTIME Versus date in Ubuntu 2604 bash The EPOCHREALTIME method is 3103 times faster than date. However, when the same test is run on Ubuntu 2404 when the date test is run before the EPOCHREALTIME test, EPOCHREALTIME is 1240 faster than date. Other Linux distros show performance to Ubuntu 2404. It appears that a side effect of fixing whatever the bug is has the effect of slowing down date. However, this is probably not a significant issue in normal circumstances. 72 date versus ts in Ubuntu 2604 bash The date method is 3.7 times faster than ts 73 date versus ts in Ubuntu 2604 dash The date method is 4.9 times faster than ts 74 date versus ts in Freebsd sh The date method is 2.5 times faster than ts 75 date versus adjtimex in Alpine Busybox The date method is 6.0 times faster than adjtimex 76 date versus ts in Alpine Busybox The date method is 20.0 times faster than ts 77 bc versus awk in Ubuntu 2604 I compared calculating the difference between two numbers when using bc versus awk. The difference is negligible, with bc being only 7% faster than awk. 78 Conclusion for Benchmarks Based on these results, if you need to measure elapsed time to high resolution and care about runing the command with as little overhead as possible, then the order of preference should be the following. 79 If you are using a newer version of bash, then use EPOCHREALTIME. If that is not available, then use date, provided it allows for high resolution times. If the above two cannot be used, then use ts. If you are using Busybox and cannot install either GNU date or ts, then use adjtimex. Date is the closest in terms of being the universal portable solution, but it does not work in all cases. 80 I have not compared different platforms to each other in terms of performance, as that would be a much more involved problem that is outside the scope of this episode. However, different operating systems implement different commands in different ways. 81 For example, on Openbsd and Freebsd, ts appears to be an ELF binary. That is, it is executable machine code, possibly written in C. On Ubuntu however, ts appears to be a perl script. As a result of this, the advantage that date has over ts is much less in Freebsd than it is with Ubuntu (and likely other Linux distros) as on Freebsd it doesn't need to load a perl interpreter to run ts. -------------------- 82 Overall Conclusion You no doubt thought that measuring elapsed time was going to be so simple, and how could someone get an entire podcast out of such a simple subject? And yet here we are half an hour later with just a basic overview of the subject. 83 I hope you found this interesting and informative. Please let us know in the comments if you think that I have done anything incorrectly, or if you have another way of doing things. I hope to see you all again in another future episode of HPR. -------------------- Provide feedback on this episode.

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. In UNIX Curio #8 ( HPR episode 4657 ), I talked about using standard utilities to compare files. Left unmentioned, however, was a method commonly used today—the hash function. As I've stated in previous entries, while I am an engineer, I don't have a background in computer science, so my understanding of the mathematics is limited. But I can give a practical description of what a hash function does. It takes an input, performs a set of calculations on it, and produces an output. As hash functions are practically used, the input is a set of bytes, such as a file or another piece of data like a password. The output is a numerical value in a fixed range—most often, expressed as hexadecimal characters. Because this "hash value" can always be represented in a certain number of bytes, its length as printed is usually a constant number of characters, padded with leading zeros if necessary. This episode will not cover the use of hashes in programming, focusing instead on using them to validate data. A hash function, or more specifically, a cryptographic hash function, has an additional property. It should be very difficult to predict what changes to the input would be required to produce a specific change in the output. An older, related concept is called a "checksum". While these are designed to vary when the input data is damaged or digits are transposed, they do not necessarily have that last property mentioned for cryptographic hashes. You have probably already encountered a checksum, even if you didn't recognize it. On a 16-digit number assigned to a Mastercard or Visa 1 credit or debit card, the first six digits identify the card issuer (such as a bank), the next nine digits are assigned to you by the issuer, and the last digit is a check digit. The check digit is calculated using the values of the previous 15 digits, and it is a simple way to avoid typos in entering a card number. In another example, every Ethernet frame that your devices send or receive includes a checksum 2 to help ensure that the contents weren't scrambled in transit. This is 32 bits long and is called a cyclical redundancy check, commonly referred to as a CRC. A CRC is also used in many other places—for example, the .zip file format includes one for each archive member, and this allows a program extracting files from the archive to identify if any were damaged. Our UNIX Curio for today is another example, the cksum utility 3 . It generates a 32-bit CRC based on the Ethernet algorithm. It operates on either a named file or standard input and outputs the CRC value, the length of the input, and the pathname if a file was given as an argument. Unlike most modern hashing programs, the checksum is printed as a decimal integer and is not padded, so it can be anywhere from one to ten digits long. The length value is the number of bytes in the input (actually specified as the number of octets , as systems could potentially use a byte that isn't eight bits long), also expressed as a decimal integer. There are two major ways that one could use cksum to check the validity of a file. First, if you are transferring a file from one UNIX-like system to another, you could run cksum against it on both systems and check that the CRC and length are the same. The utility can also be given multiple filenames as arguments, which would generate a list that can then be compared. The second way would be for someone publishing a file or set of files to also publish the CRC values, lengths, and names so that people downloading them could verify that they match. However, I don't think the practice of publishing lists like this really started until more recent hash functions like MD5 and SHA-1 came about so it is unlikely that anyone would publish CRC values instead. The advantage of these tools should be pretty obvious in comparison to cmp , one of the utilities discussed in UNIX Curio #8. To verify a file using cmp , you need two files to compare—if you're trying to check a large file you downloaded, you would need to spend the time and bandwidth to download a second copy. And if they didn't match, you would have no idea which of the two, if either, was correct. By contrast, cksum is quicker to run, doesn't require downloading a massive amount of excess data, and if run against the original file, makes clear what the correct value is. This utility is a follow-on from a program called sum , which operated very much the same. I had a bit of trouble tracking down the exact development history, but what seems clear is that two different variants 4 were popular: a BSD version and a System V version. Both output 16-bit checksums, but used different algorithms so they didn't give the same results. Also, the BSD version printed the length of the input data as the number of 1,024-byte blocks, while the System V version instead gave a count of 512-byte blocks. (Some sources claim that System V sum generates a 32-bit checksum 5 , which could possibly be true internal to the algorithm, but I have tested several independent implementations of the utility and all of them output a 16-bit value for both the System V and BSD algorithms.) From what I can tell, the BSD version 6,7 came first; it was in 3BSD but probably appeared even earlier. An identical copy of BSD's sum was included with UNIX/32V 8,9 , which was AT&T's 1979 port of Seventh Edition UNIX to the VAX and became one of the ancestors of System III. The divergence seems to have started with System III, released in 1980; its version of the sum utility 10,11 changed to a new default algorithm, though it could be made to use the BSD algorithm via the -r option. System V looks to have kept the same behavior as System III. It's not clear to me why this algorithm is universally called the "System V algorithm" rather than the "System III algorithm"; perhaps it is because System V saw much more widespread use. Instead of trying to reconcile these differences, the POSIX committee decided to create a new utility with a unique name, use a separate algorithm entirely, and avoid the block-length dispute by printing the length in octets instead of blocks. I should point out that POSIX states that the CRC algorithm for cksum does not strictly meet the mathematical definition of a "checksum". I don't know enough to say exactly why it doesn't qualify or to say whether either of the sum algorithms do. However, in less-formal usage the term "checksum" has gathered the meaning of any value used to represent or validate a set of data, so I am fine with using it no matter the technical details of the algorithm. When two different inputs produce the same checksum or hash value, this is called a "collision". Because the output value has a limited range, there are an infinite number of possible inputs that could produce a collision. From a practical standpoint the possibilities are more limited—the majority of these inputs are larger than the number of atoms in the universe, which can't fit on any machine. Unlike a cryptographic hash algorithm, the CRC is not specifically designed to resist an attacker crafting a malicious input that would cause a collision. However, it should be sufficient to detect accidental damage. Programs implementing more modern cryptographic hash algorithms are superior to the checksum utilities in avoiding collisions (whether malicious or accidental), but there are still three advantages that the older programs have. First, a system running a historical operating system might not have the hash programs available, but is more likely to have cksum or sum already included. Second, the checksum values are much shorter than the hashes output by the newer programs, making them easier for a user to compare by looking at them. This advantage is not as great as it might appear at first, because a common way to check a hash these days is to save a list of hashes and filenames—the hash programs can use that and do the comparison themselves, sparing the user from having to validate it character by character. The third advantage is that cksum prints the input length in bytes. This greatly limits the number of inputs that could be maliciously crafted to create a collision. I did a moderate amount of research on implementations of modern cryptographic hash algorithms and found that some, such as MD5, SHA-1, and SHA-2, do use the length of the input (often termed "message length" in the literature) as part of the material fed in to the algorithm, but none of the hashing utilities present this length to the user as part of its output. There are two possible reasons for this that seem evident to me. First, if one is hashing a password, you would certainly not want to give a clear indication of its length—that would give any attacker a massive head start on guessing the password. However, that doesn't explain why one would avoid printing the input length for a file that is made publicly available. Second, it is convenient in many contexts, such as database entries or in software (such as git ), for the hash to be a fixed length. Including an extra value that can be of variable length would complicate those use cases. However, the length value could simply be dropped and they would be no worse off than they are currently. Historically on UNIX, password hashing was treated differently from checksumming files— the crypt() function 12 was used for passwords while sum and later cksum were used to confirm a file's integrity. So even rather early on, these two use cases employed algorithms with different properties, but I haven't dived into the history deeply enough to know how intentional this was. My discussion in this episode focuses on the file use case, so understand that I'm largely avoiding the topic of password hashing. Digital signatures are yet another use case, one that I'm ignoring entirely. Every few years, some security researcher declares a particular hash algorithm to be "broken" and that everyone should move over to a new one, which generally has a longer hash. While the larger hash space certainly reduces the opportunity for collisions, this disrupts workflows, such as publishing information about software releases by e-mail, which still tends to observe a 78-character limit on each line 13 , making it harder to include a list of hashes with filenames next to them. This is in addition to the work of modifying software and scripts to use the new algorithm and managing how to treat past data. It seems to me that publishing the input length along with the hash would make it far more difficult to craft a malicious input that matches both, but I haven't found discussion of that during my investigation. (See the Appendix for a possible implementation.) Perhaps someone listening can record a response episode for HPR explaining that. References: Payment card number https://en.wikipedia.org/wiki/Payment_card_number Ethernet frame: Frame check sequence https://en.wikipedia.org/wiki/Ethernet_frame#Frame_check_sequence Cksum specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/cksum.html GNU coreutils manual: sum https://www.gnu.org/software/coreutils/manual/html_node/sum-invocation.html FreeBSD 15.0 sum manual page https://man.freebsd.org/cgi/man.cgi?query=sum&sektion=1&manpath=FreeBSD+15.0-RELEASE+and+Ports 3BSD sum manual page https://www.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/man/man1/sum.1 3BSD sum source https://www.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/cmd/sum.c UNIX/32V sum manual page https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/man/man1/sum.1 UNIX/32V sum source https://www.tuhs.org/cgi-bin/utree.pl?file=32V/usr/src/cmd/sum.c System III sum manual page https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/man1/sum.1 System III sum source https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/sum.c Crypt specification https://pubs.opengroup.org/onlinepubs/009695399/functions/crypt.html RFC 2822: Internet Message Format: Line Length Limits https://datatracker.ietf.org/doc/html/rfc2822#section-2.1.1 OpenSSH 10.1 released https://lwn.net/ml/all/dd12623ae86aa5eb@cvs.openbsd.org/ Appendix The MD5 hash algorithm was (and still is) widely used, but many people characterize it as being "broken" and discourage its use. Let us imagine a variant of this, called MD5.L, where the normal MD5 hash is followed by a "." character and the input length expressed as a hexadecimal number. Take, for example, the e-mail message announcing the release of OpenSSH 10.1 14 . At the bottom, it includes an SHA-1 hash and an SHA-2 256-bit hash for the available gzipped tar files. That longer hash is encoded with Base64 because if it were given as a hexadecimal number, it would make the line longer than 78 bytes. The MD5.L hash of the file would be one character shorter than the SHA-1 hash, as shown below. (The extra length of the name makes them both consume the same number of characters. The hashes shown are for the "portable" version of OpenSSH.) Some people claim SHA-1 is also broken, seeking to have people use newer and longer hash functions. For an attacker to compromise MD5.L in this example, they would not only have to create a valid tar file compressed with gzip containing a malicious payload having the right MD5 hash, that file would have to be exactly 1,972,831 bytes long (the decimal equivalent of 1e1a5f). While there are still many possible inputs that could be tried (256 1972831 , to be exact*), this is far fewer than the infinite possibilities for plain MD5, SHA-1, or SHA-2. If for some reason it is super important to have a fixed hash length, let's imagine another variation called MD5+L. In this one, instead of L being the input length, it is the input length modulo one terabyte (2 40 bytes), which can be represented by 10 hexadecimal characters, left-padded with zeros. While this approach substantially increases the number of possible inputs an attacker could try, it is likely that an intended victim would notice that the file they downloaded is larger (or smaller) than expected by that much. The MD5+L hash is longer than a SHA-1 hash, but still shorter than a 256-bit SHA-2 hash. SHA1 (openssh-10.1p1.tar.gz) = 7fd17b99d1beffb47cd380d64079e920bb0bd91f SHA256 (openssh-10.1p1.tar.gz) = ufx6K4JXlGem8vQ+SoHI4d/aYU3bT5slWq/XAgu/B1g= MD5.L (openssh-10.1p1.tar.gz) = 80dd9bb00a86519934710d05903fdf07.1e1a5f MD5+L (openssh-10.1p1.tar.gz) = 80dd9bb00a86519934710d05903fdf07+00001e1a5f Of course, if MD5 is considered to be too weak even with the inclusion of the length, one could produce a ".L" or "+L" version of any hash function. However, longer hashes will end up running into the 78-character limit. *This is a number with 4.75 million digits that the bc utility on my laptop took almost 5 minutes to calculate. Provide feedback on this episode.

Why setting up commercial email and VPN services is incredibly hard, avoiding TrueNAS’s move from FreeBSD to Linux, why we avoid virtualising storage systems, and bridging WiFi to an external building. Plugs Support us on patreon and get an ad-free RSS feed with some early episodes Using Object Storage with OpenZFS and SeaweedFS Discussion Jeff Moss explains why setting up private email and VPN services are so difficult Feedback XigmaNAS Free consulting We were asked about bridging WiFi to an external building. Point-to-point Wi-Fi bridging between buildings—the cheap and easy way See our contact page for ways to get in touch.

inotify in FreeBSD, how changes to poudriere.conf affect the build time, Migrating mail servers from exim to OpenSMTPD, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Native inotify in FreeBSD News Roundup How changes to poudriere.conf affect the build time Follow on Giving poudriere a jump start Migrating mail servers from exim to OpenSMTPD (smtpd) is fun and useful Orion PDA Recap of the April 2026 Frankfurt Area FreeBSD Hackathon – Sven Ruediger 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

Mythos found a 23-year-old vulnerability in FreeBSD that no human team had caught. Your 30-day patch cycle assumes years before it gets weaponized. Today that window is one day. Next year it will be one hour.Lieuwe Jan Koning, Co-founder & CTO at ON2IT, sits down with Rob Maas, Field CTO at ON2IT, to break down what Anthropic's Mythos actually found, why the public release (Fable) still frustrates security professionals, and whether the FABLE framework gives defenders a realistic path forward.Rob's verdict: there is truth in what Anthropic claims. It is not as catastrophic as the marketing suggests. But if your fundamentals are not in place, the time to fix that is now.00:00:00 Introduction00:00:46 What is Mythos? From Project Glasswing to Fable00:03:13 What Mythos actually found: FreeBSD, Palo Alto, real patches00:05:57 The zero-day clock: from years to one hour00:09:00 The FABLE framework and the CSA "Mythos Ready" paper00:15:24 Authentication, segmentation, and egress filtering00:20:51 Myth or reality: Rob's verdictSubscribe to Threat Talks and turn on notifications for deep dives into the world's most active cyber threats and hands-on exploitation techniques.

FreeBSD to OpenBSD Wireguard, Object storage with OpenZFS and SeaweedFS, a zfs script for labeling drives, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines FreeBSD to OpenBSD Wireguard Using Object Storage with OpenZFS and SeaweedFS News Roundup zfs – a helper script for labelling all those drives AI errno(2) values The vi Family Creating a Samba Active Directory Domain Controller on FreeBSD Beastie Bits Let's find out how to get predictable IPv6 addresses assigned to OpenBSD VMs 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 Davi - BSDCan 2026 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

.NET on FreeBSD 15, Klara and TrueNAS fixing dedup, dhcpcd and unbound in FreeBSD Jails, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Running .NET 10.0 on FreeBSD 15.0 How Klara and TrueNAS collaborated to fix one of ZFS's longest standing limitations News Roundup Back to FreeBSD: Part 1 dhcpd and unbound in FreeBSD jails How our environment still needs the security boundary of Unix logins Increasing a bhyve vm disk 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

OpenBSD 7.9, Critical Infrastructure in FreeBSD, GhostBSD Finance report, Solaris 11.4 updates, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines OpenBSD 7.9 60th Edition has been released and Reported over on Undeadly Cleaning Up Critical Infrastructure in FreeBSD News Roundup Apple Wants to Kill Your Time Capsule but They Run NetBSD So They Can Not Oracle To Reduce The Frequency Of Solaris 11.4 Updates FreeBSD on a Thinkpad T14 Gen 2 Intel January 2026 Finance Report Beastie Bits The DragonFly site has a recently-updated page describing how DPorts is assembled and the process to contribute. TUHS - Unix use of VAX protection modes Origin of the rule that swap size should be 2x of the physical memory - The Duke and the Beastie - Improving OpenJDK support for 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 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

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. In UNIX Curio #4 ( HPR episode 4617 ), I teased the subject of file compression. Today I'm circling back to that. The history of data compression goes back at least to the 1970s, and in contexts outside UNIX and computers, probably even earlier. Somehow, it is refreshing to learn that humans have always struggled to have enough storage space to keep all the data they want to hang on to. One way around this limitation is to use some form of compression. I am only going to dive into lossless compression for this episode—that is, a compression method that can be reversed and will spit out the original data bit for bit. Lossy compression methods also have their places: you might be familiar with their use for audio (such as Ogg Vorbis or MP3); it's also used for images (such as JPEG). Lossy compression allows some of the original data to be thrown away, resulting in a smaller file than is possible with lossless compression, but the intent is for the result to still sound or look "good enough" to a human observer. Also, I am going to limit my discussion to generic methods used for many types of data; while FLAC does lossless compression, it is specifically designed just for audio. I should make clear that I have never studied computer science or information theory, so this episode will not get into the science behind various types of compression algorithms and how they differ. But in general, these methods take advantage of the fact that many types of data have recurring patterns. English text mostly consists of words that often re-appear many times—source code similarly has keywords and variable names that recur. Compression is accomplished by representing a piece of data that occurs multiple times with a symbol that is shorter in length. The first compression program in the UNIX world I could find is called pack , from 1978 1 . It was shortly followed in 1979 by a similar program called compact 2 . Both of these used a technique called Huffman coding, but with some differences between them. Files compressed with pack were given a .z extension and compact gave filenames a .C extension. Roughly every five or ten years after this, a new program would come along and achieve lasting popularity. There were, and still are, two opposing forces facing any new form of compression. Working in favor was the advantages it provided—first among these was achieving a better compression ratio, but performance improvements such as speed or reduced memory usage could also be compelling. The force against any new method was the fact that it was not yet widely supported—it doesn't much help to have a smaller file if the people you share it with cannot decompress it. The next major advance in compression arose out of three scientific papers: two in 1977 and 1978 by Abraham Lempel and Jacob Ziv (called LZ77 and LZ78), and one by Terry Welch in 1984 which built on LZ78. This last method is typically referred to as LZW. Our UNIX Curio for today is a program called compress 3 that implements the LZW method. Files compressed this way are named with the extension .Z . I had always assumed that this was to honor Jacob Ziv, but now that I've researched the history, it seems more likely to be a follow-on from how files compressed by pack were named. Since pack did not use any of the Lempel-Ziv methods, I would guess that it used .z because that wasn't already taken by anything else, but that's pure speculation. I do recall encountering .Z files in the wild, but feel certain that hasn't happened in the last 25 years, maybe longer. If you need to expand one of these, uncompress 4 is the program to use ( GNU's gunzip can also handle them 5 ). However, there was a serious problem that arose with the LZ78 and LZW compression methods. Both of them were patented, and the owner became aggressive in seeking payment from developers and users. The compress utility was developed within two months of the publication of Welch's 1984 paper and was included in Bell Laboratories' Eighth Edition UNIX before these shakedowns started. The paper did not disclose that a patent had been filed, and apparently Spencer Thomas and the other developers of compress were unaware of it. The utility became popular for a while, and was even standardized by POSIX, but people moved away from LZW once the legal threats started. Another important advance came in 1991 and was called the DEFLATE compression method. It combined the un-patented LZ77 method with Huffman coding to achieve a similar level of compression as LZW (actually, often better) without the legal trouble. DEFLATE was developed for PKZIP and was soon adopted by the GNU project's gzip compressor. While Phil Katz (the "PK" in PKZIP ) patented one way of implementing the DEFLATE method, it was possible to write a compressor and decompressor without infringing 6 ; also, he apparently never tried to enforce the patent 7 . As I mentioned in UNIX Curio #4, .zip is both an archive and a compression format. Each archive member can be compressed with one of several possible methods (or stored without compression). Unlike a tar file where compression can be applied to the entire archive, in .zip each archive member is compressed individually. This often means a .zip file will be slightly bigger than a tar file with the same contents compressed with gzip , because the .zip format cannot take advantage of duplication that occurs among more than one member of the archive. The vast majority of .zip files use only the DEFLATE and uncompressed storage methods and these are the only options if you want to follow the profile standardized in ISO/IEC 21320-1. Actually, since they both use DEFLATE, gzip is able to extract a .zip file in the special case where it only holds one member compressed with that method. From the 1990s onward, people paid significant attention to avoiding patent landmines, so only methods that didn't have that problem became broadly popular. While the patents on LZ78 and LZW have since expired, I feel like their most successful legacy was in discouraging people from using those methods, leading to DEFLATE taking the popularity crown. The next step came in 1996 and 1997 with the development of bzip and bzip2 by Julian Seward. The original method was quickly followed by bzip2 , which was the version that achieved true popularity. They use the Burrows-Wheeler transform, which does not itself compress data but re-arranges it to make it more compressible; this is combined with other techniques 8 . (At least, that's my understanding. I told you, I'm not up on information theory.) This provides a significant reduction in the compressed size of the data compared to earlier methods—however, it is slower than DEFLATE both during compression and decompression. Separate projects have developed parallel versions of gzip and bzip2 that can take advantage of multi-processor machines, but the original utilities run single-threaded. Another five years later, in 2001, Igor Pavlov added the Lempel-Ziv-Markov chain algorithm (LZMA), an enhancement to LZ77, to his 7-Zip compression tool. This was followed a few years later by LZMA2, a container format that allowed for LZMA compression to be split between multiple threads. Broad LZMA2 support came to the UNIX world in 2009 with the xz utility 9 . It offers roughly similar compression ratios to bzip2 , though it can be better or worse depending on the data to be compressed. While compression generally takes even longer than bzip2 , decompression is significantly faster (though still not as fast as gzip ). The Linux kernel relatively quickly supported booting from xz-compressed images 10 because it was a good match for that use case—compression, the time-consuming activity, only has to be done once while the more frequent decompression during boot happens relatively fast. The last method I will cover is Zstandard 11 , often written as zstd . This came about in 2015, and is another variation on LZ77 that uses finite-state entropy (which means nothing to me, but you might understand it). It performs about as well as DEFLATE in terms of compression ratios, but is much faster both when compressing and decompressing data. I should say that these statements are true with the typical default settings—depending on the compression level selected, it can compress more slowly, but compress the data smaller. However, decompression is always speedier than DEFLATE. This makes it attractive for some uses, and it is heavily promoted by Meta/Facebook, where Yann Collet developed it. For example, shipping large amounts of actively-used data between machines in a data center can go more quickly when the size is reduced; however, if the compression and decompression steps take too long that benefit is lost. A speedy method can be valuable even if it doesn't result in the greatest reduction in size. This use case stands in contrast to, say, a compressed backup file which might only be accessed in a disaster recovery scenario or never accessed at all, making size more important than speed. Both the xz and zstd utilities have some built-in support for multi-threading, but the default is to run in a single thread. While xz can use multiple threads for decompression (but only if the file was compressed in multi-thread mode), the reference zstd utility can only use more than one thread for compression, not decompression. There are many other methods of lossless compression that have been developed over the decades, but I believe these are the ones you are most likely to encounter in the world of UNIX-like systems. This is a personal opinion, and others might choose a different set. As mentioned, it can be tough for a new method to gain popularity and 35-year-old DEFLATE is still probably the most commonly used despite not being the fastest or offering the greatest reduction in size. Even systems like FreeBSD, NetBSD, and OpenBSD that do not like to include GNU tools supported it by developing their own version of gzip based on the permissively-licensed zlib library. Technically, the LZW method used by the compress utility is still standardized by POSIX, so one might expect it to have the widest support. However, aggressive patent enforcement discouraged adoption, especially by Free and Open Source Software systems—even though the patent has expired, it is still out of favor compared to DEFLATE. For this reason, I feel justified in calling it a curio. References: Eighth Edition UNIX pack.c https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/pack/pack.c 2.9BSD compact.c https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/ucb/compact/compact.c Compress specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/compress.html Uncompress specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/uncompress.html GNU Gzip manual https://www.gnu.org/software/gzip/manual/gzip.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 https://tools.ietf.org/html/rfc1951 History of Lossless Data Compression Algorithms: The Rise of Deflate https://ethw.org/History_of_Lossless_Data_Compression_Algorithms#The_Rise_of_Deflate bzip2 https://en.wikipedia.org/wiki/Bzip2 XZ Utils https://en.wikipedia.org/wiki/XZ_Utils 2.6.38 merge window part 2 https://lwn.net/Articles/423541/ zstd https://en.wikipedia.org/wiki/Zstd Appendix The table below demonstrates the results of compressing different types of data using tools described in this episode. While not totally rigorous, I did run each compression and decompression multiple times to ensure I was getting consistent results. The laptop I used has an Intel Core i5-6200U CPU running at 2.30GHz, and the system had at least 5 GB of free memory for each run. While this processor has two cores and can run four simultaneous threads, all utilities were run single-threaded. The term "best" means the highest level of compression available (the exact level used is shown). For bzip2 , the default is the best. For zstd , "best" is -19, which is the highest "normal" level, but "ultra" levels that are even higher also exist. Ratios are the percentage of the original size that the file was reduced to (other sources might instead express the compression ratio as the reduction in size achieved). In all results, smaller numbers are better. ┌────────────────────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐ │ │ gzip │ gzip │ bzip2 │ xz │ xz │ zstd │ zstd │ │ │(default -6) │ (best -9) │ (-9) │(default -6) │ (best -9) │(default -3) │ (best -19) │ ├──────────────┬─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 22,036,508 │ 21,891,623 │ 15,795,698 │ 13,487,768 │ 12,938,464 │ 20,454,657 │ 13,709,078 │ │ │ │ (24%) │ (24%) │ (17%) │ (15%) │ (14%) │ (23%) │ (15%) │ │English Text ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(90,532,092 │Compression │ 4.8s │ 7.6s │ 8.5s │ 49.8s │ 58.8s │ 0.6s │ 65.2s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 0.7s │ 0.8s │ 3.7s │ 1.2s │ 1.2s │ 0.4s │ 0.4s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 125,291,122 │ 124,189,544 │ 98,016,512 │ 84,882,492 │ 81,954,344 │ 120,604,855 │ 87,298,645 │ │ │ │ (21%) │ (21%) │ (17%) │ (14%) │ (14%) │ (20%) │ (15%) │ │Source Code ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(590,008,320 │Compression │ 22.0s │ 39.3s │ 54.8s │ 241s │ 298s │ 3.7s │ 348s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 5.1s │ 5.1s │ 20.3s │ 8.1s │ 7.8s │ 2.4s │ 2.4s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 32,830,905 │ 32,371,241 │ 26,856,579 │ 20,717,288 │ 20,352,880 │ 28,538,810 │ 23,154,582 │ │ │ │ (19%) │ (19%) │ (16%) │ (12%) │ (12%) │ (17%) │ (13%) │ │Binary Program├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(171,972,264 │Compression │ 6.4s │ 22.4s │ 18.6s │ 62.2s │ 67.8s │ 0.8s │ 111s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 1.5s │ 1.5s │ 5.6s │ 2.3s │ 2.3s │ 0.7s │ 0.7s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 146,397,772 │ 146,397,757 │ 144,485,451 │ 131,950,232 │ 130,926,780 │ 147,154,979 │ 145,703,840 │ │ │ │ (89%) │ (89%) │ (88%) │ (80%) │ (80%) │ (90%) │ (89%) │ │WAVE Audio ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(164,396,302 │Compression │ 9.2s │ 9.2s │ 25.1s │ 70.4s │ 97.7s │ 0.7s │ 58.3s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 2.0s │ 2.0s │ 13.5s │ 12.2s │ 12.1s │ 0.6s │ 0.8s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┴─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │ gzip │ gzip │ bzip2 │ xz │ xz │ zstd │ zstd │ │ │(default -6) │ (best -9) │ (-9) │(default -6) │ (best -9) │(default -3) │ (best -19) │ └────────────────────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘ English text consists of Titles 1 through 10 of the 2020 U.S. Code of Federal Regulations . Source code consists of a tar file containing the Linux kernel source, version 4.0. Binary program consists of an ELF-format executable of the pandoc application, version 2.17.1.1 found on Debian 12. Audio consists of a 24-bit Signed Integer PCM WAVE file with 2 channels at 44.1kHz, about 10:21 in length. For comparison, the audio-specific flac lossless compression utility reduced this file to 97,962,711 bytes (60%) in 2.6 seconds at the default (-5) level and to 97,714,876 bytes (59%) in 5.4 seconds at the highest (-8) level. Provide feedback on this episode.

The NetBSD/FreeBSD Merge announcement, the rise and fall of SPARC, GhoseBSD 26.2 and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines NetBSD/FreeBSD will not merge, November 1993 announcement Rise and Fall of SPARC: Why No One Misses It News Roundup Help needed testing GhostBSD 26.2 Redundant DHCP server and DNS Resolver using OpenBSD and FreeBSD Universities And In house Tech Beating my head on OpenVPN 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 Paul - Feedback 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

Switching from Proxmox to Sylve, FreeBSD Quarterly report, FreeBSD's laptop program, Migrating ZFS, Haiku and OpenSSL news, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines I Switched from Proxmox to Its FreeBSD Counterpart on My Home Server – Here is How it Went FreeBSD Quarterly Report The FreeBSD Foundation's Laptop Support Project News Roundup Migrating ZFS filesystems from one zpool to another – same host Haiku Isn't Just For X86 Anymore, Boots On ARM In QEMU OpneSSL 4.0 Other schedulers? Illumos? 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

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. I would imagine that most users of UNIX-like systems have heard of cron —certainly any system administrator should have. Briefly, cron is a way of running a job repeatedly based on the time and date; for example, a job could run every hour, at 5:00am every Tuesday, or the 3rd of every month. It is commonly used for administrative or maintenance tasks that should be done on a regular schedule, such as checking for software updates, rotating log files, or updating the database for the locate command. As well-known as cron is, there is a similar utility that very few seem to be aware of: at . This is the word "at", and has nothing to do with the at symbol "@". An at job is very much like a cron job, except that an at job only runs one time. A job is submitted by running at timespec 1 , where timespec is the time and date the job is to be run. The linked POSIX specification page describes acceptable formats for timespec ; some examples are " now ", " 14:00 ", " noon tomorrow ", " 14:00 + 3 months ", and " 14:00 January 19, 2038 ". The utility then waits on standard input for you to enter a set of commands to be run in the job. You end input by typing Control-D to mark the end of text. (As an alternative to typing in the job, you could instead use the "

Who survived the install, who made it to the desktop, and who learned the hard way that one little mistake will blow up the entire BSD box.Sponsored By:Jupiter Party Annual Membership: Put your support on automatic with our annual plan, and get one month of membership for free!Managed Nebula: Meet Managed Nebula from Defined Networking. A decentralized VPN built on the open-source Nebula platform that we love.Support LINUX UnpluggedLinks:

The FCC relaxes its foreign router ban to allow for security updates, the ShinyHunters group disrupts schools across the globe, a 21-year-old remote code execution bug turns up in FreeBSD, and another Linux privilege escalation bug was disclosed… without a patch. Show notes Risky Bulletin: FCC relaxes foreign router ban to allow for security updates

Cybersecurity Looks Like Proof of Work Now, Compensating for RAM Constraints with L2ARC on ZFS, GhostBSD 26.1, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Cybersecurity Looks Like Proof of Work Now Compensating for RAM Constraints with L2ARC on ZFS GhostBSD 26.1 News Roundup I connected a phone to my FreeBSD server My Journey to the BSDs The unseen hero of OpenBSD Beastie Bits BSD Can Schedule up OpenBSD Campaign 2025 OpenBSD Campaign 2026 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

We dig into the Copy Fail vulnerability and test a proof-of-concept against our own box. Plus, Jon Seager, VP of Engineering at Canonical joins us, and we kick off the BSD Challenge!Sponsored By:Jupiter Party Annual Membership: Put your support on automatic with our annual plan, and get one month of membership for free!Managed Nebula: Meet Managed Nebula from Defined Networking. A decentralized VPN built on the open-source Nebula platform that we love.Support LINUX UnpluggedLinks:

Danger of Libredtail https://isc.sans.edu/diary/Danger%20of%20Libredtail%20%5BGuest%20Diary%5D/32936 FreeBSD dhclient vulnerability https://www.freebsd.org/security/advisories/FreeBSD-SA-26:12.dhclient.asc Linux Copy-Fail Vulnerability CVE-2026-31431 https://copy.fail Bryan Nice Research Paper https://www.linkedin.com/in/bryannice/ https://www.sans.edu/cyber-research/detecting-ai-pickling

In March 2012, the FBI surrounded a hurricane-rated steel door in Galveston, Texas. Behind it sat 30 year old Higinio Ochoa, drinking coffee in his boxers, flushing his one-time pad passwords down the toilet before letting federal agents inside. The operation to capture "w0rmer" had finally terminated.The process had initialized years earlier in childhood IRC rooms and 2600 chat channels. Ochoa taught himself to hack on dial-up connections, installing FreeBSD from thirty floppy disks at eleven years old. By his twenties, he was running cameras and internet infrastructure for Occupy Wall Street camps. When he witnessed police beating a woman having a seizure during a raid, something switched. The technical skills pivoted toward purpose.Cabin Crew launched with surgical precision. Ochoa mass-scanned police systems for SQL injections and admin pages, often not knowing which department he'd compromised until crafting the press release. He signed every hack, tagged every defacement, live-tweeted FBI taunts. His girlfriend posed in a bikini outside the Alabama Department of Public Safety holding signs that read "PwN3D by w0rmer" with GPS coordinates embedded in the photo metadata.Today he consults for governments and holds battlefield accommodations from Ukraine. The smooth hands that once broke into Secret Service-designed systems now defend critical infrastructure at levels where people could die if information leaks.TIMSTAMPS00:00 The Early Days of Hacking04:22 From Hobbyist to Activist08:30 The Shift to Purposeful Hacking13:16 The Rise of Cabin Crew17:58 The Psychology of Hacking and Branding21:11 The Origins of Wormer: A Hacker's Journey25:10 The FBI's Approach: How They Caught Me27:50 The Day of Reckoning: My Arrest Experience32:44 Life in the System: Mental Struggles and Adaptations36:18 Navigating Post-Prison Life: Challenges and Restrictions44:40 Navigating Life Post-Incarceration47:27 The Struggles of Redemption51:19 Finding Opportunities in a Stigmatized Field55:23 The Evolution of a Hacker's Journey58:46 Contributions to Information Security01:01:19 Words of Wisdom for Aspiring Hackers01:05:42 The Dream of a Cybersecurity Bar[Higinio “w0rmer” Ochoa – LinkedIn] - https://www.linkedin.com/in/x0hig Professional profile of Higinio Ochoa, a former Anonymous-affiliated hacktivist turned cybersecurity consultant, where he shares insights on security, research, and his work in the industry.[DEF CON Hacker Conference] - https://defcon.org/ One of the world's largest and most influential cybersecurity and hacker conferences, referenced in the episode as a key part of early hacker culture and later professional engagement.[Cybersecurity and Infrastructure Security Agency (CISA)] - https://www.cisa.gov/ A U.S. government agency focused on cybersecurity and infrastructure protection, mentioned in relation to responsible disclosure and ethical hacking initiatives.[Cloudflare] - https://www.cloudflare.com/ A global web infrastructure and cybersecurity company where the guest briefly worked after prison, playing a role in his transition into legitimate security work.[The Pirate Bay] - https://thepiratebay.org/ A well-known file-sharing platform referenced in the discussion about monitored internet usage and security research environments post-release.

Breaking up Big Tech, Porting MacOS to the Nintendo Wii, OpenBSD on the Pomera DM250, Postgres is your friend and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Breaking up with Big Tech Porting MacOS to the Nintendo Wii News Roundup Installing OpenBSD on the Pomera DM250 Postgres is Your Friend. ORM is Not Java Sun SPOTs I like to use Soviet control panels as a starting point Beastie Bits OSHintosh - an open source 68000 Macintosh Time to update 2.11BSD: biggest patch ever landed before 35th anniversary A quick and easy Guide to Tmux 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 Producer Note, If you have emailed in and you havent heard back and we havent covered your message, email again. Our email is flooded with spam and I might have missed your message. 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

Proxmox to FreeBSD, Hidden values of CPU-Intensive Compression, Cells for NetBSD, OpenBSD 7.8 on RPIs, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines From Proxmox to FreeBSD and Sylve in Our Office Lab The Hidden Value of CPU-Intensive Compression on Modern Hardware News Roundup Cells for NetBSD – Kernel Enforced Jail Like Isolation with User Friendly Operations OpenBSD 7.8 on Raspberry Pi Zero 2W OpenSSH 10.3/10.3p1 released I'm just the Barista 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 Tim - Are OCI Images useful for Freebsd.md 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

Wayland setting back Linux, Dr Callahan's semi retirement, holding onto your hardware, PF queues breaking the 4gbps barrier, and mroe... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Wayland set the Linux Desktop back by 10 years Semi-retirement, or, really, changing my relationship with the BSDs [Hold on to Your Hardware](https://マリウス.com/hold-on-to-your-hardware/) News Roundup PF queues break the 4 Gbps barrier Nobody said there was math on this exam! The web is bearable with RSS The Pipe 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

When Anthropic announced Project Glasswing, the headline was the capability: an AI model that found a 27-year-old flaw in OpenBSD and a 17-year-old remote code execution vulnerability in FreeBSD — fully autonomously, no human in the loop after the initial prompt. But the story underneath the capability is a structural one about who gets early intelligence, who sets the disclosure timeline, and what happens to every organization that wasn't in the room. In this edition of Lens Four, Sean Martin examines Project Glasswing through three lenses: the intelligence asymmetry it creates for security programs, what it reveals about the broken assumptions underneath CVE, CVSS, and NIST, and why the equity framing in Glasswing's messaging doesn't survive contact with the data.

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. When you think about creating and managing archives on a UNIX system, tar is probably the utility that comes to mind. But this was not the first archiving program; ar was in First Edition UNIX 1 and cpio also pre-dates it, sort of 2 . According to the NetBSD manual page, cpio was developed within AT&T before tar , but did not get widely released until System III UNIX after tar was already well known from the earlier release of Seventh Edition UNIX (a.k.a. Version 7). You might think that ar and cpio are old and irrelevant these days, but these formats do live on. Each Debian package file 3 is an ar archive which in turn contains two tar files. On Red Hat, Fedora, SUSE, and some other distributions, each .rpm package file 4 contains a cpio payload. So these may very well still be in use on your modern Linux system. But let's get back to the subject of what you might want to use to create archives today. The tar utility has persisted in its popularity over the decades, and you most probably have a version installed on your UNIX-like systems. One of the problems with tar , however, is that it has not kept a consistent file format. Also, different implementations have used differing syntax at times. There are excellent reasons for the file format changing 5 . The names people give files have gotten longer over time, and the original Seventh Edition tar format could only handle a total pathname length of 100 bytes for each archive member. In addition, filenames were in ASCII format, and modern filesystems now accommodate richer encodings with characters that aren't in ASCII. The size of each archive member was limited to 8 gigabytes—unthinkably large back then, but not so big these days. User and group ownership could only be specified by numeric ID, which can vary from one system to another. Many other types of files and information simply couldn't be stored: block and character device nodes, FIFOs, sockets, extended attributes, access control lists, and SELinux contexts. As a result, the tar format had to evolve over the years. One important version was the ustar format, created for the 1988 POSIX standard. The POSIX committee wanted to try standardizing both the file format and syntax for the tar command. While the ustar format addressed some shortcomings, progress marched on. Filesystems started allowing filenames in different character sets and more types of information to be attached to files, so for the 2001 revision of POSIX they gave up on standardizing the tar utility and came up with a new format and utility, which is our actual UNIX Curio for this episode: pax 6 . Since the pax program didn't have historical baggage, they could specify its options, behavior, and file format and be sure everyone's implementation would match. Developers of different tar implementations had been reluctant to change away from their historical option syntax to the standard. The pax utility was also an attempt to avoid taking sides between those who advocated for tar and fans of cpio . The pax file format was an extension of ustar with the ability to add arbitrary new attributes tied to each archive member as UTF-8 Unicode. Some of these attribute names were standardized, but implementers could also define their own, making the format more future-proof. Older versions of tar that could handle the ustar format should still be able to process pax archives, but might not know what to do with the extra attributes. GNU tar developed its current archive format 7 alongside the standardization of the ustar format. The GNU format was based on an early draft which later underwent incompatible changes, so the two unfortunately are not interchangable. Unlike ustar , the GNU format has no limits on the size of files or the length of their names. In addition to its own format, GNU tar is able to detect and correctly process both ustar and pax archives. In situations where its native format can't store necessary information about a file (such as POSIX access control lists or extended attributes), GNU tar will automatically output the pax format instead (called "posix" in documentation). However, it still uses the GNU format by default, though the documentation has been threatening to move to the POSIX format for at least 20 years 8 . The good news is that the ustar , pax , GNU tar , and Seventh Edition tar formats are well documented and utilities across many UNIX-like systems 2,7,9,10,11 are able to handle these, depending on which formats existed when the utility was developed. While your system may not have pax itself installed, there are other archiving utilities that can read the file format, including GNU tar . (Somewhat amusingly, Debian and some other Free Software operating systems package a pax utility developed by MirBSD 12 which largely follows the POSIX-specified interface, but doesn't support reading or writing archives in pax format!) Look at the manual page for the tar , cpio , or pax utilities on your system to see if they can handle pax archives. Perhaps one aspect that has worked in favor of tar and other UNIX archive formats is that they only concern themselves with storing files and make no attempt at compression. Instead, it is common for a complete archive file to be compressed after creation; many utilities can be told to do this step for you, but it is not typically the default behavior. Therefore, if a better compression method comes along, the archive format doesn't need to change. If you do use compression, be careful to choose a method that is available on the destination system. Compressing files is a big enough subject to deserve its own episode, so we won't talk more about it here. So which format should you use when creating an archive? Unfortunately, there is no single answer that applies in all circumstances. The pax format is supported among modern UNIX-like systems and can represent all types of files and metadata. While other systems, their filesystems, and archive utilities might not be able to properly make use of all the metadata, they should at least be able to extract the data contained in files and, if Unicode is supported, give them appropriate filenames. If you intend to unpack the archive on an older system, more research might be needed to figure out what formats it is able to handle. The Seventh Edition tar format (often called "v7") is widely supported, including by older systems, but has limitations in what it can contain as described earlier. Moving beyond the UNIX world, things get even more complicated. Apple's macOS, with its FreeBSD underpinnings, easily handles tar files. However, when it comes to MS-DOS and Windows, it's a bit different. There, a multitude of archiving programs and formats arose, usually combining archiving with compression. PKZIP was probably the most popular of these and its .zip format became common in many places, helped by the fact that PKWARE openly published the specification. While there is only a single .zip format, it has many options, some proprietary, and different implementations have diverged in the way some aspects are handled (or not handled). An ISO/IEC standard for .zip 13 was published in 2015 giving a baseline profile, and sticking to it produces files that can be widely extracted successfully. Other file formats like OpenDocument use the .zip format and typically hew to the standardized profile. Windows' File Explorer, starting with Windows XP, can natively extract .zip files 14 . The Info-ZIP program 15 is a Free Software implementation for a wide variety of systems (even rather obscure ones); while it might not be installed on yours, if you're copying the archive file over, you can probably copy over its unzip utility at the same time to unpack it. So .zip probably has the broadest support, although it might not already be present on every system. However, as Klaatu points out in Hacker Public Radio episode 4557 16 , .zip files and applications handling them aren't always great at maintaining metadata about files. The .zip format doesn't seem to have any way to represent UNIX file permissions, and user/group ownership can only be included as numeric IDs. Other types of metadata on UNIX-like systems are not saved at all. This is probably not a problem in some cases, such as with a collection of photos, but for others it might be a concern. While pax as a utility does not seem to have gained much popularity or support, except on commercial UNIX systems where including it was required to conform to the POSIX standard, its file format has persisted. Free Software systems have generally avoided the pax interface, preferring to stick with the tar utility on the command line, but usually have good support for archive files in the pax format. Outside of UNIX-like systems, .zip seems to have become the most common file format, and support for it is also good in the UNIX world, though it might not be built in. References: Archive (library) file format https://man.cat-v.org/unix-1st/5/archive NetBSD 10.0 cpio manual page https://man.netbsd.org/NetBSD-10.0/cpio.1 Debian binary package format https://manpages.debian.org/trixie/dpkg-dev/deb.5.en.html RPM V6 Package format https://rpm.org/docs/6.0.x/manual/format_v6.html NetBSD 10.0 libarchive-formats manual page https://man.netbsd.org/NetBSD-10.0/libarchive-formats.5 Pax specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/pax.html GNU tar manual https://www.gnu.org/software/tar/manual/tar.html GNU tar manual for version 1.15.90 https://web.cvs.savannah.gnu.org/viewvc/*checkout*/tar/tar/manual/tar.html?revision=1.3 FreeBSD 15.0 libarchive-formats manual page https://man.freebsd.org/cgi/man.cgi?query=libarchive-formats&sektion=5&apropos=0&manpath=FreeBSD+15.0-RELEASE+and+Ports OpenBSD 7.8 tar manual page https://man.openbsd.org/OpenBSD-7.8/tar HP-UX Reference (11i v3 07/02) - 1 User Commands N-Z (vol 2) https://support.hpe.com/hpesc/public/docDisplay?docId=c01922474&docLocale=en_US MirBSD pax(1) manual page http://www.mirbsd.org/htman/i386/man1/pax.htm#Sh.STANDARDS ISO/IEC 21320-1:2015 Information technology - Document Container File Part 1: Core https://www.iso.org/standard/60101.html Mastering File Compression on Windows https://windowsforum.com/threads/mastering-file-compression-on-windows-how-to-zip-and-unzip-files-effortlessly.369235/ About Info-ZIP https://infozip.sourceforge.net/ HPR4557::Why I prefer tar to zip https://hackerpublicradio.org/eps/hpr4557/index.html Provide feedback on this episode.

When Anthropic announced Project Glasswing, the headline was the capability: an AI model that found a 27-year-old flaw in OpenBSD and a 17-year-old remote code execution vulnerability in FreeBSD — fully autonomously, no human in the loop after the initial prompt. But the story underneath the capability is a structural one about who gets early intelligence, who sets the disclosure timeline, and what happens to every organization that wasn't in the room. In this edition of Lens Four, Sean Martin examines Project Glasswing through three lenses: the intelligence asymmetry it creates for security programs, what it reveals about the broken assumptions underneath CVE, CVSS, and NIST, and why the equity framing in Glasswing's messaging doesn't survive contact with the data.

Anthropic houdt zijn nieuwste AI-model Mythos bewust buiten publiek bereik, omdat het in staat is duizenden onbekende kwetsbaarheden te vinden in vrijwel elk groot digitaal systeem. Minister van Financiën Scott Bessent en Fed-voorzitter Jerome Powell riepen deze week topbestuurders van Wall Street-banken bijeen voor een urgente bespreking van de risico's. Stijn Goossens bespreekt het in deze Tech Update. Tijdens de testfase identificeerde Mythos Preview duizenden zogenaamde zero-day kwetsbaarheden, in elk groot besturingssysteem en elke grote webbrowser. In één geval vond het model volledig zelfstandig een zeventien jaar oud beveiligingslek in FreeBSD waarmee een aanvaller op afstand volledige controle over een server kan overnemen. Anthropic benadrukt dat het model niet specifiek is getraind op cyberbeveiligingstaken: de gevaarlijke capaciteiten kwamen voort uit algemene verbeteringen in redeneren en programmeervaardigheden. Bessent en Powell riepen Wall Street-leiders bijeen voor een urgente bijeenkomst op het ministerie van Financiën in Washington, om er zeker van te zijn dat banken op de hoogte zijn van de mogelijke risico's van Mythos en vergelijkbare toekomstige modellen, en dat ze maatregelen nemen om hun systemen te beschermen. Voor Nederland en Europa stelt dit een bredere vraag: hoe afhankelijk zijn we van Amerikaanse techbedrijven als het gaat om de beveiliging van onze digitale infrastructuur, en wat kunnen overheden hier zelf in betekenen? Verder in deze Tech Update Steeds meer jonge Nederlandse kinderen gebruiken dagelijks meerdere digitale apparaten. Uit onderzoek van Netwerk Mediawijsheid blijkt dat kinderen onder de zes jaar gemiddeld ruim twee apparaten per dag gebruiken, met een gemiddelde schermtijd van 102 minuten, ruim boven het landelijk advies. Experts waarschuwen dat tablets en touchscreens dichtbij het gezicht oogproblemen zoals bijziendheid kunnen versterken, terwijl een kwart van de ouders zelf moeite heeft de telefoon weg te leggen. Zometeen in De Schaal van Hebben: Philips OneTurn hybride strijkijzer See omnystudio.com/listener for privacy information.

FreeBSD and OpenZFS in the Quest for Technical Independence, Reviews make you 10x slower, OpenBSD on a Motorola 88000, Jailrun, and more. NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines FreeBSD and OpenZFS in the Quest for Technical Independence: A Storage Architect's View Every layer of review makes you 10x slower News Roundup The story of OpenBSD on Motorola 88000 series processors Jailrun + jailrun github FreeBSD Users: We Need to Talk About Claude Code Vibe-coded ext4 for OpenBSD 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

The Real Cost of Technology Dependence, FreeBSD 15 Linuxator with CUDA, Bidirectional OPNsense/pfSense, Netbase, a SYN attack, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines The Real Cost of Technology Dependence: Building Independence with Open-Source Storage News Roundup Building Hierarchical Jails (Podman x Native Jail) on FreeBSD 15 FreeBSD 15.0 Linuxulator with CUDA Setup Bidirectional OPNsense/pfSense Firewall Configuration Migration/Conversion CLI SYN attack Syn attack follow up Netbase is Port of NetBSD Utilities to Another UNIX Like Operating Systems Beastie Bits OpenBSD -current moves to 7.9-beta - Delayed hibernation comes to OpenBSD/amd64 laptops 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

This is a recap of the top 10 posts on Hacker News on April 01, 2026. This podcast was generated by wondercraft.ai (00:30): Claude Code Unpacked : A visual guideOriginal post: https://news.ycombinator.com/item?id=47597085&utm_source=wondercraft_ai(01:56): Live: Artemis II Launch Day UpdatesOriginal post: https://news.ycombinator.com/item?id=47603657&utm_source=wondercraft_ai(03:23): EmDash – A spiritual successor to WordPress that solves plugin securityOriginal post: https://news.ycombinator.com/item?id=47602832&utm_source=wondercraft_ai(04:50): DRAM pricing is killing the hobbyist SBC marketOriginal post: https://news.ycombinator.com/item?id=47606840&utm_source=wondercraft_ai(06:17): I quit. The clankers wonOriginal post: https://news.ycombinator.com/item?id=47598511&utm_source=wondercraft_ai(07:43): CERN levels up with new superconducting kartsOriginal post: https://news.ycombinator.com/item?id=47597935&utm_source=wondercraft_ai(09:10): SpaceX files to go publicOriginal post: https://news.ycombinator.com/item?id=47604155&utm_source=wondercraft_ai(10:37): Claude wrote a full FreeBSD remote kernel RCE with root shellOriginal post: https://news.ycombinator.com/item?id=47597119&utm_source=wondercraft_ai(12:04): U.S. exempts oil industry from protecting Gulf animals, for 'national security'Original post: https://news.ycombinator.com/item?id=47595620&utm_source=wondercraft_ai(13:31): Is BGP safe yet?Original post: https://news.ycombinator.com/item?id=47600382&utm_source=wondercraft_aiThis is a third-party project, independent from HN and YC. Text and audio generated using AI, by wondercraft.ai. Create your own studio quality podcast with text as the only input in seconds at app.wondercraft.ai. Issues or feedback? We'd love to hear from you: team@wondercraft.ai

FreeBSD is one of the longest-running and most influential open-source operating systems in the world. It was born from the Berkeley Software Distribution in the early 1990s, it has powered everything from high-performance networking infrastructure to game consoles and content delivery networks. Over three decades, it has evolved through major architectural shifts, from symmetric multiprocessing The post FreeBSD with John Baldwin appeared first on Software Engineering Daily.

FreeBSD is one of the longest-running and most influential open-source operating systems in the world. It was born from the Berkeley Software Distribution in the early 1990s, it has powered everything from high-performance networking infrastructure to game consoles and content delivery networks. Over three decades, it has evolved through major architectural shifts, from symmetric multiprocessing The post FreeBSD with John Baldwin appeared first on Software Engineering Daily.

Designing OpenZFS Storage for Independence, The day Telnet died, PiDP 11/70, OpenBSD on SGI and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Designing OpenZFS Storage for Independence: Pool Architecture, Failure Domains, and Migration Paths 2026-01-14: The Day the telnet Died Reports of Telnet's Death Have Been Greatly Exaggerated News Roundup PiDP-11/70 Build Workshop OpenBSD on SGI: a rollercoaster story Terminals Should Generate 256 Color Palette FreeBSD tribal knowledge: Changes to snapshot strategy Beastie Bits BSDCan reg is now open An Oral History of Unix Major update to drm(4) code in OpenBSD-current (to linux 6.18.16) Patched FreeBSD AMIs 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

Jails for NetBSD, ARC and L2ARC sizing for Proxmox, Anatomy of bsd.rd, Docker Containers on FreeBSD, Running Time Machine inside a FreeBSD Jail, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Jails for NetBSD ARC and L2ARC Sizing on Proxmox News Roundup Lab: Anatomy of bsd.rd — No Reboot Required Exploring Docker containers on FreeBSD Time Machine inside a FreeBSD jail After decades on Linux, FreeBSD finally gave me a reason to switch operating systems Beastie Bits - - 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 Emelio - openbsd 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

Pool and Vdev topology for promox, KDE Plasma is not forcing systemd, Running a 2.11 BSD system, Booting NetBSD from a wedge and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Pool and VDEV Topology for Proxmox Workloads News Roundup KDE Plasma 6.6 is Not Forcing systemd(1) but Arguments Rage On. An old article with covering : Running and administrating a 2.11 BSD system Booting NetBSD from a wedge, the hard way Beastie Bits The NetBSD Foundation will participate in Google Summer of Code 2026! Solaris 11.4 SRU90: Preserve Boot Environments zfs-2.4.1 Hardening OPNsense: Using Q-Feeds to Block Malicious Traffic 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 Gary - A nice blog 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 ZFS vs BTRFS Architects features and stability RHEL on ZFS Root: An Unholy Experiment News Roundup Slackware on Encrypted ZFS Root. https://tumfatig.net/2026/slackware-on-encrypted-zfs-root/ OpenIndiana Is Porting Solaris' IPS Package Management To Rust FreeBSD Jail Memory Metrics Tcl: The Most Underrated, But The Most Productive Programming Language How to Setup WireGuard on OpenBSD: The Ultimate Self-Hosted VPN Guide (2026) 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

Bryan Cantrill is the co-founder and CTO of Oxide Computer Company. We discuss why the biggest cloud providers don't use off the shelf hardware, how scaling data centers at samsung's scale exposed problems with hard drive firmware, how the values of NodeJS are in conflict with robust systems, choosing Rust, and the benefits of Oxide Computer's rack scale approach. This is an extended version of an interview posted on Software Engineering Radio. Related links Oxide Computer Oxide and Friends Illumos Platform as a Reflection of Values RFD 26 bhyve CockroachDB Heterogeneous Computing with Raja Koduri Transcript You can help correct transcripts on GitHub. Intro [00:00:00] Jeremy: Today I am talking to Bryan Cantrill. He's the co-founder and CTO of Oxide computer company, and he was previously the CTO of Joyent and he also co-authored the DTrace Tracing framework while he was at Sun Microsystems. [00:00:14] Jeremy: Bryan, welcome to Software Engineering radio. [00:00:17] Bryan: Uh, awesome. Thanks for having me. It's great to be here. [00:00:20] Jeremy: You're the CTO of a company that makes computers. But I think before we get into that, a lot of people who built software, now that the actual computer is abstracted away, they're using AWS or they're using some kind of cloud service. So I thought we could start by talking about, data centers. [00:00:41] Jeremy: 'cause you were. Previously working at Joyent, and I believe you got bought by Samsung and you've previously talked about how you had to figure out, how do I run things at Samsung's scale. So how, how, how was your experience with that? What, what were the challenges there? Samsung scale and migrating off the cloud [00:01:01] Bryan: Yeah, I mean, so at Joyent, and so Joyent was a cloud computing pioneer. Uh, we competed with the likes of AWS and then later GCP and Azure. Uh, and we, I mean, we were operating at a scale, right? We had a bunch of machines, a bunch of dcs, but ultimately we know we were a VC backed company and, you know, a small company by the standards of, certainly by Samsung standards. [00:01:25] Bryan: And so when, when Samsung bought the company, I mean, the reason by the way that Samsung bought Joyent is Samsung's. Cloud Bill was, uh, let's just say it was extremely large. They were spending an enormous amount of money every year on, on the public cloud. And they realized that in order to secure their fate economically, they had to be running on their own infrastructure. [00:01:51] Bryan: It did not make sense. And there's not, was not really a product that Samsung could go buy that would give them that on-prem cloud. Uh, I mean in that, in that regard, like the state of the market was really no different. And so they went looking for a company, uh, and bought, bought Joyent. And when we were on the inside of Samsung. [00:02:11] Bryan: That we learned about Samsung scale. And Samsung loves to talk about Samsung scale. And I gotta tell you, it is more than just chest thumping. Like Samsung Scale really is, I mean, just the, the sheer, the number of devices, the number of customers, just this absolute size. they really wanted to take us out to, to levels of scale, certainly that we had not seen. [00:02:31] Bryan: The reason for buying Joyent was to be able to stand up on their own infrastructure so that we were gonna go buy, we did go buy a bunch of hardware. Problems with server hardware at scale [00:02:40] Bryan: And I remember just thinking, God, I hope Dell is somehow magically better. I hope the problems that we have seen in the small, we just. You know, I just remember hoping and hope is hope. It was of course, a terrible strategy and it was a terrible strategy here too. Uh, and the we that the problems that we saw at the large were, and when you scale out the problems that you see kind of once or twice, you now see all the time and they become absolutely debilitating. [00:03:12] Bryan: And we saw a whole series of really debilitating problems. I mean, many ways, like comically debilitating, uh, in terms of, of showing just how bad the state-of-the-art. Yes. And we had, I mean, it should be said, we had great software and great software expertise, um, and we were controlling our own system software. [00:03:35] Bryan: But even controlling your own system software, your own host OS, your own control plane, which is what we had at Joyent, ultimately, you're pretty limited. You go, I mean, you got the problems that you can obviously solve, the ones that are in your own software, but the problems that are beneath you, the, the problems that are in the hardware platform, the problems that are in the componentry beneath you become the problems that are in the firmware. IO latency due to hard drive firmware [00:04:00] Bryan: Those problems become unresolvable and they are deeply, deeply frustrating. Um, and we just saw a bunch of 'em again, they were. Comical in retrospect, and I'll give you like a, a couple of concrete examples just to give, give you an idea of what kinda what you're looking at. one of the, our data centers had really pathological IO latency. [00:04:23] Bryan: we had a very, uh, database heavy workload. And this was kind of right at the period where you were still deploying on rotating media on hard drives. So this is like, so. An all flash buy did not make economic sense when we did this in, in 2016. This probably, it'd be interesting to know like when was the, the kind of the last time that that actual hard drives made sense? [00:04:50] Bryan: 'cause I feel this was close to it. So we had a, a bunch of, of a pathological IO problems, but we had one data center in which the outliers were actually quite a bit worse and there was so much going on in that system. It took us a long time to figure out like why. And because when, when you, when you're io when you're seeing worse io I mean you're naturally, you wanna understand like what's the workload doing? [00:05:14] Bryan: You're trying to take a first principles approach. What's the workload doing? So this is a very intensive database workload to support the, the object storage system that we had built called Manta. And that the, the metadata tier was stored and uh, was we were using Postgres for that. And that was just getting absolutely slaughtered. [00:05:34] Bryan: Um, and ultimately very IO bound with these kind of pathological IO latencies. Uh, and as we, you know, trying to like peel away the layers to figure out what was going on. And I finally had this thing. So it's like, okay, we are seeing at the, at the device layer, at the at, at the disc layer, we are seeing pathological outliers in this data center that we're not seeing anywhere else. [00:06:00] Bryan: And that does not make any sense. And the thought occurred to me. I'm like, well, maybe we are. Do we have like different. Different rev of firmware on our HGST drives, HGST. Now part of WD Western Digital were the drives that we had everywhere. And, um, so maybe we had a different, maybe I had a firmware bug. [00:06:20] Bryan: I, this would not be the first time in my life at all that I would have a drive firmware issue. Uh, and I went to go pull the firmware, rev, and I'm like, Toshiba makes hard drives? So we had, I mean. I had no idea that Toshiba even made hard drives, let alone that they were our, they were in our data center. [00:06:38] Bryan: I'm like, what is this? And as it turns out, and this is, you know, part of the, the challenge when you don't have an integrated system, which not to pick on them, but Dell doesn't, and what Dell would routinely put just sub make substitutes, and they make substitutes that they, you know, it's kind of like you're going to like, I don't know, Instacart or whatever, and they're out of the thing that you want. [00:07:03] Bryan: So, you know, you're, someone makes a substitute and like sometimes that's okay, but it's really not okay in a data center. And you really want to develop and validate a, an end-to-end integrated system. And in this case, like Toshiba doesn't, I mean, Toshiba does make hard drives, but they are a, or the data they did, uh, they basically were, uh, not competitive and they were not competitive in part for the reasons that we were discovering. [00:07:29] Bryan: They had really serious firmware issues. So the, these were drives that would just simply stop a, a stop acknowledging any reads from the order of 2,700 milliseconds. Long time, 2.7 seconds. Um. And that was a, it was a drive firmware issue, but it was highlighted like a much deeper issue, which was the simple lack of control that we had over our own destiny. [00:07:53] Bryan: Um, and it's an, it's, it's an example among many where Dell is making a decision. That lowers the cost of what they are providing you marginally, but it is then giving you a system that they shouldn't have any confidence in because it's not one that they've actually designed and they leave it to the customer, the end user, to make these discoveries. [00:08:18] Bryan: And these things happen up and down the stack. And for every, for whether it's, and, and not just to pick on Dell because it's, it's true for HPE, it's true for super micro, uh, it's true for your switch vendors. It's, it's true for storage vendors where the, the, the, the one that is left actually integrating these things and trying to make the the whole thing work is the end user sitting in their data center. AWS / Google are not buying off the shelf hardware but you can't use it [00:08:42] Bryan: There's not a product that they can buy that gives them elastic infrastructure, a cloud in their own DC The, the product that you buy is the public cloud. Like when you go in the public cloud, you don't worry about the stuff because that it's, it's AWS's issue or it's GCP's issue. And they are the ones that get this to ground. [00:09:02] Bryan: And they, and this was kind of, you know, the eye-opening moment. Not a surprise. Uh, they are not Dell customers. They're not HPE customers. They're not super micro customers. They have designed their own machines. And to varying degrees, depending on which one you're looking at. But they've taken the clean sheet of paper and the frustration that we had kind of at Joyent and beginning to wonder and then Samsung and kind of wondering what was next, uh, is that, that what they built was not available for purchase in the data center. [00:09:35] Bryan: You could only rent it in the public cloud. And our big belief is that public cloud computing is a really important revolution in infrastructure. Doesn't feel like a different, a deep thought, but cloud computing is a really important revolution. It shouldn't only be available to rent. You should be able to actually buy it. [00:09:53] Bryan: And there are a bunch of reasons for doing that. Uh, one in the one we we saw at Samsung is economics, which I think is still the dominant reason where it just does not make sense to rent all of your compute in perpetuity. But there are other reasons too. There's security, there's risk management, there's latency. [00:10:07] Bryan: There are a bunch of reasons why one might wanna to own one's own infrastructure. But, uh, that was very much the, the, so the, the genesis for oxide was coming out of this very painful experience and a painful experience that, because, I mean, a long answer to your question about like what was it like to be at Samsung scale? [00:10:27] Bryan: Those are the kinds of things that we, I mean, in our other data centers, we didn't have Toshiba drives. We only had the HDSC drives, but it's only when you get to this larger scale that you begin to see some of these pathologies. But these pathologies then are really debilitating in terms of those who are trying to develop a service on top of them. [00:10:45] Bryan: So it was, it was very educational in, in that regard. And you're very grateful for the experience at Samsung in terms of opening our eyes to the challenge of running at that kind of scale. [00:10:57] Jeremy: Yeah, because I, I think as software engineers, a lot of times we, we treat the hardware as a, as a given where, [00:11:08] Bryan: Yeah. [00:11:08] Bryan: Yeah. There's software in chard drives [00:11:09] Jeremy: It sounds like in, in this case, I mean, maybe the issue is not so much that. Dell or HP as a company doesn't own every single piece that they're providing you, but rather the fact that they're swapping pieces in and out without advertising them, and then when it becomes a problem, they're not necessarily willing to, to deal with the, the consequences of that. [00:11:34] Bryan: They just don't know. I mean, I think they just genuinely don't know. I mean, I think that they, it's not like they're making a deliberate decision to kind of ship garbage. It's just that they are making, I mean, I think it's exactly what you said about like, not thinking about the hardware. It's like, what's a hard drive? [00:11:47] Bryan: Like what's it, I mean, it's a hard drive. It's got the same specs as this other hard drive and Intel. You know, it's a little bit cheaper, so why not? It's like, well, like there's some reasons why not, and one of the reasons why not is like, uh, even a hard drive, whether it's rotating media or, or flash, like that's not just hardware. [00:12:05] Bryan: There's software in there. And that the software's like not the same. I mean, there are components where it's like, there's actually, whether, you know, if, if you're looking at like a resistor or a capacitor or something like this Yeah. If you've got two, two parts that are within the same tolerance. Yeah. [00:12:19] Bryan: Like sure. Maybe, although even the EEs I think would be, would be, uh, objecting that a little bit. But the, the, the more complicated you get, and certainly once you get to the, the, the, the kind of the hardware that we think of like a, a, a microprocessor, a a network interface card, a a, a hard driver, an NVME drive. [00:12:38] Bryan: Those things are super complicated and there's a whole bunch of software inside of those things, the firmware, and that's the stuff that, that you can't, I mean, you say that software engineers don't think about that. It's like you, no one can really think about that because it's proprietary that's kinda welded shut and you've got this abstraction into it. [00:12:55] Bryan: But the, the way that thing operates is very core to how the thing in aggregate will behave. And I think that you, the, the kind of, the, the fundamental difference between Oxide's approach and the approach that you get at a Dell HP Supermicro, wherever, is really thinking holistically in terms of hardware and software together in a system that, that ultimately delivers cloud computing to a user. [00:13:22] Bryan: And there's a lot of software at many, many, many, many different layers. And it's very important to think about, about that software and that hardware holistically as a single system. [00:13:34] Jeremy: And during that time at Joyent, when you experienced some of these issues, was it more of a case of you didn't have enough servers experiencing this? So if it would happen, you might say like, well, this one's not working, so maybe we'll just replace the hardware. What, what was the thought process when you were working at that smaller scale and, and how did these issues affect you? UEFI / Baseboard Management Controller [00:13:58] Bryan: Yeah, at the smaller scale, you, uh, you see fewer of them, right? You just see it's like, okay, we, you know, what you might see is like, that's weird. We kinda saw this in one machine versus seeing it in a hundred or a thousand or 10,000. Um, so you just, you just see them, uh, less frequently as a result, they are less debilitating. [00:14:16] Bryan: Um, I, I think that it's, when you go to that larger scale, those things that become, that were unusual now become routine and they become debilitating. Um, so it, it really is in many regards a function of scale. Uh, and then I think it was also, you know, it was a little bit dispiriting that kind of the substrate we were building on really had not improved. [00:14:39] Bryan: Um, and if you look at, you know, the, if you buy a computer server, buy an x86 server. There is a very low layer of firmware, the BIOS, the basic input output system, the UEFI BIOS, and this is like an abstraction layer that has, has existed since the eighties and hasn't really meaningfully improved. Um, the, the kind of the transition to UEFI happened with, I mean, I, I ironically with Itanium, um, you know, two decades ago. [00:15:08] Bryan: but beyond that, like this low layer, this lowest layer of platform enablement software is really only impeding the operability of the system. Um, you look at the baseboard management controller, which is the kind of the computer within the computer, there is a, uh, there is an element in the machine that needs to handle environmentals, that needs to handle, uh, operate the fans and so on. [00:15:31] Bryan: Uh, and that traditionally has this, the space board management controller, and that architecturally just hasn't improved in the last two decades. And, you know, that's, it's a proprietary piece of silicon. Generally from a company that no one's ever heard of called a Speed, uh, which has to be, is written all on caps, so I guess it needs to be screamed. [00:15:50] Bryan: Um, a speed has a proprietary part that has a, there is a root password infamously there, is there, the root password is encoded effectively in silicon. So, uh, which is just, and for, um, anyone who kind of goes deep into these things, like, oh my God, are you kidding me? Um, when we first started oxide, the wifi password was a fraction of the a speed root password for the bmc. [00:16:16] Bryan: It's kinda like a little, little BMC humor. Um, but those things, it was just dispiriting that, that the, the state-of-the-art was still basically personal computers running in the data center. Um, and that's part of what, what was the motivation for doing something new? [00:16:32] Jeremy: And for the people using these systems, whether it's the baseboard management controller or it's the The BIOS or UF UEFI component, what are the actual problems that people are seeing seen? Security vulnerabilities and poor practices in the BMC [00:16:51] Bryan: Oh man, I, the, you are going to have like some fraction of your listeners, maybe a big fraction where like, yeah, like what are the problems? That's a good question. And then you're gonna have the people that actually deal with these things who are, did like their heads already hit the desk being like, what are the problems? [00:17:06] Bryan: Like what are the non problems? Like what, what works? Actually, that's like a shorter answer. Um, I mean, there are so many problems and a lot of it is just like, I mean, there are problems just architecturally these things are just so, I mean, and you could, they're the problems spread to the horizon, so you can kind of start wherever you want. [00:17:24] Bryan: But I mean, as like, as a really concrete example. Okay, so the, the BMCs that, that the computer within the computer that needs to be on its own network. So you now have like not one network, you got two networks that, and that network, by the way, it, that's the network that you're gonna log into to like reset the machine when it's otherwise unresponsive. [00:17:44] Bryan: So that going into the BMC, you can are, you're able to control the entire machine. Well it's like, alright, so now I've got a second net network that I need to manage. What is running on the BMC? Well, it's running some. Ancient, ancient version of Linux it that you got. It's like, well how do I, how do I patch that? [00:18:02] Bryan: How do I like manage the vulnerabilities with that? Because if someone is able to root your BMC, they control the system. So it's like, this is not you've, and now you've gotta go deal with all of the operational hair around that. How do you upgrade that system updating the BMC? I mean, it's like you've got this like second shadow bad infrastructure that you have to go manage. [00:18:23] Bryan: Generally not open source. There's something called open BMC, um, which, um, you people use to varying degrees, but you're generally stuck with the proprietary BMC, so you're generally stuck with, with iLO from HPE or iDRAC from Dell or, or, uh, the, uh, su super micros, BMC, that H-P-B-M-C, and you are, uh, it is just excruciating pain. [00:18:49] Bryan: Um, and that this is assuming that by the way, that everything is behaving correctly. The, the problem is that these things often don't behave correctly, and then the consequence of them not behaving correctly. It's really dire because it's at that lowest layer of the system. So, I mean, I'll give you a concrete example. [00:19:07] Bryan: a customer of theirs reported to me, so I won't disclose the vendor, but let's just say that a well-known vendor had an issue with their, their temperature sensors were broken. Um, and the thing would always read basically the wrong value. So it was the BMC that had to like, invent its own ki a different kind of thermal control loop. [00:19:28] Bryan: And it would index on the, on the, the, the, the actual inrush current. It would, they would look at that at the current that's going into the CPU to adjust the fan speed. That's a great example of something like that's a, that's an interesting idea. That doesn't work. 'cause that's actually not the temperature. [00:19:45] Bryan: So like that software would crank the fans whenever you had an inrush of current and this customer had a workload that would spike the current and by it, when it would spike the current, the, the, the fans would kick up and then they would slowly degrade over time. Well, this workload was spiking the current faster than the fans would degrade, but not fast enough to actually heat up the part. [00:20:08] Bryan: And ultimately over a very long time, in a very painful investigation, it's customer determined that like my fans are cranked in my data center for no reason. We're blowing cold air. And it's like that, this is on the order of like a hundred watts, a server of, of energy that you shouldn't be spending and like that ultimately what that go comes down to this kind of broken software hardware interface at the lowest layer that has real meaningful consequence, uh, in terms of hundreds of kilowatts, um, across a data center. So this stuff has, has very, very, very real consequence and it's such a shadowy world. Part of the reason that, that your listeners that have dealt with this, that our heads will hit the desk is because it is really aggravating to deal with problems with this layer. [00:21:01] Bryan: You, you feel powerless. You don't control or really see the software that's on them. It's generally proprietary. You are relying on your vendor. Your vendor is telling you that like, boy, I don't know. You're the only customer seeing this. I mean, the number of times I have heard that for, and I, I have pledged that we're, we're not gonna say that at oxide because it's such an unaskable thing to say like, you're the only customer saying this. [00:21:25] Bryan: It's like, it feels like, are you blaming me for my problem? Feels like you're blaming me for my problem? Um, and what you begin to realize is that to a degree, these folks are speaking their own truth because the, the folks that are running at real scale at Hyperscale, those folks aren't Dell, HP super micro customers. [00:21:46] Bryan: They're actually, they've done their own thing. So it's like, yeah, Dell's not seeing that problem, um, because they're not running at the same scale. Um, but when you do run, you only have to run at modest scale before these things just become. Overwhelming in terms of the, the headwind that they present to people that wanna deploy infrastructure. The problem is felt with just a few racks [00:22:05] Jeremy: Yeah, so maybe to help people get some perspective at, at what point do you think that people start noticing or start feeling these problems? Because I imagine that if you're just have a few racks or [00:22:22] Bryan: do you have a couple racks or the, or do you wonder or just wondering because No, no, no. I would think, I think anyone who deploys any number of servers, especially now, especially if your experience is only in the cloud, you're gonna be like, what the hell is this? I mean, just again, just to get this thing working at all. [00:22:39] Bryan: It is so it, it's so hairy and so congealed, right? It's not designed. Um, and it, it, it, it's accreted it and it's so obviously accreted that you are, I mean, nobody who is setting up a rack of servers is gonna think to themselves like, yes, this is the right way to go do it. This all makes sense because it's, it's just not, it, I, it feels like the kit, I mean, kit car's almost too generous because it implies that there's like a set of plans to work to in the end. [00:23:08] Bryan: Uh, I mean, it, it, it's a bag of bolts. It's a bunch of parts that you're putting together. And so even at the smallest scales, that stuff is painful. Just architecturally, it's painful at the small scale then, but at least you can get it working. I think the stuff that then becomes debilitating at larger scale are the things that are, are worse than just like, I can't, like this thing is a mess to get working. [00:23:31] Bryan: It's like the, the, the fan issue that, um, where you are now seeing this over, you know, hundreds of machines or thousands of machines. Um, so I, it is painful at more or less all levels of scale. There's, there is no level at which the, the, the pc, which is really what this is, this is a, the, the personal computer architecture from the 1980s and there is really no level of scale where that's the right unit. Running elastic infrastructure is the hardware but also, hypervisor, distributed database, api, etc [00:23:57] Bryan: I mean, where that's the right thing to go deploy, especially if what you are trying to run. Is elastic infrastructure, a cloud. Because the other thing is like we, we've kinda been talking a lot about that hardware layer. Like hardware is, is just the start. Like you actually gotta go put software on that and actually run that as elastic infrastructure. [00:24:16] Bryan: So you need a hypervisor. Yes. But you need a lot more than that. You, you need to actually, you, you need a distributed database, you need web endpoints. You need, you need a CLI, you need all the stuff that you need to actually go run an actual service of compute or networking or storage. I mean, and for, for compute, even for compute, there's a ton of work to be done. [00:24:39] Bryan: And compute is by far, I would say the simplest of the, of the three. When you look at like networks, network services, storage services, there's a whole bunch of stuff that you need to go build in terms of distributed systems to actually offer that as a cloud. So it, I mean, it is painful at more or less every LE level if you are trying to deploy cloud computing on. What's a control plane? [00:25:00] Jeremy: And for someone who doesn't have experience building or working with this type of infrastructure, when you talk about a control plane, what, what does that do in the context of this system? [00:25:16] Bryan: So control plane is the thing that is, that is everything between your API request and that infrastructure actually being acted upon. So you go say, Hey, I, I want a provision, a vm. Okay, great. We've got a whole bunch of things we're gonna provision with that. We're gonna provision a vm, we're gonna get some storage that's gonna go along with that, that's got a network storage service that's gonna come out of, uh, we've got a virtual network that we're gonna either create or attach to. [00:25:39] Bryan: We've got a, a whole bunch of things we need to go do for that. For all of these things, there are metadata components that need, we need to keep track of this thing that, beyond the actual infrastructure that we create. And then we need to go actually, like act on the actual compute elements, the hostos, what have you, the switches, what have you, and actually go. [00:25:56] Bryan: Create these underlying things and then connect them. And there's of course, the challenge of just getting that working is a big challenge. Um, but getting that working robustly, getting that working is, you know, when you go to provision of vm, um, the, all the, the, the steps that need to happen and what happens if one of those steps fails along the way? [00:26:17] Bryan: What happens if, you know, one thing we're very mindful of is these kind of, you get these long tails of like, why, you know, generally our VM provisioning happened within this time, but we get these long tails where it takes much longer. What's going on? What, where in this process are we, are we actually spending time? [00:26:33] Bryan: Uh, and there's a whole lot of complexity that you need to go deal with that. There's a lot of complexity that you need to go deal with this effectively, this workflow that's gonna go create these things and manage them. Um, we use a, a pattern that we call, that are called sagas, actually is a, is a database pattern from the eighties. [00:26:51] Bryan: Uh, Katie McCaffrey is a, is a database reCrcher who, who, uh, I, I think, uh, reintroduce the idea of, of sagas, um, in the last kind of decade. Um, and this is something that we picked up, um, and I've done a lot of really interesting things with, um, to allow for, to this kind of, these workflows to be, to be managed and done so robustly in a way that you can restart them and so on. [00:27:16] Bryan: Uh, and then you guys, you get this whole distributed system that can do all this. That whole distributed system, that itself needs to be reliable and available. So if you, you know, you need to be able to, what happens if you, if you pull a sled or if a sled fails, how does the system deal with that? [00:27:33] Bryan: How does the system deal with getting an another sled added to the system? Like how do you actually grow this distributed system? And then how do you update it? How do you actually go from one version to the next? And all of that has to happen across an air gap where this is gonna run as part of the computer. [00:27:49] Bryan: So there are, it, it is fractally complicated. There, there is a lot of complexity here in, in software, in the software system and all of that. We kind of, we call the control plane. Um, and it, this is the what exists at AWS at GCP, at Azure. When you are hitting an endpoint that's provisioning an EC2 instance for you. [00:28:10] Bryan: There is an AWS control plane that is, is doing all of this and has, uh, some of these similar aspects and certainly some of these similar challenges. Are vSphere / Proxmox / Hyper-V in the same category? [00:28:20] Jeremy: And for people who have run their own servers with something like say VMware or Hyper V or Proxmox, are those in the same category? [00:28:32] Bryan: Yeah, I mean a little bit. I mean, it kind of like vSphere Yes. Via VMware. No. So it's like you, uh, VMware ESX is, is kind of a key building block upon which you can build something that is a more meaningful distributed system. When it's just like a machine that you're provisioning VMs on, it's like, okay, well that's actually, you as the human might be the control plane. [00:28:52] Bryan: Like, that's, that, that's, that's a much easier problem. Um, but when you've got, you know, tens, hundreds, thousands of machines, you need to do it robustly. You need something to coordinate that activity and you know, you need to pick which sled you land on. You need to be able to move these things. You need to be able to update that whole system. [00:29:06] Bryan: That's when you're getting into a control plane. So, you know, some of these things have kind of edged into a control plane, certainly VMware. Um, now Broadcom, um, has delivered something that's kind of cloudish. Um, I think that for folks that are truly born on the cloud, it, it still feels somewhat, uh, like you're going backwards in time when you, when you look at these kind of on-prem offerings. [00:29:29] Bryan: Um, but, but it, it, it's got these aspects to it for sure. Um, and I think that we're, um, some of these other things when you're just looking at KVM or just looks looking at Proxmox you kind of need to, to connect it to other broader things to turn it into something that really looks like manageable infrastructure. [00:29:47] Bryan: And then many of those projects are really, they're either proprietary projects, uh, proprietary products like vSphere, um, or you are really dealing with open source projects that are. Not necessarily aimed at the same level of scale. Um, you know, you look at a, again, Proxmox or, uh, um, you'll get an OpenStack. [00:30:05] Bryan: Um, and you know, OpenStack is just a lot of things, right? I mean, OpenStack has got so many, the OpenStack was kind of a, a free for all, for every infrastructure vendor. Um, and I, you know, there was a time people were like, don't you, aren't you worried about all these companies together that, you know, are coming together for OpenStack? [00:30:24] Bryan: I'm like, haven't you ever worked for like a company? Like, companies don't get along. By the way, it's like having multiple companies work together on a thing that's bad news, not good news. And I think, you know, one of the things that OpenStack has definitely struggled with, kind of with what, actually the, the, there's so many different kind of vendor elements in there that it's, it's very much not a product, it's a project that you're trying to run. [00:30:47] Bryan: But that's, but that very much is in, I mean, that's, that's similar certainly in spirit. [00:30:53] Jeremy: And so I think this is kind of like you're alluding to earlier, the piece that allows you to allocate, compute, storage, manage networking, gives you that experience of I can go to a web console or I can use an API and I can spin up machines, get them all connected. At the end of the day, the control plane. Is allowing you to do that in hopefully a user-friendly way. [00:31:21] Bryan: That's right. Yep. And in the, I mean, in order to do that in a modern way, it's not just like a user-friendly way. You really need to have a CLI and a web UI and an API. Those all need to be drawn from the same kind of single ground truth. Like you don't wanna have any of those be an afterthought for the other. [00:31:39] Bryan: You wanna have the same way of generating all of those different endpoints and, and entries into the system. Building a control plane now has better tools (Rust, CockroachDB) [00:31:46] Jeremy: And if you take your time at Joyent as an example. What kind of tools existed for that versus how much did you have to build in-house for as far as the hypervisor and managing the compute and all that? [00:32:02] Bryan: Yeah, so we built more or less everything in house. I mean, what you have is, um, and I think, you know, over time we've gotten slightly better tools. Um, I think, and, and maybe it's a little bit easier to talk about the, kind of the tools we started at Oxide because we kind of started with a, with a clean sheet of paper at oxide. [00:32:16] Bryan: We wanted to, knew we wanted to go build a control plane, but we were able to kind of go revisit some of the components. So actually, and maybe I'll, I'll talk about some of those changes. So when we, at, For example, at Joyent, when we were building a cloud at Joyent, there wasn't really a good distributed database. [00:32:34] Bryan: Um, so we were using Postgres as our database for metadata and there were a lot of challenges. And Postgres is not a distributed database. It's running. With a primary secondary architecture, and there's a bunch of issues there, many of which we discovered the hard way. Um, when we were coming to oxide, you have much better options to pick from in terms of distributed databases. [00:32:57] Bryan: You know, we, there was a period that now seems maybe potentially brief in hindsight, but of a really high quality open source distributed databases. So there were really some good ones to, to pick from. Um, we, we built on CockroachDB on CRDB. Um, so that was a really important component. That we had at oxide that we didn't have at Joyent. [00:33:19] Bryan: Um, so we were, I wouldn't say we were rolling our own distributed database, we were just using Postgres and uh, and, and dealing with an enormous amount of pain there in terms of the surround. Um, on top of that, and, and, you know, a, a control plane is much more than a database, obviously. Uh, and you've gotta deal with, uh, there's a whole bunch of software that you need to go, right. [00:33:40] Bryan: Um, to be able to, to transform these kind of API requests into something that is reliable infrastructure, right? And there, there's a lot to that. Uh, especially when networking gets in the mix, when storage gets in the mix, uh, there are a whole bunch of like complicated steps that need to be done, um, at Joyent. [00:33:59] Bryan: Um, we, in part because of the history of the company and like, look. This, this just is not gonna sound good, but it just is what it is and I'm just gonna own it. We did it all in Node, um, at Joyent, which I, I, I know it sounds really right now, just sounds like, well, you, you built it with Tinker Toys. You Okay. [00:34:18] Bryan: Uh, did, did you think it was, you built the skyscraper with Tinker Toys? Uh, it's like, well, okay. We actually, we had greater aspirations for the Tinker Toys once upon a time, and it was better than, you know, than Twisted Python and Event Machine from Ruby, and we weren't gonna do it in Java. All right. [00:34:32] Bryan: So, but let's just say that that experiment, uh, that experiment did ultimately end in a predictable fashion. Um, and, uh, we, we decided that maybe Node was not gonna be the best decision long term. Um, Joyent was the company behind node js. Uh, back in the day, Ryan Dahl worked for Joyent. Uh, and then, uh, then we, we, we. [00:34:53] Bryan: Uh, landed that in a foundation in about, uh, what, 2015, something like that. Um, and began to consider our world beyond, uh, beyond Node. Rust at Oxide [00:35:04] Bryan: A big tool that we had in the arsenal when we started Oxide is Rust. Um, and so indeed the name of the company is, is a tip of the hat to the language that we were pretty sure we were gonna be building a lot of stuff in. [00:35:16] Bryan: Namely Rust. And, uh, rust is, uh, has been huge for us, a very important revolution in programming languages. you know, there, there, there have been different people kind of coming in at different times and I kinda came to Rust in what I, I think is like this big kind of second expansion of rust in 2018 when a lot of technologists were think, uh, sick of Node and also sick of Go. [00:35:43] Bryan: And, uh, also sick of C++. And wondering is there gonna be something that gives me the, the, the performance, of that I get outta C. The, the robustness that I can get out of a C program but is is often difficult to achieve. but can I get that with kind of some, some of the velocity of development, although I hate that term, some of the speed of development that you get out of a more interpreted language. [00:36:08] Bryan: Um, and then by the way, can I actually have types, I think types would be a good idea? Uh, and rust obviously hits the sweet spot of all of that. Um, it has been absolutely huge for us. I mean, we knew when we started the company again, oxide, uh, we were gonna be using rust in, in quite a, quite a. Few places, but we weren't doing it by fiat. [00:36:27] Bryan: Um, we wanted to actually make sure we're making the right decision, um, at, at every different, at every layer. Uh, I think what has been surprising is the sheer number of layers at which we use rust in terms of, we've done our own embedded firmware in rust. We've done, um, in, in the host operating system, which is still largely in C, but very big components are in rust. [00:36:47] Bryan: The hypervisor Propolis is all in rust. Uh, and then of course the control plane, that distributed system on that is all in rust. So that was a very important thing that we very much did not need to build ourselves. We were able to really leverage, uh, a terrific community. Um. We were able to use, uh, and we've done this at Joyent as well, but at Oxide, we've used Illumos as a hostos component, which, uh, our variant is called Helios. [00:37:11] Bryan: Um, we've used, uh, bhyve um, as a, as as that kind of internal hypervisor component. we've made use of a bunch of different open source components to build this thing, um, which has been really, really important for us. Uh, and open source components that didn't exist even like five years prior. [00:37:28] Bryan: That's part of why we felt that 2019 was the right time to start the company. And so we started Oxide. The problems building a control plane in Node [00:37:34] Jeremy: You had mentioned that at Joyent, you had tried to build this in, in Node. What were the, what were the, the issues or the, the challenges that you had doing that? [00:37:46] Bryan: Oh boy. Yeah. again, we, I kind of had higher hopes in 2010, I would say. When we, we set on this, um, the, the, the problem that we had just writ large, um. JavaScript is really designed to allow as many people on earth to write a program as possible, which is good. I mean, I, I, that's a, that's a laudable goal. [00:38:09] Bryan: That is the goal ultimately of such as it is of JavaScript. It's actually hard to know what the goal of JavaScript is, unfortunately, because Brendan Ike never actually wrote a book. so that there is not a canonical, you've got kind of Doug Crockford and other people who've written things on JavaScript, but it's hard to know kind of what the original intent of JavaScript is. [00:38:27] Bryan: The name doesn't even express original intent, right? It was called Live Script, and it was kind of renamed to JavaScript during the Java Frenzy of the late nineties. A name that makes no sense. There is no Java in JavaScript. that is kind of, I think, revealing to kind of the, uh, the unprincipled mess that is JavaScript. [00:38:47] Bryan: It, it, it's very pragmatic at some level, um, and allows anyone to, it makes it very easy to write software. The problem is it's much more difficult to write really rigorous software. So, uh, and this is what I should differentiate JavaScript from TypeScript. This is really what TypeScript is trying to solve. [00:39:07] Bryan: TypeScript is like. How can, I think TypeScript is a, is a great step forward because TypeScript is like, how can we bring some rigor to this? Like, yes, it's great that it's easy to write JavaScript, but that's not, we, we don't wanna do that for Absolutely. I mean that, that's not the only problem we solve. [00:39:23] Bryan: We actually wanna be able to write rigorous software and it's actually okay if it's a little harder to write rigorous software that's actually okay if it gets leads to, to more rigorous artifacts. Um, but in JavaScript, I mean, just a concrete example. You know, there's nothing to prevent you from referencing a property that doesn't actually exist in JavaScript. [00:39:43] Bryan: So if you fat finger a property name, you are relying on something to tell you. By the way, I think you've misspelled this because there is no type definition for this thing. And I don't know that you've got one that's spelled correctly, one that's spelled incorrectly, that's often undefined. And then the, when you actually go, you say you've got this typo that is lurking in your what you want to be rigorous software. [00:40:07] Bryan: And if you don't execute that code, like you won't know that's there. And then you do execute that code. And now you've got a, you've got an undefined object. And now that's either gonna be an exception or it can, again, depends on how that's handled. It can be really difficult to determine the origin of that, of, of that error, of that programming. [00:40:26] Bryan: And that is a programmer error. And one of the big challenges that we had with Node is that programmer errors and operational errors, like, you know, I'm out of disk space as an operational error. Those get conflated and it becomes really hard. And in fact, I think the, the language wanted to make it easier to just kind of, uh, drive on in the event of all errors. [00:40:53] Bryan: And it's like, actually not what you wanna do if you're trying to build a reliable, robust system. So we had. No end of issues. [00:41:01] Bryan: We've got a lot of experience developing rigorous systems, um, again coming out of operating systems development and so on. And we want, we brought some of that rigor, if strangely, to JavaScript. So one of the things that we did is we brought a lot of postmortem, diagnos ability and observability to node. [00:41:18] Bryan: And so if, if one of our node processes. Died in production, we would actually get a core dump from that process, a core dump that we could actually meaningfully process. So we did a bunch of kind of wild stuff. I mean, actually wild stuff where we could actually make sense of the JavaScript objects in a binary core dump. JavaScript values ease of getting started over robustness [00:41:41] Bryan: Um, and things that we thought were really important, and this is the, the rest of the world just looks at this being like, what the hell is this? I mean, it's so out of step with it. The problem is that we were trying to bridge two disconnected cultures of one developing really. Rigorous software and really designing it for production, diagnosability and the other, really designing it to software to run in the browser and for anyone to be able to like, you know, kind of liven up a webpage, right? [00:42:10] Bryan: Is kinda the origin of, of live script and then JavaScript. And we were kind of the only ones sitting at the intersection of that. And you begin when you are the only ones sitting at that kind of intersection. You just are, you're, you're kind of fighting a community all the time. And we just realized that we are, there were so many things that the community wanted to do that we felt are like, no, no, this is gonna make software less diagnosable. It's gonna make it less robust. The NodeJS split and why people left [00:42:36] Bryan: And then you realize like, I'm, we're the only voice in the room because we have got, we have got desires for this language that it doesn't have for itself. And this is when you realize you're in a bad relationship with software. It's time to actually move on. And in fact, actually several years after, we'd already kind of broken up with node. [00:42:55] Bryan: Um, and it was like, it was a bit of an acrimonious breakup. there was a, uh, famous slash infamous fork of node called IoJS Um, and this was viewed because people, the community, thought that Joyent was being what was not being an appropriate steward of node js and was, uh, not allowing more things to come into to, to node. [00:43:19] Bryan: And of course, the reason that we of course, felt that we were being a careful steward and we were actively resisting those things that would cut against its fitness for a production system. But it's some way the community saw it and they, and forked, um, and, and I think the, we knew before the fork that's like, this is not working and we need to get this thing out of our hands. Platform is a reflection of values node summit talk [00:43:43] Bryan: And we're are the wrong hands for this? This needs to be in a foundation. Uh, and so we kind of gone through that breakup, uh, and maybe it was two years after that. That, uh, friend of mine who was um, was running the, uh, the node summit was actually, it's unfortunately now passed away. Charles er, um, but Charles' venture capitalist great guy, and Charles was running Node Summit and came to me in 2017. [00:44:07] Bryan: He is like, I really want you to keynote Node Summit. And I'm like, Charles, I'm not gonna do that. I've got nothing nice to say. Like, this is the, the, you don't want, I'm the last person you wanna keynote. He's like, oh, if you have nothing nice to say, you should definitely keynote. You're like, oh God, okay, here we go. [00:44:22] Bryan: He's like, no, I really want you to talk about, like, you should talk about the Joyent breakup with NodeJS. I'm like, oh man. [00:44:29] Bryan: And that led to a talk that I'm really happy that I gave, 'cause it was a very important talk for me personally. Uh, called Platform is a reflection of values and really looking at the values that we had for Node and the values that Node had for itself. And they didn't line up. [00:44:49] Bryan: And the problem is that the values that Node had for itself and the values that we had for Node are all kind of positives, right? Like there's nobody in the node community who's like, I don't want rigor, I hate rigor. It's just that if they had the choose between rigor and making the language approachable. [00:45:09] Bryan: They would choose approachability every single time. They would never choose rigor. And, you know, that was a, that was a big eye-opener. I do, I would say, if you watch this talk. [00:45:20] Bryan: because I knew that there's, like, the audience was gonna be filled with, with people who, had been a part of the fork in 2014, I think was the, the, the, the fork, the IOJS fork. And I knew that there, there were, there were some, you know, some people that were, um, had been there for the fork and. [00:45:41] Bryan: I said a little bit of a trap for the audience. But the, and the trap, I said, you know what, I, I kind of talked about the values that we had and the aspirations we had for Node, the aspirations that Node had for itself and how they were different. [00:45:53] Bryan: And, you know, and I'm like, look in, in, in hindsight, like a fracture was inevitable. And in 2014 there was finally a fracture. And do people know what happened in 2014? And if you, if you, you could listen to that talk, everyone almost says in unison, like IOJS. I'm like, oh right. IOJS. Right. That's actually not what I was thinking of. [00:46:19] Bryan: And I go to the next slide and is a tweet from a guy named TJ Holloway, Chuck, who was the most prolific contributor to Node. And it was his tweet also in 2014 before the fork, before the IOJS fork explaining that he was leaving Node and that he was going to go. And you, if you turn the volume all the way up, you can hear the audience gasp. [00:46:41] Bryan: And it's just delicious because the community had never really come, had never really confronted why TJ left. Um, there. And I went through a couple folks, Felix, bunch of other folks, early Node folks. That were there in 2010, were leaving in 2014, and they were going to go primarily, and they were going to go because they were sick of the same things that we were sick of. [00:47:09] Bryan: They, they, they had hit the same things that we had hit and they were frustrated. I I really do believe this, that platforms do reflect their own values. And when you are making a software decision, you are selecting value. [00:47:26] Bryan: You should select values that align with the values that you have for that software. That is, those are, that's way more important than other things that people look at. I think people look at, for example, quote unquote community size way too frequently, community size is like. Eh, maybe it can be fine. [00:47:44] Bryan: I've been in very large communities, node. I've been in super small open source communities like AUMs and RAs, a bunch of others. there are strengths and weaknesses to both approaches just as like there's a strength to being in a big city versus a small town. Me personally, I'll take the small community more or less every time because the small community is almost always self-selecting based on values and just for the same reason that I like working at small companies or small teams. [00:48:11] Bryan: There's a lot of value to be had in a small community. It's not to say that large communities are valueless, but again, long answer to your question of kind of where did things go south with Joyent and node. They went south because the, the values that we had and the values the community had didn't line up and that was a very educational experience, as you might imagine. [00:48:33] Jeremy: Yeah. And, and given that you mentioned how, because of those values, some people moved from Node to go, and in the end for much of what oxide is building. You ended up using rust. What, what would you say are the, the values of go and and rust, and how did you end up choosing Rust given that. Go's decisions regarding generics, versioning, compilation speed priority [00:48:56] Bryan: Yeah, I mean, well, so the value for, yeah. And so go, I mean, I understand why people move from Node to Go, go to me was kind of a lateral move. Um, there were a bunch of things that I, uh, go was still garbage collected, um, which I didn't like. Um, go also is very strange in terms of there are these kind of like. [00:49:17] Bryan: These autocratic kind of decisions that are very bizarre. Um, there, I mean, generics is kind of a famous one, right? Where go kind of as a point of principle didn't have generics, even though go itself actually the innards of go did have generics. It's just that you a go user weren't allowed to have them. [00:49:35] Bryan: And you know, it's kind of, there was, there was an old cartoon years and years ago about like when a, when a technologist is telling you that something is technically impossible, that actually means I don't feel like it. Uh, and there was a certain degree of like, generics are technically impossible and go, it's like, Hey, actually there are. [00:49:51] Bryan: And so there was, and I just think that the arguments against generics were kind of disingenuous. Um, and indeed, like they ended up adopting generics and then there's like some super weird stuff around like, they're very anti-assertion, which is like, what, how are you? Why are you, how is someone against assertions, it doesn't even make any sense, but it's like, oh, nope. [00:50:10] Bryan: Okay. There's a whole scree on it. Nope, we're against assertions and the, you know, against versioning. There was another thing like, you know, the Rob Pike has kind of famously been like, you should always just run on the way to commit. And you're like, does that, is that, does that make sense? I mean this, we actually built it. [00:50:26] Bryan: And so there are a bunch of things like that. You're just like, okay, this is just exhausting and. I mean, there's some things about Go that are great and, uh, plenty of other things that I just, I'm not a fan of. Um, I think that the, in the end, like Go cares a lot about like compile time. It's super important for Go Right? [00:50:44] Bryan: Is very quick, compile time. I'm like, okay. But that's like compile time is not like, it's not unimportant, it's doesn't have zero importance. But I've got other things that are like lots more important than that. Um, what I really care about is I want a high performing artifact. I wanted garbage collection outta my life. Don't think garbage collection has good trade offs [00:51:00] Bryan: I, I gotta tell you, I, I like garbage collection to me is an embodiment of this like, larger problem of where do you put cognitive load in the software development process. And what garbage collection is saying to me it is right for plenty of other people and the software that they wanna develop. [00:51:21] Bryan: But for me and the software that I wanna develop, infrastructure software, I don't want garbage collection because I can solve the memory allocation problem. I know when I'm like, done with something or not. I mean, it's like I, whether that's in, in C with, I mean it's actually like, it's really not that hard to not leak memory in, in a C base system. [00:51:44] Bryan: And you can. give yourself a lot of tooling that allows you to diagnose where memory leaks are coming from. So it's like that is a solvable problem. There are other challenges with that, but like, when you are developing a really sophisticated system that has garbage collection is using garbage collection. [00:51:59] Bryan: You spend as much time trying to dork with the garbage collector to convince it to collect the thing that you know is garbage. You are like, I've got this thing. I know it's garbage. Now I need to use these like tips and tricks to get the garbage collector. I mean, it's like, it feels like every Java performance issue goes to like minus xx call and use the other garbage collector, whatever one you're using, use a different one and using a different, a different approach. [00:52:23] Bryan: It's like, so you're, you're in this, to me, it's like you're in the worst of all worlds where. the reason that garbage collection is helpful is because the programmer doesn't have to think at all about this problem. But now you're actually dealing with these long pauses in production. [00:52:38] Bryan: You're dealing with all these other issues where actually you need to think a lot about it. And it's kind of, it, it it's witchcraft. It, it, it's this black box that you can't see into. So it's like, what problem have we solved exactly? And I mean, so the fact that go had garbage collection, it's like, eh, no, I, I do not want, like, and then you get all the other like weird fatwahs and you know, everything else. [00:52:57] Bryan: I'm like, no, thank you. Go is a no thank you for me, I, I get it why people like it or use it, but it's, it's just, that was not gonna be it. Choosing Rust [00:53:04] Bryan: I'm like, I want C. but I, there are things I didn't like about C too. I was looking for something that was gonna give me the deterministic kind of artifact that I got outta C. But I wanted library support and C is tough because there's, it's all convention. you know, there's just a bunch of other things that are just thorny. And I remember thinking vividly in 2018, I'm like, well, it's rust or bust. Ownership model, algebraic types, error handling [00:53:28] Bryan: I'm gonna go into rust. And, uh, I hope I like it because if it's not this, it's gonna like, I'm gonna go back to C I'm like literally trying to figure out what the language is for the back half of my career. Um, and when I, you know, did what a lot of people were doing at that time and people have been doing since of, you know, really getting into rust and really learning it, appreciating the difference in the, the model for sure, the ownership model people talk about. [00:53:54] Bryan: That's also obviously very important. It was the error handling that blew me away. And the idea of like algebraic types, I never really had algebraic types. Um, and the ability to, to have. And for error handling is one of these really, uh, you, you really appreciate these things where it's like, how do you deal with a, with a function that can either succeed and return something or it can fail, and the way c deals with that is bad with these kind of sentinels for errors. [00:54:27] Bryan: And, you know, does negative one mean success? Does negative one mean failure? Does zero mean failure? Some C functions, zero means failure. Traditionally in Unix, zero means success. And like, what if you wanna return a file descriptor, you know, it's like, oh. And then it's like, okay, then it'll be like zero through positive N will be a valid result. [00:54:44] Bryan: Negative numbers will be, and like, was it negative one and I said airo, or is it a negative number that did not, I mean, it's like, and that's all convention, right? People do all, all those different things and it's all convention and it's easy to get wrong, easy to have bugs, can't be statically checked and so on. Um, and then what Go says is like, well, you're gonna have like two return values and then you're gonna have to like, just like constantly check all of these all the time. Um, which is also kind of gross. Um, JavaScript is like, Hey, let's toss an exception. If, if we don't like something, if we see an error, we'll, we'll throw an exception. [00:55:15] Bryan: There are a bunch of reasons I don't like that. Um, and you look, you'll get what Rust does, where it's like, no, no, no. We're gonna have these algebra types, which is to say this thing can be a this thing or that thing, but it, but it has to be one of these. And by the way, you don't get to process this thing until you conditionally match on one of these things. [00:55:35] Bryan: You're gonna have to have a, a pattern match on this thing to determine if it's a this or a that, and if it in, in the result type that you, the result is a generic where it's like, it's gonna be either the thing that you wanna return. It's gonna be an okay that contains the thing you wanna return, or it's gonna be an error that contains your error and it forces your code to deal with that. [00:55:57] Bryan: And what that does is it shifts the cognitive load from the person that is operating this thing in production to the, the actual developer that is in development. And I think that that, that to me is like, I, I love that shift. Um, and that shift to me is really important. Um, and that's what I was missing, that that's what Rust gives you. [00:56:23] Bryan: Rust forces you to think about your code as you write it, but as a result, you have an artifact that is much more supportable, much more sustainable, and much faster. Prefer to frontload cognitive load during development instead of at runtime [00:56:34] Jeremy: Yeah, it sounds like you would rather take the time during the development to think about these issues because whether it's garbage collection or it's error handling at runtime when you're trying to solve a problem, then it's much more difficult than having dealt with it to start with. [00:56:57] Bryan: Yeah, absolutely. I, and I just think that like, why also, like if it's software, if it's, again, if it's infrastructure software, I mean the kinda the question that you, you should have when you're writing software is how long is this software gonna live? How many people are gonna use this software? Uh, and if you are writing an operating system, the answer for this thing that you're gonna write, it's gonna live for a long time. [00:57:18] Bryan: Like, if we just look at plenty of aspects of the system that have been around for a, for decades, it's gonna live for a long time and many, many, many people are gonna use it. Why would we not expect people writing that software to have more cognitive load when they're writing it to give us something that's gonna be a better artifact? [00:57:38] Bryan: Now conversely, you're like, Hey, I kind of don't care about this. And like, I don't know, I'm just like, I wanna see if this whole thing works. I've got, I like, I'm just stringing this together. I don't like, no, the software like will be lucky if it survives until tonight, but then like, who cares? Yeah. Yeah. [00:57:52] Bryan: Gar garbage clock. You know, if you're prototyping something, whatever. And this is why you really do get like, you know, different choices, different technology choices, depending on the way that you wanna solve the problem at hand. And for the software that I wanna write, I do like that cognitive load that is upfront. With LLMs maybe you can get the benefit of the robust artifact with less cognitive load [00:58:10] Bryan: Um, and although I think, I think the thing that is really wild that is the twist that I don't think anyone really saw coming is that in a, in an LLM age. That like the cognitive load upfront almost needs an asterisk on it because so much of that can be assisted by an LLM. And now, I mean, I would like to believe, and maybe this is me being optimistic, that the the, in the LLM age, we will see, I mean, rust is a great fit for the LLMH because the LLM itself can get a lot of feedback about whether the software that's written is correct or not. [00:58:44] Bryan: Much more so than you can for other environments. [00:58:48] Jeremy: Yeah, that is a interesting point in that I think when people first started trying out the LLMs to code, it was really good at these maybe looser languages like Python or JavaScript, and initially wasn't so good at something like Rust. But it sounds like as that improves, if. It can write it then because of the rigor or the memory management or the error handling that the language is forcing you to do, it might actually end up being a better choice for people using LLMs. [00:59:27] Bryan: absolutely. I, it, it gives you more certainty in the artifact that you've delivered. I mean, you know a lot about a Rust program that compiles correctly. I mean, th there are certain classes of errors that you don't have, um, that you actually don't know on a C program or a GO program or a, a JavaScript program. [00:59:46] Bryan: I think that's gonna be really important. I think we are on the cusp. Maybe we've already seen it, this kind of great bifurcation in the software that we writ

OpenZFS monitoring, hellosystems 0.8, GhostBSD and XLibre, Bhyve Exporters and 30 year old LibC issues. NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines OpenZFS Monitoring and Observability: What to Track and Why It Matters helloSystem 0.8 Released FreeBSD Based OS Inspired by macOS. https://itsfoss.gitlab.io/post/hellosystem-08-released-freebsd-based-os-inspired-by-macos/ News Roundup [Default GhostBSD to XLibre](https://github.com/ghostbsd/ghostbsd-build/pull/259] Addressing XLibre Change and GhostBSD Future Bhyve Prometheus Exporter for Sylve on FreeBSD. Linux GNU C Library Fixes Security Issue Present Since 1996 Beastie Bits NetBSD 11.0 RC1 available! The Book of PF, 4th Edition is now available December 2025 Finance Report LLDB improvements on FreeBSD Any desire for OnmiOS/Illumos Support : Now's your chance to convince me 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

This is a recap of the top 10 posts on Hacker News on February 23, 2026. This podcast was generated by wondercraft.ai (00:30): The Age Verification Trap: Verifying age undermines everyone's data protectionOriginal post: https://news.ycombinator.com/item?id=47122715&utm_source=wondercraft_ai(01:55): Ladybird adopts Rust, with help from AIOriginal post: https://news.ycombinator.com/item?id=47120899&utm_source=wondercraft_ai(03:21): Americans are destroying Flock surveillance camerasOriginal post: https://news.ycombinator.com/item?id=47127081&utm_source=wondercraft_ai(04:47): Elsevier shuts down its finance journal citation cartelOriginal post: https://news.ycombinator.com/item?id=47119530&utm_source=wondercraft_ai(06:12): Pope tells priests to use their brains, not AI, to write homiliesOriginal post: https://news.ycombinator.com/item?id=47119210&utm_source=wondercraft_ai(07:38): Binance fired employees who found $1.7B in crypto was sent to IranOriginal post: https://news.ycombinator.com/item?id=47127396&utm_source=wondercraft_ai(09:04): Hetzner (European hosting provider) to increase prices by up to 38%Original post: https://news.ycombinator.com/item?id=47121029&utm_source=wondercraft_ai(10:29): Magical Mushroom – Europe's first industrial-scale mycelium packaging producerOriginal post: https://news.ycombinator.com/item?id=47119274&utm_source=wondercraft_ai(11:55): FreeBSD doesn't have Wi-Fi driver for my old MacBook, so AI built one for meOriginal post: https://news.ycombinator.com/item?id=47129361&utm_source=wondercraft_ai(13:21): ASML unveils EUV light source advance that could yield 50% more chips by 2030Original post: https://news.ycombinator.com/item?id=47125349&utm_source=wondercraft_aiThis is a third-party project, independent from HN and YC. Text and audio generated using AI, by wondercraft.ai. Create your own studio quality podcast with text as the only input in seconds at app.wondercraft.ai. Issues or feedback? We'd love to hear from you: team@wondercraft.ai

GeoIP PF FreeBSD, ZFs in production, linuxulator feels like magic, XFCE is great, the scariest boot code, and more... NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines GeoIP-Aware Firewalling with PF on FreeBSD ZFS in Production: Real-World Deployment Patterns and Pitfalls News Roundup Xfce is great Linuxulator on FreeBSD Feels Like Magic The scariest boot loader code OpenBSD-current now runs as guest under Apple Hypervisor 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 Matt - Audio Levels Interviews can be troublesome because there's only so much we can do with multiple guests with multiple feeds, and mulitple audio conditions. We can try to normalize but sometimes it's just not easy to do without editing taking an entire day.. 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

AT&T's $2000 shell, ZFS Scrubs and Data Integrity, FFS Backups, FreeBSD Home Nas, and more. NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines One too many words on AT&T's $2,000 Korn shell and other Usenet topics Understanding ZFS Scrubs and Data Integrity News Roundup FFS Backup FreeBSD: Home NAS, part 1 – configuring ZFS mirror (RAID1) 8 more parts! Beastie Bits The BSD Proposal UNIX Magic Poster Haiku OS Pulls In Updated Drivers From FreeBSD 15 FreeBSD 15.0 VNET Jails Call for NetBSD testing 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 Gary - Links 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

ZFS Scrubs and Data integrity, Propolice, FreeBSD vs Slackware and more. NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Understanding ZFS Scrubs and Data Integrity The story of Propolice Desk reviews describe comment ask questions No reponses, no justications. [Tj's Desk](media/bsdnow649-tjs-desk.jpg) [Ruben's Desk](media/bsdnow649-rubens-desk.jpg) News Roundup FreeBSD vs. Slackware: Which super stable OS is right for you? Prometheus, Let's Encrypt, and making sure all our TLS certificates are monitored Wait, a repairable ThinkPad!? 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

FreeBSD's Future, 18 years of greytrapping, PF vs Linux firewalls, and more. NOTES This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon Headlines Powering the Future of FreeBSD Eighteen Years of Greytrapping - Is the Weirdness Finally Paying Off? BSDCan Organisating committee Interview News Roundup How I, a non-developer, read the tutorial you, a developer, wrote for me, a beginner BSD PF versus Linux nftables for firewalls for us 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

The Unix v4 recovery, webzfs, openbgpd 9.0, MidnightBSD 4.0, and more... NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/bsdnow) and the BSDNow Patreon (https://www.patreon.com/bsdnow) Headlines University of Utah team discovers rare computer relic (https://ksltv.com/science-technology/university-of-utah-discovers-rare-computer-relic/853296/) The attempt to read the UNIX V4 tape is underway! (https://mastodon.social/redirect/statuses/115747843746305391) UNIX V4 Tape from University of Utah (https://archive.org/details/utah_unix_v4_raw) UNIX V4 tape successfully recovered: First ever version of UNIX written in C is running again (https://www.theregister.com/2025/12/23/unix_v4_tape_successfully_recovered/) An initial analysis of the discovered Unix V4 tape (https://www.spinellis.gr/blog/20251223/) WebZFS (https://github.com/webzfs/webzfs) News Roundup OpenBGPD 9.0 released (https://www.undeadly.org/cgi?action=article;sid=20251231070524) MidnightBSD 4.0 (https://www.midnightbsd.org/notes/4.0/index.html) Let's run FreeBSD 15.0-RELEASE on a Raspberry Pi Zero 2 W (https://briancallahan.net/blog/20251216.html) Figuring out how I want to set up the TVPC (https://vulcanridr.mataroa.blog/blog/figuring-out-how-i-want-to-set-up-the-tvpc/) TVPC update (https://vulcanridr.mataroa.blog/blog/tvpc-update/) C&C Red Alert2 in your browser (https://chronodivide.com) 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 rick - shout out.md (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/646/feedback/rick%20-%20shout%20out.md) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Join us and other BSD Fans in our BSD Now Telegram channel (https://t.me/bsdnow)

R. Tyler Croy, a principal engineer at Scribd, joins Corey Quinn to explain what happens when simple tasks cost $100,000. Checking if files are damaged? $100K. Using newer S3 tools? Way too expensive. Normal solutions don't work anymore. Tyler shares how with this much data, you can't just throw money at the problem, but rather you have to engineer your way out.About R. Tyler: R. Tyler Croy leads infrastructure architecture at Scribd and has been an open source developer for over 14 years. His work spans the FreeBSD, Python, Ruby, Puppet, Jenkins, and Delta Lake communities. Under his leadership, Scribd's Infrastructure Engineering team built Delta Lake for Rust to support a wide variety of high performance data processing systems. That experience led to Tyler developing the next big iteration of storage architecture to power large-scale fulltext compute challenges facing the organization.Show Highlights:01:48 Scribd's 18-Year History04:00 One Document Becomes Billions of Files05:47 When Normal Physics Stop Working08:02 Why S3 Metadata Costs Too Much10:50 How AI Made Old Documents Valuable13:30 From 100 Billion to 100 Million Objects15:05 The Curse of Retail Pricing 19:17 How Data Scientists Create Growth21:18 De-Normalizing Data Problems25:29 Evolving Old Systems27:45 Billions Added Since Summer29:29 Underused S3 Features31:48 Where to Find TylerLinks: Scribd: https://tech.scribd.comMastodon:  https://hacky.town/@rtylerGitHub: https://github.com/rtylerSponsored by: duckbillhq.com

Corey Quinn sits down with Avery Pennarun, co-founder and CEO of Tailscale, for a deep dive into how the company is reinventing networking for the modern era. From finally making VPNs behave the way they should to tackling AI security with zero-click authentication, Avery shares candid insights on building infrastructure people actually love using, and love talking about.They get into everything: surviving 100% year-over-year growth, why running on two tailnets at once is pure chaos, and how Tailscale makes “secure by default” feel effortless. Plus, they dig into why FreeBSD firewalls needed some tough love, the uncomfortable truth behind POCs, and even the surprisingly useful trick of turning your Apple TV into an exit node.About Avery: Avery Pennarun is the co-founder and CEO of Tailscale, where he's redefining secure networking with a simple, Zero Trust approach. A veteran software engineer with experience ranging from startups to Google, he's known for turning complex systems into approachable, user-friendly tools. His contributions to projects like wvdial, bup, and sshuttle reflect his belief that great technology should be both powerful and easy to use. With a mix of technical depth and dry humor, Avery shares insights on modern networking, internet evolution, and the realities of scaling a startup.Highlights:(0:00) Introduction to Tailscale and Security(00:52) Sponsorship and Personal Experiences(02:07) Technical Deep Dive into Tail Scale(06:10) Challenges and Future of Tail Scale(22:45) Building the Tail Net's API(23:54) Connecting Cloud Providers with Tailscale(25:22) Tailscale as a Security Solution(26:44) Innovations and Future of TailscaleSponsored by: duckbillhq.com

Holidays 2025 - What you been do'in? NOTES This episode of BSDNow is brought to you by Tarsnap (https://www.tarsnap.com/bsdnow) and the BSDNow Patreon (https://www.patreon.com/bsdnow) Headlines What tech did we enjoy playing with or found interesting in 2025? 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 - Gary - Storage Is Cheap (https://github.com/BSDNow/bsdnow.tv/blob/master/episodes/644/feedback/Gary%20-%20Storage%20Is%20Cheap.md) Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv (mailto:feedback@bsdnow.tv) Join us and other BSD Fans in our BSD Now Telegram channel (https://t.me/bsdnow)

DLLs & TLS Callbacks As a follow-up to last week's diary about DLL Entrypoints, Didier is looking at TLS ( Thread Local Storage ) and how it can be abused. https://isc.sans.edu/diary/DLLs%20%26%20TLS%20Callbacks/32580 FreeBSD Remote code execution via ND6 Router Advertisements A critical vulnerability in FreeBSD allows for remote code execution. But an attacker must be on the same network. https://www.freebsd.org/security/advisories/FreeBSD-SA-25:12.rtsold.asc NIST Time Server Problems The atomic ensemble time scale at the NIST Boulder campus has failed due to a prolonged utility power outage. One impact is that the Boulder Internet Time Services no longer have an accurate time reference. https://tf.nist.gov/tf-cgi/servers.cgi https://groups.google.com/a/list.nist.gov/g/internet-time-service/c/o0dDDcr1a8I