Deweloperzy OpenBSD: Ingo Schwarze

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.

Drugim z kolei jest Ingo Schwarze


 

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 second interview – Ingo Schwarze.


 

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

https://2015.eurobsdcon.org/speakers/ingo-schwarze/

Ingo Schwarze has been an OpenBSD user since 2001 and a developer since 2009.  He maintains the OpenBSD in-tree mandoc since making it the only documentation formatter in the base system in 2009/2010.
He also maintains the portable mandoc distribution since 2013 and the OpenBSD groff(1) port since 2010 and has contributed to various parts of the OpenBSD userland, for example the Perl rewrite of the
security(8) script, as well as smaller contributions to the rc.d(8) framework, the yp(8) subsystem, the C library, and various other programs.

Outside the free software world, he studied physics in Siegen/Germany and worked as a researcher in elementary particle physics at CERN and at the University of Karlsruhe (KIT), and as a Perl programmer for Sophos UTM.

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

Since 2001, so for almost three quarters of its history by now. Originally, it was pure chance.  A coworker who used to run various Linux distributions repeatedly got his boxes rooted. Instead of properly securing them, he proposed to try OpenBSD.  I said i didn’t care much which system he used.  At that time, i was used to working on many different Unix and Unix-like systems (DEC OSF/1, Ultix, HP-UX, AIX, SuSE Linux, Debian GNU/Linux …) and OpenBSD looked like just another Unix-like system, so why not.

Almost instantly, i fell in love with the system because i quickly realized how simple it was.  Even with almost no OpenBSD experience, typical sysadmin tasks took me about a quarter of the time i would have spent on a bloated, clicki-bunti, deeply overengineered system like Debian.  I never looked back.

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

Because it’s so simple to use, much, much simpler than any other system i have ever seen, excepting only HP-proprietary systems on hp200 computers in the 1980s, but those were much less powerful than a modern Unix system, so no wonder they were even simpler.

The main effect of the simplicity is that you spend less time learning how to do now matter what with the system (using nothing but the manual pages and the FAQ), and then again less time actually doing it, and you make fewer errors using it.  A side-effect of the simplicity is that there are fewer bugs than in other systems, and a side effect of that is that there are fewer vulnerabilities.

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

Yes, for any kind of workstation, laptop, and server since about 2001/2002, with exactly one exception:  At one point, i needed to run a specific Windows-only bookkeeping software and maintained a dedicated Windows NT box for that (2003-2006).

Even at work at Sophos, i chose to run OpenBSD on my desktop, defying the official company policy at the time that any kind of Linux was allowed on developer machines, but nothing else.  It worked well even when doing lower-layer work.  For example, i developed patches to the Perl interpreter (e.g. perl/mg.c) for SLES on OpenBSD-current.

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

After lurking on the mailing lists for years, then sending a relatively low number of patches (about a dozen) during two years starting in February 2007, but to very different areas (libc, ksh, drivers, xenocara build system, ports, documentation, web site), i found a mail from Theo in my mailbox.  That was in March 2009, so i have been a developer for slightly less than a third of the project’s existence.  After getting my account, i intensified my work from one patch every two months (2007-2009) to one commit a day on average (2009-2015).

What is required?

  1. Independence.
    In case you need to ask others what to do, it’s hopeless.
  2. Team spirit.
    In case you just want to work on your toy project, don’t pay
    attention to the current project needs at each point in time,
    and don’t ask others for their opinions where it matters, it’s
    hopeless.
  3. Mindful listening.
    You must be able to extract useful information from technical
    feedback even when it’s worded tersely and bluntly.  If you are
    easily offended, it’s hopeless.
  4. Realistic self-assessment.
    If you repeatedly work on topics that are way above your head,
    that’s hopeless.  Ideally, you work both on stuff you know well
    (to get real work done) and on stuff that’s challenging for you,
    to improve your skills.
  5. Diligence.
    If the results of your work are full of problems, it’s hopeless.
    The occasional bug or oversight, however, can be dealt with.
  6. Perseverance.
    If you don’t make sure your work (and that work you care about
    done by others) gets properly reviewed, tested, committed, and
    maintained, it’s hopeless.  Sometimes, that’s harder than it
    seems, everyone is busy and stuff is easily forgotten.

Obviously, being a good programmer helps.  However, work needs to be done in all areas of the system, and the level of technical expertise required varies greatly.  Some OpenBSD developers almost never write a line of code and yet commit regularly and are of critical importance to the group.  Besides, much can be learnt on the job.

If any of the above are missing, it is unlikely that you will keep your account for long.  However, in a few cases, people lacking one or two of the above team up with a developer who reviews and commits their work.  But getting that to work is usually harder than becoming a developer oneself.

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

Currently, mostly the documentation formatting toolbox, mandoc, see http://mdocml.bsd.lv/press.html for details.

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

That varies greatly.  In some months, i hardly did anything.  In some weeks, i worked on OpenBSD for 70 hours.  Most of the time, it probably varies between 5 and 15 hours a week.  But i never tried to measure anything in this respect.  The grand total probably is between 1500 and 4000 hours so far.

http://www.oxide.org/cvs/schwarze.html

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 outside world?

Tools get picked up when they are uselful, like afl.

The term „process improvement” sounds a bit like part of a meta discussion that OpenBSD developers tend to avoid.

Regarding the process, it really boils down to this:

  1. Write a useful patch.
  2. Make sure the right people see it (those interested, those
    knowledgeable, and those it might hurt).
  3. Collect the feedback, improve the patch as needed.
    If required, repeat the steps 2 and 3, but not too often,
    don’t waste everybody’s time.
  4. Commit it as soon as it is better than the existing code.
  5. Quickly fix any problems that were overlooked – or if you can’t,
    back it out immediately and go back to step 1.
  6. Maintain it.

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?

Above all, the fact that mandoc is now used by default not only in OpenBSD, but also in FreeBSD, NetBSD, and illumos, and even by two niche Linuxes (Alpine and Void).  That we got semantic searching to the point where it is just taken for granted (in both OpenBSD-release and FreeBSD-current).  The mandoc system of error and warning messages. Lots small things like my recent eqn(7) improvements.

Most other contributions are relatively minor, so nothing to be particularly proud of.  But some are nifty anyway:  The fact that my work on daily(8)/weekly(8) made sure you only get mail when anything looks suspicious, but not each and every day; the fact that due to an idea i implemented, you can still log into a properly configured box using YP even when the network is down; the improved security and maintainability of the security(8) script after my rewrite together with afresh1@; the groff and gpresent ports; the improvements to lots of HISTORY sections in manual pages.

Using SQLite was a bad idea, it’s too bloated, and the code is excessively obfuscated by portability goo and performance trickery. I’d definitely like to get rid of that heavy-weight component and throw it out of the base system.  Ports is a better place for it to live.  Not sure yet how to do that, though.

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

I have no idea.  OpenBSD, as a matter of principle, does not make long-term or even medium-term plans.  We work on the tasks at hand, and it takes the time it takes.  The only planning that is required is to start very intrusive, potentially dangerous projects right after the tree is unlocked after cutting a release, such that there is as much time as possible for the new project to mature before it’s first included in the next release.  Six months later.  But that’s it, that’s all.

Right now, many people are working on reducing the global kernel lock such that the kernel can more efficiently use multiple CPUs, but i’m not involved in that work.

The currently running pledge(2) project (formerly called tame(2)) is definitely important as the next step in exploit mitigation; i’m tangentially involved, but others do the real work in that area.

Later this month in Berlin, we will have a look at our UTF-8 support. The challenge is to make the useful pieces work, cut all the bloaty and dangerous crap as much as possible, and consolidate the codebases to make them reviewable and maintainable.  In particular, to carefully delete all code supporting any charsets except UTF-8 and US-ASCII.

As far as i’m aware, the worst long-term problem is that not a single acceptable C compiler exists.  Gcc is buggy, unstable, and not free software, Clang is bloated and lacks support for some architectures, Pcc is outdated, not portable enough, and lacks manpower, and writing a compiler from scratch is far beyond the manpower of the OpenBSD project.  I have no idea how that will be solved, and i will almost certainly be unable to contribute in that area, but i expect temporary workarounds will be found that are good enough to keep going.

In any case, OpenBSD seems vital and healthy and becomes better than it already is every day.  That’s all that really matters.


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

https://2015.eurobsdcon.org/speakers/ingo-schwarze/

Ingo Schwarze jest użytkownikiem OpenBSD od 2001 roku, zaś deweloperem od 2009 r. Utrzymuje mandoc, jedyny program formatujący dokumentację w systemie bazowym od 2009/2010r. Dodatkowo serwisuje jego przenośną wersję od 2013 r. oraz port OpenBSD groff(1) od 2010. Udzielał się także w różnych częściach użytkowych systemu OpenBSD, np. przepisując security(8) w Perlu oraz mniejsze dokładki do szablonu rc.d(8), podsystemu yp(8), biblioteki standardowej C czy różnych innych programów.

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

Od 2001 roku, czyli 3/4 jego historii. Pierwotnie, przez przypadek. Współpracownik, który używał różnych dystrybucji Linuksa, miał regularnie rootowane maszyny. Zamiast je poprawnie zabezpieczyć, zaproponował nam użycie OpenBSD. Powiedziałem, że nie zależy mi zbytnio na tym, którego systemu będziemy używać. W tamtych dniach byłem przyzwyczajony do różnych wersji Uniksa i jemu podobnych systemów (DEC OSF/1, Ultix, HP-UX, AIX, SuSE Linux, Debian GNU/Linux …), tymczasem OpenBSD wyglądało, jak kolejny system oparty o Unix, zatem dlaczego nie?

Prawie natychmiast zakochałem się w tym systemie, ponieważ zorientowałem się jaki jest prosty. Nawet bez żadnego doświadczenia z OpenBSD typowe zadania administratora zabierały 1/4 czasu, który był by wymagany na nadmuchanych, klik-buntowatych, głęboko prze-projektowanych systemach takich, jak Debian. Nigdy do nich nie wróciłem.

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

Ponieważ jest on prosty, dużo dużo łatwiejszy od innych systemów, które do tej pory widziałem, za wyjątkiem komercyjnego systemu HP na komputerach hp200 w 1980 roku, ale systemy te były słabsze od współczesnych systemów Unix, nic dziwnego że były jeszcze łatwiejsze.

Główny skutek prostoty systemu to czas, jaki oszczędzasz na nauce, jak się nim posługiwać (używając nie więcej niż strony dokumentacji man oraz FAQ), a następnie czas wymagany do wykonywania na nim pracy okazuje się jeszcze krótszy,ty zaś zauważasz, że popełniasz przy tym mniej błędów. Efekt uboczny tego wszystkiego, to mniej pomyłek, niż w przypadku innych systemów, co przekłada się na mniej błędów związanych z bezpieczeństwem.

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

Tak, dla dowolnego rodzaju stacji roboczej, laptopa czy serwera od około 2001/2002 roku, z dokładnie jednym wyjątkiem: Przez pewien czas miałem potrzebę uruchamiania specyficznej Windowsowej aplikacji księgowe. Na te potrzeby posiadałem dedykowany sprzęt z Windowsem NT (w latach 2003-2006).

Nawet w pracy w Sophos wybierałem OpenBSD jako swój system na pulpit, sprzeciwiając się polityce firmy, która mówiła, że dowolny rodzaj Linuksa na maszynie dewelopera jest dozwolony, nic innego. Przykładowo, rozwijałem patche dla interpretera Perla (np. perl/mg.c) dla SLES pod OpenBSD-current.

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

Po czyhaniu na liście mailingowej przez kilka lat i wysłaniu kilku łatek (mniej niż tuzin) dotyczących bardzo różnych obszarów (libc, ksh, sterowników, systemu budowania xenocara, portów, dokumentacji, stroni) przez dwa lata w okresie od Lutego 2007, znalazłem emaila od Theo na swojej skrzynce pocztowej. To było w marcu 2009, więc jestem deweloperem od prawie 1/3 istnienia projektu. Po otrzymaniu konta zintensyfikowałem swoją pracę z jednego patcha na dwa miesiące (2007-2009) do średnio jednego commita dziennie (2009-2015).

Co jest wymagane?

  1. Niezależność – Jeżeli musisz pytać innych co należy robić, to sytuacja jest beznadziejna.
  2. Duch zespołu – Jeżeli chcesz pracować nad swoim własnym projektem, bez zwracania uwagi na obecne potrzeby projektu na każdym kroku i nie pytając innych o opinie, to sytuacja jest beznadziejna.
  3. Świadome słuchanie – Musisz być w stanie wydobyć użyteczną informację z technicznych komentarzy dotyczących twojej pracy, nawet jeżeli jest przekazana bezpośrednio i bez ogródek. Jeżeli łatwo cię urazić, to sytuacja jest beznadziejna.
  4. Realistyczna samoocena – Jeżeli ciągle pracujesz nad tematami, które są ponad twoje możliwości, to sytuacja jest beznadziejna. W idealnych warunkach poświęcasz czas na rzeczy, które dobrze znasz (aby wykonać faktyczną pracę) i na rzeczach, które są dla ciebie wyzwaniem, aby rozwijać twoje możliwości.
  5. Dbałość – Jeżeli wyniki twojej pracy są pełne problemów, to sytuacja jest beznadziejna. Jednakże na drobne błędy da się przymknąć oko.
  6. Wytrwałość – Jeżeli nie upewniasz się, że twoja praca (i praca, na której tobie zależy) jest poprawnie przeglądnięta, przetestowana i zacommitowana, a następnie utrzymywana, to sytuacja jest beznadziejna. Czasami jest to znacznie trudniejsze niż się wydaje, każdy jest zajęty, zaś o pewnych sprawach bardzo łatwo zapomnieć.

Oczywiście bycie dobrym programistą pomaga, lecz pożądana jest praca w każdym obszarze systemu, a wymagany poziom technicznej wiedzy mocno zróżnicowany.  Niektórzy deweloperzy OpenBSD prawie nigdy nie piszą choćby jednej linijki kodu, a mimo wszystko regularnie commitują zmiany, które są krytyczne z perspektywy całej grupy. Poza tym bardzo wiele można się nauczyć będąc już w zespole.

Jeżeli brakuje ci dowolnego z powyższych elementów, to raczej nie utrzymasz swojego konta na długo, choć w nielicznych przypadkach ludziom, którym brakowało jednej lub dwóch z powyższych cech udawało się dogadać z obecnym deweloperem przeglądającym i commitującym ich pracę. Doprowadzenie do takiej sytuacji wymaga jednak często więcej pracy, niż zostanie samodzielnym deweloperem.

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

Obecnie głównie nad narzędziami formatującymi dokumentację mandoc. Spójrz na http://mdocml.bsd.lv/press.html, jeżeli chcesz dowiedzieć się więcej.

7. Ile czasu zajmuje Ci praca przy projekcie OpenBSD?

To jest mocno zróżnicowane. W niektórych miesiącach praktycznie nie robię nic, ale bywały tygodnie, kiedy pracowałem nad OpenBSD przez 70 godzin. Znaczna część czasu pewnie uśrednia się w okolicach 5 do 15 godzin tygodniowo, jednak nigdy nie starałem się tego mierzyć. Łączny czas spędzony klasyfikuje się pewnie gdzieś pomiędzy 1500 a 4000 godzin, jak do tej pory.

http://www.oxide.org/cvs/schwarze.html

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?

Narzędzia zaczynają być używane w momencie, gdy stają się użyteczne – jak afl.

Termin „najlepsze praktyki” brzmi jak meta-dyskusja, której deweloperzy OpenBSD starają się unikać.

Odnośnie procesu, sprowadza się on do tego, co następuje:

  1. Pisz przydatne łatki.
  2. Upewnij się, że odpowiednie osoby je zobaczą (ci – których to interesuje, ci – którzy coś o tym wiedzą, oraz ci – których to zaboli).
  3. Zbierz informacje zwrotne, popraw łątkę wedle konieczności, powtórz kroki 2 i 3, ale niezbyt często – nie marnuj czasu wszystkich dookoła.
  4. Commituj zmianę, jeśli tylko jest lepsza od obecnego kodu.
  5. Szybko naprawiaj problemy, które przeoczyłeś – jeżeli nie jest to możliwe, to jak najszybciej wycofaj swoją zmianę i wróć do kroku 1.
  6. Serwisuj swoją zmianę.

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

Przede wszystkim fakt, że mandoc jest teraz używany domyślnie nie tylko w OpenBSD, ale i we FreeBSD, NetBSD, Illumos, jak też przez dwie niszowe dystrybucje Linuksa (Alpine i Void Linux). Ponadto fakt, że doprowadziliśmy semantyczne wyszukiwanie do poziomu, w którym jest ono oczekiwaną funkcjonalnością (przynajmniej w OpenBSD-release i FreeBSD-current). Następnie system błędów i ostrzeżeń z mandoc. Oraz wiele małych ulepszeń ostatnio dodanych do eqn(7).

Wiele pozostałych dodatków, to drobiazg w porównaniu do powyższych; nic, z czego mógłbym być bardziej dumny. Jednakże kilka z nich jest dość przydatnych mimo wszystko: Fakt, że moja praca nad daily(8)/weekly(8) powoduje, że dostajesz maila tylko, gdy coś wygląda podejrzanie, a nie każdego dnia; Fakt, że dzięki pomysłowi, jaki zaimplementowałem możesz nadal zalogować się do poprawnie skonfigurowanego systemu używając YP nawet jeśli sieć leży; poprawione bezpieczeństwo i serwisowalność skryptu security(8) po moich wspólnym jego przepisaniu wraz z afresh1@; porty groff i gpresent; poprawki w wielu sekcjach HISTORY stron man.

Użycie SQLite było złym pomysłem. Jest zbyt nadęte, a kod jest zbyt skomplikowany z powodu warstw wymaganych dla przenośności programu pomiędzy platformami i sztuczek związanych z wydajnością. Zdecydowanie chciałbym się pozbyć tego ociężałego elementu oraz wyrzucić go z bazowego systemu. Porty są dla niego znacznie lepszym miejscem, choć nie jestem pewien, jak to zrobić.

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

Nie mam pojęcia. OpenBSD z reguły nie przygotowuje, ani długo, ani średnio terminowych planów. Pracujemy nad bieżącymi sprawami i zajmują one tyle czasu, ile potrzebują. Jedyne planowanie jakie jest konieczne, to rozpoczęcie bardzo inwazyjnych, potencjalnie niebezpiecznych prac zaraz po odcięciu wydania tak, by nowy projekt miał jak najwięcej czasu, aby dojrzeć do jego zawarcia w kolejnym wydaniu systemu 6 miesięcy później, ale to wszystko.

Obecnie wiele osób pracuje nad zredukowaniem globalnego lockowania na kernelu, by mógł on wykorzystać efektywnie wiele jednostek CPU, jednak ja nie jestem zaangażowany w te prace.

W chwili obecnej rozwijany projekt pledge(2) (pierwotnie zwany tame(2)), zdecydowanie jest kolejnym dużym krokiem w zapobieganiu eksploatacji systemu; jestem przelotnie w to zaangażowany, lecz inne osoby wykonują faktyczną pracę w tym obszarze.

Później, w tym miesiącu, w Berlinie, zwrócimy uwagę na nasze wsparcie dla UTF-8. Wyzwaniem jest dostarczenie użytecznych fragmentów kodu, wycinając przy tym jak najwięcej tłuszczu i niebezpiecznych elementów, konsolidując kod do formy możliwej do przeglądu i serwisowania. W szczególności ostrożnie usuwając kod wspierający wszystkie kodowania oprócz UTF-8 i US-ASCII.

O ile mi wiadomo, najgorszym długofalowym problemem jest brak akceptowalnego kompilatora języka C. GCC jest pełne błędów, niestabilne i ‚not free’. Clang jest nadęty, nie posiada wsparcia dla części architektur, PCC jest przedawnione, niezbyt przenośne i brakuje mu rąk do pracy, a napisanie kompilatora od podstaw jest poza możliwościami projektu OpenBSD, uwzględniając ilość osób nad nim pracującą. Nie mam pojęcia, jak ten problem zostanie rozwiązany i raczej na pewno nie będę w stanie wesprzeć prac w tej części systemu, ale oczekuję tymczasowych rozwiązań, które będą wystarczająco dobre, aby utrzymać nas na dalszym kursie.

W każdym razie, OpenBSD wydaje się żywotne i zdrowe. Staje się coraz lepsze każdego dnia. Tylko to ma znaczenie.

Skomentuj

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