HN user

barend

15 karma
Posts0
Comments9
View on HN
No posts found.

Your introductory text and video mention the NSA and PGP. The PGP system has been around for a long time without getting any mainstream traction. There are numerous reasons for this failure, but the general complexity of public key crypto has to be one of them.

On the project page you write

An intuitive, modern user interface makes strong security accessible to everyone.

Can you share a bit more about the way you envision this?

It would make little sense for the finished feature to work retrospectively; apps would just grab the bounty on first launch and then the harm is done before you can get to the settings screen. This looks more like the screen you'd go to if you change your mind about an app. I expect the primary control for this feature to be a just-in-time dialog, similar to permission popups on iOS.

[dead] 13 years ago

I didn't realize this, I hadn't seen hsmaker.com and thought this was fresh. I will delete the link, thanks for te reply.

I've come to see the key distinction between git and SVN as:

* Old workflow: "commit code" and "share code with team" are jumbled together.

* New workflow: "commit code" and "share code with team" are separate actions.

This looks so obvious, but coming from years of using SVN, it took me a while to understand the implications. With git I could fix (with commit --amend) those embarrassing "whoops, forgot to add an untracked file" kinds of mistakes. Over time, I found that my local commits became smaller and more frequent because I can reorder and squash them before pushing (or git-svn dcommitting, as most of my clients run SVN).

Consider a larger change where you might implement it one way, decide you were on the wrong track, back off a bit and implement it some other. With SVN these false paths are either in the common repository confusing the history, or I'm in a disconnected state for an uncomfortably long time. With git, all these changes are local commits that are ultimately kept out of the main history because I've reordered the change history into something comprehensible.

It took me a few months to grok git. Reading an article on the filesystem structure of the repository helped me a great deal.

Funny, one of my complaints about OSX compared to Windows is the (IMO) lackluster implementation of keyboard shortcuts. Perhaps I just don't see it, if so please enlighten me, but OSX's key bindings feel random and inconsistent to me. To elaborate:

On Windows the Windows-key is the modifier key for global operating system functions, things like lock screen (win-l), explorer (win-e) and projector mode (win-p). Save for legacy bindings like CTRL-ESC, no global functions tie to the other modifier keys. The CTRL and ALT modifiers are therefore free to bind to functions of the currently active application. Some of these follow standard conventions, like ALT-F4, CTRL-S. Aside from these, any application is free to implement a keyboard scheme (and e.g. exploit symmetry) without clashing with the operating system.

Contrast this to OSX where there appears to be no designated key for global functions. A "naked" F11 triggers Expose, Ctrl-F2 puts focus in the menu bar, Cmd-space pops up Spotlight, leaving just Opt as unbound. Like in Windows, there are some conventions like CTRL-comma. There is no global key to open a Finder window, although Spotlight alleviates much of the pain.

With no standard key for global functions, the potential for key clashes is always there. Software that targets just OSX can avoid these, but cross-platform applications that originated elsewhere are quite often prohibited from using the same set of key bindings in every platform.

Finally, OSX lacks a key binding for the context menu (i.e. the equivalent of SHIFT-F10 or the dedicated key on Windows systems) and mnemonic keys (the underlined characters in menu items; OSX wants you to type the caption of the desired menu item). The lack of mnemonic keys invalidates all my muscle memory in Eclipse, I really miss them.