Deweloperzy OpenBSD: Henning Brauer

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.

Trzynasty Henning Brauer


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 thirteenth interview – Henning Brauer.


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

I’m Henning, not 20 any more, OpenBSD developer since 2002. I architected & wrote large parts of pf, started, architected and wrote large parts of bgpd and ntpd. The imsg & privsep framework I wrote for bgpd is in almost all newer OpenBSD daemons. I also worked a lot in the network stack, including many redesigns. One of the last bigger projects I did was the replacement of the queueing subsystem.

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

I started using OpenBSD around 2.6 or 2.7 times. Basically, we had a DoS attack against a linux webserver and it behaved poorly. Around the same time a colleague was telling me about their very positive experience with switching their Nameservers to FreeBSD, so I looked at FreeBSD, and OpenBSD + NetBSD while on it. OpenBSD behaved very well against the replayed attack and generally attracted me, things were just Done Right.

We had a pair of OpenBSD firewalls with ipf shortly after, with manual failover of course, nothing like carp was even remotely on the radar – at these times, a „cold standby” scheme was common for many things with higher availibility requirements. I had performance problems. When OpenBSD 3.0 with the first pf incarnation was published, I tried it right away. It was very fast – both at runtime and to crash. In a long debugging session with Daniel Hartmeier we eventually found the problem and fixed it; from that point on I was running pf instead of ipf and the very same machines that were pegged on CPU for hours every day peaked at some 10% CPU load. I wrote an email to misc@ giving a short rundown of the story, and received an invitation to the upcoming hackathon from theo in return. They haven’t let me off the leash since then :)

Honestly, besides the incredible technical expertise in the OpenBSD hackers group, this is just and awesome crowd that is a lot of fun to work with, and more than just work with. It is still an honour for me to be part of this group.

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

Well, I’m not into marketing really, but I can easily tell why I use OpenBSD almost everywhere.

Reliability.

That goes much further than „not crashing”. Running internet-facing services with often high availability requirements means you need a software stack that just works, all the time, and doesn’t surprise you. „Just works” here includes a very very important bit: not getting taken over by third parties. Security is critical.

Reliability also means that the software stack has to be user friendly in the sense of not surprising the admin – you neither want sudden reboots, sudden death of daemons providing essential services and so on. The consistency that OpenBSD delivers gives me that, whatever I do in the scope of the OpenBSD base system doesn’t lead to surprises but works exactly how you expect it to (and minor derivations are getting fixed when encountered). Having to add a tiny bit to a production system that shall not fail and not having to fear that this addition causes havoc is worth a lot.

I could write on and on, there is so much I count on the positive side. Very noteworthy before I stop to not digress too much of course is the security OpenBSD delivers. I don’t have to worry about machines being taken over while I have beer with friends, sleep, sit in an airplane, or whatnot. OpenBSD’s defense in depth approach, last not least through the many mitigation techniques, helps a lot there, even with 3rd-party software that is sometimes questionable from the security standpoint but you can’t escape from – php probably being the prime example. Getting all that without major performance impact is impressive.

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

Yes, my workstation at work runs OpenBSD (and even hosts my personal homepage), so do all my laptops. I have work to do and don’t want to fiddle with the OS in the process, it needs to Just Work. OpenBSD gives me that.

The vast majority of the many many many many machines at work also run OpenBSD. The fact that these don’t need babysitting but generally just require attention for upgrades every now and then makes a real difference. Of course we have extensive monitoring to not run into surprises, but generally, OpenBSD machines required very very little manual maintenance.

But there’s so much more. Even my little media server at home runs OpenBSD. The microcontrollers driving the door locks at work interface with OpenBSD, so do the ones controlling the lights. All money runs through OpenBSD – the bank interfaces run on it. So does all billing including invoice generation.

I think it is pretty appropriate to call OpenBSD my daily driver.

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

Well my entry point was, as mentioned above, pf – me apparently being one of the first ones to try it in a bigger production setup.

A common saying in OpenBSD is that you receive your account when other developers get annoyed by the number of diffs of yours that they commit. At some point you get the commit bit to do it yourself. So to get involved, you just get involved. Fix problems, annoyances, inconsistencies when you encounter them and send the diff to tech@, same goes for missing functionality. Your diffs usually either get committed or you get valuable feedback.

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

„everything networking” is probably closest.

When I run into shortcomings (from my subjective PoV, of course) I try to work on those too where feasible – an example is the template support in disklabel for autoinstall with custom partitioning I did earlier this year.

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

I don’t do any time accounting – after all, OpenBSD hacking is supposed to be fun.
The amount of time I spend on OpenBSD varies a lot. In the last couple of months it was very very very little unfortunately due to extraordinary workload and some health issues, I hope that’ll change soon.
In the good ol’ days ™ it was much easier to allocate time; I wrote the initial bgpd from zero over the buffer, imsg and privsep frameworks to the point where session management was reasonably there, i. e. could talk to peers, keep sessions up thru keepalives etc, in 2 or 3 weeks. Over the last years the bigger projects happened mostly at or around hackathons. These are very important for OpenBSD, the progress you can make by throwing a bunch of us in a room for a coupe of days straight is amazing – and it is a lot of fun.

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?

We don’t tend to have that much „process” written in stone. Last not least keep in mind that we’re all volunteers and do this for fun. OpenBSD is not an isolated remote island for and by itself, so of course there is influence both from and to the outside world. I bet you’ll get 10 different answers (being examples, really) on how OpenBSD influenced the outside world when you ask 10 developers. Similarly, almost every developer brings his own experience and ideas into OpenBSD.

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 probably most proud of pf, last not least on how far it spread. I can’t envision something as great as pf evolving in another environment than OpenBSD – the sheer number of developers who have contributed/committed to pf is pretty impressive already. But it really is much more than just the hard facts, it’s the environment of smart people that are easy (and fun!) to work with.

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

Forecasts are always hard – esp. covering a nontrivial timeframe. I see no indicators for OpenBSD losing traction or anything in that direction, rather the opposite. I am very sure that OpenBSD will stay OpenBSD and not allow i. e. a large corporate user to steer it. Basically the freedom to do „the right thing” versus having to follow commercial interests.

Shorter term one of the bigger challenges is better SMP in the kernel, from my PoV unsurprisingly last not least in the network stack. There has been great progress already, which I unfortunately couldn’t contribute too much to, yet.

I do see a need for improvements in the file system area, foremost more flexibility.

Longer term it’s much more about general trends than specifically OpenBSD. We see the environment we operate in changing quite drastically these days. With IT as a whole becoming more mature some of the „written in stone” rules count less and less, some will become irrelevant. The widely deployed line of thought that you set up a bunch of machines for a certain task and re-do everything a couple of years later vanishes; the need to replace hardware frequently is about to vanish (where it hasn’t already) since you don’t need to buy new hardware every couple of years due to performance requirements – in many areas, at least. The trend towards virtualization is part of that: a current entry-level server is way to beefy for many many many tasks, so one way to make efficient use of its resources is virtualization. I predict that we’ll see setups being around MUCH longer than what we’re used to today. The virtualization has another side-effect – shifting VMs from one host to another is trivial, while today it is pretty common to do fresh installs on new hardware when the hardware is changed. We’ll see much longer-living installs not just due to longer hardware life, we’ll see that to a whole new level with VMs that just get shifted to new/other hosts/platforms. That makes maintenance a much bigger deal, a system that is totally cluttered after a few years, with nobody being able to really grok what’s going on is an increasing problem with age of the installation. OpenBSD’s simplicity, consistency and great management infrastructure help a lot there.

At the same time, what used to be exclusively IT stuff spreads into many other areas. We see computers controlling all kinds of everyday things, from trains to airplanes, from your heating system to power plants and traffic lights. Especially in these roles we won’t see frequent upgrades in the sense of replacing the setup – a plane usually flies for 20+ years, a train often reaches 40 before retirement, and even today we already have power plants controlled by ancient PDP11s. In these use cases you also seldom see an IT admin team taking care of the computers, they are just a part of the bigger picture. At the same time we see these things getting networked more and more, including being connected to the internet. That in turn makes security even more important than it already is. As bad as a taken over website is, a taken over power grid, train, or airplane is MUCH worse.

The increasing use of commodity IT equipment in these more or less embedded roles where we typically don’t see an administrator team dealing with software upgrades etc has a lot of consequences. It doesn’t have to be something as obviously important as the power grid – in the majority of cases, much lower profile, these systems will need to become way more „self maintaining”, in the sense of applying updates and especially security fixes largely automated. There will be staff at least supervising the process for power plants, airplanes, trains and the like (at least I really really really hope that…), less so for less prominently exposed use cases. The alternatives for the majority of these cases won’t be „automated maintenance” versus „manual maintenance”, the option in way too many cases would be „unmaintained” (call me disenchanted if you like).

That all said, the maintenance automation doesn’t necessarily have to be part of the base OS, so large parts of that might happen in an OS-independent way, of course with OS specific bits to keep care of the OS itself. But the OS needs to be automation friendly. And guess what: OpenBSD already is. Of course there is still room for improvement and I generally expect the automation bits to gain importance over the next decade; I think OpenBSD is well prepared for that.


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

Jestem Henning, już nie 20 letni, deweloper OpenBSD od 2002 roku. Zaprojektowałem i napisałem spore fragmenty pf; rozpocząłem, zaprojektowałem i napisałem spore części bgpd oraz ntpd. Szablony imsg oraz privsep, które napisałem dla bgpd, są w praktycznie każdym nowszym demonie działającym w OpenBSD. Wykonałem też dużo pracy w stosie sieciowym, wliczając w to sporo zakończonych projektów od początku. Ostatni duży projekt, jaki zrealizowałem dotyczył przerobienia podsystemu kolejkowania.

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

Zacząłem używać OpenBSD w czasach wersji 2.6 lub 2.7. W skrócie, przeżyliśmy atak DoS na serwer www działający pod Linuksem i nie zachował się on zbyt dobrze. Mniej więcej w tym samym czasie kolega opowiadał mi o swoim bardzo pozytywnym doświadczeniu z migracją serwera nazw na FreeBSD, zatem popatrzyłem na FreeBSD oraz przy okazji na OpenBSD + NetBSD. OpenBSD zachowało się bardzo dobrze na reprodukcji ataku i generalnie przyciągnęło moją uwagę, rzeczy były po prostu Zrobione Dobrze.

Mieliśmy kilka firewalli OpenBSD z ipf chwilę później, oczywiście z manualnym awaryjnym przejmowaniem ruchu, nic w rodzaju carp nie było wtedy jeszcze nawet na horyzoncie. W tamtych czasach, „zimny serwer” w gotowości był częstym schematem dla wielu rzeczy wymagających dużej dostępności. Miałem problemy wydajnościowe. Kiedy pojawiło się OpenBSD 3.0 z pierwszą nkarnacją pf, natychmiast go wypróbowałem. Było bardzo szybkie – tak w działaniu, jak i w czasie potrzebnym, by cały system sie zawiesił. W trakcie długiej sesji debugowania ja i Daniel Hartmeier znaleźliśmy źródło problemu, po czym je naprawiliśmy. Odtąd używałem pf zamiast ipf, a te same maszyny, które miały podniesione zużycie CPU godzinami każdego dnia, teraz szczytowały z maksymalnie 10% obciążeniem CPU. Napisałem maila na listę misc@, opisując krótko całą historię, a w zamian otrzymałem od theo zaproszenie na zbliżający się hackathon. Od tamtego momentu nie spuścili mnie jeszcze ze smyczy :)

Szczerze, poza niesamowitą wiedzą techniczną w grupie hakerów OpenBSD, to po prostu niesamowity tłum ludzi, z którymi się fantastycznie pracuje, i nie tylko pracuje. Nadal zaszczytem jest dla mnie bycie częścią tego.

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

Raczej nie kręci mnie marketing, ale szybko mogę wymienić powody, przez które używam OpenBSD prawie wszędzie.

Niezawodność.

Znaczy to więcej, niż tylko „nie zawieszać się”. Prowadzenie serwisów wystawionych bezpośrednio w internet, często z dużymi wymaganiami odnośnie dostępności oznacza, że twój stos oprogramowania powinien po prostu działać – cały czas oraz bez niespodzianek. „Po prostu działa” zawiera w sobie pewien ważny aspekt – niemożność przejęcia przez zewnętrznych aktorów. Bezpieczeństwo jest aspektem krytycznym.

Niezawodność oznacza również, że stos oprogramowania musi być przyjazny użytkownikowi w sensie przewidywalność przez administratora – nikt nie chce nagłych restartów, nagłej śmierci demonów dostarczających krytycznych usług etc. Spójność w systemie OpenBSD gwarantuje, że cokolwiek mam do zrobienia przy bazowym systemie, nie sprawi niespodzianek i będzie działać dokładnie tak, jak tego oczekuję (a drobne odstępstwa od tej reguły są naprawiane zaraz po ich napotkaniu). Wiele znaczy dodanie jakiegoś drobiazgu do systemu produkcyjnego bez obaw o to, że spowoduje on kompletną zapaść tegoż systemu.

Mógłbym tak pisać w nieskończoność, bo wiele jest takich pozytywnych aspektów. Zanim odbiegnę zbyt bardzo od tematu, ważne jest oczywiście bezpieczeństwo, którego dostarcza OpenBSD. Nie muszę się martwić o to, że moje maszyny zostaną przejęte w chwili, gdy popijam piwo z przyjaciółmi, śpię albo siedzę w samolocie. Głębsze podejście OpenBSD do tego problemu, wliczając w to mnogie techniki prewencyjne, zbiera tu dobre żniwo, nawet jeśli chodzi o oprogramowanie firm trzecich, które jest z reguły niskich lotów pod kątem bezpieczeństwa, za to trudne do uniknięcia – jak php, będący wiodącym przykładem.  Otrzymanie tego wszystkiego bez dużej strat na wydajności jest naprawdę imponujące.

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

Tak, w pracy moja stacja robocza działa pod kontrolą OpenBSD (a nawet serwuje moją prywatną stronę), moje wszystkie laptopy również. Mam pracę do wykonania i nie mogę sobie pozwolić na marnowanie czasu na zabawę z systemem operacyjnym, musi on po prostu działać. OpenBSD mi to zapewnia.

Większość ogromnej ilości maszyn w pracy też działa pod kontrolą OpenBSD. Fakt, że nie potrzebują one być niańczone oraz że wymagają jedynie raz na jakiś czas uwagi w trakcie procesu aktualizacji, robi ogromną różnicę. Oczywiście mamy odpowiedni monitoring na wypadek ewentualnych niespodzianek, ale generalnie maszyny pod kontrolą OpenBSD nie wymagają sporo ręcznego serwisowania.

Jest tego dużo więcej. Nawet mój mały serwer multimedialny w domu ma OpenBSD. Mikrokontrolery sterujące zamkami w pracy interfejsują się z OpenBSD, jak również i te sterujące światłem. Wszystkie pieniądze przechodzą przez OpenBSD – interfejs bankowy na nim działa. Tak jak i wszelkie płatności, łącznie z generowaniem faktur.

Myślę, że określenie OpenBSD jako mojego głównego systemu, jest poprawne.

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

Tak, jak wspomniałem wcześniej, moim punktem wejściowym był pf – najwyraźniej byłem pierwszą osobą, która wypróbowała go w większym produkcyjnym środowisku.

Popularne powiedzenie w kręgach OpenBSD mówi, że osoby dostają konto, kiedy jakiś deweloper będzie wystarczająco poirytowany ilością łat, jakie musi za tę osobę zacommitować. W pewnym momencie dostajesz bit commitowania, by robić to samodzielnie, czyli aby zaangażować się w projekt, po prostu trzeba się angażować – naprawiać problemy, irytujące rzeczy oraz niespójności w momencie, gdy je napotkasz, a powstałą łatkę wysyłać na listę mailingową tech@, analogicznie do brakujących funkcjonalności. Twoje łatki albo zostaną zacommitowane albo dostaniesz cenną informację zwrotną.

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

„Wszystko związane z siecią” – to chyba najbardziej trafne określenie.

Kiedy trafiam na niedociągnięcia (oczywiście z mojego osobistego punktu widzenia), staram się nad nimi pracować na ile jest to możliwe, przykładowo – wsparcie dla szablonów disklabel w autoinstall, które dodałem początkiem tego roku celem umożliwienia niestandardowego partycjonowania.

7. Ile czasu zajmuje Ci praca przy projekcie OpenBSD?

Nie księguję spędzonego czasu, przecież hackowanie OpenBSD ma być zabawą. Ilość czasu, jaką spędzam nad projektem OpenBSD mocno się waha. Przez kilka ostatnich miesięcy tego czasu było niestety bardzo bardzo bardzo mało z powodów dużej ilości pracy oraz pewnych problemów zdrowotnych. Mam nadzieję, że wkrótce ulegnie to zmianie.

W starych dobrych czasach(tm) organizacja czasu była dużo łatwiejsza: napisałem wstępną implementację bgpd od zera nad buforem, szablony imsg oraz privsep, utrzymywanie sesji przez  keepalives itd – w 2 lub 3 tygodnie. Przez ostatnie kilka lat większe projekty działy się głównie w trakcie lub w okolicach hackathonów. Są one bardzo ważne dla OpenBSD. Postęp, który można osiągnąć wrzucając naszą grupkę do jednego pokoju na kilka dni, jest niesamowity. Jest to też świetna zabawa.

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 mamy ogromnego „procesu” wykutego w skale. Nie zapominaj o tym, że koniec końców jesteśmy ochotnikami i wykonujemy tę pracę dla zabawy. OpenBSD nie jest samotną wyspą, zatem pojawia się  jakiś wpływ z zewnątrz, jak również jest on wywierany przez nas w przeciwną stronę. Założę się, że dostałbyś przynajmniej 10 różnych odpowiedzi (będących tylko przykładami) na pytanie zadane 10 deweloperom dotyczące tego, jak OpenBSD wpłynęło na świat zewnętrzny. Analogicznie, prawie każdy deweloper wnosi własny bagaż doświadczeń i pomysłów do projektu OpenBSD.

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 chyba najbardziej dumny jestem z pf, biorać pod uwagę to,  jak daleko zaszedł. Nie potrafię wyobrazić sobie powstania czegoś tak fascynującego jak pf, w żadnym środowisku innym niż OpenBSD – sama liczba deweloperów, którzy przyczynili się już do jego rozwoju robi bardzo duże wrażenie. To znacznie więcej niż surowe fakty, to środowisko bystrych ludzi, z którymi łatwo (i zabawnie!) się pracuje.

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

Prognozowanie jest zawsze trudne. Zwłaszcza, gdy dotyczy nietrywialnych przedziałów czasowych. Nie widzę żądnych symptomów wskazujących na to, że OpenBSD może stracić na tempie rozwoju, wręcz odwrotnie. Jestem pewien, że OpenBSD nadal będzie OpenBSD i nie pozwoli kierować swoim rozwojem jakiejś dużej korporacji. Generalnie, postawi na wolność w robieniu „tego co potrzebne” wbrew komercyjnym celom biznesu.

W najbliższym czasie jednym z większych wyzwań będzie lepsze wsparcie dla SMP w kernelu. Jeśli chodzi o mnie, nikogo nie zaskoczy, jeśli dodam, że w stosie sieciowym. Już wykonano znaczny postęp w tym zakresie, do czego niestety nie miałem jeszcze jak się przyczynić.

Widzę potrzebę ulepszeń w obszarze systemu plików, przede wszystkim potrzebę większej elastyczności.

W dalszej perspektywie bardziej liczą się ogólne trendy, niż te specyficzne dla OpenBSD. Widzimy jak środowisko, w którym operujemy, zmienia się obecnie dość drastycznie. Informatyka dorasta, pewne dotychczas „wyryte w skale” zasady stają się mniej ważne, część z nich wkrótce stanie się bez znaczenia. Szeroko przyjęta linia myślenia, że konfiguruje się kilka maszyn dla pewnego zadania, a następnie co parę lat robi się to ponownie – już zanika. Potrzeba konieczności częstej wymiany sprzętu zanika (tam gdzie jeszcze całkiem nie wymarła), ponieważ nie musisz już kupować nowego co parę lat powodu wymagań co do wydajności, przynajmniej w większości obszarów. Trend w kierunku wirtualizacji po części jest tego przyczyną – obecnie nawet serwer startowy jest nadmiernie napakowany względem stawianych wymagań, zatem jednym z optymalnych sposobów wykorzystania jego zasobów jest wirtualizacja. Przewiduję, że obecne konfiguracje będą żyły ZNACZNIE dłużej, niż jesteśmy przyzwyczajeni. Wirtualizacja ma jeszcze jeden efekt uboczny – przerzucanie systemów z jednej fizycznej maszyny na drugą jest łatwe, podczas gdy instalacja od zera na nowym sprzęcie, zaraz po jego wymianie, była dotychczas standardowym rozwiązaniem. Zobaczymy znacznie dłużej żyjące instalacje, nie ze względu na dłuższy czas życia sprzętu, a z powodu nowego poziomu wirtualizacji oraz przerzucania systemów z nowego/innego hosta/platformy. To sprawia, że serwisowanie staje się większym problemem. Po paru latach sstemy są tak zaśmiecone, że nikt nie jest w stanie pojąc co się z nimi dzieje tak naprawdę. Jest to problem pogłębiający się wraz z wiekiem każdej instalacji. Prostota, spójność i fantastyczna infrastruktura administracyjna OpenBSD bardzo pomagają w tym zakresie.

Jednocześnie, to co było wyjątkowe w informatyce zaczyna przenikać do wielu innych obszarów. Widzimy komputery sterujące rzeczami codziennymi – od pociągów po samoloty, od twojego systemu ogrzewania po elektrownie czy światła uliczne. Szczególnie tam nie widać częstych aktualizacji wdrożonych konfiguracji – samolot zwykle lata przez ponad 20 lat, a pociąg często ponad 40, zanim przechodzi w stan spoczynku. Nawet dzisiaj mamy elektrownie wciąż kontrolowane przez zabytkowe PDP11. W tych przypadkach użycia rzadko spotyka się zespół administratorów zajmujących się tymi komputerami, są one po prostu częścią większego planu. W tej samej chwili coraz więcej tych rzeczy zostaje podpiętych do sieci, co z kolei sprawia, że bezpieczeństwo jest jeszcze ważniejsze, niż do tej pory. O ile źle jest utracić kontrolę nad stroną internetową, to utrata infrastruktury dostarczającej prąd, pociągu lub samolotu, okazuje się ZNACZNIE gorsza.

Rosnący trend produktywizacji sprzętu informatycznego na obszarach embedded, gdzie nie ma typowego zespołu administratorów zajmujących się aktualizacją oprogramowania, jest związany z wieloma konsekwencjami. Nie musi to być wcale coś tak ważnego, jak sieć dostawy prądu. W większości przypadków będą to dużo mniej widoczne systemy, które powinny stać się znacznie bardziej „samo-serwisujące” w sensie automatycznego aktualizowania, zwłaszcza łatek bezpieczeństwa. W elektrowni, samolocie, pociągu jest przynajmniej pewien zespół ludzi monitorujących cały proces (mam naprawdę ogromną nadzieję, że tak jest…), lecz zabraknie go w mniej widocznych przypadkach. Dla większości z tych scenariuszy alternatywami nie będą „automatyczne serwisowanie” albo „ręczne serwisowanie”, dla wielu z nich jedyną opcją będzie „brak serwisowania” (można powiedzieć, że nie mam złudzeń).

Pomijając wszystko, co powiedziałem – automatyzacja wcale nie musi być wbudowana w system bazowy, więc znaczna jej większość może być zaimplementowana w sposób niezależny od systemu, oczywiście uwzględniając specyficzne dla danego systemu elementy po to, by móc się nim również zająć. Jednakże sam system musi być przyjazny takiej automatyzacji. Zgadłeś – OpenBSD już jest. Nadal są miejsca, w których można jeszcze wprowadzić ulepszenia i spodziewam się, że fragmenty dotyczące automatyzacji nabiorą dużego znaczenia w następnej dekadzie. Myślę, że OpenBSD jest na to bardzo dobrze przygotowane.

Skomentuj

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