Jonhoo

I don't think taskset should affect this at all. It modified the CPU affinity, which my code respects, so everything should behave as expected.

While I wish it was this simple, not having your application be "GOPATH ready" (i.e. allowing it to be directly set to be GOPATH) makes a lot of other things harder. For example, build and benchmark scripts that need to compile the application from source (and thus can't necessarily use `go get`), now need to take care to construct two parent directories before checking out the code. The fact that go doesn't follow symlinks when building doesn't make things easier either. It also forces you to file away your projects deep in your $GOPATH directory, rather than organizing them in other (better) ways and then linking them into your $GOPATH.

I looked around, but couldn't find one. If you're running Linux, you can do it manually yourself (blacklist all, whitelist the ones you need) in about fifteen minutes. I posted the steps for Arch Linux somewhere further down.

FWIW, here's what I just did on my (Arch) Linux machine:

  $ for f in /etc/ssl/certs/*.pem; do sudo ln -sfn "$f" /etc/ca-certificates/trust-source/blacklist/; done
  $ sudo update-ca-trust

This will block all currently installed CAs (as well as double-block some, but that doesn't really matter). You then need to add them back in.

Restart your browser, and go to websites you access frequently (change them to https:// if necessary). Click the (broken) padlock and read off what CA they used; remove the corresponding .pem file from the blacklist directory. Some might be signed by intermediate certs and thus hard to find, but SSL Hopper has a great chain inspection tool at https://www.sslshopper.com/ssl-checker.html you can use to identify the topmost CA cert you need to whitelist.

After you're done, run "sudo update-ca-trust" again, and restart your browser. All normal sites should work, and you've gotten rid of ~160 root certs.

If it's of interest to anyone, here are the ones I whitelisted to get all sites I bothered to try up an running:

  $ sudo rm DigiCert_* GeoTrust_* Go_Daddy_* GlobalSign_* VeriSign_* StartCom_Certification_Authority* Comodo_* AddTrust_* Thawte_* thawte_Primary_Root_CA* Baltimore_CyberTrust_Root.pem UTN_USERFirst_Hardware_Root_CA.pem Visa_eCommerce_Root.pem
  $ ls /etc/ssl/certs/*.pem | wc -l
  206
  $ ls /etc/ca-certificates/trust-source/blacklist/
  163

EDIT: Note that this is not a perfect solution; the CAs you've whitelisted could still go bad, and you'll need to blacklist any new CA certs that are added with subsequent ca-certificates updates. But it's a start.

  ping mit.edu | sed -u 's/.*/ping pong/' | espeak

is even funnier...

For those who want to reproduce the ping example, get espeak and run:

  ping mit.edu | sed -u 's/.*/ping/' | espeak

First of all, I reject the premise of this article:

> Markdown (.MD) is a text format that lazy people use to write HTML.

This is just blatantly false. Markdown was never intended to replace HTML.

Second, the author points how how "The quick brown fox jumps over the lazy dog" is not very legible. I completely agree. However, this is contrived example that you are unlikely to encounter in practice. Just as it would be unlikely someone would mix bold and italics so closely in "real" formatted text.

The author then goes on to say that

> Lets face it, even Programmers don't like reading raw Markdown and so in the most popular .MD repository of them all - github - the Markdown files are rendered in the browser as nicely formatted HTML.

As a programmer, I actually really enjoy reading Markdown files. While it is true that it can be made more visually appealing for inclusion in a website like what happens on GitHub, it is great to have a somewhat standardized format that makes it pleasant to read those same files when you aren't browsing the files online. While I would bring up browsing files from the command-line here, the author seems to have a strong dislike for those of us who dabble in the black magic that is the shell.

All this aside, it is true that Markdown is not the right tool for everyone, and that the toolchain does not necessarily make it easy for beginners to get started writing all of their documents in Markdown. However, try to make someone open a Word document without Word, and see how easy that is. The lack of (beginner friendly) tooling is definitely not a sign of a poor format.

Finally, the author ends with

> However, if you have heard that there is this cool format available and it cures all your textual needs and it is just really really easy to use and really really quick...then think about the elixir you are being offered and re-read this document before slurping away...

  a) it is not a new format
  b) it never claims to cure all your textual needs - it aims to make it easier to create formatted text, where previously there was none
  c) it is, without a doubt, really really easy, and really really quick, because any plain text document is valid Markdown. All Markdown does is attempt to standardize some (already fairly common) methods for applying *simple* formatting to that text.

While the author bashes Markdown's lack of standardization, the cases that are brought up by CommonMark are more important for implementors than for writers, and "regular" users will likely find the informal language description more than satisfactory for common usage.

TL;DR: The author is hating on Markdown, mostly due to incorrect assumptions and seemingly a personal dislike for plain-text formats.

My bad. Was relying on the URL for duplicate checking.

From reading these comments it seems most people only read the headline. Such a shame, because it was a really well researched, thought through and written article.

Which is a very very useful skill to have in its own right

Perfect size, font, line height and column width on that post. Kudos!

I posted this further up, but the ideal font size for main body text is supposedly between 50-75 characters per line. The first reference I found was this one: http://baymard.com/blog/line-length-readability but this is a very common rule of thumb

Depending on the font size, 600px gets you pretty close to the ideal of 50-75 characters per line: http://baymard.com/blog/line-length-readability

This sounds like a DPI issue though? If the DPI is set correctly, the same font in the same font size should look the same size on two different screens, no?

The real solution here is to base all font size calculations off the default font in the user's browser (which the user can change). If everyone did this, you would be able to enjoy a consistent font size across most sites. It will probably never happen though.

I just wish all sites used something like the CSS3 rem (root ems) unit so we could at least make it a bit easier for the user to have a say in the font size the site uses.

In general, web developers (and the designers commandeering them around) need to stop resetting font sizes on body {} or something similarily silly. The default browser font size should be the base value, and all other fonts should simply be bigger or smaller by some factor. In an ideal world, people would also start using ems instead of pxs for media queries, but alas, we probably won't see that for quite some time.

Really really enjoyed this article. What are the visions for the future that our ancestors will laugh at? It seems people have stopped dreaming.

Just to be clear, I didn't post this because I found it enlightening. I posted it for its stupidity.

Has the author not gotten the memo about Security through obscurity not being security at all?

This had nothing to do with GNOME, it was a bug in X that affected any lock application.

Seems like I'm not allowed to change it anymore..?