Interesting stuff, and I like the writing style.

I do the same for various other git commands, such as git checkout ('gc').

The only problem is that this breaks git tabcomp. Haave you (or anyone else) dealt with this?

I choose a middle approach - rather than making loads of new base commands, I just use the aliases, and only for the really common commands

> git co > git st > git ci

Fellow git aliaser, consider shell aliasing git to g!

But it is sexist/discriminating https://en.wikipedia.org/wiki/Affirmative_action

Yes! Usually it's not a problem, but every now and then relativenumber really kills performance.

The last time I noticed this was with valgrind logs; and I have no idea what exactly is causing it (amount of lines doesn't seem to be it).

Thankfully it's perfectly usuable for day-to-day editing. Binding :set rn! to a key circumvents this problem well enough.

There's a typo

https://ohm2013.org/wiki/Camping:Travel follow the sings towards "Recratiegebied Geestmerambacht". sings

It's a wiki

What resources did you use to implement gif89a?

You already mentioned the specification ( http://www.w3.org/Graphics/GIF/spec-gif89a.txt ). Did you use anything else?

Animation is now considered a core feature of GIF, but it was implemented as an extension by Netscape and surprisingly there is no official spec for it.

Extensibility is provided for in the specification, but the actual implementation within each application extension is, of course, application-specific.

The extensions I know about:

- NETSCAPE (animation)

- NETSCAPE (buffering)

- ANIMEXTS (same as Netscape animation)

- GIFCONnb (found this GIF Construction Set extension during testing but didn't try to reverse engineer it)

The only one of consequence is the animation one.

The page I used at the time to describe the animation extension no longer exists, but this page describes it and others:

http://www.vurdalakov.net/misc/gif

Doesn't this already exist? Multiple times?

Oh well, obvious 'exploit'. Wondering how Y! will react. They must've forseen this, right?

Probably poorly.

Question though, how large of a file can you hide with steganography in a 300mb picture?

Would that be big enough to hide an MP3?

On a side note, can you upload files to Flickr that have data appended after the end of the image data? Like people were doing on 4chan until moot removed that capability.

I have a wee bit of Stego experience as I've written a couple of implementations. Generally for it to be "undetectable", you shouldn't go with more than 25% of an image file, assuming 24-bit color, being data, as it quickly becomes apparent that there is something fishy going on. Your best bet is to create a kind of "keyed stegonagraphy" where you generate a series of keyed nodes, creating a cycle (in the graph theoretic sense) of nodes, each node corresponding to a pixel, and the entire cycle determined entirely deterministically from the key.

This is akin to key schedulers used in various cryptography schemes, I suppose. The idea is that you REALLY don't want to just shove your data all at the beginning of the file in order, as it becomes really easy to tease out the data with some cursory frequency analysis/bruteforcing. "Oh the first 20 pixels encode the first X bytes of <insert well known file type here>, BALEETED!"

Then you simply have each user pick their own key, stored locally, and have the cycle generated on the fly when encoding and retrieving data.

They'll probably just ban the API key people use for it.

Not to mention the names of his scripts are the best

Wish there was one in my area