Priceless Python FU

__ = """ enu Help Some help Colors Red Green Light green 1 2 3 Dark green Blue Cyan Cobalt blue Diamond blue Version Verion 0.1 Details D 1 D 2 D 3 Test version Progress bar """.splitlines() class _: def __init__(_): _.___ = [] _.__ = [(-1, _.___)] def _(_, __): __________________ = _.___ for ___ in __: if not ___.strip(): continue ____ = ___.replace('\t', ' ') _____ = ____.lstrip() ______ = ____.strip() _______ = len(____)-len(_____) if _______ > _.__[-1][0]: _________________ = [] __________________.append(_________________) _.__.append((_______, _________________)) __________________ = _________________ elif _______ <_.__[-1][0]: _.__.pop() __________________ = _.__[-1][1] __________________.append(______) return _.___[0] print _()._(__)

Direct Connect Hubs for Mac

Since I've started hacking on the brand new ncdc I found myself in need of a hub. I don't mind it being slow since it's only for testing purposes, but it should at least run and work which proved surprisingly hard.

• Lamahub was the most promising. It is written in C, supposed to run on just about every platform under the sun and has a lama(sic) theme which i'm always up for. Sadly it doesn't work out of the box on a mac. It took me a bit of time to patch it so it finally built correctly. I then spent an hour playing with it and four clients, believing to have found an error in ncdc which turned out to be a bug in the hub. Needless to say i was annoyed and trashed it.
  
• dtella was up next. The website doesn't tell you anything (well maybe it does, but it was done and the sf.net page isn't very informative), the macosx install script is borked and i quickly gave up debugging it. That would have all been ok, i just started the dtella.py from where it was but had to discard that program as well since it isn't meant for running more than one client from the same ip. How that fits with their premise is a bit of a mystery to me, what about a dorm room where two people share an external ip?
• MPPS aka Voltron dchub aka Tiny Box dchub are apparently iterations of the same luabase hub core from what i can tell. I got some errors about missing modules and i don't feel like learning lua to debug it, so i moved on. Still, if you are Lua affine this is probably your hub.
• Valuthub is a now extinct project (at least their berlios site doesn't exist anymore and I can't find a different one.
• myhub is a java based (not exactly my favoured programming language mind you) hub that barfed on me when compiling. From the short time i looked over it I believe the author plain forgot to include one file that contains the missing class. Since upstream's dead I won't write it either
• and the winner is py-dchub. It's the only one that worked straight out of the box with so far no insufficiencies I've found yet. Upstream's dead here as well from what i can tell but it's python so who cares.
  

So only one out of 6-8 hubs actually worked out of the box, two maybe three sort of work after some fiddling of which dtella is probably not your regular dchub.  All in all the usual sad state of affair for OSS software for the mac (well or anything that isn't completely mainstream).

On Passwords

This has been bugging me for years but it comes up again and again. So it's time for passwords - a case study:

• Passwords are important, hardly anyone doubts that (well at least for some passwords). Still people don't act accordingly. I know a company that has a policy(wtf!) that the password for any company related account is required to always be the same as the user name. (I mean wtf?!?)
• Passwords are sensitive.
  • Still a lot of servers do auth in plain without encryption. At any stage in between anybody with access to the wire can see them. This is scarier than you might think. For example my dorm has switches that let you read the traffic of hundreds of other people.
  • Even if that is not the case you still have to trust the other end (and that they know what they are doing). I administrate a lot of computers and the people i work with are a rather capable team. I am pretty sure i can vouch for their good will, so i would trust this end. Nevertheless we for example had our ldap passwords stored in plain text and synced them into our university backup system, since we didn't set up the server initially and never thought about.
• Passwords are difficult to get right: This is has many aspects
  
  • they should be memorable. It doesn't help if you have to carry it around in a pocket to know it
  • they shouldn't be too short and lala is too short ;)
    
  • they should be somewhat safe You know the drill, alphanumeric, capitalization, not based on a dictionary word...  Read this and laugh. If you find the full list, you'll be surprised how sexed up thelist is. When setting up our new shell server, we ran all passwords against cracklib as an audit and over half of them fell through!
  • they shouldn't be too safe. It's a sad reality but some setups even if they allow it are plain incapable of processing certain chars/encodings whatever. I had to have my university computer account reset because they had a fuckup in their system rendering passwords with umlauts different when entered and read back. This is germany for christ's sake. How many times a week must they have had this problem?!?
  • they shouldn't all be the same. Most people use the same password over and over, if you get one you potentially have a lot of accounts (i verified this a couple of times).You'd be scared if i had actual figures proving how many people do that.
    There is a difference to be made here: I asked the most tech affine and security conscious people i know and they on average had something like 5 or 6 different personal passwords. The point is they usually have an unobvious scheme of adjusting it and incorporating part of the sites name or similar into it to make them different for each site

A lot of this gone wrong can be learned by bad example from the security "experts" at HBGary and their recent fuckup. So we have all these ideas and that's all nice in theory, but:

1. Why, oh why does every single site have to make up another different insane requirement for passwords. Please use sane somewhat lenient minimum requirements. I propose 7 chars min, one letter, one other and possible an upper case letter.  I can understand requiring numbers or special chars, a minimum length or not all lower/upper case but why the heck would you impose a maximum length of 8 (!) chars or no caps or requiring numbers only. All these make it more predictable, less easy to remember (i still hit sites where none of my standard passwords can be adapted to be accepted) and less safe in the long run. You don't gain security you lessen it!
2. If you insist on restricting your passwords firmly, please, please add your requirements to the login page! I have reset my password countless times on many sites only to remember it when i read the reqs when asked to set the new passwords. That would usually help me more than anything. I have turned to writing the reqs in the security question because it's easier that way.

Synctex

I recently became aware of Synctex the successor of pdfsync.
pdfsync is a technology that allows synchronization between a (la)tex file and the corresponding pdf output. It wasn't the first of its kind but certainly the best i've tried. In practice you need support by both your viewer and editor but then it's down to pressing a command or (shift/ctrl/whatever)+clicking somewhere and you are magically teleported into the other app to the spot corresponding to the one you were at on the other side. Anyone who has texed and needed to proof a doc of more than 5 pages length before will understand that this is invaluable.


For all the goodness, this had some drawbacks unfortunately: pdfsync was based on some tex primitives as opposed to being embedded into the engine, so the output under some circumstances wasn't perfect, it could change the generated rendering and it was incompatible with some popular packages (e.g. colortbl). I have never been bitten by any of these in the last 3 years but it always was a good excuse for viewers not supporting it (they are usually the end that carries the burden).
It unfortunately still has it's place as we will see shortly, so here are links to set up  forward  and backward search underMacOS + vim + skim, evince doesn't have it and never will which leaves you with xpdf and okular on linux, both of which aren't my favourites.

In comes synctex: It is the natural evolution of pdfsync done by the original author and has all the goodies without the down sides. Setting it up under Mac was even easier now that skim supports macvim as a preset :). Just choose MacVim under preferences>sync and put the following in your .vim/ftplugin/tex.vim (assuming you use the vim-latex suite)

let g:Tex_DefaultTargetFormat = 'pdf'
let g:Tex_CompileRule_pdf = 'pdflatex -synctex=1 --interaction=nonstopmode $*'
let g:Tex_ViewRule_pdf = 'Skim'

Look at this for all other MacOS related progs, mupdf, and evince. Okular just needs to be called with

okular --unique 'file.pdf#src:linenumber file.tex'

(That's what i think the evince people should have done instead of using dbus. Oh, well...)

Now for the bad part, lua(la)tex + evince/okular isn't working with synctex. I filed bugs with luatex, evince and okular but i don't expect a solution for this anytime soon. :( That means i am back to pdfsync for now, since i really, really like my luatex. So have fun with that!

Edit: you need to tell vim to call okular/evince with the exact same filename that lualatex produces which is ./file
In order to do that goto compiler.vim which if you installed vim-latex in your .vim is under .vim/ftplugin/latex-suite/compiler.vim otherwise probably somewhere in /usr.
Apply this patch for okular. For evince it really depends which script you use, but read the patch and do it analogously.

Impurity Test endlich online!

Du hörst immer du wärst verdorben, glaubst es aber nicht? Du hast schon vor langem von ihm gehört, aber nie getraut ihn zu machen? Verzweifle nicht, er ist endlich hier! In der Tradition der besten Varianten, die wir kennen, raffiniert durch endloses Durchtesten, perfektioniert durch das verderbte Wesen Vieler. Der Impurity Test ist endlich hier!

Interesting article and some of the comments are even more insightful than the article itself. I think i agree with Anonymous (22. August 2010), who explains the futility of the whole attempt, s/he laconically summarized it like so:
That to make the internet useless for bad people, it must also be made useless for good people. You could literally firewall the entire damned thing to where the internet passed only ICMP echo requests, and do you know what would happen then? Spammers would resort to hawking viagra via ping packets fired in morse code, hoping to reach ham radio operators looking in the general vicinities of their DSL modems' RX LEDs. (I'm *not* kidding.)
And sadly enough s/he's right.

libao and the mac

Anyone who hasn't updated libao on the mac to 1.1. yet do so now! It fixes those two really annoying bugs concerning playback stopping when hibernating,suspending or (un-)plugging an audio connector.
By the way if you don't know why open source is useful, i think i have yet to find a text that expresses my views on this better than http://www.xiph.org/about/