Is There a Connection Between Open Source and Unix?

Why does the history of computing matter? Joël and Developer at thoughtbot Sara Jackson, ponder this and share some cool stories (and trivia!!) behind the tools we use in the industry.

---

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

---

• Sara on Twitter
• UNIX philosophy
• Hillel Wayne on why we ask linked list questions
• History of Unix, Linux, and Open Source / Free Software
• Collected Histories of Unix
• Selected pages from the nine research editions of the UNIX® Programmer’s Manual illustrate the development of the system. Accompanying commentary recounts some of the needs, events, and individual contributions that shaped this evolution
• These are dates that every hacker knew were important at the time, or shortly afterwards.
• Unix at 50: How the OS that powered smartphones started from failure
• First hand account of history of Unix and Multics by Tom Van Vleck

Transcript:

JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. And today, I'm joined by fellow thoughtboter, Team Lead, and Developer Sara Jackson.

SARA: Hello, happy to be here.

JOËL: Together, we're here to share a little bit of what we've learned along the way. So, Sara, what's new in your world?

SARA: Well, Joël, you might know that recently our team had a small get-together in Toronto.

JOËL: And our team, for those who are not aware, is fully remote distributed across multiple countries. So this was a chance to get together in person.

SARA: Yes, correct. This was a chance for those on the Boost team to get together and work together as if we had a physical office.

JOËL: Was this your first time meeting some members of the team?

SARA: It was my second, for the most part. So I joined thoughtbot, but after thoughtbot had already gotten remote. Fortunately, I was able to meet many other thoughtboters in May at our summit.

JOËL: Had you worked at a remote company before coming to thoughtbot?

SARA: Yes, I actually started working remotely in 2019, but even then, that wasn't my first time working remotely. I actually had a full year of internship in college that was remote.

JOËL: So you were a pro at this long before the pandemic made us all try it out.

SARA: I don't know about that, but I've certainly dealt with the idiosyncrasies that come with remote work for longer.

JOËL: What do you think are some of the challenges of remote work as opposed to working in person in an office?

SARA: I think definitely growing and maintaining a culture. When you're in an office, it's easy to create ad hoc conversations and have events that are small that build on the culture. But when you're remote, it has to be a lot more intentional.

JOËL: That definitely rings true for me. One of the things that I really appreciated about in-person office culture was the serendipity that you have those sort of random meetings at the water cooler, those conversations, waiting for coffee with people who are not necessarily on the same team or the same project as you are.

SARA: I also really miss being able to have lunch in person with folks where I can casually gripe about an issue I might be having, and almost certainly, someone would have the answer. Now, if I'm having an issue, I have to intentionally seek help. [chuckles]

JOËL: One of the funny things that often happened, at least the office where I worked at, was that lunches would often devolve into taxonomy conversations.

SARA: I wish I had been there for that.

[laughter]

JOËL: Well, we do have a taxonomy channel on Slack to somewhat continue that legacy.

SARA: Do you have a favorite taxonomy lunch discussion that you recall?

JOËL: I definitely got to the point where I hated the classifying a sandwich. That one has been way overdone.

SARA: Absolutely.

JOËL: There was an interesting one about motorcycles, and mopeds, and bicycles, and e-bikes, and trying to see how do you distinguish one from the other. Is it an electric motor? Is it the power of the engine that you have? Is it the size?

SARA: My brain is already turning on those thoughts. I feel like I could get lost down that rabbit hole very easily.

[laughter]

JOËL: Maybe that should be like a special anniversary episode for The Bike Shed, just one long taxonomy ramble.

SARA: Where we talk about bikes.

JOËL: Ooh, that's so perfect. I love it. One thing that I really appreciated during our time in Toronto was that we actually got to have lunch in person again.

SARA: Yeah, that was so wonderful. Having folks coming together that had maybe never worked together directly on clients just getting to sit down and talk about our day.

JOËL: Yeah, and talk about maybe it's work-related, maybe it's not. There's a lot of power to having some amount of deeper interpersonal connection with your co-workers beyond just the we work on a project together.

SARA: Yeah, it's like camaraderie beyond the shared mission of the company. It's the shared interpersonal mission, like you say. Did you have any in-person pairing sessions in Toronto?

JOËL: I did. It was actually kind of serendipitous. Someone was stuck with a weird failing test because somehow the order factories were getting created in was not behaving in the expected way, and we herd on it, dug into it, found some weird thing with composite primary keys, and solved the issue.

SARA: That's wonderful. I love that. I wonder if that interaction would have happened or gotten solved as quickly if we hadn't been in person.

JOËL: I don't know about you, but I feel like I sometimes struggle to ask for help or ask for a pair more when I'm online.

SARA: Yeah, I agree. It's easier to feel like you're not as big of an impediment when you're in person. You tap someone on the shoulder, "Hey, can you take a look at this?"

JOËL: Especially when they're on the same team as you, they're sitting at the next desk over. I don't know; it just felt easier. Even though it's literally one button press to get Tuple to make a call, somehow, I feel like I'm interrupting more.

SARA: To combat that, I've been trying to pair more frequently and consistently regardless of if I'm struggling with a problem.

JOËL: Has that worked pretty well?

SARA: It's been wonderful. The only downside has been pairing fatigue.

JOËL: Pairing fatigue is real.

SARA: But other than that, problems have gotten solved quickly. We've all learned something for those that I've paired with. It goes faster.

JOËL: So it was really great that we had this experience of doing our daily work but co-located in person; we have these experiences of working together. What would you say has been one of the highlights for you of that time?

SARA: 100% karaoke.

JOËL: [laughs]

SARA: Only two folks did not attend. Many of the folks that did attend told me they weren't going to sing, but they were just going to watch. By the end of the night, everyone had sung. We were there for nearly three and a half hours. [laughs]

JOËL: It was a good time all around.

SARA: I saw a different side to Chad.

JOËL: [laughs]

SARA: And everyone, honestly. Were there any musical choices that surprised you?

JOËL: Not particularly. Karaoke is always fun when you have a group of people that you trust to be a little bit foolish in front of to put yourself out there. I really appreciated the style that we went for, where we have a private room for just the people who were there as opposed to a stage in a bar somewhere. I think that makes it a little bit more accessible to pick up the mic and try to sing a song.

SARA: I agree. That style of karaoke is a lot more popular in Asia, having your private room. Sometimes you can find it in major cities. But I also prefer it for that reason.

JOËL: One of my highlights of this trip was this very sort of serendipitous moment that happened. Someone was asking a question about the difference between a Mac and Linux operating systems. And then just an impromptu gathering happened. And you pulled up a chair, and you're like, gather around, everyone. In the beginning, there was Multics. It was amazing.

SARA: I felt like some kind of historian or librarian coming out from the deep. Let me tell you about this random operating system knowledge that I have. [laughs]

JOËL: The ancient lore.

SARA: The ancient lore in the year 1969.

JOËL: [laughs] And then yeah, we had a conversation walking the history of operating systems, and why we have macOS and Linux, and why they're different, and why Windows is a totally different kind of family there.

SARA: Yeah, macOS and Linux are sort of like cousins coming from the same tree.

JOËL: Is that because they're both related through Unix?

SARA: Yes. Linux and macOS are both built based off of different versions of Unix. Over the years, there's almost like a family tree of these different Nix operating systems as they're called.

JOËL: I've sometimes seen asterisk N-I-X. This is what you're referring to as Nix.

SARA: Yes, where the asterisk is like the RegEx catch-all.

JOËL: So this might be Unix. It might be Linux. It might be...

SARA: Minix.

JOËL: All of those.

SARA: Do you know the origin of the name Unix?

JOËL: I do not.

SARA: It's kind of a fun trivia piece. So, in the beginning, there was Multics spelled M-U-L-T-I-C-S, standing for the Multiplexed Information and Computing Service. Dennis Ritchie and Ken Thompson of Bell Labs famous for the C programming language...

JOËL: You may have heard of it.

SARA: You may have heard of it maybe on a different podcast. They were employees at Bell Labs when Multics was being created. They felt that Multics was very bulky and heavy. It was trying to do too many things at once. It did have a few good concepts. So they developed their own smaller Unix originally, Unics, the Uniplexed Information and Computing Service, Uniplexed versus Multiplexed. We do one thing really well.

JOËL: And that's the Unix philosophy.

SARA: It absolutely is. The Unix philosophy developed out of the creation of Unix and C. Do you know the four main points?

JOËL: No, is it small sharp tools? It's the main one I hear.

SARA: Yes, that is the kind of quippy version that has come out for sure.

JOËL: But there is a formal four-point manifesto.

SARA: I believe it's evolved over the years. But it's interesting looking at the Unix philosophy and seeing how relevant it is today in web development. The four points being make each program do one thing well. To this end, don't add features; make a new program. I feel like we have this a lot in encapsulation.

JOËL: Hmm, maybe even the open-closed principle.

SARA: Absolutely.

JOËL: Similar idea.

SARA: Another part of the philosophy is expecting output of your program to become input of another program that is yet unknown. The key being don't clutter your output; don't have extraneous text. This feels very similar to how we develop APIs.

JOËL: With a focus on composability.

SARA: Absolutely. Being able to chain commands together like you see in Ruby all the time.

JOËL: I love being able to do this, for example, the enumerable API in Ruby and just being able to chain all these methods together to just very nicely do some pretty big transformations on an array or some other data structure.

SARA: 100% agree there. That ability almost certainly came out of following the tenets of this philosophy, maybe not knowingly so but maybe knowingly so. [chuckles]

JOËL: So is that three or four?

SARA: So that was two. The third being what we know as agile.

JOËL: Really?

SARA: Yeah, right? The '70s brought us agile. Design and build software to be tried early, and don't hesitate to throw away clumsy parts and rebuild.

JOËL: Hmmm.

SARA: Even in those days, despite waterfall style still coming on the horizon. It was known for those writing software that it was important to iterate quickly.

JOËL: Wow, I would never have known.

SARA: It's neat having this history available to us. It's sort of like a lens at where we came from.

Another piece of this history that might seem like a more modern concept but was a very big part of the movement in the '70s and the '80s was using tools rather than unskilled help or trying to struggle through something yourself when you're lightening a programming task. We see this all the time at thoughtbot. Folks do this many times there is an issue on a client code. We are able to generalize the solution, extract into a tool that can then be reused.

JOËL: So that's the same kind of genesis as a lot of thoughtbot's open-source gems, so I'm thinking of FactoryBot, Clearance, Paperclip, the old-timey file upload gem, Suspenders, the Rails app generator, and the list goes on.

SARA: I love that in this last point of the Unix philosophy, they specifically call out that you should create a new tool, even if it means detouring, even if it means throwing the tools out later.

JOËL: What impact do you think that has had on the way that tooling in the Unix, or maybe I should say *Nix, ecosystem has developed?

SARA: It was a major aspect of the Nix environment community because Unix was available, not free, but very inexpensively to educational institutions. And because of how lightweight it was and its focus on single-use programs, programs that were designed to do one thing, and also the way the shell was allowing you to use commands directly and having it be the same language as the shell scripting language, users, students, amateurs, and I say that in a loving way, were able to create their own tools very quickly. It was almost like a renaissance of Homebrew.

JOËL: Not Homebrew as in the macOS package manager.

SARA: [laughs] And also not Homebrew as in the alcoholic beverage.

JOËL: [laughs] So, this kind of history is fun trivia to know. Is it really something valuable for us as a jobbing developer in 2022?

SARA: I would say it's a difficult question. If you are someone that doesn't dive into the why of something, especially when something goes wrong, maybe it wouldn't be important or useful.

But what sparked the conversation in Toronto was trying to determine why we as thoughtbot tend to prefer using Macs to develop on versus Linux or Windows. There is a reason, and the reason is in the history. Knowing that can clarify decisions and can give meaning where it feels like an arbitrary decision.

JOËL: Right. We're not just picking Macs because they're shiny.

SARA: They are certainly shiny. And the first thing I did was to put a matte case on it.

JOËL: [laughs] So no shiny in your office.

SARA: If there were too many shiny things in my office, boy, I would never get work done. The cats would be all over me.

MID-ROLL AD:

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers, that can actually help cut your debugging time in half.

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

JOËL: So we've talked a little bit about Unix or *Nix, this evolution of systems. I've also heard the term POSIX thrown around when talking about things that seem to encompass both macOS and Linux. How does that fit into this history?

SARA: POSIX is sort of an umbrella of standards around operating systems that was based on Unix and the things that were standard in Unix. It stands for the Portable Operating System Interface. This allowed for compatibility between OSs, very similar to USB being the standard for peripherals.

JOËL: So, if I was implementing my own Unix-like operating system in the '80s, I would try to conform to the POSIX standard.

SARA: Absolutely. Now, not every Nix operating system is POSIX-compliant, but most are or at least 90% of the way there.

JOËL: Are any of the big ones that people tend to think about not compliant?

SARA: A major player in the operating system space that is not generally considered POSIX-compliant is Microsoft Windows.

JOËL: [laughs] It doesn't even try to be Unix-like, right? It's just its own thing,

SARA: It is completely its own thing. I don't think it even has a standard necessarily that it conforms to.

JOËL: It is its own standard, its own branch of the family tree.

SARA: And that's what happens when your operating system is very proprietary. This has caused folks pain, I'm sure, in the past that may have tried to develop software on their computers using languages that are more readily compatible with POSIX operating systems.

JOËL: So would you say that a language like Ruby is more compatible with one of the POSIX-compatible operating systems?

SARA: 100% yes. In fact, to even use Ruby as a development tool in Windows, prior to Windows 10, you needed an additional tool. You needed something like Cygwin or MinGW, which were POSIX-compliant programs that it was almost like a shell in your Windows computer that would allow you to run those commands.

JOËL: Really? For some reason, I thought that they had some executables that you could run just on Windows by itself.

SARA: Now they do, fortunately, to the benefit of Ruby developers everywhere. As of Windows 10, we now have WSL, the Windows Subsystem for Linux that's built-in. You don't have to worry about installing or configuring some third-party software.

JOËL: I guess that kind of almost cheats by just having a POSIX system embedded in your non-POSIX system.

SARA: It does feel like a cheat, but I think it was born out of demand. The Windows NT kernel, for example, is mostly POSIX-compliant.

JOËL: Really?

SARA: As a result of it being used primarily for servers.

JOËL: So you mentioned the Ruby tends and the Rails ecosystem tends to run better and much more frequently on the various Nix systems. Did it have to be that way? Or is it just kind of an accident of history that we happen to end up with Ruby and Rails in this ecosystem, but just as easily, it could have evolved in the Windows world?

SARA: I think it is an amalgam of things. For example, Unix and Nix operating systems being developed earlier, being widely spread due to being license-free oftentimes, and being widely used in the education space. Also, because it is so lightweight, it is the operating system of choice. For most servers in the world, they're running some form of Unix, Linux, or macOS.

JOËL: I don't think I've ever seen a server that runs macOS; exclusively seen it on dev machines.

SARA: If you go to an animation company, they have server farms of macOS machines because they're really good at rendering. This might not be the case anymore, but it was at one point.

JOËL: That's a whole other world that I've not interacted with a whole lot.

SARA: [chuckles]

JOËL: It's a fun intersection between software, and design, and storytelling. That is an important part for the software field.

SARA: Yeah, it's definitely an aspect that deserves its own deep dive of sorts. If you have a server that's running a Windows-based operating system like NT and you have a website or a program that's designed to be served under a Unix-based server, it can easily be hosted on the Windows server; it's not an issue. The reverse is not true.

JOËL: Oh.

SARA: And this is why programming on a Nix system is the better choice.

JOËL: It's more broadly compatible.

SARA: Absolutely. Significantly more compatible with more things.

JOËL: So today, when I develop, a lot of the tooling that I use is open source. The open-source movement has created a lot of the languages that we know and love, including Ruby, including Rails. Do you think there's some connection between a lot of that tooling being open source and maybe some of the Unix family of operating systems and movements that came out of that branch of the operating system family tree?

SARA: I think that there is a lot of tie-in with today's open-source culture and the computing history that we've been talking about, for example, people finding something that they dislike about the tools that are available and then rolling their own. That's what Ken Thompson and Dennis Ritchie did. Unix was not an official Bell development. It was a side project for them.

JOËL: I love that.

SARA: You see this happen a lot in the software world where a program gets shared widely, and due to this, it gains traction and gains buy-in from the community. If your software is easily accessible to students, folks that are learning, and breaking things, and rebuilding, and trying, and inventing, it's going to persist. And we saw that with Unix.

JOËL: I feel like this background on where a lot of these operating systems came but then also the ecosystems, the values that evolved with them has given me a deeper appreciation of the tooling, the systems that we work with today. Are there any other advantages, do you think, to trying to learn a little bit of computing history?

SARA: I think the main benefit that I mentioned before of if you're a person that wants to know why, then there is a great benefit in knowing some of these details. That being said, you don't need to deep dive or read multiple books or write papers on it. You can get enough information from reading or skimming some Wikipedia pages.

But it's interesting to know where we came from and how it still affects us today. Ruby was written in C, for example. Unix was written in C as well, originally Assembly Language, but it got rewritten in C. And understanding the underlying tooling that goes into that that when things go wrong, you know where to look.

JOËL: I guess that that is the next question is where do you look if you're kind of interested? Is Wikipedia good enough? You just sort of look up operating system, and it tells you where to go? Or do you have other sources you like to search for or start pulling at those threads to understand history?

SARA: That's a great question. And Wikipedia is a wonderful starting point for sure. It has a lot of the abbreviated history and links to better references. I don't have them off the top of my head. So I will find them for you for the show notes. But there are some old esoteric websites with some of this history more thoroughly documented by the people that lived it.

JOËL: I feel like those websites always end up being in HTML 2; your very basic text, horizontal rules, no CSS.

SARA: Mm-hmm. And those are the sites that have many wonderful kernels of knowledge.

JOËL: Uh-huh! Great pun.

SARA: [chuckles] Thank you.

JOËL: Do you read any content by Hillel Wayne?

SARA: I have not.

JOËL: So Hillel produces a lot of deep dives into computing history, oftentimes trying to answer very particular questions such as when and why did we start using reversing a linked list as the canonical interview question? And there are often urban legends around like, oh, it's because of this. And then Hillel will do some research and go through actual archives of messages on message boards or...what is that protocol?

SARA: BBS.

JOËL: Yes. And then find the real answer, like, do actual historical methodology, and I love that.

SARA: I had not heard of this before. I don't know how. And that is all I'm going to be doing this weekend is reading these. That kind of history speaks to my heart. I have a random fun fact along those lines that I wanted to bring to the show, which was that the echo command that we know and love in the terminal was first introduced by the Multics operating system.

JOËL: Wow. So that's like the most common piece of Multics that as an everyday user of a modern operating system that we would still touch a little bit of that history every day when we work.

SARA: Yeah, it's one of those things that we don't think about too much. Where did it come from? How long has it been around? I'm sure the implementation today is very different. But it's like etymology, and like taxonomy, pulling those threads.

JOËL: Two fantastic topics. On that wonderful little nugget of knowledge, let's wrap up. Sara, where can people find you online?

SARA: You can find me on Twitter at @csarajackson.

JOËL: And we will include a link to that in the show notes.

SARA: Thank you so much for having me on the show and letting me nerd out about operating system history.

JOËL: It's been a pleasure.

The show notes for this episode can be found at bikeshed.fm.

This show is produced and edited by Mandy Moore.

If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review on iTunes. It really helps other folks find the show.

If you have any feedback, you can reach us at @_bikeshed or reach me @joelquen on Twitter or at hosts@bikeshed.fm via email.

Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeeee!!!!

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

• Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.

Support The Bike Shed