Skip to content

Der Verkauf von .org

Wir haben heute Morgen unsere Daten zu den Unterzeichnern von savedotorg.org geschickt. Eine wirklich gute Sache.

Gerade wir als Hoster werden von einem Verkauf von .org betroffen sein. Ich persönlich befürchte ja, dass die Domains nicht nur minimal, sondern durchaus merklich teurer werden könnten.

Denn sind wir 'mal ehrlich: Gerade beim Preis können Registrare, Hoster und letztendlich Kunden nicht (mehr) viel machen, wenn die Preiserhöhung erst einmal im Raum steht. Und ein Investor tut das (ein Kauf) ja quasi nie aus ethischen oder sozialen Gesichtspunkten heraus, sondern aus Gründen der Generierung von Profit (entweder im laufenden Betrieb über Erträge oder über einen späteren, höheren Verkaufspreis).

Daher lieber vorher gegensteuern und zumindest Widerstand leisten, damit all diese unsäglich geldgeilen Investoren (ich ich mag den Terminus "Investor" eigentlich nicht wirklich, er ist ja primär positiv assoziiert) einen gewissen Gegenwind spüren. Vielleicht wird dann die Angst vor einer Fehlinvestition so groß, dass die Bewertungswaage kippt.

Weihnachtsfeier geplant

So schnell hatten wir noch nie einen gemeinsamen Termin für unsere Weihnachtsfeier finden können. Binnen weniger Stunden hatten wir einen Termin und einen Ort gefunden.

Dieses Jahr werden wir es "ruhig" angehen lassen - auf Wunsch quasi aller - und "nur" in einem Restaurant feiern.

Ich freue mich sehr.

Bachelor of Engineering und winmail.dat

Ich erhielt eine E-Mail mit einem Anhang, die eigentlich eine PDF sein sollte. Es war aber eine winmail.dat. Ich vermute: Digitale Unerfahrenheit.

In der Signatur hatte der Unterzeichner ein "Bachelor of Eng." (also Bachelor of Engineering).

Was man heutzutage im Studium so alles lernt. Nicht.

Leidenschaftlicher Programmierer

Aufgrund des lieben Kommentars von Jens habe ich mich dazu entschieden, auf den zugegeben nicht ganz so lieben Kommentar von Manni zu "antworten" - bzw. ganz allgemein zu dem Thema.

Ich bin seit meinem 13. Lebensjahr Programmierer. Und ich behaupte, dass ich von Anfang an mit Leidenschaft dabei bin (und mit Leidensbereitschaft, mit 14 war C++ dran).

Programmieren ist für mich keine Last, sondern eine wahnsinnig große Freude, die mich zugleich erfüllt und entspannt. Nachts oder früh morgens in (m)einem ruhigen Büro mit guter Instrumentalmusik zu sitzen und zu programmieren, ist für mich besser als jede Netflix-Session. Ich bin dann quasi glückselig.

In 99% der Fälle programmiere ich dabei "irgendwas" für manitu. Und ja, auch "CEO eines global agierenden Unternehmens" (Zitat Manni) tue ich das. Vielleicht auch gerade deswegen. Ich möchte "auch als CEO" nicht den Bezug zur Basis verlieren. Ich arbeite genauso im Support mit, und programmiere genauso mit. Bei fast jedem Projekt.

Ich gebe zu, dass ich gerade beim Programmieren sehr penibel bin. Da ich täglich sehe, was Code von tausenden anderen (z.B. die unzähligen Pakete in jeder Linux-Distribution) anrichten kann, lege ich Wert auf kleinste Details. Manchmal entscheiden diese kleinen Dinge über "Leben oder Tod".

Und genauso lege ich Wert auf Ressourcen sparenden Code. Ja, man muss Code nicht bis zum letzten Detail durchoptimieren, er soll v.a. für einen selbst und andere (!) lesbar sein. Alles, was der Lexer eh wegoptimiert, muss man nicht selbst optimieren.

Aber um einmal in dem konkreten Beispiel zu bleiben: Wenn man aus dem Paket php-iban z.B. nur die Funktion iban_to_machine_format() verwenden möchte, muss man eben die php-iban.php einbinden - und das liest automatisch die genannte registry.txt (quasi als Art von "main"-Funktion der Datei). Obwohl sie für diesen Funktions-Aufruf nicht verwendet wird.

Das wäre vielleicht nicht ganz so schlimm, wenn es eben nicht üblich wäre, solche Bibliotheken via Composer zu verwenden und auch aktuell zu halten. Somit wird die Datei in jedem Projekt, das die Bibliothek verwendet, mitgeladen. Beim Aufruf jeder PHP-Datei, die den Composer-Autoloader nutzt. Also vermutlich jeder.

Mein Patch bestand aus ganzen 3 Zeilen. Ich habe das Laden registry.txt einfach ausgelagert an die 2 einzigen Stellen, an denen sie nötig ist. Der Autor des Pakets hatte in seiner _iban_load_registry() bereits Code drin, der ein doppeltes Laden der Datei vermeidet.

Seht selbst:

Ich hatte gesehen, dass der Autor Patches nicht sehr aufgeschlossen ist, daher hatte ich meinen Patch so klein wie möglich gehalten. Quasi ohne Impact - auch optischer Natur ;-)

Normalerweise hätte ich, wie es auch in einigen Kommentaren hier bereits gesagt wurde, vorgeschlagen, die Datei in ein PHP-Code umzuwandeln und ggf. sogar noch bedingt via require_once() einzubinden, dann hätte der PHP-OPCache sie mitopitmiert.

Schade, dass der Autor dem Patch nicht sehr aufgeschlossen zu sein scheint. Vielleicht möchtet Ihr ihn ja nochmal mit Kommentaren im Pull-Request dazu animieren ;-) ?

Umgefallen

Gestern hier direkt vor meinem Fenster. Schade, dass ich Euch die Gesichter nicht zeigen kann:


Es sieht so aus, als ob dabei nicht einmal Glas zu Bruch gegangen wäre. Glück gehabt!

Wir haben unsere Lieferung übrigens noch bekommen :razz:

Meine persönliche Erfahrung mit BTRFS

Ich plaudere 'mal aus dem persönlichen Nähkästchen.

Ich hatte eine ganze Zeit lang einen persönlichen Server mit BTRFS am Laufen. Weniger wegen RAID, mehr wegen Snapshots.

Bislang fand ich BTRFS "schick": Es ist im Kernel, einfach zu benutzen, die "normalen" Tools zum Anlegen und Verwalten sind intuitiv.

Bislang.

Was meinen Eindruck - gelinde gesagt - geändert hat, ist das Verhalten von BTRFS im Desaster-Fall. Es gibt ja diverse Anleitungen, Howtos etc. (siehe z.B. hier). Aber sind wir mal ehrlich: Das ist gefühlt alles mehr Glückssache als etwas Handfestes.

Ich weiß, dass es keine eierlegende Wollmilchsau bei den Dateisystemen gibt, aber ein einfaches "btrfs-check-and-repair" wäre sinnvoll. Im Endeffekt interessiert es mich - auch als sagen wir mal technisch versierten :-) - Nutzer nicht, wie ein Tool das macht. Als Technie mit Programmierergenen wünsche ich mir ein "mach halt", das alles tut, was automatisch möglich ist.

Um es nochmal genauso ehrlich zu sagen: Fast kein Anwender wird irgendwelche "manuellen" Entscheidungen treffen wollen, oder gar im Dateisystem rumspielen. Es ist mir lieber, wenn 90%+x wiederhergestellt werden, aber das zeitnah, und ich den Rest aus einem Backup wiederherstellt, als dass ein Tool versucht, 100% zu erreichen - es aber nie schafft.

Ich bin daher zu ZFS gewechselt. Ich bin gespannt, wie sich das schlagen wird :-)

Das gilt im Übrigen auch für alle manitu-eigenen Systeme. Das war vor ein paar Tagen eine "Anweisung von oben" von mir an die Technik. Die Migration läuft bereits.

Good bye, BTRFS.

manitu Stofftragetaschen

Seit heute gibt es die manitu Stofftragetaschen für nur 1 Euro im Fan-Shop :


Und da ich vermute, dass die Diskussion aufkommen wird ;-) : Wir könnten 1 oder vielleicht 2 irgendwie in einen Briefumschlag stopfen, oder ggf. auch Päckchen statt Pakete versenden. Beides möchten wir aber nicht. Unter anderem, weil wir ein IT- und kein Versandunternehmen sind und diesen Fan-Shop eben auch genau als das sehen: Von uns mit Liebe für manitu-Fans. Wir verschicken daher ordentlich in Paketen mit DHL.

Neuer Cookie-Hinweis auf unserer Webseite

Ich bediene mich 'mal bei unserem Twitter-Account ;-)

Seit gestern haben wir unseren Cookie-Hinweis verbessert:


Ich finde ihn nun wunderbar klar.

Wer alle nicht nötigen Cookies ablehnt (nötig sind ja z.B. Cookies eben für genau diese Entscheidung, oder auch den Warenkorb), erhält an den relevanten Stellen einen Hinweis:


Das ist z.B bei der (Nicht-)Historie der FAQ-Suche relevant.

DSL in Leitersweiler geht zu Ende

Seit 13 Jahren haben wir das Projekt bzw. den Verein DSL in Leitersweiler unterstützt. Das Projekt geht nun zu Ende - da ein lokaler Netzanbieter dort ausgebaut hat.

Der kleine Ort hier in der Nähe hat sich seit 2006 mangels DSL-Versorgung über eine Richtfunkstrecke zu uns selbst versorgt. Wir haben dabei eigentlich "nur" einen Mast, den Platz für Infrastruktur und natürlich die IP-Connectivity (samt fester IP-Adressen) zur Verfügung gestellt :-)

Es war eine schöne, reibungslose Zeit. Ich zitiere aus der E-Mail des Projektverantwortlichen zum Abschluss:

Die Apachen-Buchhaltung

Diese Antwort auf eine Zahlungserinnerung wollte ich Euch nicht vorenthalten:

In unserer Zahlungserinnerung steht übrigens nichts von "mit noch freundlicher Gesinnung". Das nur am Rande.

Und: Wie man bei uns nicht wissenlicht bestellen kann, ist mir ein Rätsel. Wir haben die Hürden im Bestellprozess bewusst hoch gelegt.

22 Jahre manitu

Heute vor 22 Jahren begann die Geschichte von manitu - und ich bin jeden einzelnen Tag glücklich damit und stolz darauf.

Stolz darauf, dass wir seit 22 Jahren uns und dem Geist von und den Idealen hinter manitu treu geblieben sind, und die mir persönlich so wichtig waren, sind und immer sein werden, und die ich als die DNA von manitu sehe: Die Menschlichkeit.

Stolz darauf, dass wir seit 22 Jahren durch unsere Kunden, Partner, Freude und viele mehr täglich lernen, uns verbessern, uns in Frage stellen, uns korrigieren, uns bestärken. All dies ist Teil des Reifeprozesses von manitu, der nie enden wird. Daher an dieser Stelle ein herzliches Danke an Alle - denn erst Ihr alle habt das möglich gemacht.

Glücklich, weil es die beste Entscheidung meines Lebens war und ist, das Wagnis Selbständigkeit vor 22 Jahren eingegangen zu sein. Ich kann mir keine Aufgabe - keine "Berufung" - vorstellen, die mich mehr erfüllen würde als manitu.

Das, was ich damals zu unserem 10 jährigen Jubiläum geschrieben habe, kann ich mit gutem Gewissen heute noch genauso sagen.

Stoßt mit uns an, z.B. mit einem Käffchen aus der manitu-Tasse :-D