Tumblelog by Soup.io
Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

July 07 2015

I recall when people first proposed writing a read-only filesystem for an internal project at work. While I cannot talk much about what we have implemented, I can at least say it made and still makes sense to solve our problem by implementing a filesystem.

Filesystems can be written in many ways and their implementation specifics and problems they try to solve can range from easy to very hard. Filesystems such as BTRFS, ext4 or zfs take years or even decades to write and stabilize. They are implemented in kernel land, hard to debug and use sophisticated data structures for maximum performance and reliability. However with the addition of FUSE in the 2.6.14 Linux kernel and it’s subsequent porting to other POSIX operating systems such as FreeBSD, OpenBSD and MacOS, it became much easier to write and prototype filesystems. These filesystems are userland processes that talk to a simple kernel driver that redirects filesystems calls to the userland process when necessary. In our particular case, we didn’t need maximum performance, and we could heavily rely on kernel side caching, which made writing a fuse filesystem a reasonable choice.

Prototyping

In order to get a proof of concept, I decided to write a first version in Python. fusepy is a well known and stable implementation. Writing the initial prototype was a pleasure. Most things worked out of the box and we knew our idea works. However filesystems aren’t your standard piece of software and come with a set of performance characteristics that made fusepy and python a good choice for a prototype but a rather mediocre choice for a production-ready implementation. Most programs obtain data, do some processing and write the data somewhere. Most of their time is spend in userland running the program. Filesystems are slightly different. A program like ls will try to obtain the information of a list of files by issuing multiple, often hundreds of stat calls to the kernel, causing context switches into the kernel. Once the kernel figured out that we are a fuse filesystem it will hand the task of returning the file information to the fuse kernel module. The fuse module will then take a look into a cache and if necessary issue a request via IPC to the fuse userland daemon and subsequently to the userland program. At that point we already doubled our context-switches in contrast to a regular kernel-filesystem. Now that we spooled up a stat request in userland we try to return it with at least effort as possible (we still have 99 other requests to go) and return it back to the kernel, which then returns the result via the virtual filesystem layer back to the userland process which issued the request, effectively leading to 100% context-switch overhead to traditional kernel filesystems. To make things worse, python will also take a global interpreter lock in the meantime, allowing one request at a time to be served. There is also an overhead in calling a python function compared to a C function, which given the amount of requests, can add up significantly. In addition python will need to do some datastructure juggling. While this barely gives you a full picture as to why python is not necessarily a perfect choice for a production-ready implementation, it’s enough to say, it’s not optimal.

Choosing a language

Now that we have our prototype we want to get a production-ready version fast, but we also want to minimize our overhead to get good performance. At this point we want to consider a reimplementation of the python prototype in a language that is more suitable for high-performance systems programming. What are our common choices? C, C++, Go, Rust, Haskell and D are common competitors in the systems programming world. So let’s see…

C/C++

Without a doubt C/C++ is reasonable choice. They have by far the best support for FUSE as libfuse is written in C. They are great for high-performance applications. However you will need to do your memory management yourself and deal with a class of potential errors which might not even exists in other languages such as a multitude of undefined behavior, memory management and certain types of overflows. In the end while we all agreed they are conservative reasonable choices we opted for languages which we believed get us faster to a working version.

Go

Go seemed interesting but actually fell through quite fast upon realization that calling from C into Go can lead to a 10x overhead due to stack-rewriting. This is caused by Go not following C calling conventions and uses different stack layouts.

Haskell

A great choice, but due to lack of expertise, ramp up time, etc we decided against it.

Rust

Certainly nowadays a great choice. The project I am talking about is a bit older and back then rust was not stable at all and could very well change behavior. So in addition to learning a new language we didn’t want to deal with a constant change of APIs and language features. These days I would certainly reconsider using it.

D and the good parts

As mentioned in earlier blogposts. D feels like Python in many ways but has C performance characteristics. In addition, it’s fairly mature, it uses C calling conventions and we had expertise in using it. It works well on MacOS and Linux which is all we cared (in fact D works pretty well on Windows too). So we went for it. We knew from the beginning we had to write a smaller wrapper around libfuse. D is very similar to C and C++ and really cares about interoperability. So writing a wrapper seemed to be an easy task and in fact within a few days we had a working version that grew as we needed. Once we started rewriting the python prototype on top of the new library, we were quite impressed how similar the languages seem to be and how fast we got to a working version. D’s string handling and it’s build in hashmaps and dynamic arrays made it a pleasure to work with.

The not-so-good parts

One thing we noted fairly quickly is that synchronization between the D wrapper and the C header files can be painful. If they change you will not notice unless you know it changed. The header files can diverge and miss some important calls. We had to add some wrappers in the standard library in order to get what we needed. Worst, if you make a mistake in the data layout your program will compile fine. However your program might randomly crash (that’s the good case) or just perform weird in rare cases as you might have written data to a wrongly aligned field and the C library will happy read whatever you write and take it as something completely else (I can tell you, it’s really fun when you get random results from your stat() syscall).

When porting to MacOSX it turned out that MacOS encodes the information if the operating systems supports 64-bit inodes in C header files and heavily depends on ifdefs around it which we could simply not port to D as it (luckily) doesn’t have a preprocessor. So we had to start creating unpleasant workarounds. Another issue we came along is D’s shared attribute. The basic idea that you have a transitive notion of shared data which can safely be shared across multiple threads. This works great as long as you assume that you have a thread-local store. The D compiler and the runtime supports all this by default, however it’s based on the assumption that the D runtime controls the threading and the data passed around…

A key difference
At this point it became apparent that there is a key difference between your standard D project and what we are trying to do. In most projects, your program is the main program and it calls into other libraries. In the FUSE world your program is wrapped in the libfuse context and only interacts with the world through callbacks you handed into libfuse. At that point you completely pass the control to fuse and your code only get’s called when fuse decides so. And worst, libfuse will also control the threading.

So back to shared. Well we initialize all our datastructures before libfuse starts threading, we then pass the datastructures around. At that point we either make everything shared and hope it somehow works, but that turned out to break half of the code due to incompatible qualifiers in the D libraries or we just go ahead and declare everything as __gshared and basically circumvent the whole shared business. De-facto everything our code is shared anyway. So if we have to use interfaces to that require shared qualifiers we just cast bakck and forth. That wasn’t really pretty and we started realizing that this is just the tip of the iceberg.

One bug came to mind. On a slightly unrelated note: we tried D’s contracts which caused the compiler to crash. I wasn’t necessarily impressed with discovering a compiler bug in a fairly straight forward code. But well, those things happen.

The thing with the runtime

At that point we had everything reimplemented and it worked like a charm. So we decided to enable multithreading in libfuse. Suddenly our program started to crash instantly. We rallied all our D expertise. People who have been working on D itself, it’s libraries, alternative compiler implementation etc and tried to debug what the heck is going on. We soon found out, disabling garbage collection made the problem go away. While that is “okay” for a short living program, it’s a not-so-okay workaround for a filesystem that potentially runs as long as your computer runs. So more digging into the Druntime and eventually after days we figured out that the druntime didn’t know about the threads the fuse library created. So when the garbage collector comes and tries to stop the world (as in, stop everything but the current thread) and perform the GC, it won’t know about the other threads but the current and stops nothing. So all the threads happily write data while the garbage collectors tries to run. BOOM!. However libfuse doesn’t tell you when and how many threads it will create. So how will you be able to tell the druntime about them? In the end upon every call we just check if we know about the current thread and if not attach it and then correctly detach it later. There were some MacOS specific problems around multithreading as osxfuse tried to join certain threads from time to time which the druntime considered to be attached. A long and tough deep-dive into OSXfuse and core.thread followed until eventually with some help from the D folks we figured out that we have to detach the thread and have to use pthread_cleanup to allow us to detach from the druntime.


In the end lessons were learned and in a more general notion, embedding a runtime, in particular one with a garbage collector into a project which get’s called from C/C++ contexts leads to a lot of “interesting” and mostly undocumented issues.

A final note

In the end I am not sure if I would choose D again. Modern C++14 is fairly nice to write and the amount of manual memory management in our case isn’t that bad. However now that we solved all the runtime issues and have a fairly stable version, we get back to the fun and turn around times which we like. So overall there is still a net win in choosing D.

Also D moves more and more towards a safe but gc-less memory model, which is something we for sure want to investigate once more and more of the ref-counting code and allocator code lands in upcoming D versions. I am still happy with D in general, but a bit less optimistic and more critical when choosing it then before, and particularly when writing a filesystem.

Flattr this!

July 05 2015

gaenseblumenblog: Die Liste

Dies ist eine Liste von Geschlechtern.
Die Liste wird immer mal wieder erweitert. Wenn dein Geschlecht (oder das von einer Person, die du kennst) nicht auf dieser Liste steht, schreib mich bitte an.
Die Liste steht hier, um mal einen Überblick zu schaffen oder auch Leuten, die nach einer Bezeichnung für ihr eigenes Geschlecht suchen, eine Inspiration zu geben.
Nee Quatsch, in Wirklichkeit steht sie nur hier, weil mich immer wieder Leute danach fragen und ich nicht jedes Mal einen neuen Paste ins Pastebin machen will. Nehmt sie ruhig, kopiert sie raus, erweitert sie, macht damit, was ihr wollt, ihr braucht auch nicht auf mich oder diesen Blog zu verweisen.

Hinweis 1: Kulturelle Aneinung
Viele Kulturen haben schon Begriffe für Geschlechter, die nicht männlich oder weiblich sind. Diese Begriffe haben aber in dieser Kultur eine ganz besondere Bedeutung. Deshalb sollten sie von Leuten aus anderen Kulturkreisen nicht benutzt werden.
Ich bin nicht qualifiziert, um darüber zu schreiben und deswegen mach ich es auch nicht. Vielleicht ergänze ich noch ein paar Links, wenn ich Löffel hab, um welche rauszusuchen.

Hinweis 2: Reclaiming
Einige der hier aufgeführten Geschlechter sind Begriffe, die auch oft als Beleidigungen oder üble Schimpfwörter benutzt werden. Benutze immer nur die Bezeichnungen für eine Person, die diese Person sich selbst ausgesucht hat (Selbstbezeichnung). Das gilt auch für Wörter, die nicht als Schimpfwörter benutzt werden (und übrigens auch für die Bezeichnungen "Frau" und "Mann").





Agender
Anderes
Androgyn
Apogender
Awesome
Bigender
Boi
Butch
Cis, Cisfrau, Cismann, Cisgender
Crossdresser
Cyborg
Demiboy, Demiman
Demigirl, Demiwoman
Dragking
Dragqueen
Drittes Geschlecht
Feminine-of-center
Femme, Femmegender
FTF
FTM
FTMTF
Frau
Frau*
Gender-nonconforming
Genderfluid
Genderqueer
Genderweird
Girlfag
Guydyke
Grrrl
Hermaphrodit, Herm*
Inbetween
Intergender
Intersex
Ja
Keine Ahnung
Komplementärgender
Lesbe
Mann
Mann*
Masculine-of-center
Mensch
MTF
MTM
Multigender
Mutti
Nein
Neutrois
Nichtbinär, non-binary, nb, enby
Non-fluid
Pangender
Polygender
Postgender
Schwuler
Shemale
Sissyboy
Spiegelgender
Tomboy
Trans, Transgender, Transsexuell
Transfrau, Trans*frau, Transmädchen, Transmann, Trans*mann, Transjunge
Transhetera, Translesbe, Transschwuler etc.
Transfeminin, Transmaskulin
Trans Frau, Trans Mann
Trans*hintergrund
Trigender
Tunte
Undefiniert
Unsicher
Weder-noch
Zwischendrin, Zwischendrinchen, Zwischengeschlecht

June 21 2015

Software Defined Radio: Software Defined Radio #6 Podiumsdiskussion Vorratsdatenspeicherung

Die 6. Ausgabe von Software Defined Radio mit einer Podiumsdiskussion zum Thema Vorratsdatenspeicherung.

Die Diskussion wurde am 9. Juni 2015 im Redtenbacher Hörsaal des Karlsruher Institut für Technologie (KIT) aufgezeichnet.
Teilnehmer sind:

  • Michael Hirdes Vorsitzender des Chaos Computer Club (CCC)
  • Thomas Hammer Akademischer Mitarbeiter am KIT, ehemaliger wissenschaftlicher Mitarbeiter am Bundesverfassungsgericht
  • Alexander Salomon Bündnis 90 Die Grünen, Landtagsabgeordneter in Baden-Württemberg, Sprecher für Datenschutz, Medien, Netzpolitik etc
  • Judith Skudelny Freie Demokraten, Generalsekretärin der FDP Baden-Württemberg, Rechtsanwältin
  • Rüdiger Seidenspinner Polizeihauptkommissar, Bundesschriftführer der Gewerkschaft der Polizei (GdP)
  • Achim Traichel Kriminalhauptkommissar, Verantwortlicher für den Arbeitsbereich Internetrecherche im Landeskriminalamt Baden-Württemberg

weiter Informationen unter: http://vds-was-nun.de/

June 20 2015

nomeata’s mind shares: Running circle-packing in the Browser, now using GHCJS

Quite a while ago, I wrote a small Haskell library called circle-packing to pack circles in a tight arrangement. Back then, I used the Haskell to JavaScript compiler fay to create a pretty online demo of that library, and shortly after, I create the identical demo using haste (another Haskell to JavaScript compiler).

The main competitor of these two compilers, and the most promising one, is GHCJS. Back then, it was too annoying to install. But after two years, things have changed, and it only takes a few simple commands to get GHCJS running, so I finally created the circle packing demo in a GHCJS variant.

Quick summary: Cabal integration is very good (like haste, but unline fay), interfacing JavaScript is nice and easy (like fay, but unlike haste), and a quick check seems to indicate that it is faster than either of these two. I should note that I did not update the other two demos, so they represent the state of fay and haste back then, respectively.

With GHCJS now available at my fingertips, maybe I will produce some more Haskell to be run in your browser. For example, I could port FrakView, a GUI program to render, expore and explain iterated function systems, from GTK to HTML.

June 06 2015

nomeata’s mind shares: Tiptoi auf der GPN 15

Soeben findet in Karlsuhe die Gulaschprogrammiernacht statt, eine ein Chaos-Event mit Vorträgen, Workshops, allerlei Technikspielereien und, wie der Name sagt, auch Gulasch. Ich hab hier einen Vortrag zu (mal wieder) meinen Tiptoi-Basteleien gehalten. Entgegen meiner anfänglichen Sorgen war der Vortragssaal mit geschätzt 40 Leuten ganz ansehnlich gefüllt. In Anschluss habe ich noch einen Workshop angeboten, soll heißen, wer wollte macht seinen ersten Schritte mit dem tttool und ich helf über die ersten Hürden. Besonders gefreut hab ich mich über ein junges Mädchen, das ausführlich ihre Vorstellung von Rezepten mit Tiptoi-Unterstützung erläuterte.

Ansonsten hab ich von der GPN noch nicht viel mitbekommen, da ich gerade erst angekommen bin...

June 02 2015

gaenseblumenblog: Binder

Binder sind eine Wissenschaft für sich. Weil sie auch nicht gerade billig sind, ist es schwierig, viele durchzuprobieren - und möglichst der erste sollte zufriedenstellend passen. Hier meine kleine Zusammenfassung von allem, was ich weiß, in der Hoffnung, dass es irgendwem was bringt. Wenn ihr Fragen, Hinweise, Anmerkungen und Ergänzungen habt, wendet euch an mich. Ich werde auch gern den Artikel um mehr Infos (oder Links oder Fotos) erweitern.


Einige Infos vorneweg

  • Binder sind nicht gesundheitsschädlich. Ja, wenn ihr monatelang jeden Tag einen Binder tragt, wird sich das Gewebe anpassen und eure Brüste werden danach auch ohne Binder platt gequetscht aussehen. Das ist nicht gefährlich.
  • Wenn der Binder zu eng ist, kann er sehr wohl gesundheitsschädlich sein. Das kann sogar soweit gehen, dass deine Knochen sich verschieben. Trage keinen zu engen Binder, und besonders nicht, wenn du noch nicht komplett fertig gewachsen bist!
  • Ein Binder sitzt richtig, wenn er die Brüste platt drückt, aber am Rest vom Körper nur gut anliegt. Er darf nirgendwo anders quetschen. Fettgewebe in Form schieben ist okay - Striemen hinterlassen oder wirklich Druck ausüben ist NICHT okay.
  • Es ist möglich, in einem Binder unbehindert zu atmen. Wenn du in deinem Binder nicht gut atmen kannst, trägst du den falschen Binder. Wähle eine größere Größe oder einen Binder aus elastischem Material.
  • Binder funktionieren nicht für alle. Manche Leute mögen den Druck auf der Brust nicht. Andere Leute bekommen von einem stramm sitzenden Binder einen Juckreiz, der sie sehr stört. Manche Leute können sich an diese Dinge gewöhnen, andere nicht.
  • Binder sind keine Pflicht. Nein, auch ein Transmann muss keinen Binder tragen, wenn er das Gefühl nicht mag, sich keinen leisten kann oder aus irgend einem anderen Grund eben keinen Binder trägt. Deal with it.
  • Um die Größe für den Binder zu messen, legst du ein Maßband einmal um die breiteste Stelle an der Brust und einmal direkt unter der Brust. Du addierst beide Zahlen und teilst das Ergebnis durch zwei.
Grafische Darstellung der zu messenden Größen

Einige Hersteller/Händler

Hilfreiche Links



Auswahl des richtigen Binders



  1. Verschlussart



    Die Verschlussart bestimmt, die einfach oder schwer der Binder angezogen werden kann, wie stramm er sitzen kann und wie er ggf. durch die Kleidung hindurch zu sehen ist.

    1. Reißverschluss
      Vorteile: Mit einem Reißverschluss (üblicherweise an der Vorderseite) ist der Binder sehr einfach anzuziehen. Er kann auch relativ fest verarbeitet werden und dadurch sehr stramm sitzen, ohne beim Anziehen ein zu großes Problem darzustellen.
      Nachteile: Ein Binder mit einem Reißverschluss ist nicht verstellbar. Er passt entweder, oder eben nicht. Außerdem ist der Reißverschluss durch dünne Kleidung zu sehen. Der Ausschnitt sitzt auch oft sehr weit oben, sodass er nur unter Shirts mit sehr engem Ausschnitt verschwindet.

    2. Klettverschluss
      Vorteile: Mit einem Klettverschluss (üblicherweise unter der Achsel) ist der Binder einstellbar. Er kann stramm angelegt werden oder bei Bedarf gelockert werden. Es ist auch festes Material verwendbar. Er passt sich an die Körpergröße an. Der Verschluss unter der Achsel ist nur bei ärmellosen oder sehr engen Shirts ein optisches Problem.
      Nachteile: Das Schließen des Klettverschlusses kann ohne Hilfe in eine ziemliche Fummelei ausarten. Ich fand es sehr anstrengend.

    3. Häkchen
      Vorteile: Mit Häkchen (üblicherweise unter der Achsel) lässt sich der Binder sehr einfach verschließen. Die Angelegenheit ist außerdem etwas flacher und weniger störend als ein Klettverschluss. Durch die Verschlussmöglichkeit kann er stramm sitzen und mit relativ weitem Ausschnitt geschnitten werden, sodass er optisch kaum stört.
      Nachteile: Wenn nur eine Reihe Häkchen gesetzt ist, ist der Binder nicht einstellbar.

    4. Kein Verschluss - zum Überziehen
      Vorteile: Ein Binder ohne Verschluss verschwindet unter den meisten Shirts, auch unter ärmellosen Hemden. Es gibt Menschen, die sie einfacher zum Anziehen finden - das ist nicht meine Erfahrung.
      Nachteile: Ich finde sie verdammt schwer anzuziehen. Wenn ein Binder ohne Verschluss stramm sitzen soll, ist es für mich eher schmerzhaft, ihn über die Arme zu ziehen. Wenn er groß genug ist, damit ihn bequem anziehen kann, quetscht er mir nicht genug, um ihn unter einem T-Shirt zu tragen. Weiterhin ist er ebenfalls nicht einstellbar. Die Größe muss das Optimum zwischen "Ich kann ihn anziehen" und "Er macht die Brüste platt" sein - das heißt viel Durchprobieren.
      Hinweis: Manchmal wird empfohlen, diese Binder "von unten" anzuziehen, also mit den Beinen zuerst. Wie das gehen soll, ist mir völlig unverständlich, weil ich nach wenigen Zentimetern auf unüberwindbare Hüftknochen stoße. Aber vielleicht bringt es ja wem was.



  2. Größe



    Selbstredend ist die Größe des Binders ein wichtiger Faktor. Welche Größe optimal ist (eher die größere oder die kleinere?) hängt sehr von der Verarbeitungsart des Binders ab. Insbesondere die Verschlussart spielt eine große Rolle.

    Bei einstellbaren Verschlussarten (Klettverschluss oder Häkchen mit mehreren Reihen) besteht viel Spielraum und der Binder kann an den eigenen Körper optimal angepasst werden.

    Aufpassen: Wenn der Binder zu klein ist, wirst du ihn trotzdem nicht anziehen können!

    Ein Binder ohne Verschluss, der zu klein ist, lässt sich nicht anziehen.
    Nein, auch nicht mit Luft Anhalten und Quetschen und ziehen. Du wirst ihn nicht über bekommen. Punkt.


  3. Material und Verarbeitungsart



    Die Materialien und Verarbeitungen, die ich bisher kennengelernt habe, sind folgende:

    1. Elastisches Material ohne Stütznähte (z.B. Danae Trans-Vormer Basic)
      Binder aus elastischem Material ohne Stütznähte sind sehr gut geeignet, um sie einfach überziehen zu können. Der Effekt wird entsprechend geringer ausfallen, dafür ist der Tragekomfort sehr hoch.

    2. Das Modell Brustpanzer (z.B. T-Kingdom Model 1480)
      Das Modell Brustpanzer besitzt an der Vorderseite einen sehr steifen, unelastischen Teil aus sehr dickem Material. Dieser kann Unebenheiten etc. sehr gut kaschieren.

    3. Unelastisches, dünnes Material (z.B. die 5-Euro-Ebay-Variante)
      Billiges Zeug. Kann ein Glücksgriff sein und dir gut passen (ich hatte Glück - 20 € für 4 Binder, die ich praktisch jeden Tag trage - ich kann nicht klagen). Sie sind aber nur genau dann ungefährlich, wenn du ganz tief einatmen kannst, ohne Widerstand zu spüren. Das bedeutet auch, dass solche billigen Binder nur ungefährlich sind, wenn sie die Brüste nur ein bisschen abbinden.

    4. Festes, mehrlagiges Material mit Stütznähten (z.B. gc2b)
      Binder, die sehr fest verarbeitet sind, sind entsprechend schwierig anzuziehen. Der Effekt ist dafür besser. Atmen ist allerdings wieder schwieriger.

    5. Fest verarbeitetes, aber immer noch elastisches Material (z.B. Danae Trans-Vormer Sport)
      Angenehm zu tragen bei gleichzeitig vernünftigem Effekt.



  4. Länge des Binders



    1. Volle Länge bis über den Hosenbund
      Lange Binder eignen sich besonders gut, um ihn ohne etwas darüber anzuziehen. Bei dicken bzw. fetten Menschen kann ein langer Binder zusätzlich die Hüften ein wenig zusammendrücken und somit für eine geradere Körperform sorgen, die maskuliner wirkt. Außerdem ist kein ggf. abstehender Rand auf dem Bauch zu sehen und der Binder neigt weniger stark zum Verrutschen.
      Ein weiterer Vorteil ist, dass lange Binder im Winter sehr warm sind - der Nachteil ist, dass sie im Sommer ebenfalls ziemlich warm sind.

    2. Kürzerer Binder, halbe Länge
      Ich habe die Erfahrung gemacht, dass es einfach ist, sich vom BH auf einen kurzen Binder umzugewöhnen. Ein langer Binder wäre mir einfach zu viel Stoff.
      Sie können weder Bauch noch Hüften in Form drücken, was je nach Vorliebe ein Vorteil oder ein Nachteil sein kann.
      Je nach Material kann ein kurzer Binder auch gut als Ersatz für ein Bikini-Oberteil geeignet sein.



  5. Brustgröße und Brustform



    Die Größe und Form der Brust ist natürlich ausschlaggebend für die Wahl des Binders. Kleine Brüste und Brüste mit breiter Wurzel, die von sich aus bereits weit hinter der Achsel verschwinden, sind am einfachsten zu kaschieren - hier würde ich empfehlen, Verschluss und Verarbeitungs-Art des Binders nach Tragekomfort auszuwählen. Bereits ein kaum drückender Binder aus elastischem Material kann einen ausreichenden Effekt erziehen. (Denkt dran: Der Brustkorb von Leuten ohne Boobs ist auch kein Brett. Eine kleine Wölbung erzielt einen natürlichen Effekt.)

    Bei großen Brüsten und Brüsten mit schmaler Wurzel, die nur vorn auf dem Brustkorb sitzen, würde ich tendenziell einen Binder empfehlen, der auf der Vorderseite aus mehrlagigem, unelastischen Material besteht.

    Bei Brüsten jeder Form und Größe gilt: Das Zurechtrücken des Gewebes nach dem Anziehen ist die halbe Miete! Dazu solltest du unter den Achseln unter den Binder greifen und die Brüste nach außen und unten schieben.


  6. Lieferzeit



    Wer schnell und am besten vorgestern einen Binder will, sollte nicht unbedingt aus den USA bestellen. Erfahrungsgemäß kommen Artikel aus Asien innerhalb von 1-2 Wochen, aus der EU binnen weniger Tage. Auf Bestellungen aus den USA hab ich schon monatelang gewartet. Das ist auch in Hinsicht auf möglichen Umtausch des Artikels zu beachten.


  7. Preis



    Binder sind leider ziemlich teuer. Es gibt die 5-Euro-Ebay-Variante, damit kannst du großes Glück haben oder eben 5 Euro zum Fenster rausgeworfen haben. (An dieser Stelle der freundliche Hinweis: Wenn du einen Binder hast, den du nicht trägst, schenke oder verkaufe ihn weiter - viele von uns haben wenig Geld und haben große Schwierigkeiten, die 50€ für einen neuen, professionellen Binder auszugeben.)





Fotos

Danae Basic aus elastischem Material ohne Verschluss, halbe Länge
Danae Basic, kein Verschluss, halbe Länge. Das Material ist sehr elastisch und weich. Der Effekt ist okay.

Danae Sport aus festerem, aber immer noch elastischen Material mit Reißverschluss vorne, halbe Länge
Danae Sport, Reißverschluss vorne, halbe Länge. Das Material ist immer noch elastisch, der Binder gibt sehr guten Halt und einen guten Plättungs-Effekt. Durch den Reißverschluss nur unter schlabberigen Oberteilen schön.


T-Kingdom 1480 mit Klettverschluss unter der linken Achsel, halbe Länge
T-Kingdom 1480, mit Klettverschluss unter der linken Achsel. Das Material auf der Brust ist sehr steif und fest - ein Brustpanzer.


Billiger Noname-Binder von Ebay, mit Häkchen-Verschluss
Billiger Noname-Binder von Ebay, der mir unvermutet gut passt. Der Verschluss ist eine Reihe Häkchen. Das Material ist dünn und unelastisch. Ich kann ihn nur deshalb tragen, weil er zwar eng genug ist, um meine Brüste abzudrücken, aber ansonsten weiter ist als mein Körper. Das bedeutet, dass der Effekt nicht besonders gut ist und dass der Binder am Bauch absteht.

June 01 2015

nomeata’s mind shares: ZuriHac 2015

Last weekend, I attended ZuriHac 2015, which was, as always, a pleasant event. I did not actually do a lot, besides some maintenance of Debian Haskell packages, but had some nice chats. It is always very motivating to hear that people read my blog, or that they found my talk (such as the Haskell Bytes talk at Galois) helpful.

My plan was to work on gipeda and perf.haskell.org. I did not do much until an hour before I had to leave, when Lennard Kolmodin came around and I showed him the software. He liked it so far, so we quickly set up an instance of gipeda for the “binary” library. It is not finished yet, as more benchmarks need to be extracted from the build log. That was motivating, and I got further ideas to implement during the train ride back. If only that had happened earlier during the weekend...

May 17 2015

Software Defined Radio: Software Defined Radio #5 Chaosveranstaltungen

Die 5. Ausgabe von Software Defined Radio zum Thema Chaosveranstaltungen.

mit Olf, Martin und Jack

Intro

00:00:00

Begrüßung — Vorstellung der Gäste — Chaos Computer Club — Erfa — Chaosfamily — Entropia e.V. — Entropia Projekte.

Chaosveranstaltungen

00:09:00

Hack n Play — Easterhegg — CryptoCon — IC2 / SIGINT — GPN — Chaos Singularity — Camps (Camp/ICMP/HAR/OHM/ETH0) — ICMP — MRMCDs — Datenspuren — Trollcon — Hackover.

Credits

  • Delcraft – Degree
  • Coldicus – V Cosmos Drugi Moi

April 27 2015

Wenger Online#Blog: Fotowand

Irgendwo müssen die schönen Postkarten und Bilder die man bekommt aufbewahrt werden, was liegt näher als diese an der Wand aufzuhängen. Die klassische 70er Jahre Korkwand wäre eine mögliche Lösung gewesen, ich wollte aber lieber was mit Magneten. Gebürstetes Edelstahl ist aber leider nicht magnetisch, günstiges Eisenblech nicht schön genug. Warum nicht die Leinwandoptik der dazu passend gekauften dreiteiligen Landkarte aufgreifen und ein schnödes, billiges verzinktes Eisenblech unter einem Stoffbezug verstecken?

Passender weise gibt es das Blech gleich in der gewünschten Größe im Baumarkt. Auf die Rückseite kommen ein paar Holzleisten in der gleichen Dicke wie die Leinwandbilder die später darüber hängen sollen. Die Leisten werden der einfachheitshalber mit Montagekleber direkt auf das Bleck geklebt. Das spart mühsames Schrauben, was nur die Gefahren birgt das Blech zu verbiegen oder herausstehende Schraubköpfe zu bekommen die später den Stoff durchstechen.

Maßzeichnung Rückseite mit Holzleisten

Der scharfkantige Rand des Blechs wird mit Gaffa-Tape entschärft, damit der Stoffbezug keine Löcher bekommt. Dann wird der Stoff gespannt und auf der Rückseite mit einem Tacker befestigt, dabei die Ecken schön einschlagen, da kann man ruhig bei den Bilder spicken wie das dort gelöst wurde.

Gaffa-Tape als Schutz vor der scharfen Metalkante Fertiger Stoffbezug

Eine Kiste halb durchbohrter Holzkugeln und kleine Magnetzylinder die passenderweise gleich im Loch stecken bleiben (Falls nicht, kann in Stück Bindfaden oder Papier Abhilfe schaffen) ergibt günstige und schöne Magnethalter in großer Zahl.

Photowand

April 26 2015

nomeata’s mind shares: Fifth place in Godingame World Cup

Last evening, Codingame held a “Programming World Cup” titled “There is no Spoon”. The format is that within four hours, you get to write a program that solves a given task. Submissions are first rated by completeness (there are 13 test inputs that you can check your code again, and further hidden tests that will only be checked after submission) and then by time of submission. You can only submit your code once.

What I like about Codingame is that they support a great number of programming languages in their Web-“IDE”, including Haskell. I had nothing better to do yesterday, so I joined. I was aiming for a good position in the Haskell-specific ranking.

After nearly two hours my code completed all the visible test cases and I submitted. I figured that this was a reasonable time to do so, as it was half-time and there are supposed to be two challenges. I turned out that the first, quite small task, which felt like a warm-up or qualification puzzle, was the first of those two, and that therefore I was done, and indeed the 5th fastest to complete a 100% solution! With only less than 5 minutes difference to the 3rd, money-winning place – if I had known I had such a chance, I had started on time...

Having submitted the highest ranked Haskell code, I will get a T-Shirt. I also defended Haskell’s reputation as an efficient programming language, ranked third in the contest, after C++ (rank 1) and Java (rank 2), but before PHP (9), C# (10) and Python (11), listing only those that had a 100% solution.

The task, solving a Bridges puzzle, did not feel like a great fit for Haskell at first. I was juggling Data.Maps around where otherwise I’d simple attach attributes to object, and a recursive function simulated nothing but a plain loop. But it played off the moment I had to implement guessing parts of the solution, trying what happens and backtracking when it did not work: With all state in parameters and pure code it was very simple to get a complete solution.

My code is of course not very polished, and having the main loop live in the IO monad just to be able to print diagnostic commands is a bit ugly.

The next, Lord of the Ring-themed world cup will be on June 27th. Maybe we will see more than 18 Haskell entries then?

April 19 2015

April 15 2015

nomeata’s mind shares: Talk and Article on Monads for Reverse Engineering

In a recent project of mine, a tool to analyze and create files for the Ravensburger Tiptoi pen, I used two interesting Monads with good results:

  • A parser monad that, while parsing, remembers what part of the file were used for what and provides, for example, an annotated hex dump.
  • A binary writer monad that allows you to reference and write out offsets to positions in the file that are only determined “later” in the monad, using MonadFix.

As that’s quite neat, I write a blog post for the German blog funktionale-programmierung.de about it, and also held a talk at the Karlsruhe functional programmers group. If you know some German, enjoy; if not, wait until I have a reason to hold the talk in English. (As a matter of fact, I did hold the talk in English, but only spontaneously, so the text is in German only so far.)

April 09 2015

NervengiftLabs: Thunderbird: apply filters to all folders

Most of my mail filters are applied directly on my server, where incoming mail is sorted in different IMAP folders, mostly depending on their target address (I use different addresses for every web service, yay catch all :) ).

I also have additional filters in Thunderbird since I was too lazy to install a mail filter with more features on my server. The problem with Thunderbird filters: per default they only run on the INBOX, which is kind of annoying with my given setup.

Once there was an add-on that did exactly this, but it is long dead.

But: turns out that Thunderbird has secretly had this feature all along. They simply never got around to adding a setting for it.

To activate filtering on all folders go to Preferences -> Tab Advanced -> Tab General -> Config Editor and promise to be careful.

There do a right click -> New -> String and name the new property

mail.server.default.applyIncomingFilters

and as value enter

true

(both name and value are case sensitive)

(and don’t ask me why they didn’t choose a boolean property)

Tadaa! now all filters run on all folders in your account.

March 28 2015

nomeata’s mind shares: An academic birthday present

Yesterday, which happened to be my 30th birthday, a small package got delivered to my office: The printed proceedings of last year's “Trends in Functional Programming” conference, where I published a paper on Call Arity (preprint). Although I doubt the usefulness of printed proceedings, it was a nicely timed birthday present.

Looking at the rather short table of contents – only 8 papers, after 27 presented and 22 submitted – I thought that this might mean that, with some luck, I might have chances to get the “Best student paper award”, which I presumed to be announced at the next iteration of the conference.

For no particular reason I was leisurely browsing through the book, and started to read the preface. And what do I read there?

Among the papers selected for these proceedings, two papers stood out. The award for Best Student Paper went to Joachim Breitner for his paper entitled Call Arity, and the award for Best Paper Overall went to Edwin Brady for his paper entitled Resource-dependent Algebraic Effects. Congratulations!

Now, that is a real nice birthday present! Not sure if I even would have found out about it, had I not have thrown a quick glance at page V...

I hope that it is a good omen for my related ICFP'15 submission.

March 21 2015

nomeata’s mind shares: Tiptoi-Artikel in der c't

Gestern erschien Ausgabe 08/15 der c't, und darin ein Artikel von Carsten Podszun und mir: „Stiftzauber – Eigene Bücher und Spiele für den Tiptoi vertonen“. Dies ist meine erste Veröffentlichung in einem derart populärem Magazin (Auflage etwa 270.000)! Ich bin gespannt ob das Tiptoi-Bastel-Projekt: jetzt einen neuen Aktivitätsschub bekommt und freue mich auf viele Fragen und Berichte auf der tiptoi-Mailingliste.

Ich habe ja schon ein paar mal in kleineren Magazinen veröffentlicht (3× im Linux-Magazin, Auflage 26.000; 2× in FreeX), und der Prozess war schon recht unterschiedlich. Beim Linux-Magazin bekommt man Autorenrichtlinien, die z.B. auch festlegen, mit welchen Tags man die Formatierung (Überschriften, Inline-Code) festlegt. Ich dann den Artikel geschrieben, es gab vielleicht noch etwas Feedback, und er wurde im großen und ganzen so gedruckt wie eingereicht – Tippfehler wurden eventuell noch behoben.

Der Wichtel, der den Artikel ziert

Der Wichtel, der den Artikel ziert

Bei der c't wurde ich als Autor deutlich intensiver betreut. Ende Oktober reichten wir einen erstes Konzept und Mitte November einen Rohentwurf (als Textdatei) ein – wir hofften noch in eine Ausgabe vor oder zu Weihnachten zu kommen, da um diese Zeit viele neue Tiptoi-Stifte in die Haushalte kommen und Eltern die Zeit zum Basteln haben. Dann war allerdings erst mal Funkstille bis Anfang Januar. Ich schätze dass unser Artikel in der Warteschlange von höher priorisierten Texten überholt wurde...

Mitte Januar bekamen wir dann von der uns betreuenden Redakteurin den Rohentwurf in überarbeiteter Form und als RTF-Datei zurück. Da waren dann auch die Heise-spezifischen Tags für Zwischenüberschriften o.ä. drin. Die Verzögerung hatte allerdings ihr gutes: Das tttool hat sich bis dahin deutlich weiterentwickelt und insgesamt wurde der Prozess deutlich einfacher. Ich bin also nochmal ran und habe den Text entsprechend aktualisiert und am 1. Februar wieder in die Redaktion geschickt, jetzt als RTF-Datei. Nach drei Wochen gab es dann wieder Feedback und die Aussicht auf ein Erscheinen in c't 8. Ich hab das Feedback eingearbeitet und am nächsten Tag zurück geschickt. Nach einer Woche ohne Aktivität hatte ich noch weitere kleine Verbesserungen hinterhergeschickt.

Weitere zwei Wochen ruhe und plötzlich lag uns vorletzten Mittwoch eine PDF-Datei mit einem fertig gelayouteten Artikel vor. In dem Text fehlten aber manche Änderungen aus meinen letzten beiden Mails. Ich verglich die beiden Versionen Satz für Satz um herauszufinden, was fehlt, und stellte fest dass jeder zweite Satz umformuliert oder zumindest leicht umgestellt wurde. Mein Bruder hat sich schon gewundert und gefragt ob der Text wirklich von mir geschrieben wurde...

Wir hatten nun plötzlich eine harte Deadline von 48h für letzte Änderungen – auf einmal muss also alles schnell gehen. Ich meldete daher gleich die übersehenen Passagen aus meinen letzten Mails.

Am Donnerstag kam dann die vorerst letzte Version, in der ich noch ein paar kleine sachliche Ungenauigkeiten1, Tippfehler und sprachliche Unschönheiten bemängelte. Leider kamen diese Änderungen wegen einem Problem mit meinem Mailserver (Debian-Bug 780256 mit 780578) erst Freitag Nachmittag an und konnten nicht mehr berücksichtigt werden – schade! Ich hab die finale Version jetzt noch gar nicht gesehen; vielleicht wurden sie ja im Lektorat noch behoben.

In dieser letzten Version war dann auch der Aufmacher, also das Bild oben auf der ersten Seite zu sehen. Auf die Gestaltung, die auf der Tiptoi-Mailingliste schon verwundert kommentiert wurde, hatten wir als Autoren keinen Einfluss.

Anders als beim Linux-Magazin entsteht so ein c't-Artikel also in einem recht intensiveren Dialog mit einem Redakteur, der zum Beispiel darauf achtet, dass der Artikel zur Zielgruppe passt, dass alles wichtige erklärt wird und der sprachlich nochmal drübergeht. Das ist natürlich sinnvoll und die Voraussetzung für gute Qualität.

Andererseits hat der Prozess auch große Nachteile. Die Gesamtdauer – mehr als 5 Monate vom ersten Kontakt bis zum Erscheinen mit langen Phasen des Stillstandes – ist etwas demotivierend. Zusätzlich ist die Interaktion nicht besonders wohldefiniert: Nachdem ich einen überarbeiteten Entwurf geschickt habe war mir nicht klar, ob und in welcher Form ich weitere Verbesserungen nachreichen kann. Da die Texte als RTF-Dateien rumgeschickt wurden, habe ich daraus geschlossen, dass sie nicht vernünftig versioniert werden, wie etwa Textdateien in einem Git-Repo, und eventuell manuell zusammengeführt werden müssen. Eine Lektorin in einem Buchverlag erzählte mir, dass es dort ein Token-System gibt, und immer klar ist ob der Redakteur oder der Autor jetzt den Text weiter entwickeln darf. Das hätte Missverständnisse vermieden. Noch schöner fände ich allerdings ein von Redaktion und Autor gemeinsam genutztes Etherpad, Git-Repository o.ä., was mir auch ermöglicht hätte, die Änderungen der Redaktion besser nachzuvollziehen. Bei einem technischen Verlag wie Heise sollte das doch vielen Autoren entgegen kommen.

Ich hoffe das war nicht meine letzte Veröffentlichung in einem Magazin wie der c't und weiß jetzt dass ich da das nächste Mal besser darauf achten muss, dass so Missverständnisse vermieden werden können.

An der Stelle nochmal vielen Dank an Rebecca Schwerdt für die Zeichnung, mit der wir den Artikel illustriert haben.


  1. Da steht z.B. „..., wo [der OID-Code] für das menschliche Auge nicht erkennbar ist“. Der Satz wurde von der Redaktion dazugeschrieben, ist aber falsch: Richtig wäre allenfalls „...kaum erkennbar ist.“

March 17 2015

nomeata’s mind shares: Sim Serim geschenkt bekommen

Vor gut einem Jahr habe ich das Brettspiel „Sim Serim“ unter dem Namen „Sum Serum“ als Browserspiel implementiert. Da ich das Spiel nicht selber besitze und mir die Regeln nur kurz in der Karlsruher Spielepyramide erklärt wurden, hatte ich etwas übersehen: Die Zahl der Steine pro Spieler ist eigentlich begrenzt, worauf mich kürzlich Ulrich Roth auf BoardGameGeek aufmerksam gemacht hat. Darauf hin habe ich das noch korrigiert und dabei die Grafik des Spiels (ein klein wenig) aufgehübscht.

Dass muss Heinrich Glumpler, der Autor von Sim Serim, mitbekommen haben, denn er hat meine Implementierung nicht nur ausgiebig gelobt, sondern mir tatsächlich einfach ein Exemplar des „echten“ Sim Serims geschenkt! Das freut mich natürlich sehr! (Und ist deutlich angemeher als die Reaktion von Brian Hersch auf meine Java-ME-Version von Tabu damals vor 9 Jahren...)

March 15 2015

Software Defined Radio: Software Defined Radio #3: Freifunk

 

Wir erklären was Freifunk ist und sprechen über das Freifunkprojekt in Karlsruhe und wie man dabei mitmachen kann. Mit Gastbeiträgen aus München.

Intro

00:00:00

Die Chaosradio-Familie.

Freifunk

00:02:30

Freifunk — KA-WLAN — Münchner CCC-Erfakreis — OpenWRT — Gluon — Batman — OLSR — VPN — Förderverein freie Netzwerke e.V. — Mesh-Netzwerk — Freifunk Leipzig — Providerprivileg — Störerhaftung — Freifunk Paderborn — Freifunk Karlsruhe — Treffen jeden 2. Donnerstag im Entropia (nächstes mal am 19. März) — TP-Link WR841N — (Korrektur: Nur die Antennen vom WR841ND sind abnehmbar) — Entwurf zur Novellierung des Telemediengesetzes — Artikel 8 TMG — Freifunk statt Angst.

Veranstaltungshinweise

00:55:29

Easterhegg.

Credits

March 03 2015

gaenseblumenblog: Vereinfachtes Soziales Protokoll.

  1. Wünsche und Bedürfnisse werden ausformuliert.
  2. Geäußerte Wünsche und Bedürfnisse werden wertungsfrei zur Kenntnis genommen und nach Möglichkeit beachtet.
  3. Alles wird möglichst exakt so gesagt, wie es gemeint ist.
  4. Wenn es ein Problem gibt, wird es angesprochen und ein Lösungsvorschlag gemacht.
  5. Fragen ist immer erlaubt. Antworten ist freiwillig.
  6. Stop hat jederzeit und in jedem Kontext Gültigkeit. Es muss zwingend beachtet werden.
  7. Wenn etwas anders gemeint war, als es angekommen ist, wird das klargestellt.
  8. Wer einen Fehler macht, entschuldigt sich.
  9. Eine Entschuldigung muss nicht zwangsweise angenommen werden.
  10. Die Diskussion abstrakter Begriffe ist zur Klärung konkreter Probleme ungeeignet - dazu werden greifbare Worte benutzt.
  11. Was nicht revidiert wird, hat unbegrenzt Gültigkeit.
  12. Nonverbale Hinweise und implizierte Bedeutungen gelten nur, wenn absolut sichergestellt ist, dass sie verstanden werden.
  13. Anfassen ist nur mit Ankündigung und mit Opt-out erlaubt.
  14. Regeln werden an die Menschen angepasst, nicht Menschen an die Regeln.
  15. Sämtliche Abweichungen von sämtlichen Normen werden bedingungslos akzeptiert. Auf besondere oder zusätzliche Bedürfnisse wird immer Rücksicht genommen.
  16. Wenn es die Möglichkeit gibt, einem Menschen zu helfen oder etwas Gutes zu tun, wird sie genutzt.
  17. Grenzen dürfen immer gesetzt werden. Dafür ist niemals eine Erklärung notwendig.
  18. Grenzüberschreitungen und bewusstes Verletzen einer anderen Person werden nicht geduldet.
  19. Manipulation und Bedrängen einer anderen Person sind unzulässig.
  20. Jemandem Schaden zuzufügen, ist nur zulässig, um sich selbst oder andere zu schützen oder zu verteidigen. Der Schaden muss so gering wie möglich gehalten werden.
  21. Körper und Gefühle sind nichts, wofür irgend jemand sich schämen muss. Sie dürfen in keinem Fall angegriffen werden.
  22. Gefühle stehen niemals zur Diskussion. Sie werden als Tatsache wertungsfrei akzeptiert.
  23. Die Wahrnehmung anderer Menschen steht niemals zur Diskussion. Sie wird als Tatsache wertungsfrei akzeptiert.
  24. Sei kein Arsch.
  25. Das VSP gilt für alle sozialen Interaktionen außerhalb von Notfällen insoweit, wie der physische, psychische und neurologische Zustand der Beteiligten seine Beachtung zulässt. Für besondere soziale Situationen können zusätzliche Regeln gelten.

February 25 2015

nomeata’s mind shares: DarcsWatch End-Of-Life’d

Almost seven years ago, at a time when the “VCS wars” have not even properly started yet, GitHub was seven days old and most Haskell related software projects were using Darcs as their version control system of choice, when you submitted a patch, you simply ran darcs send and mail with your changes would be sent to the right address, e.g. the maintainer or a mailing list. This was almost as convenient as Pull Requests are on Github now, only that it was tricky to keep track of what was happening with the patch, and it would be easy to forget to follow up on it.

So back then I announced DarcsWatch: A service that you could CC in your patch submitting mail, which then would monitor the repository and tell you about the patches status, i.e. whether it was applied or obsoleted by another patch.

Since then, it quitely did its work without much hickups. But by now, a lot of projects moved away from Darcs, so I don’t really use it myself any more. Also, its Darcs patch parser does not like every submissions by a contemporary darcs, so it is becoming more and more unreliable. I asked around on the xmonad and darcs mailing lists if others were still using it, and noboy spoke up. Therefore, after seven years and 4660 monitored patches, I am officially ceasing to run DarcsWatch.

The code and data is still there, so if you believe this was a mistake, you can still speak up -- but be prepared to be asked to take over maintaining it.

I have a disklike for actually deleting data, so I’ll keep the static parts of DarcsWatch web page in the current state running.

I’d like to thank the guys from spiny.org.uk for hosting DarcsWatch on urching for the last 5 years.

February 15 2015

Software Defined Radio: Software Defined Radio #2: Künstliche Intelligenz

 

Wir fragen uns: “Was ist künstliche Intelligenz?” Ein assoziativer Ringelreihn mit einer Spur Pessimismus.

Intro

00:00:00

What is Artificial Intelligence?

00:00:37

Künstliche Intelligenz — Spracherkennung — Bottom up — Pretty Little Girl's School — Weltwissen — Input — Linux-Distribution — Buffer-Overflow — Unschärfe.

Das Telefon hat "verstanden"

00:12:24

Datenbank — Sprachausgabe — Sprachsynthese — Sprache aus der Plechdose.

in letzter Zeit neue Ansaetze

00:41:47

Formale Logik — Neuronales Netz — Machine learning — Deep Learning — Bilderkennung — Kognitive_Architektur — Semantische Daten.

Termine

00:58:38

Samstag, 20. Februar Open Data Day weltweilt aber auch in Karlsruhe, ab 14 Uhr im Gewerbehof — Nächste Sendung am 15. März 18:00 auf Querfunk.

Credits

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl