If you're a webserver and want to serve clients which support gzip encoding, you need to be DEFLATE compatible.
For something like virtual memory where you'd control both the compressor and decompressor, there's little point in clever DEFLATE-compatible compressors. Instead, just pick any compressor which has the compression/CPU tradeoff you want.
The HPACK spec  remarks on this. Google carefully used DEFLATE in earlier SPDY versions  but HTTP/2 decided to be less clever.
Interestingly, SLZ's page comments on lack of history as a way to avoid CRIME attacks, which is one of the things the HTTP/2 people worried about. That seems like something it'd be easy for an implementation to screw up though (just add some buffering somewhere before the compressor...)
That's very personal. I really enjoy the rustle of a bus engine. It makes me dozy in a very pleasant (if inconvenient when I have to get down) way. Trains are great for transportation, but I don't enjoy the trip as much.
Maybe. There are lots of finicky details, like inconsistent bit ordering and arbitrary lookup tables. I think it's a long week of work at least, probably more.
On the other hand, it is probably the simplest compression format in widespread use that uses variable-length encoding, and there's a few implementation around for you to look at. Things like bzip2 and LZMA2 really don't have independent specifications and multiple implementations, and are more complicated to boot.
Byte-oriented Lempel-Ziv formats like LZ4, LZO and LZJB would be a good way to dip your toes into a production compression format. The LZW encoding used by GIF files is also "simpler" in principle but I personally find it harder to wrap my head around.
If you want to experiment with binary formats, it might also be interesting to write a decoder for a simple image format, like PCX files, or even for old game file formats like Doom's [http://doom.wikia.com/wiki/WAD].
LZJB is fantastic. Here's my take on a Python implementation of both compression and decompression: https://github.com/unwind/python-lzjb. It's ~150 lines for both, and BSD 2-clause-licensed. It's not very high-performant (I wrote it for fairly small amounts of data) but hopefully clear enough to learn from.
I'll take either a mechanical or a chiclet (like the Apple ones) keyboard over squishy rubber domes.
I personally think the chiclet boards have a lot in common with the mechanical ones - there's a very nonlinear resistance and it's pretty clear when you have, versus haven't, activated a key. I don't find many mechanical aficionados agree :)
I don't like the low profile keyboards on most laptops now. I bought my own refurbished Lenovo Thinkpad X201 mainly for its fantastic keyboard, and I also requested and got a Lenovo T440 for work which has a different but still excellent keyboard.
Many cheap rubber dome keyboards are of course horrible, but some are pretty good. I use a Dell somethingorother at home, and its very good. I also use a cheap Lenovo SK 8825 and there's nothing wrong with it at all.
Cherry switches seem to have an industrial heritage, and they seem to have been adopted by the type of gamer who likes to treat their keyboard like a Hyper Sports cabinet. Indeed, the red switch was created for gamers.
The switches don't provide much of a typing experience, unless you like the feeling of a key slamming onto a hard surface. Which you can mitigate by using O rings to try to retrieve the rubber dome feel.
Here's a quick <del>keycap</del> recap on the Cherry switches.
- Blacks. Heavy duty basic linear switch used in Carphone Warehouse POS terminals, Police keyboards, and Steelseries G series. Guaranteed cramps.
- Red. "Fast" version of Blacks, for FPS gamers. Unsuitable for any typing.
- Brown. Like a version of Reds with a bit of grit on the stem to act as an "early warning alarm" so you can hopefully avoid the painful bottoming out.
- Blue. Makes an artificial "click" halfway down the stem to fool your brain that you're using a good keyboard. Highly antisocial - favoured by people who plant leylandiis at the bottom of their small gardens.
I'm actually starting a trial run today using an Apple USB chiclet keyboard at work. My job description has shifted from coding to documentation, and I found my macbook keyboard to be slightly easier than my Filco mechanical for typing long documents, instead of code.
So far, I agree on the nonlinear feedback, and a perk is that it's a lot quieter (coders don't mind, but where I sit now it feels like I'm a kid in a corner creating a ruckus with my mech keyboard).