Listen Now

### Achieving Greatness - systemd - Not a single binary, still kinda sorta not really The Unix Philosophy - Customizable - Startup/Bootstrap scripts - Infecting the lifeblood of our world - What does your server run, bro? - Anyone can contribute - Giving youth an opportunity to learn computer science ### Adaptation - Gaming - Multimedia - BLeading Edge (yes, it's spelled correctly. I am mixing bleeding leading. Back off) - TechTubers (Linus Tech Tips, Hardware Unboxed, Level1Techs) ### LISA SU IS MY BEST FRIEND - Silicon manufacturers - Clear Linux - Nvidia sux (but I still use them) ### Not Really Linux Related - Everything is becoming browser based - It sucks - Remote Desktops - Developers, developers, developers, DEVELOPERS ### Willingness to Collaborate - WSL - Canonical - POP!_OS - RHEL <3 Amazon! - Canonical <3 Amazon! ### A Brighter Community - Hello and Thank You for Linuxing - Do You Know What DE You'll Have Today?

### Doug McIlroy - Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. - Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. - Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. - Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them. ### Peter H. Salus - Write programs that do one thing and do it well. - Write programs to work together. - Write programs to handle text streams, because that is a universal interface. ### Rob Pike - Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. - Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. - Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.) - Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures. - Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. ### Dennis Ritchie and Ken Thompson - Make it easy to write, test, and run programs. - Interactive use instead of batch processing. - Economy and elegance of design due to size constraints - Self-supporting system: all Unix software is maintained under Unix. ### ESR - Modularity - Write simple parts connected by clean interfaces. - Readable - Programs that are clean and clear. - Composition - Programs connected to programs. - Separation: Separate policy from mechanism; separate interfaces from engines. - Simplicity: Design for simplicity; add complexity only where you must. - Parsimony: Write a big program only when it is clear by demonstration that nothing else will do. - Transparency: Design for visibility to make inspection and debugging easier. - Robust: Robustness is the child of transparency and simplicity. - Representation: Fold knowledge into data so program logic can be stupid and robust. - Least Surprise: In interface design, always do the least surprising thing. - Silence: When a program has nothing surprising to say, it should say nothing. - Repair: When you must fail, fail noisily and as soon as possible. - Economy: Programmer time is expensive; conserve it in preference to machine time. - Generation: Avoid hand-hacking; write programs to write programs when you can. - Optimization: Prototype before polishing. Get it working before you optimize it. - Diversity: Distrust all claims for “one true way”. - Extensibility: Design for the future, because it will be here sooner than you think. ### Does The Unix Philosophy Still Matter? - Yes? - We can still learn - Do what makes sense - Simplify everything - Abstraction isn't the answer

SecBSD Why SecBSD? LINUX SUCKS Jk, don’t gank me bro. First heard about it on an interview with BSD Bandit. https://www.youtube.com/watch?v=Q-zSlKRqQY8 “…nor do we want to have defaults that run tools as UID 0 (root). OpenBSD is our preferred platform, with the relentless focus on security, shipping with sane defaults, proper documentation and a thorough and constant auditing process.” Security researchers comfortable with OpenBSD/*BSD platforms. Bug hunters, bounty hunters, penetration testers wanting to flex on the Linux kernel. Probably need to know a little (see: a lot) about how Information Security/Offensive Security works. Stages and process of an engagement. Don’t treat this as gatekeeping treat it as an opportunity to learn. OffSec Tools aircrack ng arp scan burpsuite ccrypt cvechecker dnsrecon exploitdb f*ckshell nemesis nikto nmap pwndb snort sublist3r zaproxy Installing SecBSD Install OpenBSD Setup ports Clone SecBSD tools make && make install OpenBSD 6.7 Release Updating with a single command: sysupgrade Reboot process JUST WORKS. AWK Blog post Loops, Decisions, Arrays Switch statement Passing arguments

Welcome to the first Head in the Clouds segment! Today we discuss what separates a VPC from a VPS, why the cloud is so "damn" expensive, and what services will serve your organization the best. We also get into monitoring your billing and utilization, why the cost justifies the time, having the latest and greatest at all times.

Primer for Head in the Clouds! What's the best VPS? Spoiler, it's Vultr. Opinions my own. I wasn't paid to say that. Blah blah blah. When to Self Host? - Personal Projects - Experiments - Personal Data - E-mail - Files Self Host Considerations? - DNS - Dynamic DNS - Service Provider - Network Intrusion - Equipment - Electric Bill When to Outsource? - Portfolio Sites - RSS - Client Sites - E-mail? - Collaboration Outsourcing Considerations? - Cost - Availability - Location - OS/Distro Shilling - Services Provided - Suit Your Needs Who to Outsource to? - Linode - Digital Ocean - Vultr Why Vultr? - OpenBSD Baby! - Dark Mode (Yes, really) - 2FA/Sane Defaults - Total Infrastructure   - High Performance   - Compute   - Bare Metal   - Dedicated Cloud - Tailored Networking

Last half of the review is in today! Sneak peak into new segment: Head in the Clouds Networking for Systems Administrators Part II - Packet Sniffing - Creating Traffic - Server Packet Filtering - Tracing Problems - Final Word "Even if you fail utterly, at least you'll finally know if that firewall port is open or not."

Hey everyone! First half of the first book review on the show! Networking for Systems Administrators by Michael W Lucas is a dive into defining how networks work, troubleshooting a network, and providing useful information into what the network engineering team needs. I give my initial thoughts, breakdown the first half of the book, and discuss some useful insights and knowledge I gained from reading. Stay tuned for the next half! - Who should read this book? - Chapter 0! - Applied OSI model - Ethernet all the things - IPv4 and IPv6 - TCP/IP - Viewing connections - Testing the network - It's always DNS

## BSD Administration and C-isms ### Deploying to OpenBSD - Played with OpenBSD and HTTPD - Not your Grandpa's HTTPD - Based on relayd - Features - Very similar to Nginx - Macros - Global conf - Sever declaration - ACME Client - Automatic Certificate Management Environment (phew) - Location blocks - Connect with Let's Encrypt - _Sane_ Defaults - Say it with me - Protections in place to protect the system admin and users - You "unlock" what you want to use - Traffic - Couldn't tell (too low) - Rendered/responded very well - Basic stress testing showed no difference than Linux ### Writing in Userland - AKA user space - Kernel exposes itself via API - Use system calls to hitup the kernel - Interrupt happens, processes process, kernel goes on about day - Pointers, I/O, networking - Writing to file - Allocating memory - Sending packets - Caching - Web server in C - Mainstream examples - Smaller projects - Without VM or Garbage Collection ### Fun Filled Excitement - Debian potentially migrating off E-mail - First Book Review (dedicating whole episode) - Networking for Systems Administrators by Michael W Lucas ### Web Server Source https://github.com/LambdaSchool/C-Web-Server

Today I catch up with Mike and Phil from The rollBak! We go into what's changed over the last year, new endeavors, why we think containers might be overkill, and more! Be sure to mutilate the subscribe button and stab that like. USE LINUX.  

## Semaphore vs Mutex vs AdminDev ### Semaphore - More of a signal than a lock/unlock - Integer value accessed through wait() and signal() - wait() checks if the int is less than or equal to 0, decrements value - signal() increments the integer value ### Semaphore Over Mutex - Mutex locks can have busy waiting. - Semaphore wait() results in busy waiting, but a process can block itself with a wakeup() implementation - Semaphore can still result in syncing issues - Critical-Section: Two processes can be in the same section if the wait() and signal() sequence is not monitored ### Semaphores in OS Dev - Counting semaphore - Value can range dramatically - Control access to a given resource consisting of finite instances - Semaphore is initialized to the given number of resources - Each process that wants to use a resource performs wait() (lowering the value count) - signal() is called when a process is finished utilizing a resource (increasing the value count) - When count == 0, all resources are used - Processes will block until count becomes greater than 0 - Binary semaphore - Value can range between 1 and 0 - Similar to mutex locking - Used in systems lacking mutual exclusion ### Atomics and Atomicity - An atomic action is a group of related operations that execute without interruption or do not execute at all - Operations isolated from other operations occurring at the same time - Observed state is pending or complete, never partially complete. - The Linux kernel - A note on Golang - Package "sync/atomic" - Low-level primitives for synchronization algorithms - "Share memory by communicating, don't communicate by sharing memory." - Emphasis on low-level applications ### Java and C, Sitting in a Red-Black Tree - My education vs my desires - C teachings - What other langs do - Why this costs - What I've learned - Java still in the mix - Shell and Python ### Why C, Again? - OS and kernel development - OS Dev Wiki - Prereqs - Userland tools - Assembly - All the cool kids do it! - The language of operating systems - The language of networking - The language of web and proxy ### New Format - Technical Buzzword Jargon Hell - Stuff like this :D - CompSci, Unix and Linux, computer programming - Off topic - Book reviews (some tech, some not) - M-m-m-mental and physical health - Ranting and raving - NOT Tech News - Linux kernel stuff - Unix-like conventions and meetups (BSD, Linux) - Interesting sites, tips, and tricks - Long segment, short segment, short segment - One long episode, two short episodes - Intro music pending ### Let Me Know! - chris@admindev.tech - forum.admindev.tech - iTunes: https://podcasts.apple.com/us/podcast/admindev-labs/id1476478667 - Stitcher: https://www.stitcher.com/podcast/the-rollbak/admindev-labs

## Race Conditions ### Definition - Two or more processes are reading or writing some shared data and the final result depends on who runs precisely when. ### Tanenbaum example (Printer daemon) - Process enters name of file in spooler dir - Printer daemon checks to see if file need printing - Prints and removes names from spooler dir - Spooler dir has 0 ... infinity - Two shared variables, output, point at file to be printed - in, points to free slot in spooler dir - Proc A and B queue file for printing - A reads in, stores slot 7 in variable - Clock interrupt occurs - B reads in, stores slot 7 in same variable - B writes to slot 7, updates in to slot 8 - A writes to slot 7, erasing what B put there, updates in to slot 8 - Spooler dir now in sync - B never receives output ### Golang example (Incrementing a counter) - Proc 1 read counter 0 - Yield thread 0 - Increment counter 1 - Proc 2 read counter 0 - Yield thread 0 - Increment counter 1 - Proc 1 write counter 1 - Proc 2 write counter 1 - Proc 1 read counter 1 - Yield thread 1 - Increment counter 2 - Proc 2 read counter 1 - Yield thread 1 - Increment counter 2 ### Go-isms - go run -race main.go - Don't communicate by sharing memory, share memory by communicating - Passing on a channel the data structure or object. ### Avoiding Race Conditions - No two processes may be simultaneously inside their critical regions. - No assumptions may be made about speeds or the number of CPUs. - No process running outside its critical region may block any process. - No process should have to wait forever to enter its critical region. ### Mutal Exclusion - While a process is busy updating shared memory no other process will attempt to enter shared memory space. - Disabling interrupts (Single CPU) - This approach is generally unattractive because it is unwise to give user processes the power to turn off interrupts. - Lock variables - Test the lock - If 0 set to 1 - Before process can set 0 to 1, another process reads as 0 - The race now occurs if the second process modifies the lock just after the first process has finished its second check. - Busy Waiting - It should usually be avoided, since it wastes CPU time - Mutual Exclusion Algorithm: G. L. Peterson - Each process calls enter\_region - Wait, if necessary, until safe to enter shared memory region - Process calls leave\_region after done with shared memory ``` #define FALSE 0 #define TRUE 1 #define N 2 / * number of processes * / int turn; / * whose turn is it? * / int interested[N]; / * all values initially 0 (FALSE) * / void enter region(int process); / * process is 0 or 1 * / { int other; / * number of the other process * / other = 1 − process; / * the opposite of process * / interested[process] = TRUE; / * show that you are interested * / turn = process; / * set flag * / while (turn == process && interested[other] == TRUE) / * null statement * / ; } void leave region(int process) / * process: who is leaving * / { interested[process] = FALSE; / * indicate departure from critical region * / } ```

Today I have the great pleasure of speaking with Lionel, a systems engineer with an incredible story about changing his career from a dead end job into the hustle and bustle of systems and software. Next episode I am going to dive into what I've been learning about threads and race conditions. ### Introducing Lionel - Systems Engineer - Ops, Dev, DBA - Management side, day to day, how he got to where he is, biggest challenge ### Threads and Race Conditions - Sneak peak into next episode - Golang tool - Functional Programming - Testing vs Design ### Lionel Interview - Who are you - What do you do ### How did you get here? - Your pressing situation - Cranking out certs - Getting the job ### Tech Enthusiast - Favorite technology stack - What interests you - What motivates you - Favorite part of your job ### Current Project ### Future and Biggest Challenge ### Shout out to Josh Duffney and Hayden Barnes

# Processes Continued - Lacking Thread Safety - Threads Share Resources - Processes Share Access - Concurrency and Parallelism on Multicore CPU - The Cost of Processes - Why use processes over threads?   - Safety (again)   - Isolation (processes under different users)   - Better Memory Utilization with Low Memory Machines   - Swapping is More Effective   - Servicing (stopping, suspending, restarting other processes)   - Distributed Computing # Applications - Apache - Google Chrome # Current Projects - Desktop migration - Game engine development - Forum architecture # Links 2D Game Engine Development on Linux https://www.udemy.com/course/cpp-2d-game-engine/  

## Linux Centric, Processes, and Kernel Developers ### Changing Directions - Why "Linux"?   - Interests change over time   - Something I've consistently gone back to   - My job and career   - Can't stay away - Not a Revamp or a Refactor - Continuing with same format   - Not a news show   - Video is on hold   - Random raw VLOG/videos ### Process - What is a process?   - Instance of a program running   - CPU instruction - What is a program?   - File with information on how to construct a process   - Binary format identification (metadata) format of executable   - Machine-language instruction   - Entry point address, where should the program execution being?   - Data   - Symbols and relocation tables, locations and names of functions, objects, debug   - Shared-library and dynamic-linking information, lists of shared libraries needed at runtime - Types of processes   - User initiated, interactive   - Background, daemon, automated - Daemon   - Online with the system   - Haunt you forever, never die   - User can interface with daemons ### Linux Process - Parent/Child   - Child process: Existing process copies itself in memory   - New PID for child, but runs concurrently with the program on execution   - fork()   - Both processes continue with the next instruction   - Child has access to file, CPU registers, and I/O that parent has access to   - PID and PPID are used to identify and keep track of processes   - man page: The child process and the parent process run in  separate memory spaces. At the time of fork() both memory spaces have the same content. Memory writes, file mappings (mmap(2)), and unmappings (munmap(2)) performed by one of the processes do not affect the other.   - Source code coming ### Better tools for kernel developers - Reliance on e-mail for Linux kernel maintainers - Process is daunting to newcomers - Tooling to assist   - 500 lines of Python   - Provide message ID for email in a thread of interest   - Entire thread downloaded and stored in local mbox file - Change in the process   - Reading email threads   - Organizing patches   - Applying tags - Hesitance/resistance to change - Do developer workflows need to change?   - Why?   - Learn a newcomer vs ask for input   - Linux kernel is great as is

### C++17 - Building GCC for C++17 - 16 threads ~20 minutes - Managing libraries ### It's a Bug, Not a Feature - Execution - TBB -- C++ template library - Parallel Algorithms ### Multiple Versioning - First time for everything - lib64 vs lib - Makefile - Linking the library directory ### C++ Crash Course by Lospinoso - Excellent modern programming book - Covers computer science topics - Details into REAL programming   - Networking   - Concurrency and Parallelism   - Filesystems   - Testing   - C++ Algorithms - Parallel Sort   - 1 billion random vectors   - sort sequentially   - sort in parallel   - Boom, roasted ### Concurrency vs Parallelism - Concurrency   - Two or more tasks in a time frame   - Scheduling via the OS to send instructions to each task - Parallelism   - Two or more tasks executing at the same time   - Scheduling has threads executing at the same time   - Race conditions ### BUT WHY?! - Forum Architecture   - .NET Core   - JavaScript   - Ruuuuuuby - Deeper understanding - Systems programming  

What's up everyone, today I am "wrapping up" the talk on Linux gaming. I need to correct the record on a few things and share my continued success with Elder Scrolls Online! Plus, some Linux feedback, news, and a PSA on encryption Linux Gaming Epilogue - DXVK - Wine - Lutris Linux Fun - Debian Bullseye - Proxmox - Current Distributions Linux News (???) - Ubuntu 20.04 - Wine 5 Encryption - More of a PSA - STORY TIME - dm-crypt - Encryption on Arch Linux - Encryption on Ubuntu https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LUKS_on_a_partition https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019 https://en.wikipedia.org/wiki/Dm-crypt

Today I talk about my experiences long ago and recent about gaming on Linux, my impressions of the Ubuntu Cinnamon Remix, and the plans for the Computer Science series. ##Gaming on Linux ### The Bad - Tedious - Lot of moving pieces (Wine? Lutris? Proton?) - Misrepresenting what it is - Still needs some work ### The Good - Surprisingly well done (Lutris) - With proper graphics settings and game settings, "it just works!" - Error reporting - Audio ## Ubuntu Cinnamon Remix - Really wanted to love it - Blank and bare - Weird graphics anomalies ## Computer Science Series Update - Learnin' myself - Playing with C - Data types and variables - Arrays - Decision - Loops - Functions - Pointers - IO/Reading/Writing - Abstract Data Types (some C++ AWW YEAH) ### Post Basics - Linux memory - Linux processes - Multithreading - Filesystems - OS design and development

Today I had the privilege of speaking with Hayden Barnes, a developer advocate for Ubuntu at Canonical. Hayden is known as the Microsoft guy at a Linux company, he founded Pengwin - a WSL distribution, and previously worked as an attorney.   - From Law to Linux - Getting into systems programming - Working at Canonical - What is WSL? - WSL compared to WSL2 - Upstream from project to WSL - Future of WSL - Canonical's involvement - Skills for the job - Proudest project - Toughest challenge - Life outside of tech More on WSL 2: https://www.youtube.com/watch?v=lwhMThePdIo https://docs.microsoft.com/en-us/archive/blogs/wsl/pico-process-overview WSLConf: https://www.wslconf.dev/ More on Hayden: https://boxofcables.dev @unixterminal on Twitter

COMPLAINS ABOUT NEW YEARS RESOLUTION DOES EPISODE ON NEW YEARS RESOLUTION Things to learn in 2020 - Containers - Programming Language - Editor - Shell - Networking   -- DNS   -- Routing   -- TCP/IP - Linux - Security   -- Auditing   -- Hardening  - - Vulnerability and Risk - Participate in a Meetup - Hackathon

Today I installed Linux Mint because someone challenged my good sensibility. Install process was smooth. I was able to play Dark Souls III on Linux for the first time (git gud, scrub). Installed a few tools, KVM, and played with some themes and settings. Probably gonna stick around for a while!