Though I haven’t had a chance to taste Swiss Vivi Kola yet, most of the German Coca-Cola alternatives just taste better anyway.

So this probably isn’t just a win for the Made in Europe movement, but also for the tastebuds of travelers.

Oh boy, here I go ranting against misinformation about recycling again.

Your claim that 60% of these bottles will be burned is false. The recycling quota for single-use plastic bottles in Germany is 97.6% (2023; source).

60% was the quota of all non-recycled plastic packaging material combined, back in 2018. This quota has further decreased since, and is now at about 30% (2023, source), so almost 70% of all plastic packaging in Germany is recycled. It’s still not perfect, but far, far better than just burning everything.

Recycling isn’t an easy and cheap process, but it can definitely work and be steadily improved, if it’s properly implemented. I’m so tired of this dumb suggestion, that recycling is bad because it’s not perfect (or, in the case of the US, full of corruption). Every bit of plastic that isn’t polluting the environment is a win. And recycling is definitely helping with that. As opposed to propagating false information on the internet.

Der Lizenzwechsel ist deshalb nicht möglich, weil der Code einer Distributed Ownership unterliegt. Im Kernel gehört der Code also dem Entwickler, der ihn beigetragen hat, weshalb Linux quasi tausende Eigentümer hat. Und da die verwendeten GPLv2- und BSD-3-Clause-Lizenzen keinerlei Upgrade-Klausel oder ähnliches beinhalten, darf der Code auch nicht einfach unter einer anderen, kompatiblen Lizenz vertrieben werden. Details dazu stehen im Punkt 1.5 Licensing der Prozessdokumentation des Kernels.

Und ja, Maintainer können abgesägt werden, das ist ja schon mehrfach aus diversen Gründen passiert. Aber ich glaube nicht, dass man realistisch betrachtet so viele Maintainer so schnell rauswerfen und ersetzen könnte, dass US-Modifikationen am Kernel zum Problem werden würden. Es ist ja nicht so, dass heute die Maintainer ersetzt werden und morgen dann auf allen Linux-Kisten ein kompromittiertes US-System läuft. Ich glaube, dass, sollte so etwas überhaupt passieren, sehr schnell ein Fork verfügbar wäre, der einen Kernel ohne Beeinflussung bereitstellen würde. Genug kompetente ehemalige Linux-Maintainer gäb es dafür dann ja.

Ich finde nicht, dass im Falle von Linux (und vielen anderen Open Source-Projekten) eine Abhängigkeit von den USA besteht.

Eine Abhängigkeit würde sich hier meiner Meinung nach daraus definieren, dass dein Gegenüber dir deine bestehenden Systeme lahmlegen oder zerstören könnte, ohne dass du konsequenzarm zu Alternativen ausweichen könntest. Bei Closed Source-Produkten wäre das beispielsweise der Fall, wenn Microsoft, einer trumpschen Weisung folgend, mittels seines Onlinekontenzwangs keine Logins aus der EU mehr zuließe.

Das ist jetzt natürlich ein Extrembeispiel, aber ähnliches wäre für Linux einfach nicht möglich. Selbst im Worst-Case, also wenn Sanktionen quasi ohne Beteiligung der sehr internationalen Maintainer-Community direkt in den Kernel gemerged werden würden, würden doch sämtliche nicht-amerikanischen Distributionen sofort den letzten sauberen Kernel forken und darauf aufbauend weiterentwickeln. Ein Lizenzwechsel des Kernels ist zudem praktisch unmöglich, weil dem alle bisher beteiligten Entwickler zustimmen müssten, was eine Restriktion weiter erschweren würde.

Es können natürlich durch Supportverträge oder die Verwendung bestimmter Distributionen (RedHat) Abhängigkeiten entstehen, die sehr wohl als solche bezeichnet werden können, weil die dahinterstehenden Unternehmen Sanktionen umsetzen könnten. Aber da ich bei Linux ansich keine realistische Möglichkeit sehe, Sanktionen der USA wirkungsvoll zu implementieren, würde ich hier, wie bei den meisten Open Source-Projekten, nicht von einer Abhängigkeit sprechen.

And that arrogant “I understand it, why don’t you?!”-attitude is exactly what’s so often the main issue in the design process of open source software.

I’d recommend watching this recent talk by Tantacrul, the design lead for MuseScore and Audacity. In it, he shows some videos of first-time user tests he conducted for Inkscape recently. It’s really fascinating to see, how users fail to do what they want because of confusing UX choices. And often it isn’t even that hard to fix. But open source image editors are just full of these little annoyances by now, which really smell like the result of inadequate user testing. And no professional would prefer to work all day with software full of little annoyances when there are alternatives.

I mean, just try adding text in Krita, for example. There’s a giant pop-up where you have to format your text without actually seeing it on your image. That’s just klunky and far more time consuming than a WYSIWYG approach would be.

This isn’t Adobe.

And as much as I want to like Krita, GIMP and such, their workflows just can’t compare with proprietary software in many cases. Also, especially for photo editing, their feature sets can’t compare with Adobe’s or Affinity’s either.

I use Krita, GIMP and Affinity Photo pretty regularly, and while there have been great improvements to the open source alternatives recently, I just get stuff done with Affinity, while still having to constantly search the web for things Krita and GIMP hide somewhere deep within their menus.

All open source image editors I’ve used are in dire need of a complete UX rework (like Blender and Musescore successfully did) before being more than niche alternatives to proprietary software.

So, as of yet, I can definitely understand the wish for a feature-rich and easily usable image editing suite on Linux.