Seems right to me:
The truth about #Emacs: Everything seems way too hard at first, then you use it for a while, then you can't live without it.
— Mohit Thatte (@mohitthatte) March 21, 2015
Seems right to me:
The truth about #Emacs: Everything seems way too hard at first, then you use it for a while, then you can't live without it.
— Mohit Thatte (@mohitthatte) March 21, 2015
The//Intercept has an excellent article on how to choose secure passwords that are (relatively) easy to remember. The problem with passwords is that they are almost never secure. Most people choose stupid ones (password, 123456, \(\dots\)) and even those of us with a bit more of a clue can almost never choose a good one. The reasons for that are psychological but the TL;DR is that humans appear to be preprogrammed to prefer patterns even when they’re trying not to.
Because of this, the only secure passwords are randomly chosen ones where the human proclivity to impose order and pattern on them can not come into play. That’s why secure password management requires a password manager such as 1password, KeePassX, or similar program. These programs choose long random sequences of characters that are very secure for passwords and then store them in an encrypted database.
The only remaining problem is choosing a password for the password manager. It holds the crown jewels so passwords like password are non-starters. The//Intercept’s recommendation is one that I’ve given here many times: Diceware. The idea is that you roll 5 dice to randomly choose a word from the Diceware list. Do that 5, 6, or 7 times and you have 5, 6, or 7 random words that together have enough entropy to resist even NSA brute forcing. This, of course, is the idea behind the famous XKCD Correct Horse Battery Staple cartoon. The big advantage of a sequence of random words like this is that while they have the same or more entropy than a long random sequence of characters, they are relatively easy to memorize.
I previously posted a Lisp implementation of Diceware that uses a cryptographically secure random number generator and is therefore very secure. There is also C version that’s a bit has a tiny bit of bias and is therefore slightly less secure. It would be easy to make it completely secure by using the 8K Diceware list that the Lisp version uses.
UPDATE: Intercepts → Intercept’s
InfoQ has a nice interview with Nic Ferrier on good software and agile. Irreal has mentioned Ferrier several times: he’s a good hacker and someone who deserves to be taken seriously.
Ferrier’s take is the agile is a way to improve communication among a development team and that many of it’s most contentious features are not really so much essential to agile as a possible way of increasing that communication.
Take a look at the interview to get the best idea of his views. I don’t know much about agile and therefore don’t write about it very much because I don’t want to be this guy:
"i don't know
much about agile. But I think X". Yeah. That's because you
don't know much about agile. And you're an eejit.
—
Nic Ferrier (@nicferrier) March
30, 2015
As some of you know, learning more about about calc has been on my TODO list for sometime (that’s literally true—it’s in my agenda). I last wrote about it just last week. I’ve finally stopped procrastinating and starting learning calc.
I began by reading the first of the three manual sections, Getting Started. This section gives a brief demonstration of how calc works and highlights some of its capabilities. Like those who came before me, I was left in awe. I knew it was quite capable but had no idea how capable.
One of the big items for me is arbitrary-size arithmetic. It seems I’m always fiddling around with large numbers and native 64-bit integers simply aren’t big enough for a lot of what I do. That’s why I usually bring up a Lisp REPL for my calculations—the big int arithmetic. I’m not going to give up my Lisp REPL, of course, but for quick calculations calc seems like a real win.
My next step is to tackle Part 2, Tutorial. As I work through that, I’ll probably make occasional posts of interesting things I discover. So far, my only regret is that it took me so long to get started. If you have to do non-trivial calculations and use Lisp, or Python, or something similar, you really should give at least the first part of the calc manual a read. It may suggest a new—and sometimes better—approach.
If reading the manual seems too arduous, Karthik C has a nice video that shows off some of calc‘s capabilities. It’s just short of 49 minutes so you’ll have to schedule some time. Very much worth your time though.
Recently, I wrote about the glories of the Jargon File and remarked that the hacker jargon it records is often hilarious. It’s easy to burn up a couple of hours browsing around in it.
Now Jeff Atwood over at Coding Horror has a list of his 30 favorite new terms that he’s culled from Stack Overflow. These are very funny and definitely worth a couple of minutes of your time.
Some of my favorites are:
I’ll let you check Atwood’s post for their definitions. Go ahead; you need a bit of comic relief.
It turns out that it’s not just the U.S. Britain, too, has bozos in charge of keeping us safe (via Nic Ferrier):
Tories plan porn site age checks http://t.co/mftZlYDrHq <- more unicorn-farming fantasies from the techno-illiterate
— Simon Phipps (@webmink) April 4, 2015
FBI Director James Comey just hates it that he’s not able to snoop on us at will. His shameless invocation of the 4 Horsemen descends into self-parody.
Sadly, his message resonates with some of our more weak minded representatives, one of whom professes himself shocked, shocked, to discover this thing called encryption. Want to worry about public safety? Ponder the fact that bozos like this are in charge of it.
Wilfred Hughes has a nice post on writing a major mode for a new language. As Hughes demonstrates, it’s pretty easy to get started but there’s lots of details and nooks and crannies to worry about.
His post shows how to get started and points out enhancements that you’ll want to make as you grow the mode. A minimal implementation should have syntax highlighting and indentation. Fortunately, it’s pretty easy to get those working, especially if you use the SMIE engine to help with indentation1.
As you build out the mode, you’ll want to add things like completion, Eldoc, and Flycheck. Hughes’ post doesn’t tell you how to program these features but it does point you in the right direction. If you’re interested in writing a major mode for a language, this post is well worth reading.
But be sure to follow the link in Hughes’ post to Steve Yegge’s musings on how hard indentation really is.
For those of you condemned for past sins to use the Exchange calendar system, this can help you keep things in the family. Actually it’s an Emacs interface for the entire Exchange Web Services API. Seems like it could be useful for those whose world straddles Emacs and Exchange.
How often have you wanted to Google some term in the document you’re working on, or look up the documentation for a function? Many of us have a few Elisp functions to do this but you end up with a lot of duplicated code and the corresponding maintenance problems.
Harry Schwartz, who we know from his chat with Sacha, addresses that problem in his latest talk to the NYC Emacs Meetup. The talk, Searching the web with engine-mode, is about Schwartz’s engine-mode. What happens is that you define a site you want to search along with a single key that tells engine-mode to query that site. There is a key prefix, nominally 【Ctrl+c /】, that invokes engine-mode and waits for the final key to specify the site.
I like this approach because rather than have a bunch of complicated key sequences to memorize, you just pick a key that suggests the site: 【d】 for DuckDuckGo, 【g】 for Google, 【w】 for Wikipedia, and so forth.
You can see Schwartz’s configuration here. As you can see, he has a lot of sites defined. It would be a pain to write separate Elisp for all of them so engine-mode is a win if you like to make such searches.
Schwartz shows the details in the video so it’s worth watching. It’s about 18 minutes.