Henri rüstet auf. Statt 50er ab dem 7.7. dann 125er. ..

Soeben aus dem Bergischen abgeholt. Jetzt noch instandsetzen, TÜV und anmelden.

Der Stiga brauchte einen neuen Zahnriemen also haben Henri und ich den getauscht. Henri hatte schon alles zerlegt.

Aber WTF? Wie kommt man da drauf als Hersteller bei 4 Schrauben 3 unterschiedliche Sorten zu nehmen.

Stiga muss seinen Service wirklich hassen so wie die das konstruieren.

Seit gestern läuft mein Glasfaseranschluss. Nach diversen Problemen welche Faser es denn nun sei, und welcher Port und Splitter läuft es nun. Umgebaut. Geht.

Die alte Festnetznummer ist damit tot und es gibt eine neue. Auf der alten haben sowieso nur Photovoltaik Vertriebler angerufen die mir eine schicke Anlage fürs Dach verkaufen wollten.

Das letzte mal hab nichts mitbekommen weil ich draussen gestanden und sinnlose Telefonate geführt habe. Heute in voller Länge. Sehr kurzweilig.

Vorbereitung ist alles. Bei Köln im Stau rumstehen. Wenigstens die Nägel schön.

Microsoft Exchange Autodiscover is a very bad documented and complicated beast. To get everything right for all of your users may be difficult. So - one would like to see the reponses which is pretty hard to get right.

So here is the curl request you need:

curl --http1.1 \
    -d -vvv \
    -XPOST \
    --user "${USER}:${PASS}"  \
    -H "user-agent: Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.10368; Pro)" \
    -H "X-User-Identity: ${EMAIL}" \
    -H "X-AnchorMailbox: ${EMAIL}" \
    -H "X-MAPIHttpCapability: 1" \
    -H "client-request-id: {$UUID}" \
    -H "X-MS-Negotiate: Server" \
    -H "Content-Type: text/xml" \
    https://autodiscover.$DOMAIN/Autodiscover/Autodiscover.xml  \
    -d @/tmp/t.xml

And the xml file to be posted:

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
    <Request>
    <EMailAddress>EMAIL</EMailAddress>
    <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
    </Request>
</Autodiscover>

As long as you dont sent the right "user-agent" you only see half of the game, namely the OWA endpoint. For evrything else you need to send the right user-agent.

Woche 3 der Ransomeware aufräumarbeiten beim Kunden. Es gibt Backups aber am Ende muss alles neu aufgesetzt werden. Die ersten 1200 Notebook Clients sind durch die Automatische Installation gelaufen. Essentielle Dienste laufen. Es knirscht aber noch überall.

Immerhin ist die Versorgung gut.

When looking for exporting the DFS targets from an AD DS dump created with ldifde you stumple upon tons of issues with bullshit microsoft creates.

First they create an .xml file with information, put this into the AD attribute msDFS-TargetListv2 and fuck up the base64 encoding beyond repair in ldifde:

See this?

\\48AD8AeABtAGwAIAB2AGUAcgBzAGkAbwBuAD0AIgAxAC4AMAAiACAAZQBuAGMAbwBkAGkAbgBnAD
0AIgB1AHQAZgAtADEANgAiAD8APgANAAoAPAB0AGEAcgBnAGUAdABzACAAbQBhAGoAbwByAFYAZQBy

Okay - this looks like base64 except the "\" at the beginning. Removing the \ breaks the base64 so you'll need them

After playing around a bit Microsoft fucked this up by replacing the needed "//" with "\".

I guess they simply pushed stuff after the base64 encoder through the filepath decoder or something.

Fucked up beyond repair

Rebuilding Debian/Stretch for MIPSel with --march=mips2 caused some packages to fail with symbol changes. Which at first puzzled me a bit but i just built the packages with ignoring the symbols.

Now we are at the last 10% of packages and i thought to dig into this a bit deeper.

So i found that some symbols simply changed. They did not disappear but changes in some subtle issue that i did not understand. So i dug into dpkg-gensymbols and how it actually did the decoding - and - Oh boy ... i wish i had not have a look.

I saw the c++ symbols from binaries for at least 15 years and had no clue on what that actually was, but now it was time to find out. Basically the c++ compiler mangles the complete function/method declaration into the c++ symbol.

Consider you have this little c++ snippet:

#include <string>

typedef std::basic_string<char> bstring;

int bar(bstring& foo) {
    foo="baz";
}

If you compile this into a shared object the symbol for bar gets:

_Z3barRNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

So how does one decode this, or how is this constructed? So c++filt comes to help to decode:

root@stretch:~# c++filt -n _Z3barRNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
bar(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)

So you can decode the full symbol to the functions declaration.

Now - after staring at the Debian/Mipsel symbol issues i found something to be missing. Compiling the same test code, with the same compiler on Mipsel and on amd64 caused the __cxx11 to be dropped from the symbol on Mipsel. So i have a broken c++ compiler on Mipsel. I transitioned from Jessies gcc 4.9 to gcc 5.1.1-23 (Which had c++11) to gcc 6.1.1 to gcc 6.3.0 and now i am generating broken symbols. So some libstdc++ abi transition has failed.

Es ist soweit. Es ist draussen warm genug. Homeoffice draussen.

Es gibt ja so die Idee das in Deutschland die Regelgeschwindigkeit absenken könnte. D.h. durch einen einfachen Trick in der StVO einfach 30km/h statt 50km/h hinter dem Ortsschild anordnet. Das ganze geht natürlich im ersten Schritt komplett ohne neue Beschilderung.

Hört sich in der Theorie total super an um der "Vision Zero" näher zu kommen, nur was heisst das für das Routing/Navigation.

Der erste Punkt ist das ja schon alles was es an Wohngebieten gibt heute schon mit einer Zone 30 oder dem Verkehrsberuhigten Bereich mit Zeichen 325 versorgt ist. D.h. aktuell sind nur noch die höherwertigen Straßen, Arterien oder Magistralen überhaupt noch schneller zu befahren.

Aber was passiert wenn wir das ändern?

Naja - Das kann eigentlich jeder zuhause ausprobieren und mal z.b. mit OSMAnd von "Schnellste Route" auf "Kürzeste route" umstellen.

Denn wenn alle Straßen "gleich schnell" sind dann zählt nicht mehr die Geschwindigkeit sondern nur noch die Distanz. Mit der Folge kommt es dann dazu das das routing sich weiträumig verändert. Auch bisher für das Routing uninteressante Wohngebiete sind mitunter jetzt kürzer und damit schneller. D.h. der Verkehr wird sich von den Magistralen in die Wohngebiete verlagern.

Um das zu demonstrieren hab ich einen "Live routenvergleich" gebaut der mit dem jeweilig identischen Datensatz arbeitet, jedoch die Regelgeschwindigkeit von 50 absenkt.

Hier ein erstes Ergebnis. Route vorher ist "grün". Router hinterher ist "rot".

Wie kommt es jetzt zu dieser Routingänderung?

Der Nordring ist mit Tempo 70 Beschildert. D.h. hier würden die Geschwindigkeiten weiter gelten. Dadurch gewinnt der natürlich deutlich an Priorität und zieht noch mehr Verkehr an. Die Arterien wie Marienfelder Straße innerhalb des Rings, oder die Bismarckstraße verlieren an Bedeutung.

Der nächste Versuch ist den Nordring auch auf Tempo 30 abzusenken.

I had a look at some QA output of mine which analyses tagging on ways like lanes, turn:lanes etc and i found TONs of oneway=no tagging.

I initially assumed these were some rouge users starting to sprinkle oneway=no everywhere and started to comment on the changesets.

After i while i discovered these were "StreetComplete" users.

So StreetComplete once again started to get users into tagging wide spread defaults on roads with ANY consent of the wider community.

Another RTC died of drained batter. Open the RTC, attach a CR2032 and there we go.

Debian dropped the support for all older MIPS based machines with the transition from Debian/Jessie to Debian/Stretch.

It was decided that from Stretch on all binaries would by default be compiled with --with-arch-32=mips32r2 which is basically only for machines produced after like 2015. All machines i initially boostrapped Debian/mips and Debian/mipsel with back in the 90ies dropped of the supported list.

So all big endian machines like the famous SGI Indy and SGI Indigo2 which were one of the first targets to be supported are now stuck with Debian/Jessie. The little endian machines like the Cobalt Cube and RAQ and the Decstations are also "dead in the water". As these machines are still see Kernel Development its a shame we dont have ANY recent userspace available.

So last week i did some work on Colo the Cobalt bootloader to be buildable with modern toolchains. The i set up sbuild and schroot to build stretch packages for a mips2 based Debian/Stretch. I most likely will not be ALL of Debian packages but just a subset like required, important, build essentials and tools everyone wants.

I start with Stretch as i want to have an upgrade path for the installations out there.

I had and have some issues calculating build order for packages. I have some first hacked improvised script which calculates required binary packages from amd64 Packages by recursive walking through Source Package Build-Depends. Then trying to match those packages to Jessie/Mipsel and rebuild Stretch/mipsel packages, trying to satisfy Build-Depends.

The little Cobalt Cube2, although nearly 25 years old is now very slowly churning through buildable packages.

I still have issues that the resulting Packages are still "uninstallable" as other packages are missing. Like debhelper beeing buildable, but the resulting packet depending on dh-autoreconf which i hadnt had. This rendered debhelper uninstallable in sbuild.

So i guess i need to fix the "incoming" queue for reprepro, not ingesting packages which are not installable by the Stretch repository and the old Debian/Jessie/Mipsel repository, or probably not only matching Build-Depends but also also Depends to get the buildable or needbuild packages.

Soon another machine will join in to build little endian packages and probably i'll find some big endian machine to build also a mips2 based big endian Debian/mips.

Sehr spannend. Ist das so ein Radiologie/MRT Fehlermodi das die das Helium ablassen müssen?

Also in den Schneepflug passt nur mein 9 Jähriges ich. Aber süß.

Was können die? Leider gehen die ja nur mit einer Deutschland Card die ich ja ablehne, oder irgendeiner anderen Schnüffelapp.

Okay ....vielleicht ist das mit dem Konfetti ein bisschen eskaliert. Und die Konfettikanonen haben wir nicht einmal abgefeuert.

Mit allen zusammen. Sehr schön.

Süß.

Man erkennt die Weihnachtszeit ja hauptsächlich daran das sich die Paketzusteller was für die Piktogramme in der Übersichtskarte einfallen lassen.

Hier DPD:

Gebraucht 2 Sedus Temptation Schreibtische erstanden. Upgrade des Arbeitsplatzes. Sehr schön geworden.

No. 2 of my antipatterns: "Landuse drag". Mappers seem to have the tendency to make little small pieces into one large, huge, even gigantic object. So they start dragging the landuse (and other objects) further and further along a road, across a road or whatever. The resulting object then rather looks like a very long snake following some arbitrary other object.

These snake like objects, or huge objects have the tendency to break pretty regular. More complexity is a unavoidable consequence by suddenly you are in the need of multipolygon relations, or unexperienced mappers accidentally break the object.

So - With landuse its like with all others things in life - Keep it simple and stupid.

See this example where someone tried to include the 4 trees on the other side of the road into the MUCH larger forest area. The falsely included area of the streets outweights by far the correctly included area. The other problem is that the boundaries of the landuse now do not follow visible contrast in the aerial imagery. Very confusing.

Another example is this. Landuse is beeing dragged along a street, making the landuse=residential a backdrop of the street. It includes the full streets width although only one side really contains residential usage. The south-east part should really be its own landuse stopping at the shoulder of the street. Again the abuse of landuse to try to make a "gapless" map makes these geometries a lot more complex than they need to be.

The last example for today is this. Dragging the landuse across a huge intersection, just to include the 4 other building on the other side. This includes more area used for traffic than it includes real residential area. Again the perimeter of the landuse does not follow any visible contrast boundary in the aerial imagery, crossing the roads in absurd and completely random angles.

So to summarize: Landuses should follow stuff you can actually see in an aerial. They should not erratically cross other objects or include other objects/area which are not represented by this landuse. Landuses are not a "backdrop" behind streets just to make the map "gapless".

If it gets to complicated, split it into smaller chunks.

For some time i was thinking about making a blog post series about geometry mapping antipattern which i find often in our dataset. So here we come with No. 1. "Keep Left"

Have you ever wondered why you get stray "Keep left", "Keep right" announcements from your navigational system although you are on a straight road cruising ahead?

It because of geometry. All announcements concerning the driving direction are direct causes of the street geometry. So when you get an announcement, have a look at the geometry.

One of the issues is sharp angle intersections. The navigation sees it as a road "split" so it tells you which of the two ways you need to take.

But lets have a look at an example intersection i found within 30 seconds.

You see - the side road joining into the tertiary goes in a straight line into the main road. But is it really at this angle? Lets have a look at the aerial photo:

You can easily see that taken the rough direction of the road the intersection is correct. But are you actually merging like this into a busy main road? Typically not. You stop nearly at 90° to the main road to have clear sight into both directions. And when you take a very close look at the roads area you'll see a trumpet like widening of the road for the vehicles to stop at 90°.

So when following the center line of the road, and on the last 10m we follow the center line of the trumpet we suddenly see a 90° intersection show up.

See this example. The grey area shows your asymmetric trumpet like area, and the yellow line shows the real center line of your road.

So when drawing simple intersections like this, most likely in the countryside, have a closer look and try to maintain a half way 90° Angle. If you hear stray announcements. Remember the position and have a look at the geometry.

Es ist kalt und es hat mehrere Tage geschneit. Der Kaffee der heute morgen auf das Lenkrad getropft ist war gefroren bevor wir losgefahren sind.

Wenn ich groß bin und meine eigene Firma habe werde ich auch so eine Brücke haben.

Der letzte Bus ist weg.

Eine neue Ladung historische Rechner. Digital, Sun, HP, NCD, Wyse.

Das basteln nächstes Jahr ist gerettet.

Immer wieder was neues. Heute: Keilriemen zerfleddert. So ohne Servolenkung, Lichtmaschine und co ist es dann doch nicht so schön fahren.

Nach Monaten der Diskussion einfach Mal das Loch wirklich suchen und Flicken.