guns

If you feel uncomfortable about this trust decision made for you by OS X, I would suggest taking a peek at the entire set of trusted root certificates in /System/Library/Keychains/ (note that Keychain Viewer hides one of them from view by default, so run:

    open /System/Library/Keychains/*

from a shell).

I don't run OS X anymore, but I was not happy with what I saw at the time.

Ironically, GPG setup in mutt is extremely easy if you use the GPGME library integration:

    set crypt_use_gpgme=yes

The documentation does not seem to stress that GPGME is favored over the old pgp_* settings (which are typically cargo-culted), but it should.

The author mentions GPGME in the article, but only to shrug it off as "too big". Given the fact that devices like the raspberry pi now run full Linux distributions, I'd say it's a weak argument.

> Do you go to any great lengths … ?

If he does not, does that disqualify him from holding an opinion on surveillance cameras? Is he complicit in their proliferation if he has not significantly altered his life in protest?

The only chance we have for avoiding a disturbingly Orwellian surveillance culture is to combat the public ignorance about the extent and power of the systems now in construction.

> I just ignore them and I'd probably just ignore this dude too.

In contrast, I thought the strong reactions from the people on film were admirable. Running away without expressing disapproval is cowardly; if I were with my family, I would give the guy fair warning, then rush him for being predatory.

What concerns me about vim emulation modes is the uncanny valley mentioned by another poster. Working in a second-class interface doesn't sound that great.

However, that's pretty strong praise, so I promise I'll give it a shot before trying to birth a new editor into the world.

Article was submitted by the author about a year ago:

http://news.ycombinator.com/item?id=3300264

> Also, how do you do the superscripts?!

Unicode. In my case I input them in vim by way of vimperator. You can input them in vim using the digraph feature (try <C-K>11 in insert mode).

My vimrc actually parses my ~/.inputrc to extract the keybindings I use to input Unicode characters in bash and every other program that uses readline, allowing me to use the same keys for Unicode chars in every context that I input text.

https://github.com/guns/meinhaus/blob/guns/etc/inputrc#L144

https://github.com/guns/meinhaus/blob/guns/etc/vim/local/com...

> If I were going to change any single thing about Vim, it would be to make MzScheme scripting support a first class citizen, and slowly re-engineer the backend to be more Emacs styled. Core C (or whatever, but C out of momentum) functions with the rest of the system build up in Scheme.

Thank god there are people who share this vision! I have solemnly promised to myself that I will write a new vim in exactly this fashion if no one has done so in the next 10 years.

One thing that I don't understand about contemporary developers is the aversion to running their editors in a terminal. The benefits of doing this are significant (e.g. session management with tmux, remote pair programming via the same), but programmers leave them behind for what is ultimately just eye candy.

The major reasons for this are the difficulty in binding complex key chords in a terminal, and the poor implementation of OS X's Terminal.app (both of which can be worked around today with a little work, and a proper X terminal). If this terminal-based workflow is going to thrive in the future, what will need to be modernized is the terminal.¹

So you heard it here first: if a new vim built atop a Lisp interpreter running on a new data-centric, mixed character-grid/HTML5-webview terminal emulator does not appear in the next 10 years, I'm on the job.²

¹ Some excellent musings on the subject: http://lubutu.com/idea/ivo

² This would all be easier if I could love to learn Emacs, but Vim modal editing is a pernicious addiction.

As a happy user of vim + fugitive¹, git² serves as a bold abstraction of my code in exactly this fashion. I do not think of files as anything but eponymous containers of namespaces. Git blame, for instance, allows tracking lines across file renames, and tpope's wonderful vim interface actually makes this easy to use.

I enjoy git on the command line, but _tight_ integration with the editor is an almost sublime experience.

So git's well-defined data structure already enables quite a bit of editor magic, but Codeq's extra layer of abstraction is very intriguing. Also, the fact that you can query the engine and get back simple data compares favorably to the mishmash of shelling out and git object parsing done by many tools today.

WRT Smalltalk's image, code management is only one of its marquee features, so I think Smalltalkers would object to calling image vs files a false dichotomy. The image is more akin to a versioned virtual machine than an SCM. I've never known the magic of the image (or a Lisp machine), so I lack an opinion on which is superior.

¹ Drew Neil's excellent video introductions to fugitive: http://vimcasts.org/episodes/archive (April/May 2011)

² and other _content_ tracking DVCSs

> The problems are mostly with people assuming `python` means `python2`, and distros/installs not providing the `python2` command

Yes, Arch follows the recommendations of the link you provided. I was compiling a naïve program that assumed /usr/bin/python to be Python, so I was trying to hack autoconf (or cmake?) by overriding the hard-coded path with the python2 libdir.

I thought it would be nice to ask python2 itself for its library path so I asked #python. The channel moderator in turn appended "NO ARCH" to the channel banner once I mentioned Arch Linux.

It is interesting that the author is an Arch Linux developer. My sole experience in the #python channel on freenode [1] was to be badly flamed once the room discovered I was an Arch user. Apparently there is considerable annoyance at Arch's decision to install Python 3 as /usr/bin/python, against the recommendations of the Python community.

While I understand that this decision may have increased calls for help from Arch users in #python, Arch is strictly rolling release, and Python 3 has been out for 4 years now. Given this last fact, the vitriol I encountered was quite surprising.

[1]: Asking simply for a method to obtain compile-time information about python from python. I got the answer from a sympathetic person in the channel. Thanks felipe

JSON is not extensible and syntactically more verbose. However, the syntax corresponds exactly to many modern dynamic languages and is now nearly ubiquitous.

> Of course JSON (http://www.ietf.org/rfc/rfc4627.txt) does this as well but using character code points.

I hope Rich will define "alphanumeric" as Unicode letter and number classes. Clojure itself is ambiguous on valid symbol identifiers. http://clojure.org/reader has the same "alphanumeric plus some punctuation" rule, but the actual reader implementation [1] is extremely permissive:

    static Pattern symbolPat = Pattern.compile("[:]?([\\D&&[^/]].*/)?([\\D&&[^/]][^/]*)");

[1]: https://github.com/clojure/clojure/blob/master/src/jvm/cloju...

That's interesting. I can't reach wikileaks.ch from my home connection, or from one linode instance, but it is available through a second linode instance (in Dallas):

https://www.refheap.com/paste/4309

These are the servers that are failing to relay packets, all of which respond to ping:

    po-10.sto1.se.portlane.net (80.67.4.128)
    te-4-4-gblx.sto1.se.portlane.net (209.130.172.178)
    149.11.24.18 (149.11.24.18)

Notice these are all Swedish IPs.

The admins of these servers may be working with Wikileaks to stop the deluge of packets from the IP blocks with the most attackers, or they are simply dropping the packets to conserve resources.

> You have encodings, Unicode, ASCII, UTF-8, ISO 9660, Latin-1, code pages, UTF-16, byte order masks, gettext macros, po files, ... the terminology and model of the problem domain are extremely complex and difficult to understand.

In the beginning, there was ASCII [1]. It was a simple encoding that mapped a byte stream to standard American letters, numerals, punctuation marks, as well as some common non-printing control codes.

ASCII only used the lower 7 bits of the 8-bit byte, reserving the upper 128 positions for any non-American characters needed for national encodings.

And indeed, many dozens of national character encodings appeared that used ASCII for its lower 128 positions and implemented their own character table in the upper 128. One very popular encoding was Latin-1 [2]. This became the standard encoding in much Western software because it adequately handled the most widely used Western languages.

One major problem with these 8-bit national encodings is that the upper 128 codes are mutually exclusive with one another. Confusingly, they almost all shared the base 128 ASCII codes, so programmers and users began to equate "plain text" and "sane encoding" with 7-bit ASCII, since one could effectively communicate universally by restricting the characters used to those in the printable ASCII table.

As it became clear that the proliferation of 8-bit encodings was untenable, there emerged Unicode. Unicode is not an encoding, but a standard that provides a table of universal code points, along with some recommendations about how to combine and display certain code points. [3]

Unicode is implemented in the modern day by UTF-8, UTF-16, and UTF-32, which are primarily distinguished, as you might guess, by the base size of the code unit.

UTF-32 is a simple encoding that simply maps every Unicode code point to a 32-bit sequence. This is simple to parse, but potentially very wasteful, so is rarely used.

UTF-16 uses 16-bit code units, and is able to simply translate the most commonly used portion of Unicode, the Basic Multilingual Plane. For code points above U+ffff, a scheme is used to span the code point along two code units. This encoding is used frequently in Windows, and in Java.

UTF-8 is a variable length Unicode encoding like UTF-16, but defaults to a small one-byte code unit and has a famously elegant algorithm, so it appeals strongly to miserly Unix hackers.

> For example, one time I downloaded some tarball (I forget what it was) that had a few bytes of binary garbage at the beginning of every file. After some research I found out that it's called the BOM and has something to do with international text, and I ended up having to WRITE A SCRIPT WHICH GOES THROUGH AND DELETES THE FIRST FEW BYTES OF EVERY FILE IN A TREE in order to use the tarball's contents.

The Byte Order Mark is clunky solution to the fundamental problem of divining the character encoding of an arbitrary byte stream. It's great if all your tools transparently support it, but annoying if not. However, some sort of convention or metadata is necessary to correctly encode your data. Python, Ruby, and other scripting languages have begun to coalesce around the magic encoding comment for source files (i.e. `# encoding: utf-8` as the first or second line).

Most everybody falls back to ASCII if no encoding is specified, or cannot be inferred from the stream itself. The better fallback is UTF-8, because breakages like yours are less likely to occur, which is why it is encouraged as the default system encoding in most cases.

> Another time, I downloaded some Java source which contained the author's name in comments. The author was German and his name contains an "o" with two dots over it. That was the only non-ASCII character in the files. Eclipse and command-line javac WOULD NOT PROCESS THE FILE and I ended up removing his name from all comments; after that it compiled without a hitch. This was the official Oracle (then Sun) javac. A fricking SOURCE TO BYTECODE COMPILER SHOULD NOT DEPEND ON YOUR SYSTEM'S NATIONALITY SETTINGS -- OR ANY LOCAL SYSTEM SETTINGS! -- TO DO ITS JOB. But it does.

These tools likely have ways of setting the encoding without inheriting from the environment, but they do fall back on the environment as a simple convention.

The trouble is that there is no reason any longer to assume that all text _must_ be 7-bit ASCII. Unix and programming languages are evolving to handle this new multilingual digital world. The only obstacle that really remains are programmers, so I think it's fair to spend a little time learning the basics of the subject.

[1]: There were other antediluvian encodings (like EBCDIC)

[2]: a.k.a. ISO-8859-1. Windows used a slightly modified version of this and called it Windows-1252 in order to complicate matters

[3]: The actual display of composite glyphs is left the implementor. For instance, both ready-made composite glyphs like é are provided, as well as a "non-spacing" acute accent mark

Working once on a MacBook with a disabled trackpad, I found the only window that I could not focus using the keyboard was the password dialog. I realized later that AppleScript could do the trick:

    (as root)
    # ps axo ucomm | grep -q SecurityAgent && osascript -e 'tell application "SecurityAgent" to activate'

Threading in MRI is still entirely appropriate for juggling IO. So that makes two of us.

You're screwed because you won't possibly be able to follow a well composed, well tested library with an extremely shallow class hierarchy and short, clear method definitions without the aid of comments?

I don't think you're giving yourself enough credit.

A quick glance at the source shows that the size of the program is a result of implementing the many methods one expects from collection classes in Ruby, not because the code is especially byzantine. In fact, I haven't seen a single instance of class inheritance; the author seems to have chosen to solely use a few well defined modules instead.

I just tried turning off line numbers, and you're right, it's great. They really don't provide enough value to justify taking 4 columns on every vertical split.

I use a pretty large font size for my terminal, and the extra 8 columns finally allows for two 80 column vertical splits on my laptop. Thanks for the suggestion!

I continue to be haunted by something a good artist friend used to say: "Don't obsess over your tools. They are not the goal".

This would ring in the back of my head as I spent many hours configuring my editor / shell / terminal setup. It felt like a guilty pleasure.

It dawned on me however, that what had drawn me to programming in the first place was a sublime text editor (TextMate), and that my business is in fact tool-building. My love for computing tools and the experience of using them reflects in the kind of software I build for clients.

On top of this, evaluating and obsessing over hacker's tools isn't confined to picking between models at the hardware store. I have pored over (and patched, however minor) bash, vim, tmux, rxvt-unicode, and many other programs that I use every day.

These things may well be rationalizations, so here's a simpler justification: the time I invest into my tools have made my experience of sitting down in front of a computer incredibly enjoyable. I once lived computer free for three years because I detested the uninspiring (and frustrating) experience of Microsoft Word and Windows 98. If that was what computing was, I wanted nothing to do with it.

I concede your point about Maxwell's equations. Their historical significance in particular is the unbelievably rich research that ensued from its implications.

By this metric, Lisp is obviously the analogue in the programming world. It would have been nice though if Lisp had triggered a sudden paradigm shift instead of this painful 50 year burn we're living through.

John Shutt's Kernel language [1], decomposes lambda into unevaluated operands, a lexical environment, and the function body:

    '(λ args body)

can be expressed as:

    ($vau args env body) [2]

Interestingly, because $vau does not evaluate `args` and explicitly recieves a lexical binding, macros are not necessary in Kernel, and hygiene is a simple matter of (eval)ing with the right environment.

Arguably then, Kernel is more fundamental than Lisp.

[1]: http://web.cs.wpi.edu/~jshutt/kernel.html

[2]: Manuel Simoni has a short overview of $vau here: http://axisofeval.blogspot.com/2012/03/i-want-to-understand-...

I believe Rich Hickey discussed Datomic in his Clojure/west keynote:

http://clojurewest.org/sessions/

I'm looking forward to the release of the conference videos.

Indeed. I didn't know about `sudo -H`, though, so thank you.

The sudo timeout convenience feature is worrisome, but there's no need to remove it entirely from the system [1]. You can set

     Defaults timestamp_timeout = 0

in your sudoers file to make sure sudo always prompts for a password. I think this should be default, since the current default of 5 minutes is an easy privilege escalation vector [2].

Also, if you like entering root's password instead of your own, you can set the `runaspw` option.

[1]: Unless you'd like to remove one more possible SUID vulnerability.

[2]: It's far from the only way for a local process to escalate privileges, so I understand it's nothing worth yelling about.

They are not equivalent. `sudo su` changes the values of USER, HOME, and SHELL to that of the root user. `sudo -s` only changes USER (it seems), but HOME is retained as the SUDO_USER's home directory.

Neither invocation changes the working directory, which is convenient.

Definitely. For instance, X is still supported on OS X after all these years, in large part due to Jeremy Huddleston:

http://lists.apple.com/archives/x11-users/2011/Nov/msg00058....

It's reassuring that I will be able to continue to use my Mac and rxvt-unicode into the forseeable future.

There is no opportunity cost for putting a digital book on the "shelf".

Alternately, you must build a rack a mile long to offer the same breadth of selection.

I think you're being facetious in turn by summarizing SOPA as the revocation of "the right of startups to avoid prosecution for user piracy".

SOPA is dangerous because it gives the executive wide power to deprive private citizens of their property, without any due process, in direct violation of the Fifth Amendment.

> The NK brand of communism is just a thin veil for the old dynastic feudal caste society that Korea traditionally was.

While your argument is defensible, I think characterizing the NK autocracy as a natural progression of pre-occupation Korea is misleading and perhaps unfair.

It's important to remember that at the time of the NK invasion in 1950, Korea had only recently been freed from the 35-year Japanese occupation in which the Japanese actively sought to eradicate Korean culture. The successor to this was another occupation by the US and USSR.

Although the new interim governments were more benign I don't think it was clear that the future would hold any kind of true independence from foreign states, and certainly US style democracy seemed quite far fetched.

And so it seems to me that if I was a young man of fighting age in Korea in 1950 (and thus born during the occupation), I would have found the NK motto of "Juche" (self-reliance) much more compelling than the murky, foreign roadmap offered by the US. Indeed, the professor in this article, Kim Hyun Sik, expresses this sentiment.

Even for many years after the Korean War, it wasn't clear that the US-led South was superior in ideals or in practice. The industry-heavy North (aided by infrastructure built by the Japanese and by Soviet engineers) flew ahead of the South in terms of economic growth and actual standards of living. Meanwhile, South Korea was embroiled in poverty, military coups, and cruel suppressions of student riots. You really couldn't have called SK a democracy until the late 1980s.

Of course, fortunes changed for NK. The classic Soviet style N-year plans were failing to meet their quotas, and as this began to happen, Kim Il Sung, who was really a foreign plant from Stalin, began to emulate Stalin's tactics of self-aggrandizement and brutal extermination of opponents.

If you wished at this point to question why it was that nobody stood up to Kim Il Sung in his rise as tyrant, you could very well blame Korean Confucianism and the hierarchical nature of Korean language and society. This is a strong reason, but I don't think it's sufficient.

There is a simpler answer: NK is a very tiny nation, with a reluctant ally on one border and a perpetual enemy on the other. Total control in a country of NK's size is actually possible, and with a constant menacing enemy, it was relatively easy to manipulate a small society into subservience. Think "1984", or the "War on Terror", but constrained to the state of Indiana.

Anyone who's studied basic probability in high school should be able to answer that question.

52! > 2^64

That's interesting. I love Little Snitch; there's no parallel in the Linux world, sadly, and I miss it when I'm configuring outbound firewall rules on my Arch box.

However, I think the trojan is giving up a little easily. Little Snitch has a checkbox titled "Prevent Rule Editing" which is unchecked by default, which implies that a process with the same privileges as the logged in user can create its own "allow" rule through a little bit of AppleScript (or whatever else).

@TREYisRAD

No, you'll want to actually use rxvt-unicode [1] on X11 on your Mac. The X implementation is annoying at times on OS X, but using a great terminal is worth it if you spend all your time in one. iTerm2 is nice, and Lion's new Terminal.app isn't bad, but programs like vim and tmux are designed with real xterm-compatible terminals in mind [2].

[1]: http://dist.schmorp.de/rxvt-unicode/

[2]: For instance, you can enter copy-mode in tmux 1.5 with a mouse scroll if you are using xterm or rxvt-unicode