J
For anybody wondering why I prefer #NetBSD over #Linux, compare the code for a small tool like whois(1):
NetBSD:
https://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/whois/whois.c?annotate=HEAD
372 lines, easy to read
Linux:
https://github.com/rfc1036/whois/blob/next/whois.c
1617 lines in the main program; unchecked malloc(3), misc buffer overflow opportunities, magic numbers, "/* This function has multiple memory leaks.*/", mixed spaces and tabs, another 2K of glue code, ...
KISS, man, KISS.
@euroinfosec It's everywhere. It's so exhausting.
@paul_ipv6 Yeah. Only on most Linux flavors these days that quickly goes sideways and straight into systemd. 🤮
System Administration: Week 6: Networking II: A Simple Request
In this video, we trace a simple HTTP request made via telnet to find out just how exactly our application knows how to connect to the remote server. In the process we learn about the ktrace(1) utility, as well as the nsswitch.conf(5), hosts(5), and resolv.conf(5) configuration files.
System Administration: Week 5: Networking I: A Network of Networks
In this video, we look at how independent networks connect to one another, how Autonomous Systems numbers allow us to identify network operators, and how peering between independent ASs works.
Tonight seems like a good time to remind folks that the next #nokings protest is planned for March 28th:
As the president escalates his authoritarian power grab, the NO KINGS non-violent movement continues to rise stronger. We are united once again to remind the world: America has No Kings and the power belongs to the people.
No Kings (www.nokings.org)
Mark your calendars, I'll see you there! 
️
Corporate editors now insist on adding AI generated "executive summaries" and "FAQ"s to blog posts, regurgitating the very document they accompany. This is purportedly for SEO (🤮), basically encouraging a "why bother reading the thing" mindset.
Still believing that actual humans are capable of actually reading a text with more than 100 words, I'm rather irritated by that.
System Administration: Week 5: Networking I:The Physical Internet
In this video, we look at the physical structure of the internet, with a focus on submarine internet communications cables. Jumping from the bottom of the OSI stack all the way to Layer 9 ("political"), we then discuss how different countries use their political power to enforce internet blocks on their citizens, leading us to warrantless wiretapping in AT&T's room 641A.
System Administration: Week 5: Networking I: IP Allocation & IPv4 Exhaustion
Mommy, where do IP addresses come from? In this video, we discuss how IANA allocates IP addresses to the Regional Internet Registries and try to illustrate just how large the #IPv6 address space is.
@jpmens It is! We don't get these snow storms as frequently as we used to. It's always very pretty on the day it lands. (Two days later, when it usually has turned into brown slush, not so much. 
Good morning, NYC!
I still don't understand where people think Senior Engineers come from if they replace Junior Engineers with AI.
How do they think the next iteration of GIGO regurgitated code will be validated and debugged if nobody understands how the black box works?
Not wanting to understand but just wanting the quick answer is a clear trend and implicit outcome of frequent AI use.
To me, that's the real supply chain risk.
System Administration: Week 5: Networking I: IPv6 Basics
In this video, we get familiar with our Big Hero IPv6, looking at the structure of the IPv6 header and IPv6 address representations.
Since we're using AWS #EC2, remember that we have instructions for how to set up a dual-stack VPC and subnet to launch your instances in:
System Administration: Week 5: Networking I: IPv4 Basics & CIDR subnetting
In this video, we cover the basics of the 32-bit IPv4 address and how we organize networks using Classless Inter-Domain Routing or CIDR subnetting. (Don't worry, we'll get to #IPv6 in the next video.)
System Administration: Week 5: Networking I: Layers
In this video, we begin our longer discussion on the topic of "networking". We're using tcpdump(8) to capture a single TCP SYN packet and start looking at the MAC and IP information, teasing out each individual byte. And don't worry, we dunk on the OSI stack model as needed and popular these days.
@b0rk FWIW, I first write the man page, then the code. Helps me clarify what the user wants, how I will interact with the tool. I then generate the README from the man page.
@b0rk Probably has to do with how you grew up on the internet. Before StackOverflow, there really wouldn’t have been anything useful on the web; “RTFM” was indeed the generic advice (and sometimes phrased more politely) on Usenet and mailing lists.
Also a factor: the quality of the man pages you’re used to (BSD man pages tend(ed?) to be significantly better than “go use the ‘info’ page” Linux default).
All this -- and a few more details -- in blog form here:
https://www.netmeister.org/blog/ipv6-adoption.html
Eat Arby's. (Arby's website is #IPv6 enabled, so, uhm, yay? But of course their MXs are IPv4 only.)
All around, I don't see the overall trend to get us to universal #IPv6 adoption within the next 10 or perhaps even 20 years.
Pareto suggests the first 80% of any large project take 20% of the time and effort, and 30 years into our IPv6 adoption migration, we're barely half-way there.
As long as IPv6 is not seen as a fundamental requirement to do business, people will continue to disable it; as long as large businesses disable IPv6, it will not be seen as a fundamental requirement.
