Date: 2015-10-19

On October 18th 20 years ago the first commits to the OpenBSD project landed in the CVS repository. Today on the anniversary the beastie.pl team invites 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.