Deweloperzy OpenBSD: Ted Unangst

Osiemnastego października dwadzieścia lat temu pierwszy commit wylądował w repozytorium CVS projektu OpenBSD. W rocznicę tego wydarzenia zespół beastie.pl zaprosił wszystkich czytelników do serii wywiadów przeprowadzonych przez nasz zespół z deweloperami projektu.

Ósmy Ted Unangst


On October 18th 20 years ago the first commits to the OpenBSD project landed in the CVS repository. On the anniversary the beastie.pl team invited all readers to a series of interviews that our staff conducted with the project developers.

We continue with our eight interview – Ted Unangst.


 

1. For the readers who don’t know you, can you shortly introduce yourself?

I’m not very good at autobiographies. I’ve been tedu@openbsd for about 12 years. I work on OpenBSD as a hobby.

2. Why did you choose to run OpenBSD? How long have you been using it?

A friend introduced me to OpenBSD about 15 years ago. At first I was just fooling around with it, and dual booting as necessary, but once I started using it as a server, I didn’t want the embarrassment of downtime whenever I had to reboot. Then I figured out I could write papers using WordPerfect (via Linux emulation) and stuck with OpenBSD full time.

3. For those readers that still haven’t joined the OpenBSD community, why should they try OpenBSD?

Everybody is looking for something different, so that’s hard to answer, but I like the simple approach the project takes. We move a little slower, sometimes, though the phrase we like to use is evolution, not revolution. Every release changes something (hopefully for the better), but it always feels like the same system.

4. Is OpenBSD your daily driver at home & at work?

Absolutely. Actually, I run some other systems as well to change it up, but I sometimes go weeks without touching a system that’s not OpenBSD.

5. How did you become an OpenBSD developer? What do you think is required in order to join the OpenBSD project as a developer?

I was fooling around with null and union mounts (a way of overlaying one part of the filesystem on top of another) and encountered some bugs. I tried fixing them with a giant diff (mostly derived from NetBSD) but the other developers weren’t too excited about it. I split it up into a few smaller diffs, and also sent some patches for a few other random issues I’d encountered. Or not even issues, just little code cleanups. Eventually I guess it was easier to have me commit the changes myself.

6. Can you tell us about some OpenBSD-related areas you work on?

It’s not really restricted to one area. I have an ongoing interest in memory management and filesystems, for example, but also did some work on little tools like grep. Recently I’ve been (re)writing some security critical tools to be simpler, both from a user perspective and for other developers. And of course, I have lots of opinions on the work others are doing, but I try to only meddle when it’s important.

7. Do you have an idea of the time you spend working on the OpenBSD project?

It varies a lot. I only work on OpenBSD when I want to, so it depends mostly on whether there’s something I want to work on. There’s usually something fun happening, so probably a fair bit of time.

8. OpenBSD tends to lead in development best practices does it work the other way around? Is there a process improvement the project started or aims to adapt from the oustide world?

I don’t think we’re doing anything that hasn’t been done before; just maybe other people don’t seem to feel like doing it. I’m solidly convinced that regularly scheduled releases are the best way to ship software, and I’ve had some success convincing others to do the same. A lot of the time, though, it turns into a scramble to squeeze features in before the deadline. I think OpenBSD is pretty good at slipping features instead of compromising quality.

Moving forward, I think we’re learning to deal with long term maintenance of software. Lots of OpenBSD developers have come and gone over the years, but their code always remains. In a project where people only work on things they care about, this can leave some gaps in coverage. Hence the motivation to reduce and simplify code and features, so that in ten years time there is less maintenance necessary.

9. It’s been a long 20 years of amazing releases. What are you most proud of and what would you like to revisit/redo?

Personally, I’m pretty happy with the way signify turned out. It was the kind of project where we would inevitably discover problems and shortcomings as we went, and what seemed workable to start would turn into a disaster just a day after we committed to using it. Fortunately, it’s worked out pretty well. There’s always something that could be better, but it’s a good first effort.

There’s also the exploit mitigation work done in malloc(). Some of that work has been picked up and found useful by other projects, but I also think there’s quite a bit more that we could be doing.

10. As a conclusion, can you tell us how you forecast OpenBSD’s future? What’s the next big challenge?

As I said before, OpenBSD prefers to move a little slow. This has saved us a lot of wasted effort chasing the latest fad, only to switch directions a year later. At the same time, in order to stay relevant and not fall too far behind, we have to guess what’s a passing fad and what’s an inevitable change.


1. Czy mógłbyś powiedzieć parę słów o sobie czytelnikom, którzy jeszcze Cię nie znają?

Nie jestem zbyt dobry w autobiografiach. tedu@openbsd jestem przez ponad 12 lat. Praca z OpenBSD to dla mnie hobby.

2. Dlaczego wybrałeś OpenBSD? Jak długo korzystasz z tego systemu?

Znajomy wprowadził mnie w OpenBSD około 15 lat temu. Na początku tylko trochę się z nim wygłupiałem, dual boot był wtedy konieczny, ale jak tylko zacząłem używać OpenBSD jako serwer, nie chciałem już być zawstydzany jego niedostępnością  za każdym razem, gdy odpalałem inny system. Odkryłem wówczas, że mogę pisać dokumenty używając WordPerfect (poprzez emulacje Linuksa), a OpenBSD stało się moim głównym systemem.

3. Dlaczego czytelnicy, którzy jeszcze nie przyłączyli się do społeczności OpenBSD powinni tego spróbować?

Każdy poszukuje czegoś innego, więc jest to pytanie wyjątkowo trudne Osobiście lubię proste rozwiązania, które obiera projekt. Poruszamy się trochę wolniej, czasami zdarza nam się używać terminu ewolucja zamiast rewolucja. Każde wydanie coś zmienia (mamy nadzieję, że na lepsze), lecz zawsze efektem końcowym jest ten sam system.

4. Czy używasz OpenBSD jako głównego systemu w domu oraz w pracy?

Absolutnie. W gruncie rzeczy używam paru innych systemów, aby zróżnicować swój dzień, ale bywają tygodnie, kiedy nie dotykam żadnego innego systemu poza OpenBSD.

5. W jaki sposób zostałeś deweloperem OpenBSD? Co – Twoim zdaniem – jest potrzebne by zostać członkiem projektu w roli dewelopera?

Wygłupiałem się z union mount-ami (metoda nakładania jednej części systemu plików na drugą) i trafiłem na kilka błędów. Próbowałem je naprawić gigantyczną łatą (głównie wyniesioną z NetBSD), ale innym deweloperom się to zbytnio nie spodobało. Podzieliłem ją zatem na kilka mniejszych łat i wysłałem kilka dodatkowych na inne przypadkowe problemy, które napotkałem po drodze – nawet nie problemy, a drobne porządki w kodzie. Koniec końców chyba byłoby łatwiej, gdybym sam nanosił te zmiany.

6. Czy mógłbyś powiedzieć parę słów o obszarach Twojego zaangażowania w OpenBSD?

Moja praca nie jest ograniczona do jednego obszaru. Przykładowo, na bieżąco interesuję się zarządzaniem pamięcią i systemami plików, a i tak wykonałem nieco pracy przy małych narzędziach, takich jak grep. Ostatnio (prze)pisywałem kilka krytycznych – z punktu widzenia bezpieczeństwa – narzędzi na bardziej proste, zarówno z perspektywy użytkownika jak i innych deweloperów. Oczywiście, mam również sporo opinii na temat pracy wykonywanej przez innych, ale staram się nie wtrącać, jeśli nie jest to istotne.

7. Ile czasu zajmuje Ci praca przy projekcie OpenBSD?

Mocno się waha. Pracuję nad OpenBSD tylko wtedy, kiedy mam na to ochotę, czyli ilość poświęconego czasu zależy od tego, czy jest coś, nad czym mam ochotę pracować. Zwykle coś fajnego się dzieje, więc spędzam dość sporo czasu.

8. OpenBSD zwykle przoduje w najlepszych praktykach deweloperskich. Czy działa to również w drugą stronę? Czy istnieją nowe praktyki, które projekt właśnie rozpoczął lub planuje zaadaptować z innych zewnętrznych projektów?

Nie uważam, że robimy coś, czego nikt wcześniej nie robił. Możliwe, że niektórym ludziom po prostu nie chce się tego robić. Jestem szczere przekonany, że regularne wydawania, to najlepszy sposób na dostarczanie oprogramowania. Miałem nawet drobne sukcesy w przekonywaniu innych do takiego samego podejścia. Niestety w wielu przypadkach sprowadza się to do biegania w panice, aby wcisnąć ostatnie funkcjonalności tuż przed deadlinem. Uważam, że OpenBSD wykonuje tu dobrą robotę, rezygnując z funkcjonalności na korzyść jakości całego wydania.

Patrząc w przyszłość myślę, że uczymy się radzić sobie z z długoterminowym serwisowaniem oprogramowania. Wielu deweloperów OpenBSD pojawiało się i znikało wraz z upływem lat, ale ich kod pozostaje. W projekcie, gdzie każdy pracuje tylko nad rzeczami, na których mu zależy, pozostawia to sporo luk w serwisowanych funkcjonalnościach. Stąd motywacja, aby redukować i upraszczać kod oraz funkcjonalności tak, by za 10 lat kodu i potreby jego serwisowania było mniej.

9. To już długie 20 lat wspaniałych wydań. Z czego jesteś najbardziej dumny oraz do czego chciałbyś ponownie zajrzeć/zrobić inaczej?

Osobiście jestem zadowolony z obecnego stanu rzeczy. To typ projektu, gdzie nieuniknione jest odkrywanie problemów lub niedociągnięć w trakcie pracy, a to co wydawało się akceptowalne na początku mogą stać się katastrofą kilka dni po podjęciu decyzji o wdrożeniu wybranego rozwiązania. Na szczęście dla nas wszystko zywkle kończy się dobrze. Zawsze coś można zrobić lepiej, ale mamy niezły start.

Jest jeszcze praca, którą wykonaliśmy przy mechanizmamach prewencyjnych w malloc(). Część z tych prac została podjęta przez inne projekty jako użyteczna, uważam jednak, że możemy w tym obszarze zrobić jeszcze więcej.

10. W ramach podsumowania, jak kreślisz przyszłość dla OpenBSD? Co jest kolejnym największym wyzwaniem?

Jak wspominałem wcześniej, OpenBSD lubi poruszać się powoli. Pozwoliło nam to zaoszczędzić sporo energii w pogoni za chwilowo popularnymi rozwiązaniami tylko po to, by kilka lat później pójść w innnym kierunku. Jednośnie, aby pozostać nafali i pozostać w tyle, musimy zgadywać co jest chwilową a co nieuniknioną zmianą.

Skomentuj

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *