Jan Schaumann
Say you work in tech for a large industry leading company with various US gov contracts.
When the Trump administration starts implementing its deportation program and builds its concentration camps, they will need somebody to supply the inventory, book keeping, cloud infrastructure, software services, etc. for all of that.
Will your company accept those contracts?
What will you do?
Jan Schaumann
I know that every single large tech company _will_ take (and compete for) those contracts.
"Somebody's gonna do it, might as well be us."
"We're providing a generic service to a large customer."
"We have to stay competitive."
"As nothing illegal / not in violation of our Terms of Service."
"We already have existing contracts with them, this is nothing different."
"We have a responsibility to our share holders to make money."
Jan Schaumann
Look, all I'm saying is I've been ignoring all previous instructions for several decades now and nobody called me intelligent, artifical or otherwise.
Jan Schaumann
How do you know somebody is using #Nix? Don't worry, they'll tell you.
Srsly.
Jan Schaumann
#Unix trivia:
The original #BSD daemon was drawn by John Lasseter for Sam Leffler's "Unix System Manager's Manual". (Lasseter & Leffler (previously at CSRG) worked at Lucasfilm, which sold the Graphics Group to Steve Jobs to become Pixar.)
He then drew the version used by McKusick's "The Design and Implementation of the 4.3BSD Operating System" (McKusick still holds the copyright for that daemon). It was used by #FreeBSD until 2005; #NetBSD used the Iwo Jima inspired daemons logo until 2004.
Jan Schaumann
Ancient Rules of Open Source #17
If you wait long enough, the person who reported the bug will eventually fix it themselves.
Although sometimes that can be 20 years:
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=27309
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 8, Interprocess Communications Intro
We begin our discussion of Interprocess Communication by providing a quick overview of the different properties of #IPC mechanisms as well as which mechanisms we will cover:
- Signals (see previous week)
- System V IPC (Semaphores, Shared Memory, Message Queues)
- Pipes and FIFOs
- socketpairs and sockets
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 8, System V Interprocess Communication
In this video lecture, we cover traditional #SystemV #IPC: semaphores, shared memory, and message queues. We also look at the POSIX message queues implementation and how this model forms the basis of many popular "pub sub" services like e.g., Amazon Simple Queue Service, Apache Kafka, or RabbitMQ.
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 8, Pipes and FIFOs
With this video lecture, we continue our discussion of Interprocess Communication and dive into two of the oldest and most ubiquitous forms of Unix #IPC: pipes (the basis of the Unix Philosophy) and FIFOs. We also discuss popen(3) and the dangers of shelling out to unverified commands.
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 9, socketpair(2)
We continue our discussion of IPC with a look at the socketpair(2) system call and compare its functionality with that of the pipe(2) call. We also introduce the concept of sockets, domains, and protocols.
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 9, socket(PF_LOCAL, SOCK_DGRAM, 0)
In this segment, we introduce the #sockets API by an example of datagram connections in the PF_LOCAL (formerly AF_UNIX) domain.
These “Unix domain sockets” appear in the filesystem (S_ISSOCK), but serve only as rendezvous point. I/O can be done using read(2)/write(2) or recv(2)/send(2).
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 9, socket(PF_INET, SOCK_DGRAM, 0)
In this video lecture, we show how to communicate between hosts across the internet using datagram sockets in the PF_INET domain (i.e., #UDP). We also observe the packets as they are sent by using the #tcpdump utility.
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 9, socket(PF_INET6, SOCK_STREAM, 0)
In this video, we demonstrate the use of STREAM sockets in the INET6 domain, meaning we'll use TCP to establish a sequenced, reliable, two-way byte stream over an #IPv6 network. We use our good friend #tcpdump to inspect the packets on the wire, observing the TCP three-way handshake, data being pushed, the connection tear down or reset (RST) packets from the server.
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 9, I/O Multiplexing using select(2)
We complete our discussion of interprocess communication and move from one-to-one communications towards a more typical client-server model with a server side process capable of handling multiple simultaneous clients. We accomplish this by using the select(2) syscall to handle synchronous I/O multiplexing.
Jan Schaumann
Advanced #Programming in the #UNIX Environment
The #NetBSD operating system comes with a number of historical Unix research papers found in /usr/share/doc: Marshall Kirk McKusick on the Fast File System, Robert Morris and Ken Thompson on Password Security, a shell tutorial by Stephen R. Bourne, a guide to using vi(1) by Bill Joy, and the well known BSD IPC tutorials (linked below) that we used in our last videos!
https://stevens.netmeister.org/631/ipc.pdf
https://stevens.netmeister.org/631/ipctut.pdf
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 6, The Environment
We're going to take a look at the process environment, using what we learned about the process layout in memory to understand how the environment variables are stored and, if necessary, moved around. We'll also get a quick look at what malloc(3) does.
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 6, The Environment (a tangent from 2011)
How large can the environment get? Is there a limitation on the size of a single environment variable? And why did I sometimes encounter this error message:
sudo: unable to execute <command>: success
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 6, Process Limits and Identifiers
Having looked at the process layout in memory, how it starts and is terminated, we now learn that certain properties are restricted via resource limits, specified as a "soft" and a "hard" limit, with only the superuser being able to raise the latter.
A process also has a process ID (PID) and a parent process ID (PPID). More
on these process relationships in our next videos.
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 6, Process Control
In the last video lecture for this week, we look at process control: how new processes are started from an executable, what resources are shared between parent and child, and what happens when they terminate. In particular, we will look at the fork(2), exec(3), and wait(2) system calls. Be warned, though: there will be #zombies, so limber up (Rule #7).
Jan Schaumann
Advanced #Programming in the #UNIX Environment
Week 6 related link: #Linux x86 Program Start Up or - How the heck do we get to main()?
Compare to what we covered in Segment 2 of this week.
http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.
