Does operating system (OS) choice even matter anymore to most people? Especially with the emergence of serverless and containers? Debian may not see its name up in lights much these days, but it’s still very much front, center, and relevant to what people are doing in Cloud environments.
Today, we’re talking to Elana Hashman, a Python packager and Debian developer. Everything inside a base operating system may not be interesting to end users, but such a collection of components is necessary to create a functioning Linux system.
Some of the highlights of the show include:
Alternative Linux operating systems, including Amazon Linux 2
Level of awareness about free software when choosing and distributing an OS
What is a Python packager? How do you become one?
Python is the new default language due to growth and adoption of its ecosystem
Packaging community off-putting to beginners; find someone who understands the system to guide you
Full Episode Transcript:
Corey: Hello and welcome to Screaming In The Cloud with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming In The Cloud.
This week’s episode of Screaming In The Cloud is generously sponsored by Digital Ocean. From where I sit, every cloud platform out there biases for something. Some bias for offering a managed service around every possible need a customer could have. Others bias for, “Hey, we heard there’s money to be made in the cloud. Maybe give some of that to us.”
Digital Ocean, from where I sit, biases for simplicity. I’ve spoken to a number of Digital Ocean customers and they all say the same thing which distills down to, they can get up and running in less than a minute and not have to spend weeks going to cloud school first. Making things simple and accessible has tremendous value in speeding up your time to market.
There’s also value in Digital Ocean offering things for a fixed price. You know what this month’s bill is going to be, you’re not going to have a minor heart issue when the bill comes due, and that winds up carrying forward in a number of different ways. Their services are understandable without having to spend three months of study first. You don’t really have to go stupendously deep just to understand what you’re getting into. It’s click a button or make an API call and receive a cloud resource.
They also offer very understandable monitoring and alerting. They have managed database offering, they have an object store, and as of late last year, they offer managed Kubernetes offering that doesn’t require a deep understanding of Greek mythology for you to wrap your head around it. For those wondering what I’m talking about, Kubernetes is of course named after the Greek god of spending money on cloud services.
Lastly, Digital Ocean isn’t what I would call small-time. There are over 150,000 businesses using them today. Go ahead and give them a try or visit do.co/screaming and they’ll give you a free $100 credit to try it out. That’s do.co/screaming. Thanks again to Digital Ocean for their support of Screaming In The Cloud.
Hello and welcome to Screaming In The Cloud, I'm Corey Quinn. I'm joined today by Elana Hashman who's a Python Packager and a Debian developer. We're going for alliteration today. Welcome to the show.
Elana: Great alliteration, my favorite thing.
Corey: You've been doing a fair number of interesting things that are, we'll call it cloud adjacent for the moment just because if I call it anything else, I'll get yelled at by people writing into well actually metaDESK.
Let’s start at the beginning. A little over a year ago, you became a Debian developer which is first, for those who are unaware, that's not exactly an easy thing to become. A lot of open source projects tend to have a certain hierarchy of how they're structured, how things wind up getting into production especially when you're a large, well-known, baseline operating system that extends into the underpinnings of a good portion of the internet. It turns out that you don't want someone say, me writing arbitrary code and submitting that into the thing that runs banking software. That's no small joke. Can you tell us how you got there?
Elana: It was a terrible journey. I spent a long time being very resistant. Many folks were like, “Elana, you're smart. We need more women in Debian. You should join Debian.” And I said, “Well, that sounds like a lot of free unpaid labor. Why would I want to do that?” But then the technical challenges pitched my interest. I guess at the beginning of January 2017, I started working on packaging some Clojure software. Fast forward, I don't know, almost two years at this point, I maintain almost every piece of Clojure software in Debian.
It was very interesting because I actually became a DD in a pretty short—as far as things go—period of time. Normally, you have to wait at least six months to become a DM or a Debian Maintainer who has a limited upload rights, and then you can wait another six months and become a Debian developer with upload access. I sort of tried to bypass that process and said, “But I’m only uploading new packages because I'm trying to get this new thing, the clojure package manager called Leiningen into Debian. I don't want DM permissions because I'm not maintaining existing things, I'm adding all these new things to the archive.”
Somehow, I managed to convince folks of this. It was almost exactly six months from my first package upload with the help of a sponsor, up to actually getting upload rights into the archive. There's no hierarchy in Debian, that's the problem with Debian. It’s this massive anarchist collective with a lot of rules. Convincing that you too should be 1 of the 1,000 or so folks that's considered a member of the project can be challenging, and full of rules-mongering mostly.
Corey: One thing that I wanted to ask you about is, first of all, for those who are unaware, or don't have a deep history of operating systems, and Linux backgrounding, Debian is an operating system that underlies a lot of existing things in the cloud today. For example, Ubuntu is built on top of Debian as its upstream package. Although it's not generally seeing its name up in lights much these days, it very much is front, center, and relevant in 2018 to what people are doing in cloud environments.
My question for you is, in 2018—as it draws to a close and we look into 2019—does the distribution matter. In fact, even taking a step beyond that, does the operating system matter as people's environments and managed services start to move up the stack into things that are very aligned with, “I just write some code and it runs serverlessly.” Or, “Here’s a container, I don't care what you run it on.” Does the operating system choice even matter to most people at this point?
Elana: I suspect most people know it doesn't matter because it's underneath the surface. It's not something that they're going to be consciously interacting with. I've heard you know Container Linux is going to take over everything. No one is ever going to have to run an operating system anymore. We've got immutable infrastructure. We've got Atomic-OS, and we've got CoreOS, and all these wonderful stuff, but you're running Docker containers on those, and what are your Docker containers built on?
Well, it turns out that the vast majority of Docker containers that are not alpine-based are actually based on Debian. You get that base operating system whether or not you think you do, or you want it. A lot of the stuff inside the base OS is not necessarily super interesting to an end user, but this collection of all these terrible C-ABIs or application binary interfaces them working together, and them being distributed such that they can all be compatibly, dynamically linked with applications, you don't get a functioning Linux system without that these days.
I guess until we sort of replace C as the lingua franca, we won't. But whether it's Debian, or Red Hat based system, or one of many other Linuxes, it's kind of hard to avoid somewhere deep down in the stack. I don't think that we have any good alternatives at this point for such things.
Corey: There is an argument to be made over in AWS land where, “Oh, just use Amazon Linux.” I'm sorry, updating myself now, “Use Amazon Linux 2.” For those who aren't aware, first I envy you. Secondly, that effectively takes upstream Red Hat/CentOS and then winds up layering a whole bunch of nonsense on top of it into a Frankenstein style of distribution, and spinning something out that’s supposedly is highly optimized for the Amazonian environments in which it runs.
To my understanding, they're starting to build a lot of other services on top of that operating system in those images. Now that you can download and run it in other environments, great. Except, no one in their right mind does that. You've effectively built an entire distribution of Linux that only exists in one particular cloud environment, with the caveat that it is effectively the largest cloud environment by a landslide. It's not quite as silly as it would be if Ted’s bar and Grill, and cloud as a hosting service were to do the same type of thing. That is the only real competitor that I've seen these days at large scale cloud to Ubuntu which of course is Debian derived itself.
Elana: It's funny because the concept of a proprietary Linux distribution–it’s almost like a oxymoron. The concept boggles my mind. Why would you want such a thing? It's weird because I don't really think that Debian is not a commercial product. Debian is a bunch of people who care about free software working together to build a free operating system. The core of Debian is all 100% free software. Anything that you can install in the Debian world, you can build it from source. Even if that requires some level of bootstrapping process, you can do such a thing.
Amazon Linux sounds like probably not the case. Who knows? The user space certainly doesn't have to be free software, they can stick whatever they want in there. Debian doesn't really care about commercial competitors or I think commercialization at all. There was a big controversy a few years back about even getting folks paid for very core work that they needed to do on the OS. It's almost like an irrelevant question I guess. I work on Debian because I use Debian, I care about free software, and if packages that I want to install don't exist, I would like them to be in Debian. Now, I have the ability to go and upload those things. I don't know. I mean in terms of the commercial applications, not really something that I think most DDs are thinking about.
Corey: I think that it's one of those areas that has so many things in computing seem to do. It's slipping beneath the surface of awareness for most people. It's easy to say that that's a bad thing. It's easy to say that it shouldn't be that way. I disagree. I think that the fact that I don't have to sit here and spend two days and a lot of work figuring out what compiler flags to set, to get a particular web server software up and running is a good thing, by and large for technology, or by society. We also in some ways have lost sight of the incredible amount of work by huge teams of people on an ongoing daily basis that underlie the systems that we have all built business solutions on top of.
Elana: I think it's a good thing. I don't want to have to every time I run a new application feel like, “Look at my compiler flags -05, -fun role loops, yeah,” I don't think about that stuff. As a developer, I especially do not want to have to fight with, “I have the simple version error because I don't have the right ABIs available, and I need to go and recompile everything.” That is just a massive pain in the butt. There's me as the OS developer who says, “I want all of these things to work compatibly together and I want to do some terrible gross yak shaving in order to make sure that my base OS works.”
But then there's me as a developer who says, “I just don't want that to be a problem that I have to think about it.” If folks don't have to think about Debian because it is so seamless, and magical that it just works, I think that's amazing. I think it's a big win. I don't really care about, “Do we have the right name recognition?” There's definitely some reasons that one might want name recognition, but I don't know. I don't know what advantage it would convey. Certainly, as like a woman on the internet, I don't actually want a name recognition personally. As far as my software that I write and or maintain goes, maybe it's similar there I think it's a great thing and it’s almost even a testament to Debian stability and quality of software that people don't have to think about any of those details. They just work and you don't have to care. Except when they don't of course, then maybe you have to care.
Corey: Everyone loves having caring inflicted upon them.
Elana: The best kind.
Corey: One of the fun things that I find is, as we start going down this path to figuring out the operating system that you wind up running the distribution of that operating system, if it's not Windows for example, that's one area of I guess choice that’s slipping beneath the sea. The one very much isn't is the other half of what you wind up doing which is, you are a Python Packager. I know almost nothing about what it takes to become a Python Packager. Let's start at the beginning. What is that?
Elana: Sure. I am a member of the Python Packaging Authority and what that means is that I have commit access to certain projects that enable folks to be able to distribute Python. The history of Python Packaging is very long and colorful. I think my first talk I gave as a professional out of university was at PyCon, and I was talking about some workshops that I had done teaching folks Python. I said at some point that for students who didn't have a lot of experience with programming in general, the concept of putting together a Python Package and distributing it, that was very challenging, and to maybe consider that in your curriculum. A bunch of folks from Python Packaging came after me.
One of them came up to me and said afterwards, “I subtweeted you about saying mean things about us.” I'm like, “It’s not mean, it’s broken. It’s just bad.” I guess the curse is to me that I would end up working on some of that core tooling a few years later. The stuff that I do right now is mostly focused on Linux and focused on binary distribution of Python extensions. For example something like NumPy, very important library for scientific Python, and it has a bunch of binary components that it needs call out to.
Python is not necessarily super fast, you're doing all these numerical computations, what would be more appropriate for such a thing than FORTRAN. How do you distribute FORTRAN dependencies as part of a Python Package? Well, you need to compile it, and you need to dynamically link to those FORTRAN things, and that story becomes very messy. It's the kind of thing that most people really don't want to have to think about this. For many years, you shouldn't have even considered trying to peep install NumPy because it would be a disaster as you try to compile all the stuff inside the Python Packaging, it wouldn't work.
One of the projects that I worked on is called the Many Linux Project Tool that I'm currently the maintainer of called Auditwheel. These two things work together in order for people to be able to compile these super compatible, relatively portable Python binaries in these ancient Docker images, and then audit them, and vendor any dependencies they need, and then be able to distribute those so they run on almost any operating system, or almost any modern operating system hence the name Many Linux.
I guess I package the Python packages that I maintain. I package Auditwheel. It's not like with Debian where there's this upstream package that I am now the downstream of, and I'm adding some stuff, and making it work in an operating system context in the world of Python Packaging. I actually write the tools to enable people to do that packaging themselves.
Corey: Something that I find fascinating is for better or worse, Python has become something of a lingua franca for almost everything done in the cloud. It's been one of the approved languages on Google’s side for a long time. They're push and go a fair bit lately. But for most of what people tend to be doing in Cloud based environments, go tend to be a little low level for a lot of the outcomes they're looking for. Whenever I need to write something, I find myself in 2018, reaching for Python.
The only other language I've ever felt that way about was almost 10 years ago and it was Perl. It turns out that was the wrong pony upon which to bet. But it seems now that we're really in a place where Python is the default language. Yes, there's an argument to be made that some cloud providers focus on other things, but right now, everywhere I look, and that might be selection bias, it seems to be Python. Is that what you're seeing?
Elana: Yeah, I mean it's sort of incredible how much adoption there's been and how much growth there's been in the Python ecosystem especially with some of the bumps and tumbles from the Python II to the Python III transition. I really like the Python community and I think that's one of its strengths. Python as a language has I think a lot better governance than average. It was sort of super interesting to watch Guido [inaudible 00:17:11] quit recently as BDFL and things for the most part just continue along as normal.
It's funny you mentioned Perl because I feel like Amazon internally still run on silly string in Perl scripts or so I've heard. I feel like this is true in a lot of cloud context. But in most context I worked, yeah Python, it is the go-to language. All the more important, but the tools that make it work, work well.
Corey: I don't present myself as a software developer because first off, my code is terrible, and secondly, I find that that doesn't tend to capture what I do these days. But I still find that one day I woke up and people said that, “Do you know Python?” “No, I don’t.” “But you did this wrong, this wrong and you fixed, you'll find it works.” “Oh my god, I know Python.” And it turned into sort of a shocking awareness for me. It's not quite it hit the point where when I have a problem, the first thing I look at is Python. Again, I'm an old, grumpy systems administrator, I go for Bash first and foremost. When that runs out of steam, then I step out to Python. You have a somewhat similar background yourself to my understanding.
Elana: Long ago, my first programming language of all time was mIRC Scripts, when I was a teenager and chilling on IRC at lunch. My Python experience was really weird because I picked it up in order to work on this open source project that's now winded down called OpenHatch, which was this Meta open source project that was dedicated to getting more folks involved in free software. I started working on the website which was written in Django. They would scrape various bug databases for projects, and try to aggregate all of these what we call bitesize, or good first issues, that kind of thing.
I worked on that for a bit and then I did some interview in Python for some company. I came out of that initial phone screen or something like that, I came out of that thinking, “Python almost reads pseudo code.” But I guess I really don't know Python because that interview sort of crushed my self-esteem. I don't really understand how to do object-oriented code in Python. I've been in this soft comfortable world of playing around with Django.
Then again a year later, folks would see this Python code that I wrote and they're like, “This is very good code,” so they'd expect me to know all of this deep Python language stuff that I didn't know at all. Things like how to put a package together, and like what libraries were good in what context, sort of like the arcane stuff you learn as you become more an expert in the programming language. It was just so wild to me that I could appear to be so fluent in a language that people would expect me to know these things. There's definitely something to be said about how easy I think Python syntax is to pick up, compared to other programming languages. That's like the ultimate imposter syndrome like, “I apparently wrote code so good that people think I know things but I really don’t.”
Corey: Right. Normally to pull that off, you have to be something like an economist or whatnot. You're this giant fraud messing with people. How long do you think you can carry that out for? “Well, I have four books published so far, so we're still waiting.” And it turns into this whole people don't catch on to some extent.
On the other side of the coin, there's also the story of going in for job interviews by which I mean the terrible form of job interviews, where instead of, “Tell me what you're good at, we'll talk about that. I'm going to pick apart random code, you work right under stress on a whiteboard,” because that's how most of us write code day-to-day, on a whiteboard with a marker while people judging the future of our career, looked on condescendingly. It becomes a very surreal experience.
I've shortcut my way out of taking jobs that require me to do that just because it's, “No, I don't feel like performing like a dancing bear on command. You can go ahead and find someone else for this role.” I used to think there was something wrong with me, but no, those interviews are actually terrible and stressful.
Elana: Yeah. It continues to be challenging for me because I've never written code in such a way. Python is frequently a good choice for some of these questions, but also not. It doesn't lend itself very well to questions that want you to recursive on. Then I go and reach for some sort of a list, but my tool can't and they say, “You can't write this. That's not a real thing.” I say, “Well, I wrote production list for 2 ½ years,” and they say, “No, that is nonsense. Clojure is not real.” And I say, “Okay.”
Yeah, the whiteboard coding I mean certainly Python, there's so many more details you don't have to take care of when you are writing your various answers for interviewing questions in Python. It really does read like pseudo code in a lot of cases. I don't know if that really forced me into figuring out stuff more. Certainly, I still feel like I'm a terrible whiteboard interviewer, but it is handy in my content.
Corey: Absolutely. To tie together the two areas that you've focused on specifically Python Packaging and Debian development, I dabbled early in my career for those who had the special joy of working with SaltStack. I was the first Ubuntu packager for this. The reason that happened is, back in those days, I was one of the first dozen or so developers to work, I was number 15, and no one else was there. Alright, I need to run this on Ubuntu based environment, I guess I'll build a package for this. Then I sort of started dipping my toe into the murky world of how that works. I spent about half a year doing that.
Then the project got large enough at the time to start attracting the notice of other people and some Debian developers came in, “Let's see what you've done. Oh my god,” and the very politely told me to, “We’ll handle it and never ever touch it again.” There's a lot of challenging minutia to getting a package like that up and running. Everyone has an opinion on it, and it turns out that's not really a great starter package. To be very direct, I found that in many ways despite of people’s attempt to be polite, the experience is fairly off-putting. What advice would you have for someone who wants to get into doing stuff like that so that they have a better experience with it than I did.
Elana: Yeah, that is a great question. A lot of the packaging communities, not just Debian, not just Ubuntu, there are these reputation of being very off-putting, unfriendly to beginners, and I don't think they're totally underserved. The policy can be almost impenetrable, like you have to have some level of background in understanding Linux for these things to make sense, and like historical context around certain decisions, and then there's all these social rules which are like also somewhat impenetrable.
My advice would be to find someone who understands the system and has your back. I frequently get questions from folks now know that I know Debian and Ubuntu system so to speak. They'll be like, “Can you help me with this thing? I filed this bug and Ubuntu isn’t listening to me. They don’t understand. This is really frustrating.” Go and reach out to them on IRC, and have a chat about it, and then comment on the issue, or test the patch, or whatever, making everybody happy.
Having somebody to watch out for you to help you avoid these social faux pas, and to guide you in the right direction, and to show you that the various parts of policy that you need to care about, that honestly, I think is your best bet. That was to a large extent like how I figured out a lot of these stuff. Some of it was certainly just trudging through policy, and trying to figure it out, but a lot of it was like, “Hey, so and so, can you help me with this package? I tried to Google this thing, but it didn't work and policy says this and the main pages says this, and they contradict each other, can you please help me with this?” Folks tend to actually be pretty welcoming and understanding when you go ahead with that sort of approach. It is unfortunate that there has historically been sort of an almost hostility towards newcomers making mistakes, not knowing. I mean it's so much to know, of course people are going to make mistakes. I think that as a community we're working on that.
Corey: A lot of that documentation around this stuff is awful too—one of the things I noticed pretty early on.
Elana: It doesn't exist at all.
Corey: Yeah, or worse, I found there are four different ways to build Debian packages and the documentation I found kept shifting between them without saying, “Oh, but if you're going this way...” No, no. One sentence the next would change perspective on different tooling and different approaches. I read this five times and at that point I work in technology for almost a decade. I wasn't Babe in the Woods when it came to this stuff, but it was very clearly there's something wrong here with either my reading comprehension suddenly, or these documentation pieces are terrible because they assume this giant body of knowledge that was never explicitly explained.
Elana: I wrote a blog post called “A Tale of Three Debian Build Tools” in order to—because a bunch of folks were bugging me, they're like, “How do you build packages, Elana?” and I'm like, “Oh, I guess we build packages a lot of different ways. I didn't really think about that,” and I pick these things up, initially I started with git build package, because it doesn't require root, and it has a reasonably good documentation, and it's relatively friendly. Then people were like, “Well, you can't use that build a package to upload you should use pbuilder,” “Okay, what is pbuilder?” I’m trying to figure that out, “Okay, this thing's pretty cool and why the hell does it put the output? What? Where does that go? That should not go there?” Dumps a bunch of stuff and [inaudible 00:26:50] who knows what, and that was very confusing.
Then some folks were like, “Why do you use pbuilder? It's so slow. You should sbuild.” I ended up writing a blog post about this. I wrote packaging tutorials for Clojure Packages not even to help other people but just so I could document my process, so if I spent six months away from it, I would remember what the heck I was working on. It's not the best. I really wish there was much better documentation. I frequently have had to go and dig into code in order to understand how various build tools works, only to discover that the tools were massive blobs of Perl. I mean I could understand them because I've written some Perl in my past, but it's like, “What house of cards was this thing built on?” You don't want to touch anything because there's no tests of course.
Corey: Exactly. It turns out not just that it’s a technically challenging area, there is a lot of minutia, this stuff is hard, and yes, mistakes will show and matter. The entire lesson I took from it was not how to really focus on being an awesome packager, or terrific developer member of the community, but rather if you want something done, screw it up to the point where people take it away from you.
Elana: I don't want people coming into the community and that being the lesson they take away. It’s sort of depressing to look at it that way. One of the things that Debian I have found to be very effective is the law of two feet. If you are the first person to go and do a thing, and you are willing to put in the work to maintain it, folks have a really hard time of doing anything about it. They may yell and scream at you and tell you you're doing everything wrong, but they can't really depose you
It's actually very socially unacceptable to try to depose someone unless you go all the way up to escalating to the technical committee, and there's much drama, then you end up on the front page of the LWN or something like that. We need to do better. I think that a lot of the work that Debian has been doing anti-harassments and stuff like that is making the community better. I mean it's not like we have this documentation team that we can just send things and be like, “Hey you, go document these build tools because our story sucks.” Or, “Go add really good tutorial so more people can get involved in this stuff.”
Debian is just a collection of individuals who are all working sort of independently in their own little fight domes on things that they personally care about. It sometimes amazes me that it works at all. I can't just go and tell people, “Go write this you tutorial.” The group Debian Woman has previously been responsible for a lot of this stuff. Now Debian Woman is not super active, and they’re merging with Debian diversity, and all the tutorials are five years out of date. What do we do? Well, I don't know. How do we direct people at working on these stuff? I don't know. I don't even want to try to suggest, “Hey, maybe we should pay someone to do this,” because the last time that happened everybody cried bloody murder. It is a problem.
Corey: It seems to me that there's a better story for this in the future of making the community more accessible to people. Again, I used to be deep in the weeds of IRC myself. I was network staff on Freenode for the better part of the decade. Part of the reason I did that was because I got tired of what I saw in a number of different channels, which was, someone shows up and ask a question, and the first thing you do, and there's almost a race to be able to do it is not to help them with the question, but to tell them their question is stupid, they're stupid, they didn't ask the question properly, or read the documentation. That is one of those things I found absolutely abhorrent. Why don't we have more people with more diverse backgrounds working in tech? Well, because every time someone shows up in tech, regardless of the rest, you start by subjecting them to trial by fire, and most people have better things to do with their time than playing these games.
I absolutely have nothing but respect for people who stick around to that hazing. But I think that is one of the crappiest things we can wind up doing. We as a tech community writ large, not any particular community, not any particular network, not any particular software package, none of it just as a society I guess. We can do better than that. We’re finally starting to turn the corner on that, I think, I hope, where there are decent ways of finding mentorship of getting involved in the community, but Lord knows that one of the reasons I probably didn't contributed to my not becoming a full time developer all the time was., I didn't want to sit and take that abuse every day.
Elana: No, not at all. I've certainly had my share of that myself. I think one of the reasons that I have been successful in the free and open source software community is that, I am very good at independently being able to research things, and go find the documentation, and I can work for days without needing to reach out for someone for help. I can just, “Okay, I've got this problem.” I will guide myself towards the various things and try to figure it out because I might ask someone.
It's been good because now that I'm working on some things which are considered like—it’s gross to call the bleeding edge, but they're a little bit bleeding edge. Certainly they are new-fangled and untested previously. That definitely comes in handy because it's not scary and off-putting to not have someone holding my hand, because nobody was holding my hand to begin with. But I'm certainly like, “That should not be the baseline or the standard.” I was very lucky to get involved in free software via OpenHatch, because OpenHatch was such a welcoming, warm, helpful community. It was really great.
Folks would come into our IRC channel, and they’d ask basic questions, and people would be very helpful, and respond right away, and try to get them the help they needed. Even if it was the thousandth time question had been answered that day. Sometimes as a maintainer, it can become very trite when somebody asks a question a thousandth time that day, “I guess I have to link that thing again. Maybe I should just make a macro for this.” I mean that person doesn't know that. It's unfair to take your anger out on them.
Corey: One experience that I have that stuck with me years later was in 2012, where I went to scale the southern California area Linux expo. I saw a talk by Jordan Sissel, the founder and creator of Logstash, which has since been acquired by Elastic, it's the L in ELK Stack. He's still there. He gave a talk on Logstash that was transformative in a number of different ways. First, that was one of the talks that inspired me to try my hand at public speaking. If you’ve ever seen one of my talks and thought it was crappy, self-aggrandizing, I’m a terrible speaker, etc, blame Jordan. Secondly, it turned out that he had a line in there that just resonated with me six years later that, “If a new user has a bad time, that's a bug. Fix your documentation. Fix your culture.” It was something that was electrifying where it set the stage for, “Yes, this is what every product should espouse and doesn't,” and ever since then it it's sort of been something that once you see it, you can't unsee it.
Trying to create that type of environment for people has always been what I've been about. In my newsletter last week in AWS is snarky and sarcastic because that is my sense of humor, but I'm very careful never to punch down. When I'm sitting here making fun of Amazon a near $1 trillion company depending on the week. They can take it, they have succeeded. If I'm sitting here making fun of a newcomer to a space, or a start-up of five people, I'm not being clever, I’m being a jerk. I think there needs to be an awareness that meeting people where they are, and making things accessible to them is on the onus of you if you want to see uptake and adoption of what it is you do.
Corey: Where can people find you if they want to hear more about your thoughts, wisdom, code, thoughts on life, etc?
Elana: Well, they can find me on Planet Debian or read my blog directly on Syndicates to Planet Debian. My website is hashman.ca.
Corey: To be clear, Planet Debian is one of those things where it's an aggregator of different blogs or it's a way station that you can get to by connecting through Narnia?
Elana: Definitely Narnia. No. It just aggregates various XML feeds into a single blogging place. Folks are like, “Oh yeah, I saw your latest blog post at Planet Debian. I love what you did.” “Oh yeah, I put my blog on Planet Debian.” Or you could access my blog at hashman.ca/blog. I also tweet @ehashdn, it’s a bad LDAP joke, because my username was taken which was very disappointing. You can also find me on Mastodon if you're so inclined.
Corey: That raises the wonderful question of, is there such a thing as a good LDAP joke?
Elana: You know, as a student I implemented atomic incrementation in LDAP and I think that we should just not even think about such things.
Corey: Absolutely. Well, I’ll put links to those in the show notes as well.
Elana: Great. I can spell them out for you if you need me to do such a thing via email.
Corey: Perfect. Well, thank you once again for taking the time to speak with me. I appreciate it.
Elana: Thanks so much for having me on the show.
Corey: Elana Hashman of Debian and Python Fame. I'm Corey Quinn. This is Screaming In The Cloud.
This has been this week's episode of Screaming In The Cloud. You can also find more at firstname.lastname@example.org or wherever you find a snarky soul.