Starred articled from my feed reader

Mütze auf, Mütze ab, Sonnenhut für Mütze eintauschen, eincremen, Regenjacke drüberziehen, Schwitzen und wieder ausziehen - der ganz normale Ablauf in der ersten Stunde unserer Wanderungen - eigentlich egal wohin. Und dann dieser Wind, der selbst das Surfboard unter dem Auto wegfegt, sodass es von nun an nachts immer mit in den Van - und somit auch ins Bett - genommen werden muss. Einmal gab es so heftige Sturmböen, dass wir unsere Fahrt unterbrechen und den nächstgelegenen Campingplatz aufsuchen mussten. Ein Glück, dass wir unsere Reise nur von einen Tag auf den nächsten planen und uns somit flexibel an Wetterbedingungen anpassen können- bis auf den Kajak Trip im Milford Sound, wo wir letztendlich im strömenden Regen 3,5h auf dem Wasser paddelten - aber wo kein Regen, da auch keine Wasserfälle.

Gerade sitzen wir an einem wunderschönen Fluss in Wānaka und lassen unsere letzten vier Wochen Revue passieren. Wir verließen Christchurch Mitte November mit dem Ziel, den mittleren und südlichen Teil der Südinsel zu erkunden. Die Südinsel ist (laut Wikipedia) fast halb so groß wie Deutschland, hat aber nur so viele Menschen wie Köln (gute 1 Million). Der Grund für die dünne Besiedlung im Vergleich zur kleineren Nordinsel ist vor allem die Bergkette, welches die regenreiche Westcoast vom Rest der Insel trennt. Nur ein paar Pässe verbinden den Osten und den Westen, und während Matthias und ich hier sitzen und auf die zurückgelegten Kilometer schauen, haben wir uns entschieden, nicht noch über die Westcoast zurück nach Christchurch zu fahren, sondern auf dem direktesten Weg durch das Inland. Zwar haben wir noch eine Woche Zeit bis Weihnachten, aber die ereignisreichen letzten Wochen machen sich bemerkbar. Nicht nur wir, sondern auch unser Campervan Herbie brauchen nochmal ein paar Tage Pause und Pflege, bis es nach Weihnachten mit unseren Freunden Tobi und Selma weitergeht.

Insgesamt haben wir uns gut an das Leben auf so engem Raum gewöhnt (mit dem Surfboard ist es noch enger), auch wenn wir ständig am Suchen, Putzen und Wegräumen von Dingen sind. Wehe, die Kopfhörer kommen nicht an den designierten Ort zurück oder der Hut hängt nicht am richtigen Haken! Ordnung hat hier wirklich nochmal einen anderen Stellenwert erreicht. Klassiker, die ich immer suche: meinen Schlüssel, Sonnenbrille und Ladekabel. Matthias sucht dauernd seine Kopfhörer oder seine (zweite) Mütze. Verlorengegangen ist bisher aber nie was. Auch das Fahren im Linksverkehr ist mittlerweile normal geworden und Herbie kämpft sich tapfer die Berge hoch. Da es hier nur selten mehrspurige Straßen zum Überholen gibt, unsere Lieblingsgeschwindigkeit aber bei 80km/h statt 100km/h liegt (nur so schnell fahren, wie das Auto keine Geräusche von sich gibt...), ist es hier üblich, bei Gelegenheit an die Seite zu fahren und die Autoschlange hinter einem durchzulassen. Häufig wird sich dann mit einem Hupen oder kurzem Warnlicht bei einem bedankt – die Kiwis sind natürlich an die alten, langsamen Camper gewöhnt. Wir haben bisher hauptsächlich positive Erfahrungen mit den Locals gemacht. Auf einem Freedomcamp (Campingplatz für alle, die selfcontained sind, siehe letzter Blogeintrag) in der kleine Gemeinde Lumsden kam neulich sogar die Feuerwehr vorbei und hat weihnachtliche Schokolade an uns Touristen verteilt.

Die steigenden Temperaturen und das langanhaltende Tageslicht versetzen uns nur wenig in Weihnachtsstimmung, aber immerhin haben wir einen kleinen Tee Adventskalender im Supermarkt gefunden. Wenn beim Einkaufen dann Weihnachtslieder gespielt werden und die festliche Dekoration zwischen dem Sommerobst liegt, kommt es einem kurz etwas verkehrt vor. Die Kassierer sind übrigens meistens sehr daran interessiert, wie uns das Land gefällt und ob wir eine gute Zeit haben -während ein zweiter Mitarbeiter unseren Einkauf in die Taschen einsortiert. Anfangs habe ich noch versucht, das selber zu übernehmen (schließlich sind wir Aldi-Kassen gewöhnt und auf Hochgeschwindigkeit beim Einräumen trainiert), aber das verwirrt die freundlichen Kassierer hier und die Situation wird "akward". Stattdessen ist also Zeit, sich auf das Gespräch einzulassen. Wir wurden anfangs gewarnt, dass Einkaufen in Neuseeland deutlich teurer sein soll, als in Deutschland. Dies können wir nur bedingt bestätigen- während Matthias spezieller Diät aufgrund seiner Verdauungsbeschwerden waren die Einkäufe schon teurer (wir kauften aber auch 20 Paprika, kiloweise Nüsse und lokalen Lachs, alle paar Tage), aber durch die eh schon hohen Preise in Deutschland hatten wir schlimmeres erwartet. Unser Go-To hier sind übrigens Kiwis und Avocados, beides wird direkt in Neuseeland angebaut und ich habe selten so schnell eine Zuneigung zu einem Obst entwickelt, wie jetzt zur Kiwi! Den Biomüll trennen wir im Van zwar noch, müssen es dann schweren Herzens aber immer mit dem restlichen Haushaltsmüll gemeinsam entsorgen. Eine Sache, die wir leider nicht nachvollziehen können. Lediglich Dosen, Glass und manchmal Plastik kann man recyceln. Was die Neuseeländer dafür aber richtig drauf haben ist der Zugang zu Trinkwasser! Sowohl in Cafés und Restaurants kriegt man immer und soviel man will Wasser bereitgestellt und auch Trinkwasserbrunnen sind gut auffindbar. Meistens bei den öffentlichen Toiletten, und die gibt es wirklich an jeder Straßenecke und auch auf den allermeisten Wanderrouten (teilweise sogar auf dem Gipfel)! Wie wir mithilfe der App OsmAnd Trinkwasserquellen auffinden (auch in Deutschland), hat Matthias in einem Post auf seiner Webseite mal zusammengefasst.

Der einzig verbindliche Termin auf unserem Roadtrip war Matthias Arzttermin in Wānaka. Wie im letzten Eintrag beschrieben sind wir immer noch auf der Suche nach einer Erklärung für seine Verdauungsprobleme und hatten daher große Hoffnung für das Gespräch mit dem Gastroenterologen. Da die Klinik in Christchurch uns entweder einen Termin im März 2025 in Christchurch geben konnte oder aber in der Partnerklinik in Wānaka Ende November 2024 nahmen wir natürlich den früheren Termin wahr uns planten die Reise drum herum. Letztendlich hat Matthias ein spezielles Antibiotikum bekommen, was er vor einigen Tagen fertig eingenommen hat und nun schauen wir, wie es sich entwickelt. Sein Energielevel hat sich aufjeden Fall verbessert, was durch seine Wanderlust bemerkbar ist. Glücklicherweise ist Wānaka eines der schönsten Orte auf der Südinsel und früher oder später wären wir sowieso hergekommen. Auf dem Weg dorthin stoppten wir in Peel Forest, Lake Tekapo und dem Mt. Cook Nationalpark.

Lake Tekapo ist berühmt für seine malerische Landschaft, die vorallem im November durch das Blühen der Lupinen bekannt ist. Hier hatten wir gutes Timing, denn wir kamen genau rechtzeitig, um diese zu erleben!

Im Mount Cook Nationalpark haben wir eine der schönsten Tageswanderungen bisher gemacht – den Hooker Valley Track, der mit Hängebrücken und Boardwalks zu einem Gletschersee führt. Hier flog uns aber auch das Surfboard um die Ohren und wir reisten aufgrund des schlechten Wetters schneller weiter, als gedacht.

Der Aufenthalt in Wānaka beschränkte sich vorerst auf den Arzttermin und wir fuhren weiter nach Dunedin, da wir ohnehin ein zweites Mal planten herzukommen. Dunedin ist nach Christchurch die größte Stadt auf der Südinsel und wir waren positiv überrascht, wie schön es doch war. Matthias behauptet, dass der Farmersmarkt hier der tollsten Markt ist, auf dem er jemals war (ich stimme zu) und wir fuhren auf die Spitze der Halbinsel bei Dunedin, um die kleinsten Pinguine der Welt zu sehen. Mit einer geführten Tour sahen wir knapp 250 Blue Penguins zu, wie sie nach Einbruch der Dunkelheit ihren Weg zurück an den Strand und zu ihren Nestern fanden. Das Gebiet ist seit einigen Jahren nur noch über geführte Touren erreichbar und die Pinguin Population konnte deutlich wachsen. Ein Positivbeispiel für Ökotourismus (mehr Infos hier). Außerdem konnte ich in Dunedin nochmal surfen gehen; die Gegend wird aufgrund der zahlreichen Surfstrände auch “Cold Water Bali” genannt. Leider waren die Bedingungen nicht so gut und Windsurfer hatten deutlich mehr Spaß.

Von der Ostküste durchquerten wir den Süden einmal bis nach Te Anau im Westen. Te Anau und das Fjordland mit Milford Sound ist die Heimat von gleich drei Great Walks - Neuseelands beliebtesten Wanderrouten (insgesamt gibt es davon neun). Wir planten, die erste Etappe des Kepler Tracks zu laufen und durch Zufall war an dem Tag auch ein Ultramarathon auf genau der Strecke. Während wir den Berg hochliefen kamen uns hundert Läufer entgegen, und jeden einzelnen von ihnen feuerten wir mit klappernden Wanderstöcken und Zurufen an. Zu sehen, dass Menschen die 60km in wenigen Stunden laufen, wofür eigentlich 4 Tage angesetzt sind, war für Matthias und mich ziemlich inspirierend und auch motivierend!

Te Anau ist außerdem der Anfangs- und Endpunkt für alle, die nach Milford Sound wollen. Der einzigartige Ort liegt am Ende einer 2 stündigen Autofahrt, nur eine Straße führt dort hin und auch wieder zurück. Man kann die unglaubliche Gegend in Milford Sound entweder von einem Boot aus entdecken, oder aber vom Kajak aus! Wir entschlossen uns für letzteres und konnten einen kleinen Teil des besonderen Ortes aus ganzer Nähe betrachten - eines unserer Highlights bis jetzt, auch wenn es fast durchgehend geregnet hat. Besonders gefallen hat mir die Geschichte, wie dieser magische Ort aus Sicht der Māori entstanden ist. Diese hat uns unsere Tourleiterin erzählt, während wir mit unseren Booten ein Raft bildeten und eng beieinandersaßen. Hier könnt ihr die Geschichte nachlesen. Es ist nicht einfach, Milford Sound zu beschreiben. Die meterhohen steilen Felswände und hunderte von Wasserfällen, Vögel, Pinguine, Delfine, Bäume und Pflanzen die es nur dort gibt.

Leider sind wir nach der Kajakfahrt auch direkt wieder zurück nach Te Anau gefahren. In Milford Sound direkt gibt es nur eine Unterkunft, und die war seit Wochen ausgebucht. Und wenn man erstmal nass ist wird man im Van auch nicht wirklich trocken, sodass wir den langen, steilen Weg am Stück zurück gefahren sind. Die Straßen sind teilweise wirklich abenteuerlich: Aus dem Nichts ein Schlagloch, eine Delle, Schotter. Bangen, ob wir es im zweiten Gang den Berg hochschaffen. Wir versuchen, nicht jeden Tag zu fahren und wenn dann nicht länger als 2-3h am Stück. Weder Matthias noch ich genießen das Autofahren zu sehr und wir sind sehr froh, uns so viel Zeit nehmen zu können. Autofahrten werden häufig von dem Hörspiel der Herr der Ringe begleitet, was durch die Szenerie noch lebendiger erschien. Das erste Buch haben wir schon fertig und schauen derzeit den Film dazu, in dem viele Szenen ja hier in Neuseeland gedreht wurden!

Zuletzt besuchten wir noch Queenstown, die wohl bekannteste Stadt für Outdoor Enthusiasten! Von Bungee-Jumping über Jetski fahren und Helikopter fliegen kann man hier wirklich alles erleben. Die Stadt liegt zwischen riesigen Seen umgeben von hohen Bergen, die zurecht “the remarkables” heißen. Wir blieben nur eine Nacht, Queenstown ist wirklich unglaublich teuer und so busy! Was ich mir nicht entgehen ließ: den beliebtesten Burger der Stadt, für den man gerne mal 15min ansteht und wo anscheinend immer eine Schlange ist! Zurecht, es war wirklich lecker!

Von Queenstown waren es dann nochmal 1,5h bis wir zurück in Wānaka waren und den Kreis sozusagen geschlossen haben. Ein Must Do stand hier noch auf unserer Liste: Roys Peak- eine beliebte Wanderung für den Sonnenaufgang. Um 2 Uhr klingelte der Wecker, um 3 Uhr wurden die Kopflampen angeknipst. 3h, 7km aber 1200 Höhenmeter. Irgendwie war ich froh, im Dunkeln nicht gesehen zu haben, wo ich eigentlich hinmuss. Lediglich die Lichterkette an Menschen, die uns im Dunkeln schon einige Meter voraus waren, zeigten den Weg. Um kurz vor 6 ging die Sonne auf und wir wurden mit einer der spektakulärsten Aussichten belohnt, die wir bis jetzt in Neuseeland hatten. Ein besonderer Abschluss für diesen wunderbaren Roadtrip.

Heute haben wir uns einen Pausentag gegönnt, sind in das “Lieblingscafe” neben unserem Campingplatz gegangen (Matthias für den Kaffee, ich für di vermutlich leckersten Pain au Chocolate ausserhalb Frankreichs). Nach jeglicher Hin und Herüberlegung entschlossen wir uns, morgen über den gleichen Weg nach Christchurch zurückfahren. So wenig Höhenmeter wie möglich, so direkt wie möglich. Somit haben wir genug Zeit, in Christchurch anzukommen und notwendige Dinge zu erledigen. Ausserdem können wir uns auf die Ankunft von Tobi und Selma freuen, denn damit fängt auch der zweite Teil unserer Reise an: gemeinsam wollen wir den Great Walk im Abel Tasman Nationalpark machen und mit der Fähre auf die Nordinsel übersetzen. Mehr geplant haben wir, mal wieder, noch nicht. Doch bisher sind wir damit auch sehr gut gefahren 😊 Euch eine wunderschöne Adventszeit und gemütliche Weihnachtstage, wir melden uns spätestens im neuen Jahr (in welches wir übrigens zu allererst starten!!) wieder.

Matthias und Maike

I do not know about you, but I usually have a water bottle with me regardless where I go. I love to refill whenever possible. I dislike buying bottled water in countries where perfectly fine drinking water comes out of the tap.

It boggles me how in Europe they charge for water in cafes and restaurants. Also, it is considered not appropriate to ask for tap water in those places. Currently, I am in New Zealand and they provide you with free water in most places like libraries, cafes and restaurants. (The same goes for toilets by the way. I have never seen so many public, clean and free toilets as I did here in New Zealand.)

Being away for home, on travel or on multiday hikes, I will run into the need of refilling my water bottle(s) eventually. In this post I am going to show you how I find drinking water on a map called OpenStreetMap (OSM).

OSM is an online map which can be edited by anyone. It's kinda like Google Maps and Wikipedia combined. Since it is free and very detailed, OSM provides the data behind a lot of map apps like Komoot, MAPS.ME or OsmAnd Maps (I prefer the latter). It excels in every application except car navigation and easy search. But in many countries it's probably the best resource to find drinking water, if you know how to look for it.

What to look for?

To search OSM one needs to understand how OSM represents objects on the ground, for example a water tap or a well, using tags.

Map features and tags

In order to describe a physical feature on the map, OSM uses tags consisting of a key and a value. For example, a place to get drinking water from is tagged with the key amenity (facilities used by people) and the value drinking_water. A feature usually has a primary tag stating the main use and many secondary tags to describe additional properties. So far so good... If that was the only tag needed to find drinking water sources this post would end here - but there are other tags which represent sources to get drinking water from. More on them next.

Note: In OSM tags in use and their meaning have evolved over time. Both their usage and meaning can very depending on their context.

Tags related to drinking water

First lets have a look at the most important and common one: Map features (primary tags) representing drinkable water sources are mainly amenity=drinking_water, man_made=water_tap or natural=spring.

The most important additional property (secondary tag) is drinking_water=yes (amenity=drinking_water implies dinking_water=yes).

There is also man_made=water_well and man_made=spring_box for structures which are used to get access to groundwater and to catch water from natural spring respectively.

Let's have a look at all the possible tags related to drinking water in OSM below. The descriptions were taken directly from the OSM wiki.

Drinkable (primary tags)

amenity=drinking_water

A drinking water source which provides potable water for consumption

amenity=water_point

Places where you can get larger amounts of "drinking water" for filling a fresh water holding tank, such as found on caravans, RVs and boats

man_made=water_tap

Publicly usable water tap

man_made=drinking_fountain

Provides a small jet of drinking water

Usage discouraged. amenity=drinking_water should be used instead. fountain=* can be used to describe to type of type of fountain (e.g. fountain=bubbler or fountain=drinking).

natural=spring

A place where ground water flows naturally from the ground

Drinkable (secondary tags)

drinking_water=yes

Indication whether a feature provides drinking water

drinkable=yes

Usage discouraged. drinking_water=yes should be used instead.

drink=*

Describes if (and optionally how) a certain drink is available at an amenity or shop

fountain=drinking

For generic drinking water fountains

fountain=bubbler

For fountains which slightly jet the emitted water in the air for purpose of easy drinking

Maybe drinkable

man_made=water_well

A structural facility to access ground water, created by digging or drilling

man_made=spring_box

A structure designed for protecting and catching groundwater from a natural spring

Usually in combination with natural=spring

Probably not drinkable

amenity=fountain (Primary feature)

A fountain with cultural, decorative, or historical significance or which serves a recreational purpose

Additional property could be fountain=drinking

watering_place (Primary feature)

A place where water is contained and animals such as horses can drink

How to search?

Here comes the hard part. Now that we know what to look for, the question is how do we look for it? There is not a single way to do it, and none are as user-friendly as typing something into Google Maps, but they are more powerful.

overpass turbo

Following query to the overpass turbo service will find every possible drinking water source in your area-of-interest. Go ahead and execute this query on the overpass turbo website.

[out:json];
(
  node[amenity=drinking_water]({{bbox}});
  node[amenity=water_point]({{bbox}});
  node[man_made=water_well]({{bbox}});
  node[man_made=spring_box]({{bbox}});
  node[man_made=water_tap]({{bbox}});
  node[man_made=drinking_water]({{bbox}});
  node[fountain=drinking]({{bbox}});
  node[fountain=bubbler]({{bbox}});
  node[natural=spring]({{bbox}});
  node[drinking_water=yes]({{bbox}});
  node[drinkable=yes]({{bbox}});
);
out body;

Note: node stands for features which are represented on the map as a point instead of a line or polygon. bbox stands for bounding box, which is the visible part of the map displayed on the overpass turbo website.

Next step could be to export these points and open it in your favorite map app. Of course that is a tedious process, but might be worth it depending on what you are going to do.

OsmAnd Maps

The complexity due to the sheer number of possible tags and combination of these is the reason why many apps, like the ones I listed in the introduction, typically hide tags from the user and present them with simple categories which can be displayed on the map. Of course, behind the scenes, these categories are just a set of tags. Sometimes it is not possible to do complex searches containing a custom selection of tags in those apps. In OsmAnd Maps one can create custom categories by clicking on the search symbol, then on Categories and after scrolling all the way down on Add custom category. Unfortunately, it's still mediated by what map features (tags) OsmAnd Maps choose to display to the user. On the Add custom category screen you can select Drinking water, Water point, Water well, Spring and Water tap (just search for water and spring) to be combined in to one category which you can display on the map anytime in the future.

In most cases like touring a city or traveling in a van it is sufficient. For a multiday hike though, I like to get a comprehensive list of all possible water sources using the overpass turbo serve with the query of the previous chapter.

How to map?

Now that we know how to search for drinking water places what happens if we stumble upon a new place in the real world which is not on the map yet? The beauty of a crowdsourced and open licensed project like OpenStreetMap is that we can contribute to it and improve it for everybody coming after us!

To add a new place to the map you need an OSM account. The easiest way to map is to use the ID editor in the browser. Alternativly you can also use apps like OSM And Maps (Android and iOS) or OsmoTagger (iOS only). For instructions of how to map using OSM please have a look at the guide by learnOSM.

Lets have a look at which tags some types of drinking water sources should have.

How to tag a drinking water fountain?

Drinking water fountains have as primary tag amenity=drinking_water. If the fountain emits a jet of water into the air you can use the tag fountain=bubbler. That is it! Easy as pie.

If the feature offers an easy way to fill a bottle one can add the tag bottle=yes.

How to tag a water well or spring box?

German forest accommodates many stone and wooden structures to catch groundwater from a natural spring, so called spring box or spring catchment. In Germany they are called Quellfassung but we usually just say Brunnen. But we use Brunnen also for water wells, which leads to confusion and possible mapping errors (at least I was confused). The difference between those two structures is that water "just flows" out of a spring box whereas water needs to get pumped out of water wells.

In OSM the tag (man_made=water_well) marks places for accessing groundwater. Spring boxes are mapped with man_made=spring_box. In the later case a combination with natural=spring usually makes sense.

In both cases drinking_water=yes or drinking_water=no can be used. There is also drinking_water=conditional to state that the water seems drinkable. If there is a label "No drinking water" because there is no official control, you can add the tag drinking_water:legal=no.

Another interesting additional attribute related to springs is seasonal=no/yes/winter/....

Appendix

That is all from my side. If you know of more relevant tags or interesting information regarding drinking water sources in OSM, please share it (talfus-laddus@posteo.de)!

In general the best resource about anything related to tags is usually the OSM wiki together with taginfo.

In Germany there is also a great initiative called Tip Tap to get places like restaurants and pharmacy to offer free refill of water bottles, put them on the map and end the feeling of not being welcomed to ask for drinking water at those places. "If an establishment (café, bar, etc.) participates in a water refill network – indicated by a visble sticker or sign" use the tag drinking_water:refill=yes.

Might the Map be with you!

Thanks to Maike, my partner, for proof reading this post, despite being very possible a boring post.

I love the libraries in New Zealand. They are true community spaces!

Today I spend the whole day in one of the many libraries in New Zealand. A place where I witnessed a play for children (and their parents for that matter), a group of elderly women getting together for a round of Scrabble and a guy on a sewing machine right next to a 3D printer. How cool is that? It reminds me a bit of Maker Spaces in Germany. The libraries in New Zealand are not just about books, they are about bringing people together by offering space and resources.

I myself worked on one of the provided external monitors with my own setup: a notebook, an external ortholiniar keyboard and an ergo touchpad. Of course, the Wi-Fi was free. People without their own computer have access to one of the library. Hell, they even have gaming PCs and a PlayStation with a big screen.

Some more details I loved: They offer drinking water, which is chlorine free, and ceramic mugs; They have a bookshelf with recently returned books to see what people have been reading lately; They have a table with a big puzzle where everybody can chime in.

And all of that is super accessible: I used the printer without signing up. But if you do, the membership is free and borrowing a book as well. Last but not least, there are always a couple librarians around offering help.

New Zealand libraries are great places!

Vor einigen Jahren bin ich auf YouTube auf eine dieser faszinierenden, inspirierenden und hoffnungsvollen Dokumentationen gestoßen. In dieser ging es um das Aufforstungsprojekt Hinewai auf Banks-Peninsula in Neuseeland. Die Halbinsel besteht aus wunderschönen rollenden Hügeln bewachsen mit grünem Gras und beweidet durch Schafe und Kühe. Diese Schönheit kriegt eine kleine Delle, sobald einem bewusst wird, dass Banks-Peninsula vor der Ankunft der Maori und der Europäer von der einen Seite zur anderen, von der Küste zum höchsten Punkt der Insel, komplett mit Wald bedeckt war. Wie sah es damals nur hier aus?

Einen kleinen Teil der Antwort findet sich in Hinewai. Gestern waren Maike und ich dort. Das 1250 Hektar große Naturschutzgebiet ist durch einige Wege allen frei und jederzeit zugänglich.

So schön die rollenden grünen Hügel auch sind, so können sie auch ziemlich rau sein, ziemlich exponiert: Sie bieten keinerlei Schutz vor Wind und Sonne. Sie sind karg. Es gibt kaum Wasser.

Sobald du hingegen in den Wald eintrittst, hast du das Gefühl, verschluckt zu werden. Hier ist es voll von Leben. Hier gibt es nicht einen Grünton, sondern unzählige. Es ist total leise. Zumindest bis du auf einen der vielzähligen Bäche und Wasserfälle stoßt. Teilweise fühlt es sich an, wie ein Regenwald.

Die 40 Minütige Doku zeigt all dies und noch so viel mehr auf eine tolle Art und Weise. Sie zeigt aber auch die Menschen, die das Projekt verwirklichen. Und diese sind genauso inspirierend wie die Renaturierung. Einer davon ist Hugh. Hugh ist seit der Gründung 1987 Manager des Gebietes und er ist in der Begegnung genauso wie im Interview. Gerade als wir Hinewai verlassen wollten, sind wir ihm begegnet, wie er sein Fahrrad den Weg zur Straße hochschob. Er ist auf dem Weg zu einem Aussichtspunkt, um eines seiner regelmäßigen Fotos vom ganzen Tal zu machen. 15 Minuten später überholten wir ihn dann im 2. Gang auf der steilen Bergstraße, die er mit seinem Fahrrad bewältigte!

Alles Liebe,

Matthias und Maike

Drei Wochen sind wir nun schon auf der Südinsel Neuseelands; 23 Tage, in denen wir uns bei Liz und Tom ein (temporäres) Zuhause eingerichtet haben, zu welchem wir während unserer einjähriger Reise durch Neuseeland immer wieder zurückkehren können – als Home-Base sozusagen. Dass dies super wertvoll ist, wussten wir vor Ankunft schon und als wir von vertrauten Gesichtern am Flughafen empfangen wurden und bei eisigen Temperaturen einige Zeit später mit einem Tee vor dem Holzofen saßen, war die Dankbarkeit noch grösser. Richtig bewusst wurde es uns auch, als wir mit „Herbie Hunchback“, unserem Campervan, auf die Farm rollten und wir dank Toms Werkzeugen den ausgebauten Van noch auf unsere Bedürfnisse zuschneiden konnten und wir durch Liz das Fahren im Linksverkehr lernten. Am allerschönsten war aber, dass wir einfach Zeit hatten, um anzukommen und Vergangenes der letzten Jahre auszutauschen. Die Gastfreundschaft der beiden hat es uns einfach gemacht, uns trotz der alternativen Lebensweise, die Tom und Liz für sich gewählt haben, wohlzufühlen. Die beiden wohnen in ihrem ausgebautem Schulbus auf einem Grundstück einer Farm („The Land“) und haben sich von Warmwasser-Outdoordusche bis Gästezelt alles selber aufgebaut. Dazu gibt es Hühner und Hazy, die einjährige Hündin und Hüterin des Grundstücks. Gehütet werden muss aber eigentlich nichts, hier lässt jeder seinen Autoschlüssel in der Zündung stecken und zum Wäsche waschen läuft man beim Nachbarn einfach ins Haus. Matthias und ich haben die ersten 1,5 Wochen im Belltent geschlafen, wodurch wir uns schonmal an die Temperaturen und das Draußen-sein gewöhnen konnten.

Hier ist jetzt der Frühling angekommen, tagsüber wird es in der Sonne schon richtig heiß, nachts waren es für einige Tage noch Minusgrade und an einem Morgen war die kleine Farm mit Schnee bedeckt. Umso besser, dass wir die Abende zum Kochen und Erzählen im warmen Bus verbracht haben und Liz uns nie ohne Wärmflasche eine Gute Nacht wünschte. Den Jetlag hatten wir gut überstanden und entschieden uns, die ersten zwei Vormittage direkt mit zu verschiedenen Wochenendmärkten zu gehen. Hier verkaufen Liz und Tom französische Crêpes und wir konnten die Gegend kennenlernen und erste organisatorische Dinge wie Sim-Karte kaufen erledigen, und das Internet nach Campervans durchforsten. Nach sorgsamer Durchsuche von Facebook Marketplace schauten wir uns drei Vans an und entschieden uns letztendlich nach nur einer Woche für einen ausgebauten Mitsubishi. Unsere Kriterien waren neben einem dritten Sitz vorne auch ein hohes Dach zum Stehen, weniger als 300.000 gefahrene Kilometer, am liebsten manuell, ausgestattet mit Solar, „self contained“-Plakette und das alles bitte für höchstens 10.000 Euro. Dass wir irgendwo Abstriche machen mussten, wurde uns beim Anschauen der ersten Campervans schnell klar und da „Herbie“ fast alle Kriterien erfüllte, kauften wir ihn auch trotz einiger Mängel, was im Übrigen wesentlich unkomplizierter ist als in Deutschland und man mit einem ausgefüllten Dokument und Reisepass einfach zur nächsten Post laufen kann. In Neuseeland werden die Autos allerdings auch gefahren, bis der Reifen abfällt und auch bei den TÜVs wird gerne mal ein (oder beide?) Augen zugedrückt. Da weder Matthias noch ich Ahnung von Autos haben ging es also auch erstmal direkt zur Werkstatt, um Herbie auf Herz und Nieren zu prüfen, fielen durch den TÜV durch, ließen reparieren und erneut prüfen. Mit frischer WOF (Warrant of Fitness) ging es einen Tag später wieder zum Mechaniker, um die undichte Tür, den dauerhaft blinkenden Warnblinker und die Bremsen überprüfen zu lassen, die nach einer Fahrt mit angezogener Handbremse glühten (upsi). Somit war unser Auto-Budget auch ausgereizt und wir hoffen, dass uns der Van ohne größere Zwischenfälle nun für ein Jahr als Zuhause und fahrbarer Untersatz dienen wird. Der Vorteil eines Vans mit „self contained“ Plakette (dafür braucht man Dinge wie eine fix installierte Toilette und Spüle mit Frisch-Wasser und Abwasser-Container) ist es, dass man auf sogenannten „Freedom Camps“ umsonst stehen darf- und davon gibt es hier nicht wenige.

Zur Zeit befinden wir uns die zweite Nacht auf einem Freedom Camp in Akaroa auf einer Halbinsel nicht weit von Christchurch entfernt, denn vorgestern ging unser erster Roadtrip los! Bei Liz und Tom haben wir noch einige Verbesserungen am Van vorgenommen, Matthias hat ein Solarpanel installiert, die Toilette wurde mit Holz verkleidet und wir haben überall Haken verteilt und es uns mit Lichterketten gemütlich gemacht. Erst wenn wir richtig im Van leben, werden wir merken, was noch fehlt, was woanders verpackt werden muss und wie wir am effektivsten das Bett machen, ohne ständig alles von A nach B räumen zu müssen. Neue Routinen finden, während jeder Tag anders aussieht als der vorherige. Ich war selbst überrascht, wie schnell das Einleben bei Liz und Tom ging und es fiel nicht so leicht, die Farm zu verlassen. Aber jetzt, wo wir los sind, ist da wieder die Vorfreude auf das Unbekannte, neue Orte, neue Menschen. Alle, die wir hier bisher kennengelernt haben, strahlen neben ihrer Gastfreundschaft auch diese Liebe für ihr Land aus uns nennen uns Plätze, an denen wir vorbeikommen müssen und Dinge, die wir gesehen haben sollten. Trotz der vielen Touristen scheinen die Locals hier nicht von „uns“ genervt zu sein, sondern freuen sich und teilen ihre Lieblingsorte. Bei einer Einwohnerzahl von gerade mal 5 Millionen Menschen und knapp 2 Millionen Touristen, die jährlich das Land besuchen, ist dies schon besonders schön. Fun Fact: Da das Land so wenig Menschen hat sind die Handynummern hier auch kürzer (10 statt 12 Ziffern).

Während der vergangenen Woche waren wir durch die vielen Erledigungen häufig in Christchurch unterwegs, was wir mit Besuchen bei Liz Lieblings Hot Yoga Studio verbunden haben. Die dort erfahrene Entspannung war im nächsten Moment häufig wieder dahin, denn der Stadtverkehr mit einem Campervan und dann noch links ist nicht immer so einfach. Ich bin mir auch ziemlich sicher, dass ich Anfangs etwas Reiseübelkeit hatte. Als Beifahrer links einfach tatenlos rumzusitzen, und falsch herum in den Kreisverkehr zu fahren braucht einiges an Gewohnheit!

Und dann war da noch Matthias Geburtstag! Vielleicht erinnert, ihr euch, dass wir das Visum kurz vor seinem 30. Geburtstag beantragen mussten und hatten dann ein Jahr Zeit, um einzureisen! Ein paar Tage nach Ankunft haben wir also seinen 31. Geburtstag mit einer schönen Wanderung in Lyttelton, einem Besuch im Café und einer Hot Yoga Stunde verbracht. Und jetzt sitzen wir hier, auf einem Freedom Camp in Akaroa (siehe Karte) die Laptops geladen dank Solartechnik und müden Beinen, denn die sind an die Höhenmeter und Anstrengung der heutigen Wanderung noch nicht gewöhnt. Ab jetzt wollen wir auch so viel es geht wandern und uns auf unseren ersten mehrtägigen Great Walk vorbereiten- den Abel Tasman Track im Norden der Südinsel. Jeden Tag wird es etwas wärmer und durch die Zeitumstellung in der letzten Woche ist es auch noch hell zur Abendessenszeit um 19 Uhr. Sobald die Sonne weg kommt die Kälte, bei der einem nichts übrig bleibt, außer früh ins Bett zu gehen. Gut, dass wir somit viel Zeit zum Lesen haben und uns dem Buch Herr der Ringe widmen - denn diese Geschichte sollte man kennen, wenn man für ein Jahr in Neuseeland ist.

Alles Liebe und bis bald,

Matthias und Maike

Viereinhalb Jahre ist es her, dass ich in Frankfurt aus dem Flugzeug stieg und wieder deutschen Boden unter den Füssen hatten. Mit FFP2 Maske und Sandalen lief ich in der kalten Empfangshalle auf Papa zu, der einmal quer durch das Land fuhr, um mich in Zeiten der Unsicherheit und eingeschränktem ÖPNV nach fast zwei Jahren erstmals wieder in die Arme zu schliessen. Durch den -für mich- plötzlichen Beginn der Pandemie musste ich meine Yogalehrerausbildung, die ich zu dem Zeitpunkt auf einer kleinen Insel in Thailand absolvierte, abbrechen und flog mit einem der letzten Flieger zurück nachhause. Ich blickte auf ein Jahr Work and Travel in Kanada und anschließenden neun Monate Backpacken durch Südostasien zurück, in denen ich die Welt zu meinem Zuhause machte. Zurück in der Heimat musste ich erstmal in Quarantäne und hatte genug Zeit mir zu überlegen, wie es nun weitergeht. Der Wunsch, Physiotherapie zu studieren, kam während der Reise immer mal wieder auf und so bewarb ich mich bei mehreren Hochschulen in Deutschland, von Lübeck bis Rosenheim und alles dazwischen. Die Zusage für die Hochschule Heidelberg bekam ich im Mai 2020 nach Feierabend im Biomarkt, in dem ich zwischenzeitlich begonnen hatte zu arbeiten. In Heidelberg war ich vorher noch nie, aber eine kurze Internet Recherche ließ Vorfreude in mir aufkommen. Ich hatte genau ein Online WG-Casting und zum Glück bekam ich auch dort eine Zusage, sodass ich ein paar Monate später in die „Eppelvilla“ einzog, wie meine fünf Mitbewohner das alte Haus mit wildem Garten liebevoll nannten, ein. Dass ausgerechnet Matthias als einziger Mitbewohner bei meinem Einzug zuhause war und beim Ausräumen half (wobei entweder Papa oder er meinen Spiegel versehentlich zerbrach) und ich jetzt viereinhalb Jahre später mit ihm an meiner Seite in das einjährige Abenteuer Neuseeland aufbreche, hätte ich mir damals wohl nur schwer vorstellen können…

Das Physiotherapie Studium lief trotz der Corona-Einschränkungen weitestgehend glatt ab und auch Langeweile kam während der Lockdowns in der 6er WG nur selten auf. Mit jedem Tag, den ich in der Eppelvilla verbrachte, fühlte ich mich mehr zuhause und formte die Gemeinschaft um mich herum, nach der ich mich auf Reisen manchmal gesehnt hatte. Matthias und ich kamen im Dezember 2022 zusammen, und da wir als Mitbewohner schon das Zuhause teilten, änderte sich gar nicht so viel. Es wurde nur noch besser. Wir teilen die Liebe zur Natur und dem Draußen sein, schätzen die Freiheit unseres selbstbestimmten Lebens und ergreifen die Chance für Abenteuer. Matthias ist bereits für ein paar Monate in Neuseeland gewesen, und so war es für mich keine schwierige Aufgabe, ihm von meinem Plan und dem Wunsch nach Aufbruch zu erzählen. Wie viele, die schon dort waren, hatte auch er von dem Land geschwärmt und ich ahnte, dass es keiner Überzeugungskunst bedarf, wenn ich ihm einen einjährigen Aufenthalt in Neuseeland vorschlage. Auf einer Wanderung im schönen Lugano wurden unsere Pläne konkreter und wir entschieden uns, ein „Work and Travel“ Visum zu beantragen. Da das einjährige Visum inklusive Arbeitserlaubnis nur für Menschen bis 30 Jahre beantragbar ist und Matthias sich mit großen Schritten auf die 30 zubewegte, brauchte es allerdings einiges an genauer Planung. Zwei Wochen vor seinem Geburtstag füllten wir also die Onlinebewerbungen aus und bekamen ein paar Tage später die Zusage- ab dem Zeitpunkt hatten wir ein Jahr Zeit, um in Neuseeland einzureisen. Da für mich noch die Bachelorarbeit und das Staatsexamen anstand rückten weitere Vorbereitungen erstmal in den Hintergrund und ich konzentrierte mich auf den Abschluss des Studiums. Den erreichte ich im März dieses Jahres und fing auch direkt in einer kleinen physiotherapeutischen Praxis an zu arbeiten- einerseits, um Arbeitserfahrung zu sammeln und andererseits, um Geld für die Reise zu verdienen. Nebenbei unterrichtete ich einmal wöchentlich Yoga und konnte als studentische Hilfskraft weiterhin für die Hochschule arbeiten. Bei so einem „Vollzeit Job“ blieb nicht viel Zeit für den Sommer und auch Matthias erhöhte die Stundenanzahl in seinem Job, um die Reisekasse aufzubessern. Allerdings wird er weiterhin eine Woche im Monat bei seinem jetzigen Arbeitgeber in der Geo-Informatik arbeiten, sodass ein kleines Einkommen gesichert ist. Der Mix aus Physiotherapie, Yoga und Projektarbeit hat mir gut gefallen und ich bin schnell in eine Routine gekommen. Nach Neuseeland möchte ich mich mehr auf die Fachrichtung Neurologie spezialisieren, kann aber sagen, dass ich mit der Berufswahl bisher super glücklich bin.

Trotz der langen Arbeitswoche unternahmen Matthias und ich mehrere Trips an den Wochenenden und testeten zuletzt in den italienischen Alpen unser Outdoor-Equipment, welches wir in den letzten Monaten verbessert und optimiert haben. Unser Plan in Neuseeland ist es zwar, einen ausgebauten Camper zu kaufen und dort drin zu wohnen und zu reisen, aber wir möchten auch möglichst viele Orte zu Fuß erkunden und das Land so häufig es geht durch Wanderungen kennenlernen. Ankommen werden wir in Neuseeland erstmal bei meiner besten Freundin Liz und ihrem Partner Tom. Liz kenne ich seit dem Kindergarten und sie ging 2019 mit einem Work and Travel Visum nach Neuseeland. Als sie ein paar Monate später vor der Entscheidung stand, wegen Corona das Land zu verlassen oder zu bleiben, entschied sie sich für das Bleiben. Mittlerweile hat sie die Residency und studiert Krankenpflege in Christchurch. Gemeinsam mit ihrem Partner Tom wohnt sie in Darfield, in der Nähe von Christchurch auf der Südinsel, welches somit unser erstes Ziel ist. Und mehr geplant haben wir erstmal nicht. Ankommen, Auspacken, Akklimatisieren (in Neuseeland geht es jetzt gerade vom Winter in den Frühling mit entsprechenden Temperaturen) und erstmal durchatmen. Die letzten Wochen waren aufregend, anstrengend und emotional. Matthias und ich haben unsere WG Zimmer in der Eppelvilla aufgegeben und unser Hab und Gut bei Matthias Mama untergestellt. Der Auszug fiel mir nicht leicht, die Menschen an diesem Ort sind mir in den letzten Jahren so ans Herz gewachsen, dass es sich wirklich wie Zuhause anfühlt. Auch unser Freundeskreis in Heidelberg hat sich sehr gefestigt, was den Abschied nicht leichter machte. Bei unserer Abschiedsparty im Garten bedankten wir uns bei der WG für die schöne Zeit in Eppelheim. Matthias und ich wissen, dass wir nächsten Herbst nach Heidelberg zurückkommen wollen, aber nicht in die Eppelvilla. Wir vermissen die Nähe zum Wald und sehen Neuseeland als Chance, uns von Orten und vor allem Menschen und ihren Lebensweisen inspirieren zu lassen.

Dieser Blog ist für uns eine Möglichkeit, das Erlebte mit euch zu teilen und die Reise zu reflektieren. Ich lese ab und zu immer noch gerne meinen alten Reiseblog und lasse die Erinnerungen Revue passieren, was mich motiviert hat, das Schreiben wieder anzufangen. Dank Matthias können wir diesen Blog auf einer eigenen Website veröffentlichen, welche sich nach unseren Bedürfnissen verändern kann.

Wir schreiben die letzten Worte gerade, während wir in Singapur am Flughafen auf unseren Weiterflug nach Christchurch warten. 12 Flugstunden geschafft, weitere 10 kommen auf uns zu. Die Welt scheint so gross, und gleichzeitig falle ich in ein paar Augenblicken meiner besten Freundin in die Arme, die ich schon so lange nicht mehr gesehen habe. Schön, dass du hier bist und unser Abenteuer so begleitest. Matthias und Maike

Dies ist der letzte Eintrag von Maikes alten Blog und dient uns als Vorlage um diese Webseite zu gestalten.

Ich hatte es mir 100x im Kopf ausgemalt wie es sein würde, nach 1.5 Jahren Reisen zurück nach Deutschland zu kommen. Wie ich meine Familie beim Abendessen überraschen würde, denn sie hätten keine Ahnung, dass ich endlich nachhause komme. Wie ich mit meiner Qualifikation zur Yogalehrerin ein bisschen Geld verdiene, bis die Uni im Herbst anfängt und ich mein frisch Gelerntes anwenden kann. Wie ich mitten im Frühling nach einem kurzen Abstecher nach Barcelona die Sonne mit nachhause bringe und alle in den Arm nehme.

Dass eine globale Epidemie dieses Wunschdenken um 180 Grad drehen würde, damit hätte ich wohl lange nicht gerechnet. Und doch ist es genauso gekommen.

Als ich meinen letzten Eintrag schrieb befand ich mich noch in Malaysia und bereitete mich auf meine 4 wöchige Ausbildung auf der kleinen Insel Koh Phangan in Thailand vor. Meine Familie dachte, dass ich anschließend noch den Rest des südlichen Thailands erkunden würde, hatte insgeheim aber schon einen Rückflug über Barcelona nach Deutschland gebucht. Dort wollte ich eine Freundin besuchen und wir wären zu einem Konzert gegangen, welches schon so lange auf meiner Liste stand.

Ich konnte es kaum erwarten, einen ganzen Monat in einer kleinen Strandhütte zu wohnen, mit 15 anderen Menschen alles über das therapeutische Yoga zu lernen, das beste Essen zu genießen und jeden Tag ins Meer zu springen. Und anfangs sah mein Tagesablauf auch noch genauso aus.

Meine Hüttennachbarin Mali und ich waren die Jüngsten im Kurs und es gab sogar noch drei weitere Deutschsprachige, ansonsten war die Gruppe sehr gemischt und kam von überall aus der Welt angereist. Der Ablauf war sehr strukturiert, wir haben um 6.30 morgens angefangen und pünktlich zum Sonnenuntergang um 18 Uhr aufgehört. Sechs Tage die Woche, für eigentlich vier Wochen. Die Stimmung auf der Insel war ausgelassen, abends am Strand kamen alle zusammen, es wurde Gitarre gespielt und getrommelt, irgendwer tanzte immer. Über Corona sprachen wir nur wenig, auf der Insel fühlte ich mich isoliert - und irgendwie sicher. Mich erreichten Nachrichten aus Deutschland, wo sich die Lage tagtäglich verschlimmert. Ich werde beneidet, von all dem nichts mitzukriegen.

Mein "beach-bungalow" mit Meeresblick, nur 5 Minuten von unser Yogaschule, und nicht weit vom unserem Lieblingscafe der Köchin Pat

Wir hatten gerade die erste Woche erfolgreich überstanden als unsere drei Lehrer und Leiter des Kurses uns am Abend zusammensetzten und uns über die Maßnahmen der thailändischen Regierung informierte. Es wäre warscheinlich kein Schock für uns gewesen, hätten wir die News der letzten Tage und die sich zuspitzende Lage nah verfolgt, aber ich persönlich war wohl zu optimistisch, dass es uns hier nicht so schnell betreffen würde. Zu diesem Zeitpunkt wurde zwar schon das Konzert in Barcelona sowie der Flug dahin gestrichen, aber ich hatte ihn ohne viel Bedenken nach Deutschland umgebucht. Wie gesagt, ich hatte die Lage einfach unterschätzt. Damit die Lehrer ein bisschen Zeit hatten, um einen Plan für das weitere Vorgehen zu entwickeln bekamen wir erstmal zwei Tage frei. Wir könnten den Kurs vorübergehend online in kleinen Guppen weitermachen, schließlich war es auch viel Theorie und heutzutage gibt es ja genügend Möglichkeiten. Doch am nächsten Morgen entschieden sich die Lehrer -zu unserem Verständnis- dagegen, es wäre einfach nicht die gleiche Qualität, außerdem stehen wir noch so weit am Anfang des Kurses. Die Enttäuschung war groß, aber sie hatten recht. Es wäre keine richtige Ausbildung.

Ein letztes Mal zusammen; eine Gruppe, die ich noch besser hätte kennenlernen wollen

Mit Absage des Kurses musste auch ich eine Entscheidung treffen. Wie sicher ist eine kleine Insel, wenn uns der Virus auch hier erreicht? Das könnte aufgrund der immer steigenden Zahlen nicht mehr lange dauern. Ist die Versorgung gesichert? Wie gut kann das Gesundheitssystem hier wirklich sein? Es war zwar keine einfache, aber die richtige Entschiedung für mich persönlich und ich verschob meinen Flug auf das frühstmögliche Datum, den 31. März. Ich konnte es nicht riskieren, länger als nötig auf der Insel festzusitzen, da auch mein Reisepass bald ablaufen wird. Und für die restlichen Tage konnte ich wenigstens noch das Inselleben genießen- im Unterbewusstsein war ich jedoch mehr nervös als entspannt. Jeden Tag wurden mehr Flüge eingestellt, mehr Flughafen dicht gemacht. Schaffe ich es noch rechtzeitig nachhause?

Noch immer kamen alle zum Sonnenuntergang am Strand zusammen, es wurde einander aufmunternd zugelächelt, trotzdem gelang es uns nicht ganz, Enttäuschung zu verbergen. Viele hatten jahrelang auf diesen Kurs gespart, andere kündigten ihren Job, da sie ansonsten keine 4 Wochen Urlaub bekämen. Am nächsten Abend strich Emirates alle Flüge nach Deutschland und es war höchste Zeit, meine Eltern in die Umplanung einzuweihen. Die Situation gerät doch ein wenig außer Kontrolle. Wir entschieden uns, den Flug erneut umzubuchen, das Nahegelegenste war Copenhagen, dann mit einem seperaten Ticket nach Berlin. Den Tag darauf stelle Emirates den Flugverkehr komplett ein. Auch die Stimmung auf der Insel kippte. Wir sollten alle Schutzmasken tragen, viele Restaurants schlossen, Take-away only. Es gab einen bestätigten Corona-Fall. Zum Sonnenuntergang kamen nur noch wenige.

Wir buchten einen Flug mit einer anderen Airline und ich- wie viele andere- verließen die Insel so schnell es ging. Kurz darauf rief Thailand den Ausnahmezustand aus. Alles ging so schnell. Mit einer der letzten Fähren fuhr ich auf die Nachbarinsel und flog von da aus nach Bangkok, musste eine Nacht am Flughafen verbringen und konnte am nächstem Morgen ein Glück das Flugzeug über Helsinki nach Frankfurt boarden. Eine Szene wie sich sich am Flughafen Bangkok abspielte hab ich in meinem Leben noch nie erlebt. 99% der Menschen hielten sich an die Schutzmaskenverordnung, es wurde auf Sitzbänken gecampt, da viele hofften, mit den wenigen Standbyplätzen irgendwie aus dem Land zu kommen, ich las die Hälfte eines Buches während ich in einer langen Schlange zum Check-in Schalter stand. Außerdem traf ich auf andere Deutsche, welche bereits seit Längerem am Flughafen ausharren, um sich immer wieder in Standbylisten einzutragen. Die Angst, dass mein Flug auch überbucht war, stieg weiter an. Letztendlich bekam ich aber einen Boarding Pass und stieg am 26.3. erleichtert in den vollen Finnair Flieger. Ein paar Stunden später sah ich endlich Papa in Frankfurt, der den ganzen Weg zum Flughafen fuhr, um mich abzuholen und sowieso als mein persönliches Reisebüro agierte, um mich da irgendwie darauszuholen. Zu meiner Überrschung schien Frankfurts Flughafen entspannt, nur wenige trugen Masken, es gab keine Temperaturchecks oder Fragen, wo man her kommt.

Rucksack ist gepackt, Pat gab mir Lunch mit und nach mehreren Temperaturchecks (vor der Fähre, vor dem Flugzeug etc.) ging es für mich nach nach Bangkok, wo ich meine Südostasienreise vor 6 Monaten startete

In dem ganzen Troubel war es so einfach zu vergessen, sich auf zuhause zu freuen. Alles kam überstürzt, ich hatte keine Zeit mich vorzubereiten, vorallem auf das Wetter haha. Aber ich bin jetzt schon seit 2 Tagen wieder da und auch wenn es wahrscheinlich noch ein bisschen dauert bis ich wirklich "ankomme", bin ich heilfroh, zuhause zu sein. Und man schätzt die kleinen Dinge, welche ich so vermisste während meiner Reise. Ich kann die Flasche mit Leitungswasser auffüllen, wir trennen den Mülll vernünftig, es gibt Brot!! Wenn ich auf die letzten Tage zurück schaue wird mir erstmal bewusst, was für eine knappe Nummer das war. Meine Rückkehr hatte ich mir anders vorgestellt.

Dies ist mein letzter Bogeintrag, von jetzt an wird sich das Reisen erstmal beschränken. Ich wollte mich bedanken, dass ihr mir die letzten 1.5 Jahre, genauer gesagt 567 Tage, gefolgt seit, mich ermutigt habt, Interesse zeigtet und ich meine Geschichten mit euch teilen konnte. Wie es jetzt weiter geht weiß ich nicht, ich glaube das weiß keiner. Ich hoffe, dass wir diese Zeit getrennt, aber zusammen durchstehen. Ich begebe mich die nächsten Wochen natürlich erstmal freiwillig in die Quarantäne, obwohl ich hier auf dem Dorf ein Glück mit unserem Fiete spazieren kann (der ist übrigens soo groß geworden, als ich im September 2018 losgereist bin war er noch ein Welpe).

Ich kann es kaum erwarten, meine Großeltern und Freunde in den Arm zu nehmen, wenn das alles hier vorbei ist.

Als ich gerade die Südostasienkarte kennzeichnete fiel mir auf, dass ich sowas gar nicht für Kanada gemacht habe. Kanada, es fühlt sich wie eine Ewigkeit vor das Land verlassen zu haben, dabei war es erst im September. Ich habe oft Heimweh, Fernweh, ich weiß nicht wie man es am Besten beschreibt, und ich hoffe sehr, irgendwann dorthin zurückzukeren.

Ich glaube trotz des ganzen Verlusts & vieler Probleme, welches diese Epidemie mit sich bringt, werden wir etwas Gutes daraus mitnehmen. Auch wenn ich das vielleicht gerade noch etwas leugne.

Bleibt gesund und macht das Beste aus der Situation,

Maike

An app can be a home-cooked meal by Robin Sloan

One of the things that has sparked a lot of joy in my life in the last two years was building an app to keep track of "podcasts" I want to listen to. I'm using podcast in a very loose sense here, it's more like any content where I need to pay attention with my ears, from actual podcast episodes, to Youtube lectures from Stanford, to courses on whatever platforms, to sermons in mp3 format, to audio/video on Substack, etc.

I previously would always lose track of things, forget about them and actually not get around to listening to things. And when I would actually have time to listen to something, I would not know what to listen to.

So I decided to make an app for this. Existing apps didn't really work because I was listening content across a very wide variety of platforms.

After having heard the startup adage to start scrappy, the first iteration was a Google Sheet.

Initially it just had a couple of columns, which kept growing in number. At some point I started color coding them (for example by length so it's easier to find something based on how much time I have). This got to tags, starring favorite episodes, notes.

Then I started adding statistics. I learned that you can do a sort of SQL query in Sheets.

I love statistics. I love tracking things.

I even learned how to do some basic automation in Sheets and how to add "buttons".

But, eventually I outgrew the spreadsheet. After almost two years, I decided it's time to graduate to something more serious, so I built an app in Django. The only design awards it will win are for worst looking app, but it works very well for me. And it only has to work for me!

Now I can filter things even better, I can drill down quickly by speaker, series, tags.

Using this app has helped me listen to an average of 9 episodes per week. Previously, if I listened to 1 episode per week was good. So I'm glad I'm more organized and I'm able to learn more.

But, there's some other important lessons: home cooked software. This is an app I built for myself. It will have 1 user for the rest of my life (maaaaybe someone else from my family will use it, but unlikely). It means I can get away with things like using SQLite3 for the database. I can have one 700 line file for the views. I can mix Javascript libraries like there is no tomorrow. It's tremendously fun to develop this. And I think more programmers should build this sort of personal use software. It's small, it's niche, but over time it can get to do some pretty impressive stuff. And you know what? It's super fast. Network round trip from my NAS that is sitting on the same LAN with me is miliseconds. The app is super snappy, much faster than almost any app made by big tech or an american startup. With a minimum of effort into avoiding cascading SQL queries, it's possible to get all page loads to be under 300 ms.

I remember reading about Linus, who invented his own programming language, and wrote his own editor and a ton of other apps for personal usage. At the time I was like why would you waste your time on that? Now I'm starting to understand him and I'm starting to expand this app to slowly do more things.

But there's an interesting twist: I tried the same for tracking articles to read. It doesn't work at all. I add things and I never read them. Why? Because new articles to read are always easy to come by, Twitter, Reddit and Hacker News are always full of the latest shiny stuff, so there's no natural context for me to go and find saved articles to read. So I'll have to do some more thinking about how to solve that problem.

Viele Linux-Anwender halten sich für fortschrittlich und innovativ. Dieses Selbstbild rührt daher, dass es ihnen vor langer Zeit gelungen ist, sich von Microsoft zu lösen. Das Phänomen kennt man von anderen Gruppen wie den Alt-68ern, bei denen Fremd- und Selbstbild mit der Zeit auseinander klaffen. Dabei sind viele Linux-Anwender strukturkonservativ und lehnen Veränderungen krampfhaft ab. Einige Beispiele von bis D bis W.

Aktuell ist eine Debatte um run0 und sudo entbrannt. Die alten Konfliktlinien werden wieder sichtbar. Dieser Rückblick auf die letzten 15 Jahre soll ein wenig Gelassenheit vermitteln. Innovationen haben bei Linux immer Widerstand hervorgerufen. Am Ende haben sie sich aber meist durchgesetzt. Die verzögernden Konfliktmuster sind unvermeidlich und liegen in der Nutzerschaft begründet.

Umstrittene Neuerungen von D bis W

Dateisysteme

Ältere Linux-Anwender können sich noch an die Einführung von ext4 erinnern. Es gab damals ein paar Bugs bei der Einführung. Diese wurden maßlos überzeichnet und ließen Anwender an ext3 festhalten. Damals hieß es dann, dass doch niemand ext4 braucht, weil ext3 super ist. Das gleiche Drama begleitet bis heute Btrfs, das zwar inzwischen Standard bei vielen großen Distributionen wie openSUSE oder Fedora ist, aber dem immer noch vermeintliche Instabilität vorgeworfen wird, weshalb so mancher ältere Handbuchautor weiterhin ext4 empfiehlt.

Flatpak

Flatpak/Snap soll die Grenzen der klassischen Paketverwaltung überwinden. Die Palette der Probleme reicht von fehlendem Sandboxing über die Abhängigkeitshölle bis hin zu fehlender Abwärtskompatibilität etc. pp. Dennoch finden viele ältere Linux-Anwender diese Paketverwaltung perfekt und wollen keine Alternative. Die Entwicklung geht derzeit in Richtung Flatpak – Überraschungen nicht ausgeschlossen.

NetworkManager

Jüngere Anwender können es sich gar nicht mehr vorstellen, aber den NetworkManager, den heute alle Distributionen mitliefern, gab es nicht immer. Eine erste Version gab es 2004, natürlich von Red Hat. Nach und nach übernahm der NetworkManager die Kontrolle über Ethernet, WLAN, (Open)VPN und andere Verbindungen. Zuletzt verdrängte er mit dem Kommandozeilentool nmcli die letzten Konkurrenten. Überladen und überflüssig fanden NetworkManager viele Anwender. Schließlich gab es ja noch ifupdown und wpa_supplicant.

PulseAudio

PulseAudio wurde 2008 mit Ubuntu 8.04 einer breiten Nutzerschaft zugänglich gemacht. Sofort begannen die üblichen Diskussionen. PulseAudio sei überdimensioniert und zu undurchsichtig. Man brauche es sowieso nicht. ALSA und esound reichen völlig aus. Noch heute findet man viele Anleitungen, wie man PulseAudio abschaltet und durch damals abgekündigte Backends ersetzt. Daran erinnert sich heute niemand mehr und PulseAudio war bis zur Einführung von PipeWire Standard.

systemd

Braucht man eigentlich nicht mehr weiter ausführen. Die Entwicklung und Implementierung von systemd in die meisten Linux-Distributionen ist ein Paradebeispiel für Hass und Hetze in der Linux-Welt. Weil es von Lennart Poettering ist, weil es anders ist, weil Administratoren ihre Init-Skripte umschreiben mussten, weil Unix-Veteranen umlernen mussten. Heute gibt es eine Handvoll Distributionen, die systemd nicht verwenden. Ihre Gemeinsamkeit: Wenige Benutzer und keine größere Relevanz im Linux-Ökosystem.

systemd-logs

Binäre Logs benötigen weniger Speicherplatz, schonen die SSDs durch wesentlich effizientere Schreiboptionen und sind besser gegen Manipulation geschützt. Aber sie waren neu und anders, und man brauchte ein winziges Tool, um auf sie zuzugreifen. Außerdem kamen sie aus dem Systemd/Poettering Stall. Genug für massiven FUD und Aufruhr bei der Einführung. Heute benutzen es fast alle Distributionen.

PolKit

PolKit (früher: PolicyKit) ist ein System zur Vergabe von Berechtigungen an Benutzer. Damit bricht das System die traditionelle Trennung zwischen Benutzer- und Administratorkonto auf. Das war umständlich und anders und löste 2011, als PolicyKit weitere Verbreitung fand, massive Vorbehalte aus. Weil die bisherigen Lösungen nicht mehr funktionierten etc. pp. Heute funktioniert keine Linux-Distribution mehr ohne PolKit.

run0

Der neueste Zankapfel. Lennart Poettering hat sich sudo vorgenommen und präsentiert eine Alternative aus dem systemd-Stall. Sofort formiert sich Widerstand, denn es ist von Poettering und systemd steht irgendwo im Beschreibungstext. Dass die Konfigurationssyntax von sudo eine Katastrophe ist und mit visudo ein Werkzeug benötigt wird, damit Administratoren ihre Konfiguration nicht zerstören. Geschenkt!

Verzeichnisstruktur

Der sogenannte usrmerge bricht die veraltete UNIX-Verzeichnisstruktur auf und führt die Verzeichnisse unterhalb von /usr zusammen. Das ist für viele Anwendungsszenarien sinnvoll und die bisherige Struktur war auch nur historisch gewachsen (Warum das so ist, wurde hier mal aufgeschrieben). Das ändert nichts daran, dass es massive Vorbehalte dagegen gab und gibt, weshalb Community-getriebene Distributionen wie Debian mit massivem Zeitverzug nachziehen. Keine größere Distribution hält heute noch an der alten Struktur fest.

Wayland

Wayland wurde erstmals 2008 in groben Zügen skizziert. Es sollte X.Org ablösen, da X.Org nicht mehr den damaligen Anforderungen entsprach. Zur Erinnerung: X.Org war ein Produkt der 1980er Jahre und letztlich auch für Anwendungsszenarien der 1980er Jahre konzipiert. Der Code ist nach Aussage aller Programmierer, die daran gearbeitet haben, schon lange nicht mehr wartbar und de facto wird X nur noch von Red Hat gepflegt. X ist konzeptionell unsicher und das lässt sich nicht ändern. Programme wie xinput können z.B. alle Tastatureingaben mitschneiden. Niemand, der etwas von X.org versteht, hat diesen Zustand bestritten. Es gibt anhaltende Proteste gegen Wayland. Weil X.Org doch funktioniert, weil liebgewonnene Dinge wie Netzwerktransparenz nicht mehr funktionieren, weil es Änderungen am Desktop geben muss, weil es neu und anders ist. Die ersten Distributionen entfernen jetzt die alten X11-Sessions. Wenn Red Hat die Wartung einstellt, ist der Tod des alten Systems nur noch eine Frage der Zeit.

Gesamtschau

Bestimmt habe ich ein paar vergleichbare Phänomene vergessen. Der Debattenverlauf ist eigentlich immer gleich:

1. Es gibt eine bestehende Lösung. Diese Lösung funktioniert aber ist nicht perfekt und wurde unter anderen Rahmenbedingungen entwickelt.
2. Die bestehende Lösung lässt sich nicht konstruktiv weiterentwickeln.
3. Es gibt einen neuen Ansatz.
4. Weil der Ansatz neu ist, zieht er sofort Kritik auf sich. Wenn es keine Argumente gibt werden Lügen und Halbwahrheiten verbreitetet.
5. Am Ende setzt sich die neue Lösung nahezu immer flächendeckend durch.
6. Niemand will mehr etwas gegen die Lösung gehabt haben.

Die Argumente bedienen sich auch immer aus einem bestimmten Pool:

• Widerspricht dem KISS-Prinzip
• Widerspricht den UNIX-Prinzipien
• Ist unnötig
• Ist intransparent
• Ist unsicher
• Ist aufgeblasen

Glücklicherweise gibt es auch Ausnahmen. Die Einführung von Avahi als zeroconf-Implementierung löste meiner Erinnerung nach 2006 keine größere Debatte aus. Die meisten Anwender waren schlicht froh, dass es diese Implementierung nun endlich gab. HAL trauerte nach der Ablösung durch udev/upower und Konsorten auch niemand nach. Gleiches gilt für Gummibot / systemd-boot und das obwohl sogar systemd im Namen vorkommt.

Haben diese Lösungen Linux komplizierter gemacht? Vielleicht. Ich erinnere mich durchaus noch an Zeiten, in denen man Arch Linux in 2-3 Dateien konfiguriert hat und sich das nach Kontrolle angefühlt hat. Diese Zeiten sollte man aber auch nicht verklären, denn damals ging einfach viel nicht, was mit anderen Systemen schon funktionierte und die Tätigkeiten, für die wir unsere Systeme verwendeten waren viel beschränkter.

Ursache

Die Ursache liegt meiner Meinung nach in der Struktur der Linux-Anwender auf dem Desktop.

• Fast alle Nutzer sind Umsteiger, die von Windows oder macOS auf Linux umgestiegen sind, um bestimmten Entwicklungen zu entgehen. Sie haben in der Regel eine steile Lernkurve hinter sich und glauben, das System verstanden zu haben. Entsprechend frustriert reagieren sie auf neue Entwicklungen bei Linux, die sie nicht verstehen oder nicht verstehen wollen, weil sie ihren Wissensstand bedroht sehen.
• Während der steilen Lernkurve haben sie oft verinnerlicht, dass die Lösung bei Linux besser ist als bei macOS oder Windows. Die Überlegenheit ist vielen Anleitungen und Erklärungen für Umsteiger immanent. Warum diese bessere Lösung nun doch schlechter als eine Neuentwicklung sein soll, erschließt sich ihnen nicht. Es stellt infrage, ob die Lösung wirklich besser war.
• Die Community ist stark männlich geprägt. Das war sie schon immer. Es liegt am Thema, der Netzkultur etc. pp. Für die Debattenkultur war das nie förderlich.
• Das Durchschnittsalter steigt mangels Nachwuchs stetig an. Viele Linux-Anwender haben ihre prägenden Migrationserfahrungen irgendwann zwischen 2005 und 2010 oder sogar noch früher gemacht. Das ist fast schon zwangsläufig, weil der Desktop als privat genutztes Gerät für jüngere Anwender nicht mehr selbstverständlich ist und Linux auf modernen mobilen Geräten nie angekommen ist.

Der Kausalzusammenhang zur Debattenkultur zwischen Geschlecht und Generation ist kein exklusives Linux-Thema. Studien zur Verbreitung von Fake News zeigen, dass Männer und ältere Menschen anfällig dafür sind und diese häufiger verbreiten. Zusammen mit den ersten zwei Punkten führt zu einem stark innovationsfeindlichen Klima. Alles was wirklich neu ist, wird kritisch beäugt und schlecht gemacht. Positives Feedback bekommen nur noch kosmetische Änderungen am bestehenden Status quo.

Lösung

Das Schöne an der Situation ist, dass es für alle eine Lösung gibt. Wer die neuen Entwicklungen gut findet und nur von den Debatten genervt ist, kann sich zurücklehnen. Auf diese Unix-Veteranen hören die Entwickler und Distributoren schon lange nicht mehr. Kritische Kommentare haben keine der oben genannten Entwicklungen verhindert. Entwicklung und die Diskussion in der Community haben sich tendenziell entkoppelt. Das lässt sich mindestens seit 2010 beobachten (Entwicklung GNOME 3).

Wer sich an den Entwicklungen stört, dem empfehle ich immer FreeBSD. Das ist mittlerweile auf dem Desktop sehr gut einsetzbar und zeichnet sich durch eine wesentlich konservativere Entwicklungsrichtung aus. Dort bleibt man von solchen ungeliebten Änderungen und Vereinfachungen weitgehend verschont. Die geringe Wechselbereitschaft zu FreeBSD wundert mich immer und lässt mich mutmaßen, dass die geringe Lernbereitschaft für neue Tools schon so weit ausgeprägt ist, dass man sich auch kein neues Unix-System mehr anschauen will. Schließlich ist man ja schon ein mal migriert: Zu Linux. Noch eine Migration möchte man sich selbst scheinbar nicht zumuten. Das ist dann zu viel Innovation.

Der Artikel Der ewige K(r)ampf um Fortschritt bei Linux erschien zuerst auf Curius

Imagine you travelled back in time to the stone age with nearly all of modern science and technology memorized. Let's also stipulate that you can communicate perfectly with the people living back then, and they won't kill you on sight. How quickly could you push human civilization forward to reach the same level of material progress as the world you came from?

It seems obvious the answer is "pretty quickly," assuming you aren't immediately killed by a wild animal or utterly fail to impart any useful knowledge.

But how quickly?

Let's think of it another way. A time traveler from the year 4,000 comes back in time to visit you, right now, today, and brings all the knowledge of the future back with them. Armed with this cheat-sheet, how quickly could you manifest the next 2,000 years of material progress?

Again, "pretty quickly" seems like the answer, but exactly how quickly continues to elude us.

If you consider the first scenario, it's not clear that you could, for instance, jump start something like the industrial revolution merely by giving the right facts to a bronze-age or iron-age emperor. And this is even if they believe your technology works – there's good arguments that the real reason the industrial revolution didn't happen sooner is down to contingent civilizational constrains:

to your dismay, the emperor responds: “Your mechanism is no gift to us. It is tremendously complicated; it would take my best master craftsmen years to assemble. It is made of iron, which could be better used for weapons and armor. And even if we built these engines, they would consume enormous amounts of fuel, which we need for smelting, cooking, and heating. All for what? Merely to save labor. Our empire has plenty of labor; I personally own many slaves. Why waste precious iron and fuel in order to lighten the load of a slave? You are a fool!”

Consider also that progress doesn't move in a straight line. Humanity last visited the moon in 1972, and after the space shuttle program was retired in 2011, the United States no longer had the capacity to send Astronauts into space.

Fast forward to today, and SpaceX continues to wow the world with the latest successful flight of Starship. Studying the history of that company, however, makes us realize that this hard-won progress was also highly contingent–what if SpaceX had never gotten off the ground? How would we access even the aging space station today if we were still entirely dependent on a now-hostile Russia for our rocket launches?

On the other hand, the history of science is also littered with wild coincidences leading to sudden discoveries resulting in durable progress. Two of the most famous stories are penicillin being discovered on moldy bread and the secret of cooking food with microwaves stemming from a melted candy bar in an researcher's pocket; but did you know that pretty much every major synthetic sweetener was discovered by researchers accidentally tasting chemicals?

It is therefore a fact of the world that virtually all the popular synthetic sweeteners were discovered accidentally by chemists randomly eating their research topic.^[1]

I think this is a suspiciously high amount of serendipity. I see two options:

Super-sweet molecules like aspartame are commonplace – there are plenty of molecules hundreds of times sweeter than sucrose, but we only know the few that were ingested by accident,

Super-sweet molecules are very rare, it’s just that chemists accidentally taste a lot of chemicals. Entire chemistry departments routinely taste the entire space of possible molecules, but they don’t notice unless the molecule has a strong taste.

Finally, consider gunpowder. Supposedly Taoist alchemists accidentally discovered it while they were trying to develop an elixir of life, and we all know how profoundly their discovery changed the course of history.

We have two opposing narratives here:

1. Material progress is hard won, highly contingent, and fragile.

and:

2. There's trillion dollar bills just lying on the ground.

Let's think of this another another way – a lot of AI researchers are all agog about the idea that we're about to hit a technological singularity; once we automate AI research itself, AIs will be able to self-improve themselves and we'll get a gigantic burst of technological progress almost instantly; a century's worth of progress in weeks, days, or maybe even hours.

I'm too dumb to make sense of most of the arguments these people put forth, but here's something my smooth little brain can handle: what do different kinds of material and scientific progress require?

On one end of the spectrum, there's math – proving a new theorem or something. In theory all this takes is pure thought – it's not dependent on a bunch of highly specific coincidences all lining up just right to unlock the magic. You just need a smart enough person to work out the puzzle. In this world all it takes to advance human progress is figure out how to make more Terrence Taos.

In the middle end of the spectrum, you have something like chemistry. Discovering a new useful molecule or law of chemistry requires you to be smart but also requires you to directly interact with the physical world running experiments and doing tests and procedures. Each of these procedures has a cost, both in terms of time, as well as physical materials. So it's not enough to be smart, because your progress is limited by how quickly you can do experiments. For a particularly salient example, consider the story of the man who invented the blue LED:

On the far end of the spectrum you have stuff like biology and medicine. Here you not only have to constantly interact with the real world to learn new things, but also this is where the real world starts getting particularly uncooperative. The systems you're working with are incredibly complex and literally alive, and it's difficult to contrive perfectly controlled experiments that let you isolate cause and effect. Furthermore, many of the questions you'd like to answer like, "does this drug increase the risk of cancer in humans" come with ethical barriers and time barriers – what if it takes twenty years to get a sufficiently clear answer? What if the only experiment that could get a definitive answer basically amounts to torture, and therefore you can never run it?

The biggest limiting factor to human material progress is how many other things the next big step forward depends on besides a lot of very smart people thinking really hard about the problem.

Therefore, if you want lots of progress, and you want it sooner rather than later, our marginal focus should be on reducing the time and cost of making the next guess.

There's no better example of this than the contrast between SpaceX and Boeing. Besides being gradually hollowed out following a merger with former rival McDonnell Douglas, Boeing typifies the conventional "cost plus" government contractor. The government agrees to cover all their development expenses plus a fixed percentage of profit up top, which gives the contractor no incentive to reduce costs – the opposite, if anything. SpaceX on the other hand focuses relentlessly on decreasing costs, and subjects themselves to real world experimentation as often as possible. SpaceX makes a lot more guesses much more often than Boeing, and the gains rapidly compound.

This has personal applications too, reflecting on my ~14 year career as a game developer. After having a modest hit early on, I got bogged down in the typical indie death spiral of a 10-year mega project (that should thankfully be shipping very soon, my former colleagues tell me). I had many other accomplishments behind the scenes I'll write about one day, but I'll always regret how bogged down I let myself get on our "main game" project. This was an extremely expensive single guess both in time and money, and I would have benefited from learning its lessons faster and more cheaply.

I contrast this with my experience in my new career doing real estate mass appraisal for local governments. We decided early on that my colleague Will Jarvis should be CEO and I would focus on research and product development. I imagined that we'd spend the first six months quietly building a killer product, and only after we had something to show would we approach clients with it. Will had other ideas–like throwing me into the deep end. We immediately started doing small pilot studies with real clients on small dollar contracts, in order to learn what the problem even was. After a few false starts it became very clear what we actually needed to build, and we soon ramped up to full-scale projects. If we'd followed my approach instead, we would have gone down a complete dead end because the final product customers showed us they wanted was completely different from the one I originally envisioned.

Another thing that surprised me was how quickly I learned the new trade. I owe this to two things – first, expert mentorship from veteran appraiser Paul Bidanset (our first hire), and second, the short durations of our shipping cycle. Get a client, process the data, build the model, get feedback. Then do it again, and again, and again. Before I knew it, I had modelled dozens of jurisdictions. There's still a lot to learn and endless horizons to conquer, but I've acquired more skills and training in the last twelve months than I have in the last five years.

It all comes down to just putting in the reps, day in and day out. And then one day you look at yourself in the mirror and suddenly you have biceps. And you're like, where did those come from? The same place progress does.

Geahnt, dass die Luft in Boulder- und Kletterhallen nicht unbedingt die Qualität eines Luftkurorts aufweisen, haben wir wohl alle längst. Jetzt ist diese Vermutung wissenschaftlich untermauert: Kletterer und Beschäftigte in Kletterhallen atmen sehr wahrscheinlich hohe Dosen potenziell giftiger Gummizusätze ein. Die aus den USA stammende Umweltingenieurin und Doktorandin Anya Sherman forscht nicht…

Quelle

I started playing the NYTimes word game “Connections” recently, by the recommendation of a few friends. It has the type of freshness that Wordle lost for me a long time ago. After playing Connections for a few days, I wondered if an OpenAI language model could solve the game (the objective is to group the 16 words into 4 categories of 4 words). I tried with gpt-4-32k and gpt-4-1106-preview, tweaking prompts for a few hours and wasn’t able to make much progress. It’s certainly possible prompt engineering alone could solve this problem, but it wasn’t easy for me for find a path forward. I imagine it will involve a bit of creativity. I decided this was as good a time as any to try and fine tune a model to do a thing I couldn’t easily get it to do with prompts.

Getting the dataset

I remembered seeing at some point that Wordle had an API to return the day’s word and it does at https://www.nytimes.com/svc/wordle/v2/yyyy-mm-dd.json. I figured Connections might have a similar JSON API and it does. I wrote a script to get all the solutions to past game and put the in the connections_data folder with the naming convention yyyy-mm-dd.json.

import json
import httpx
from datetime import timedelta, datetime


url = "https://www.nytimes.com/svc/connections/v1/{date}.json"
start_date = datetime.strptime("2023-06-12", "%Y-%m-%d")

def main():
 end_date = datetime.now()
 dates_generated = [
 start_date + timedelta(days=x)
 for x in range((end_date - start_date).days + 1)
 ]
 for date in dates_generated:
 formatted_date = date.strftime("%Y-%m-%d")
 response = httpx.get(url.format(date=formatted_date))
 response_object = response.json()
 with open(f"connections_data/{formatted_date}.json" , "w") as f:
 f.write(json.dumps(response_object, indent=2))


if __name__ == "__main__":
 main()

It turns out the first game was published on 2023-06-12. Next, I wrote some not pretty code to create a jsonl file to upload to OpenAI. They describe the structure of the file to fine-tune the gpt-3.5-turbo model here.

import os
import json

SYSTEM_PROMPT = """The game "Connections" is a word game where you start with 16 words and need to group them into 4 groups of 4. Each grouping has a category that unambiguously groups the four words together. Each puzzle has exactly one solution. Watch out for words that seem to belong to multiple categories. You will be given 16 words. Output 4 groupings of 4 words and the categories to which they belong."""

OUT_FILE = "connections_prompts.jsonl"

def main():
 with open(OUT_FILE, "w") as writef:
 for file in os.listdir("connections_data"):
 if file.endswith(".json"):
 print(file)
 with open(f"connections_data/{file}", "r") as f:
 data = json.load(f)
 categories = [c for c in data["groups"].keys()]
 categories_and_members = {c: data["groups"][c] for c in categories}
 assistant_str = ""
 for c, words in categories_and_members.items():
 assistant_str += f"category: {c.lower()}\nwords: {' '.join(words)}\n\n"
 all_words = [word.lower() for group in categories_and_members.values() for word in group["members"]]
 all_words_str = ', '.join(all_words)
 out_obj = {
 "messages": [
 {
 "role": "system",
 "content": SYSTEM_PROMPT,
 },
 {
 "role": "user",
 "content": f"Here are the 16 words: {all_words_str}",
 },
 {
 "role": "assistant",
 "content": assistant_str.strip(),
 },
 ]
 }
 writef.write(f"{json.dumps(out_obj)}\n")


if __name__ == "__main__":
 main()

Estimating Price

I estimated the price of the job by counting the number of tokens in my fine-tune file. The OpenAI pricing page lists the price of the fine-tune at $0.0080 / 1K tokens. Additionally, the fine-tuning guide notes

To estimate the costs for a specific fine-tuning job, use the following formula:

base cost per 1k tokens * number of tokens in the input file * number of epochs trained

For a training file with 100,000 tokens trained over 3 epochs, the expected cost would be ~$2.40 USD.

Using tiktoken to count tokens

import tiktoken

# gpt-3.5-turbo $0.0080 / 1K tokens

with open("connections_prompts.jsonl", "r") as file:
 data = file.read()

encoding = tiktoken.encoding_for_model("gpt-3.5-turbo")
tokens = len(encoding.encode(data))
price = (tokens / 1000) * 0.0080
print(f"Number of tokens: {tokens}.\nPrice: {price:.2f}")

which output

Number of tokens: 46814.
Price: 0.37

Running the fine-tune job

I took 15 of the rows (number chosen pretty randomly) from the result and separated them out into a training file, so that OpenAI can used it to calculate loss for the fine-tuning (I think). I called these files connections_prompts_train.jsonl and connections_prompts_test.jsonl. I went to OpenAI and created a new fine-tuning job. I selected the gpt-3.5-turbo-1106 model then uploaded my training and test data, and clicked “create” and off it went. As the job ran, I could see this dashboard. Here’s what it looked like when it finished.

And it cost \$0.90. According to the fine-tune metrics, 3 epochs (given my estimated cost of \$0.37) as mentioned fine-tune training guide though I don’t recall setting that or seeing it anywhere else.

Testing the fine-tune

With the fine-tuning done, I went to the playground to try it out. I fetched the words for the next day’s puzzle, which was mercifully already available. I forgot to make a validation set. Shame on me. It would have take a bit longer to fine-tune again, and I had a lot of anticipation to see the results, it being my first fine-tune and not really understanding the loss graph or knowing if it worked.

I copied the same system prompt from the training

The game "Connections" is a word game where you start with 16 words and need to group them into 4 groups of 4. Each grouping has a category that unambiguously groups the four words together. Each puzzle has exactly one solution. Watch out for words that seem to belong to multiple categories. You will be given 16 words. Output 4 groupings of 4 words and the categories to which they belong.

then added the user message with the words

Here are the 16 words: punt, badge, tackle, run, direct, pass, end, table, ticket, stall, chair, center, lead, safety, invite, hold

and clicked submit. The model outputted

category: american football terms
words: level members

category: football actions
words: level members

category: things that might be numbered
words: level members

category: field positions
words: level members

A definite bummer. I did a quick search in my project directory for “words: level members”, and found it everywhere. Oops! I built the dataset improperly.

Fixing a dataset bug

After a bit of a reset, I found some issues in the prompt generation python script and fixed them here

import os
import json

SYSTEM_PROMPT = """The game "Connections" is a word game where you start with 16 words and need to group them into 4 groups of 4. Each grouping has a category that unambiguously groups the four words together. Each puzzle has exactly one solution. Watch out for words that seem to belong to multiple categories. You will be given 16 words. Output 4 groupings of 4 words and the categories to which they belong."""

OUT_FILE = "connections_prompts.jsonl"

def main():
 with open(OUT_FILE, "w") as writef:
 for file in os.listdir("connections_data"):
 if file.endswith(".json"):
 print(file)
 with open(f"connections_data/{file}", "r") as f:
 data = json.load(f)
 categories = [c for c in data["groups"].keys()]
 categories_and_members = {c: data["groups"][c]["members"] for c in categories}
 assistant_str = ""
 for c, words in categories_and_members.items():
 lower_words = [w.lower() for w in words]
 assistant_str += f"category: {c.lower()}\nwords: {', '.join(lower_words)}\n\n"
 all_words = [word.lower() for group in categories_and_members.values() for word in group]
 all_words_str = ', '.join(all_words)
 out_obj = {
 "messages": [
 {
 "role": "system",
 "content": SYSTEM_PROMPT,
 },
 {
 "role": "user",
 "content": f"Here are the 16 words: {all_words_str}",
 },
 {
 "role": "assistant",
 "content": assistant_str.strip(),
 },
 ]
 }
 writef.write(f"{json.dumps(out_obj)}\n")


if __name__ == "__main__":
 main()

I checked my data and validated the correct words for each category were in the output jsonl file. This time around, I remembered to create an external validation set so I had a few cases to run once the fine-tune was ready. I split the data up 60% to train, 20% to validate for the fine-tune and 20% to use myself to validate after the fine-tune.

I put up my feet and waited for the fine-tune to run.

The first run of the fine-tune.

I’m very glad I had more validation data because I couldn’t believe it when I saw it work. I ran several more and each time, it got the word groups correct. Though occasionally it seemed to struggle to get the category right with x ___ or ___ x categories. But honestly, I was a little stunned. Before this fine-tuning, the model could not come all that close to solving Connections puzzles and now it could generally get the 4 word groups right every time and the categories right most of the time. It seemed to good to be true. It was! Can you spot the problem? The input words

Here are the 16 words: fido, lucky, rover, spot, catch, notice, observe, see, bait, chum, fly, sinker, bone, rex, shirt, storm

and the output categories

category: common dog names
words: fido, lucky, rover, spot
category: perceive
words: catch, notice, observe, see
category: fishing gear
words: bait, chum, fly, sinker
category: ___ in a teacup
words: bone, rex, shirt, storm

are in the same order.

When I change the input order of the words for this fine-tune

Here are the 16 words: lucky, chum, shirt, storm, spot, catch, rex, fly, observe, rover, see, bait, fido, notice, sinker, bone

it all falls apart.

category: pal
words: lucky, chum, shirt, storm

category: find
words: spot, catch, rex

category: ways to call
words: fly, observe, rover, see

category: dog, e.g.
words: bait, fido, notice, sinker

The categories stop making sense. The model hallucinates words. Some categories don’t even have 4 words in them. This fine-tune is toast.

Fixing another dataset bug

Back to the code. I modified my data set generation code, then split my data into three sets again. I used a stable random seed, so that the generation would be the same each time.

import os
import json
import random

random.seed(42)

SYSTEM_PROMPT = """The game "Connections" is a word game where you start with 16 words and need to group them into 4 groups of 4. Each grouping has a category that unambiguously groups the four words together. Each puzzle has exactly one solution. Watch out for words that seem to belong to multiple categories. You will be given 16 words. Output 4 groupings of 4 words and the categories to which they belong."""

OUT_FILE = "connections_prompts.jsonl"

def main():
 with open(OUT_FILE, "w") as writef:
 for file in os.listdir("connections_data"):
 if file.endswith(".json"):
 with open(f"connections_data/{file}", "r") as f:
 data = json.load(f)
 categories = [c for c in data["groups"].keys()]
 categories_and_members = {c: data["groups"][c]["members"] for c in categories}
 assistant_str = ""
 for c, words in categories_and_members.items():
 lower_words = [w.lower() for w in words]
 assistant_str += f"category: {c.lower()}\nwords: {', '.join(lower_words)}\n\n"
 all_words = [word.lower() for group in categories_and_members.values() for word in group]
 random.shuffle(all_words)
 all_words_str = ', '.join(all_words)
 out_obj = {
 "messages": [
 {
 "role": "system",
 "content": SYSTEM_PROMPT,
 },
 {
 "role": "user",
 "content": f"Here are the 16 words: {all_words_str}",
 },
 {
 "role": "assistant",
 "content": assistant_str.strip(),
 },
 ]
 }
 writef.write(f"{json.dumps(out_obj)}\n")


if __name__ == "__main__":
 main()

I ran a few tests

Here are the 16 words: adult, height, kiss, top, pair, tease, times, josh, peak, ten, score, gross, kid, dozen, max, rib

category: nudge, as for information
words: hint, josh, rib, tease

category: mountain ___
words: adult, gross, height, peak

category: 12
words: dozen, max, score, times

category: ___ number
words: kid, kiss, pair, top

and

Here are the 16 words: get, presto, secure, tada, fire, voila, carpenter, adam, win, behold, surprise, anger, land, fear, happiness, red

category: eureka!
words: behold, presto, tada, voila

category: “inside out” emotions
words: anger, fear, happiness, sadness

category: ___ and peace
words: land, order, red, secure

category: ___’s rib
words: adam, carpenter, get, surprise

The results are ok, but not incredible. It does get some groupings correct. There are hallucinations, adding words that don’t exist. Also, most categories and grouping are not correct.

Evaluating the results

To figure out if this fine-tune was worthwhile, I needed benchmark against the performance of gpt-3.5-turbo-1106.

I wrote some quick and dirty code to read the validation.jsonl, make an OpenAI call, parse the response and compare it to the known, correct answer. I decided to measure percentage of puzzles correct (all four categories) and percentage of categories correct (4 words correctly grouped). I also augmented the user prompt a bit to get the un-fine-tuned model to output its response the same way the fine-tuned model would for consistent parsing.

import json
from openai import OpenAI


client = OpenAI()

data = []
puzzles_correct = 0
puzzles_incorrect = 0
with open("validation.jsonl", "r") as file:
 for row in file:
 data.append(json.loads(row))

total_puzzles = len(data)
categories_correct = 0
total_categories = total_puzzles * 4

for da in data:
 system_prompt = da["messages"][0]["content"]
 user_prompt = da["messages"][1]["content"] + """\nOutput your response in exact adherence to the following form

category: <category>
words: <word1>, <word2>, <word3>, <word4>

for example:

category: height
words: height, top, peak, max
"""

 expected_result = da["messages"][2]

 completion = client.chat.completions.create(
 model="gpt-3.5-turbo-1106"
 # for the fine-tune:
 # model="ft:gpt-3.5-turbo-1106:personal::<my_id>",
 messages=[
 {"role": "system", "content": system_prompt},
 {"role": "user", "content": user_prompt},
 ]
 )
 # parse response
 result = completion.choices[0].message.content
 categories_with_words = {}
 for line in result.strip().split("\n\n"):
 category, words_str = line.lower().split("\nwords: ")
 category_name = category.split(": ")[1].strip()
 words = [word.strip() for word in words_str.split(", ")]
 categories_with_words[category_name] = tuple(sorted(words))

 # compare to correct answer
 correct_categories_with_words = {}
 correct_str = da["messages"][2]["content"]
 for line in correct_str.strip().split("\n\n"):
 category, words_str = line.split("\nwords: ")
 category_name = category.split(": ")[1].strip()
 words = [word.strip() for word in words_str.split(", ")]
 correct_categories_with_words[category_name] = tuple(sorted(words))

 num_correct = 0
 for word_list in categories_with_words.values():
 if (word_list in list(correct_categories_with_words.values())):
 print(word_list)
 num_correct += 1
 categories_correct += num_correct
 if num_correct == 4:
 puzzles_correct += 1
 else:
 puzzles_incorrect += 1

 # Calculate and print the percentages
 percent_correct = (puzzles_correct / total_puzzles) * 100
 percent_incorrect = (puzzles_incorrect / total_puzzles) * 100
 print(f"Correct: {percent_correct:.2f}%")
 print(f"Incorrect: {percent_incorrect:.2f}%")

 percent_categories_correct = (categories_correct / total_categories) * 100
 print(f"Total Categories Correct: {percent_categories_correct:.2f}%")

I started by running the code against gpt-3.5-turbo-1106.

Correct: 0.00%
Incorrect: 100.00%
Total Categories Correct: 20.24%

Next, I ran it against my fine-tuned model.

Correct: 4.76%
Incorrect: 95.24%
Total Categories Correct: 23.81%

Not a huge difference. I did a few more runs and none of the results we’re too out of the ordinary. Other than consistent formatting, it’s not clear the model got all that much better at the game after fine-tuning.

Wrap up

This experience was an interesting introduction to model fine-tuning. The results weren’t that amazing, but I learned a lot about easy pitfalls and mistakes one can make and had some fun.

Future work

To see if there might be more to explore for this project, I ran the validation set through gpt-4 with the following results

Correct: 9.52%
Incorrect: 90.48%
Total Categories Correct: 39.29%

This improvement is notable over gpt-3.5’s ~20-25%. I requested access to fine-tune gpt-4, so we’ll see if that comes through and I can try it out.

Dateien umbenennen ist oft mühsam. Wenn man ein Extra-Werkzeug benutzt, muss man es erst lernen. Das schreiben eines extra Skriptes kann aber oft zu aufwendig sein. Es wäre doch schön, wenn man direkt im Lieblingseditor die Dateinamen verändern könnte.

Hier kommt die Werkzeugsammlung renameutils zum Einsatz.

Installation⌗

Installiert wird das ganze aus den üblichen Paketmanagern, also z.B.

brew install renameutils # macOS / Linuxbrew

pacman-S renameutils # Arch based

sudo apt install renameutils # Debian based

Benutzung⌗

Nun gibt es die Befehle: qmv und qcp, mit denen Dateien umbenannt, bzw. kopiert werden können.

Beispiel:

ls *.txt

Ausgabe:

Kopie von hallo.txt
Kopie von gutentag.txt
Kopie von abrechnung.txt

Nun verwenden wir unser neues Werkzeug:

qmv *.txt

Nun öffnet sich unser eingestellter Editor mit einer Dateiliste und wir können die Datei-Umbenennungen direkt im Editor vornehmen.

Fazit⌗

Das Verwenden von Shell-Kommandos zum Umbennen ist oft schnell. So geht das Umbenennen aller .txt Dateien in .md schnell von der Hand.

Für komplexe Fälle können wir qmv verwenden. Damit können wir unseren vertrauten Editor und alle darin vorhandenen Funktionen nutzen. Insbesondere, wenn wir keine einfachen Regeln zum Umbenennen formulieren können, helfen uns die renameutils hier stark weiter.

So ist bei mir der Alias

alias ren=qmv --format=destination-only

fest in meine Werkzeugkiste eingezogen.

When the initial Stable Diffusion models first came out, I fine-tuned them to add myself as a new concept. I did this by using the DreamBooth algorithm via fine-tuning. It only took about 5-10 images of myself. The results were pretty good (learning a new token, “mattrickard” on Stable Diffusion v1.5)

This time, I upgraded the model (SDXL) and upgraded the method (LoRA). Instead of fine-tuning, I was left with a relatively small (about 20 MB) of model weight deltas. I ended up doing LoRA applied to Dreambooth. There’s two methods I haven’t tried yet — textual inversion and pivotal tuning. The former adds a new token embedding and learns it via gradient descent. Pivotal tuning combines both textual inversion (training a new token) with Dreambooth LoRa (training a concept).

You can see how the models have improved in just a few months.

I definitely understand the sentiment behind the L. Peter Deutsch quote, "To iterate is human, to recurse divine." I enjoy an elegant recursive solution as much as other programmers, but lately I've been playing with another style of coding up similar needs that might just be easier and more flexible.

Elixir's ecosystem has quite a few HTTP clients at this point. But what's the best one? In this post, I want to break down a bunch of the clients we have available. I'll give an overview of the clients I personally like the most, and I'll talk about which clients are the best choice in different use cases. I'll also share some advice with library authors.

This is AI generated, just to be clear

All Your Clients Are Belong to Us

So, let's take a whirlwind tour of some HTTP clients available in Elixir. We'll talk about these:

• Mint
• Finch
• Req
• httpc

This is not a comprehensive list of all the Elixir HTTP clients, but rather a list of clients that I think make sense in different situation. At the end of this post, you'll also find a mention of other well-known clients, as well as advice for library authors.

Mint

Let's start with Mint. Mint is arguably the lowest-level HTTP client we've got in Elixir. It's essentially a wrapper around a raw TCP or SSL socket. Its job is to make the socket aware of the network protocol. It's stateless, meaning that all you deal with is a "connection" data structure, and it's process-less, meaning that it doesn't impose any process architecture on you.

Think about a :gen_tcp or a :ssl socket. Their job is to allow you to connect servers and clients on the TCP and TLS network protocols, respectively. When you're using one of these directly, you usually have to do most of the encoding of decoding of the data that you're sending or receiving, because the sockets carry just binary data.

Mint introduces an abstraction layer around raw sockets, rather than on top of them. Here's a visual representation:

When you use Mint, you have an API that is similar to the one provided by the :gen_tcp and :ssl modules, and you're using a socket underneath. Mint provides a data structure that it calls a connection, which wraps the underlying socket. A Mint connection is aware of the HTTP protocol, so you don't send and receive raw binary data here, but rather data that makes sense in the semantics of HTTP.

For example, let's see how you'd make a request using Mint. First, you'd want to open a connection. Mint itself is stateless, and it stores all the connection information inside the connection data structure itself.

{:ok, conn}=Mint.HTTP.connect(:http,"httpbin.org",80)

Then, you'd use Mint.HTTP.request/5 to send a request.

{:ok, conn, request_ref}=Mint.HTTP.request(conn,"GET","/",[],"")

Sending a request is analogous to sending raw binary data on a :gen_tcp or :ssl socket: it's not blocking. The call to request/5 returns right away, giving you a request reference back. The underlying socket will eventually receive a response as an Erlang message. At that point, you can use Mint.HTTP.stream/2 to turn that message into something that makes sense in HTTP.

receivedo  message ->{:ok, conn, responses}=Mint.HTTP.stream(conn, message)IO.inspect(responses)end#=> [
#=>   {:status, #Reference<...>, 200},
#=>   {:headers, #Reference<...>, [{"connection", "keep-alive"}, ...},
#=>   {:data, #Reference<...>, "<!DOCTYPE html>..."},
#=>   {:done, #Reference<...>}
#=> ]

Mint supports HTTP/1.1 and HTTP/2 out of the box, as well as WebSocket through mint_web_socket.

When to Use Mint

Generally, don't use Mint. Seriously. You know I mean this advice, because I'm one of the twopeople who maintain and originally created Mint itself! For most use cases, Mint is too low level. When you use it, you'll have to care about things such as pooling connections, process architecture, keeping the connection structs around, and so on. It's a bit like what you'd do in other cases, after all. For example, you're unlikely to use :gen_tcp to communicate directly with your PostgreSQL database. Instead, you'd probably reach at least for something like Postgrex to abstract a lot of the complexity away.

Still, there are some use cases where Mint can make a lot of sense. First and foremost, you can use it to build higher-level abstractions. That's exactly what a library called Finch does, which we'll talk about in a bit. Mint can also be useful in cases where you need fine-grained control over the performance and process architecture of your application. For example, say you have a fine-tuned GenStage pipeline where you need to make some HTTP calls at some point. GenStage stages are already processes, so having an HTTP client based on a process might introduce an unnecessary layer of processes in your application. Mint being processless solves exactly that.

A few years ago, I worked at a company where we would've likely used Mint in exactly this way. At the time, I wrote a blog post that goes into more detail in case you're interested.

Bonus: Why Isn't Mint in the Elixir Standard Library?

That's a great question! When we introduced Mint back in 2019, we posted about it on Elixir's website. Our original intention was to ship Mint with Elixir's standard library. This is also one of the reasons why we wrote Mint in Elixir, instead of Erlang. However, we then realized that it worked well as a standalone library, and including it into the standard library would increase the cost of maintaining the language as well as potentially slow down the development of Mint itself.

That said, I think of Mint as the "standard-library HTTP client", that is, the low-level client that you'd expect in the standard library of a language like Elixir.

Finch

Finch is a client built on top of Mint. It serves an important job in the "pyramid of abstractions" of HTTP clients listed in this post: pooling. Finch provides pooling for Mint connections. Using Mint on its own means implementing some sort of strategy to store and pool connections, which is what Finch provides.

Finch is quite smart about its pooling. It uses nimble_pool when pooling HTTP/1.1 connections. The nimble_pool library is a tiny resource-pool implementation heavily focused on a small resource-usage footprint as well as on performance. Since HTTP/2 works quite differently from HTTP/1.1 and the former is capable of multiplexing requests, Finch uses a completely different strategy for HTTP/2, without any pooling. All of this is transparent to users.

The API that Finch provides is still quite low-level, with manual request building and such:

{:ok, _}=Finch.start_link(name:MyFinch)Finch.build(:get,"https://hex.pm")|>Finch.request(MyFinch)#=> {:ok, %Finch.Response{...}}

However, but the convenience of pooling and reconnections that Finch provides is fantastic.

Okay, when to use Finch then? Personally, I think Finch is a fantastic library whenever you have performance-sensitive applications where you're ready to sacrifice some of the convenience provided by "higher-level" clients. It's also great when you know you'll have to make a lot of requests to the same host, since you can specify dedicated connection pools per host. This is especially useful when communicating across internal services, or talking to third-party APIs.

Req

Req is a relatively-new kid on the block when it comes to HTTP clients in Elixir. It's one of my favorite Elixir libraries out there.

Req.get!("https://api.github.com/repos/wojtekmach/req").body["description"]#=> "Req is a batteries-included HTTP client for Elixir."

It's built on top of Finch, and it takes a quite "functional-programming" approach to HTTP. What I mean by that is that Req revolves around a Req.Requestdata structure, which you manipulate to add options, callbacks, headers, and more before making an HTTP request.

req =Req.Request.new(method::get,url:"https://github.com/...")|>Req.Request.append_request_steps(put_user_agent: &Req.Steps.put_user_agent/1)|>Req.Request.append_response_steps(decompress_body: &Req.Steps.decompress_body/1,decode_body: &Req.Steps.decode_body/1)|>Req.Request.append_error_steps(retry: &Req.Steps.retry/1){req, resp}=Req.Request.run_request(req)

Req is extensively customizable, since you can write plugins for it in order to build HTTP clients that are tailored to your application.

When To Use Req

First and foremost, Req is fantastic for scripting. With the introduction of Mix.install/2 in Elixir 1.12, using libraries in Elixir scripts is a breeze, and Req fits like a glove.

Mix.install([{:req,"~> 0.3.0"}])Req.get!("https://andrealeopardi.com").headers
#=> [
#=>   {"connection", "keep-alive"},
#=>   ...
#=> ]

Req is also a great fit to use in your applications. It provides a ton of features and plugins to use for things like encoding and decoding request bodies, instrumentation, authentication, and so much more. I'll take a quote straight from Finch's README here:

Most developers will most likely prefer to use the fabulous HTTP client Req which takes advantage of Finch's pooling and provides an extremely friendly and pleasant to use API.

So, yeah. In your applications, unless you have some of the needs that we described so far, just go with Req.

httpc

While Mint is the lowest-level HTTP client I know of, there's another client worth mentioning alongside it: httpc. httpc ships with the Erlang standard library, making it the only HTTP client in the ecosystem that doesn't require any additional dependencies. This is so appealing! There are cases where not having dependencies is a huge bonus. For example, if you're a library author, being able to make HTTP requests without having to bring in additional dependencies can be great, because those additional dependencies would trickle down (as transitive dependencies) to all users of your library.

However, httpc has major drawbacks. One of them is that it provides little control over connection pooling. This is usually fine in cases where you need a few one-off HTTP requests or where your throughput needs are low, but it can be problematic if you need to make a lot of HTTP requests. Another drawback is that its API is, how to put it, awkward.

{:ok,{{version,200, reason_phrase}, headers, body}}=:httpc.request(:get,{~c"http://www.erlang.org",[]},[],[])

The API is quite low level in some aspects, since it can make it hard to compose functionality and requires you to write custom code for common functionality such as authentication, compression, instrumentation, and so on.

That said, the main drawback of httpc in my opinion is security. While all HTTP clients on the BEAM use ssl sockets under the hood (when using TLS), some are much better at providing secure defaults.

iex>:httpc.request(:get,{~c"https://wrong.host.badssl.com",[]},[],[])09:01:35.967[warning]Description:~c"Server authenticity is not verified since certificate path validation is not enabled"Reason:~c"The option {verify, verify_peer} and one of the options 'cacertfile' or 'cacerts' are required to enable this."

While you do get a warning regarding the bad SSL certificate here, the request still goes through. The good news is that this is mostly going away from OTP 26 onward, since OTP 26 made SSL defaults significantly safer.

When to Use httpc

So, when to use httpc? I would personally recommend httpc only when the most important goal is to not have any external dependencies. The perfect example for this is Elixir's package manager itself, Hex. Hex uses httpc because, if you think about it, what would be the alternative? You need Hex to fetch dependencies in your Elixir projects, so it would be a nasty chicken-and-egg problem to try to use a third-party HTTP client to fetch libraries over HTTP (including that client!).

Other libraries that use httpc are Tailwind and Esbuild. Both of these use httpc to download artifacts the first time they run, so using a more complex HTTP client (at the cost of additional dependencies) isn't really necessary.

Choosing the Right Client

I've tried to write a bit about when to use each client so far, but to recap, these are my loose recommendations:

Client	When
Mint	You need 100% control on connections and request lifecycle
Mint	You already have a process architecture, and don't want to introduce any more processes
Mint	You're a library author, and you want to force as few dependencies as possible on your users while being mindful of performance and security (so no httpc)
Finch	You need a low-level client with high performance, transparent support for HTTP/1.1 (with pooling) and HTTP/2 (with multiplexing)
Req	Most applications that make HTTP calls
Req	Scripting
httpc	You're a (hardcore) library author who needs a few HTTP requests in their library, but you don't want to add unnecessary transitive dependencies for your users

Some of the HTTP clients I've talked about here form sort of an abstraction pyramid.

Library Authors

I want to also talk about library authors here. If you're the author of a library that needs to make HTTP calls, you have the options we talked about. If you're only making a handful of one-off HTTP calls, then I'd go with httpc, so that you don't have any impact on downstream code that depends on your library. However, if making HTTP requests is central to your library, I would really recommend you use the "adapter behaviour" technique.

What I mean by adapter behaviour technique is that ideally you'd build an interface for what you need your HTTP client to do in your library. For example, if you're building a client for an error-reporting service (such as Sentry), you might only care about making synchronous POST requests. In those cases, you can define a behaviour in your library:

defmoduleSentryClient.HTTPClientBehaviourdo@type status() :: 100..599@type headers() :: [{String.t(),String.t()}]@type body() :: binary()@callback post(url :: String.t(), headers(), body()) ::
{:ok, status(), headers(), body()}|{:error, term()}end

This would be a public interface, allowing your users to implement their own clients. This allows users to choose a client that they're already using in their codebase, for example. You can still provide a default implementation that ships with your library and uses the client of your choice. Incidentally, this is exactly what the Sentry library for Elixir does: it ships with a default client based on Hackney. If you go with this approach, remember to make the HTTP client an optional dependency of your library:

# In mix.exs
defpdepsdo[# ...,
{:hackney,"~> 1.0",optional:true}]end

What About the Others?

These are not all the HTTP clients available in Elixir, let alone on the BEAM! I have not mentioned well-known Elixir clients such as HTTPoison and Tesla, nor Erlang clients such as hackney.

HTTPoison

HTTPoison is an Elixir wrapper on top of hackney:

HTTPoison.get!("https://example.com")#=> %HTTPoison.Response{...}

Because of this, I tend to not really use HTTPoison and, if necessary, go straight to hackney.

Hackney

hackney is a widely-used Erlang client which provides a nice and modern API and has support for streaming requests, compression, encoding, file uploads, and more. If your project is an Erlang project (which is not the focus of this post), hackney can be a good choice.

:hackney.request(:get,"https://example.com",[])#=> {:ok, 200, [...], "..."}

However, hackney presents some issues in my opinion. The first is that hackney had questionable security defaults. It uses good defaults, but when changing even a single SSL option, then it drops all those defaults. This is prone to security flaws, because users don't always fill in secure options. While not technically a fault of the library itself, the API makes it easy to mess up:

# Secure defaults:
:hackney.get("https://wrong.host.badssl.com")#=> {:error, {:tls_alert, {:handshake_failure, ...
# When changing any SSL options, no secure defaults anymore:
ssl_options =[reuse_sessions:true]:hackney.get("https://wrong.host.badssl.com",[],"",ssl_options: ssl_options)# 11:52:32.033 [warning] Description: ~c"Server authenticity is not verified ...
#=> {:ok, 200, ...}

In the second example above, where I changed the reuse_sessions SSL options, you get a warning about the host's authenticity, but the request goes through.

Another thing that I think could be improved in hackney is that it brings in a whopping seven dependencies. They're all pertinent to what hackney does, but it's quite a few in my opinion.

Last but not least, hackney doesn't use the standard telemetry library to report metrics, which can make it a bit of a hassle to wire in metrics (since many Elixir applications, at this point, use telemetry for instrumentation).

One important thing to mention: while HTTPoison is a wrapper around hackney, its version 2.0.0 fixes the potentially-unsecure SSL behavior that we just described for hackney.

Tesla

Tesla is a pretty widely-used HTTP client for Elixir. It provides a similar level of abstraction as Req. In my opinion, its main advantage is that it provides swappable HTTP client adapters, meaning that you can use its common API but choose the underlying HTTP client among ones like Mint, hackney, and more. Luckily, this feature is in the works for Req as well.

The reason I tend to not reach for Tesla is mostly that, in my opinion, it relies a bit too much on module-based configuration and meta-programming. In comparison, I find Req's functional API easier to compose, abstract, and reuse.

There are other clients in Erlang and Elixir: gun, ibrowse, and more. But we gotta draw a line at some point!

Conclusions

We went through a bunch of stuff here. We talked about the clients I personally like and recommend for different use cases. You also got a nice little summary table for when to use each of those client. Last but not least, I mentioned some other clients as well reasons why I prefer the ones in this post.

That's all. Happy HTTP'ing!

Acknowledgements

I want to thank a few folks for helping review this post before it went out. Thank you José, Wojtek, and Jean.

Hast du auch schon richtig Kohl- äh Kartoffeldampf auf deine Blauen Schweden, Granolas und Rosa Tannenzapfen, weißt aber nicht, wann der richtige Zeitpunkt für die Kartoffelernte gekommen ist? Keine Sorge, ich erkläre dir hier, woran du erkennst, dass du deine Kartoffeln ernten kannst und wie du auch schon besonders früh in den Genuss der ersten zarten Frühkartoffeln kommst. Also los geht’s! Die Vielfalt der Erntezeitpunkte von Kartoffeln Es sorgt meistens für reichlich Verwirrung, den richtigen Zeitpunkt zum Kartoffeln ernten abzupassen. Denn es gibt Frühkartoffeln, mittelfrühe Kartoffeln, späte Kartoffeln und sehr späte Kartoffeln. Frühe Sorten brauchen meistens nur 90 bis 110 Tage, bis du sie aus dem Boden ziehen kannst. Sehr späte Kartoffeln hingegen fühlen sich bis 170 Tage pudelwohl in deinen Beeten. Und dann gibt es noch Sorten, deren Reifedauern irgendwo dazwischen liegen. Du siehst, eine Universalempfehlung für den richtigen Zeitpunkt zum Kartoffeln ernten gibt es nicht. Es kommt immer darauf an, welche Sorte du eingepflanzt hast. Aber auch die Witterung und der Anbauzeitpunkt wirken sich darauf aus, wann deine Kartoffeln erntereif sind. Wenn du deine Frühkartoffeln …

Der Beitrag Kartoffeln ernten: Wann kann die tolle Knolle aus der Erde? erschien zuerst auf Wurzelwerk.