### 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

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.

• aircrack ng
• arp scan
• burpsuite
• ccrypt
• cvechecker
• dnsrecon
• exploitdb
• f*ckshell
• nemesis
• nikto
• nmap
• pwndb
• snort
• sublist3r
• zaproxy

• Install OpenBSD
• Setup ports
• Clone SecBSD tools
• make && make install

Updating with a single command: sysupgrade

Reboot process JUST WORKS.

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! - [email protected] - forum.admindev.tech - iTunes: https://podcasts.apple.com/us/podcast/admindev-labs/id1476478667 - Stitcher: https://www.stitcher.com/podcast/the-rollbak/admindev-labs