was about to say that ...

> Tags: satire email

I think it's a fair warning.

Half the comments on long blog posts usually end up discussing the headline, or even just part of it. Combine that with the difficulty people on online forums have to recognise blatant satire and you'll end up with pages of discussion about SMTP before you know it.

I see at least four top level comments failing to see the satire or talking about email. The downvotes are pushing them down, but it shows the sarcasm warning was necessary…

git does not clone hooks, but if a subdirectory of a repo has the structure of a bare repo it can hijack git subcommands for code execution. try:

  git clone https://git.0x90.space/vmann/pwnd && cd pwnd/whoot && git status

it is a bit crazy this is not disabled by default yet.

That's terrifying. I'll think twice before cloning any repository from now on.

> not disabled by default yet

You're saying there's a way to "disable" this behavior?

Set safe.bareRepository = explicit.

Available since Git v2.38:

https://github.com/git/git/commit/8d1a7448206e11cd

none that i know of

That's fascinating! Time to update my Blogpost on git hooks and go down this rabbit hole !

I never got why people think using tar is hard. Specify your archive File with f. want to eXtract it? add a x. want to Create it? add a c. Want it to be Verbose while doing that? add a v. if it's gZiped add a z. Granted, j for bzip2, t for listing is less obvious, but with that it's about everything you need for everyday usage and that more than suffices to disarm that bomb.

Here's an example of better UX (subjectively):

  zip my-archive.zip my-directory
  unzip my-archive.zip

(disclaimer: zip/unzip won't be a reasonable alternative for all of the use cases of tar)

Good software doesn't beg that much explanation. And when it does, then either "--help" or just the command with no parameters e.g. "zip" or "unzip" should provide what's necessary. I don't believe that tar does that, but instead overwhelms the user, whereas "tar --usage" is overwhelming.

Here's another comment of mine which serves a precise example of why tar is problematic in my eyes: https://news.ycombinator.com/item?id=29339018

I don't feel like it follows the UNIX philosophy that well either, though i won't argue that it should be much smaller (because it is powerful, although someone might argue that), but that its commands should be grouped better.

That said, maybe things would be more tolerable if we used the full parameters instead of memorizing silly mnemonics, here's an excerpt from the linked comment:

  $ tar --verbose --create --gzip --file=new-archive.tar.gz ./files-i-want-to-archive

tar -xzvf filename.tar.gz

The mnemonic I use:

x - extract

z - ze

v - vucking

f - files

Interestingly

  $ bash -c 'cd /var/empty; echo .*'
  . ..

but

  $ ksh -c 'cd /var/empty; echo .*'
  .*

Seems some ksh dev got bitten and restricted this ...

This is beautiful. I will try to implement this once i'm at home ...

Title is missleading. From the title I expected something about how to design a hash algorithm, but the article is just a walk through the specific operations SHA-1 performs w/o further explanation.

Can anyone recommand resources about the actual design of (cryptographic) hash algorithms?

Compiles fine with -Wall -Werror. No warnings.

    int x = 1;
    bool y = x;

    # cl.exe /W3 main.c

This code gives a warning on VS2012. But it doesn't give one when the cast is in a loop condition. That is weird.

http://stackoverflow.com/a/31552168/5994461

This stackoverflow message talks about the specs for C11, and the first comment adds information on the C++03 spec. It seems that implicit cast from integer to boolean is allowed... under all circumstances... depending on what specification the compiler is following :D

For future references, I'll just summarize this as "C and C++ are minefields". We'll just add that to the list of WTF behaviors.

By the way, if you think that "C has had bool for 19 years" [the C99 spec specifically]. You clearly didn't work in C for long enough with a large variety of tools. The world is bigger than just GCC.

> But it doesn't give one when the cast is in a loop condition. That is weird.

I believe that the justification for that is that you'll often want to do e.g.

    while (node) {
      node.val += 3;
      node = node->next;
    }

Implicit conversion of a type into a bool is pretty useful here, or for e.g.

    while (std::cin >> x >> y) { ... }

I imagine the warning is following the rules for explicit constructors/operators in C++: an if condition is considered an "explicit" call to an `operator bool`. http://en.cppreference.com/w/cpp/language/explicit

Nice read. I liked it ... :)