cjh_

The 'point' of solutions in this space is that they allow password access across devices. They use end-to-end encryption and support self hosting, what else could they do?

> Since all of your data is fully encrypted before it ever leaves your device, only you have access to it. Not even the team at Bitwarden can read your data, even if we wanted to. Your data is sealed with end-to-end AES-256 bit encryption, salted hashing, and PBKDF2 SHA-256.

From the linked page (https://bitwarden.com/)

This sounds amazing.

I recently witnessed an intoxicated man collapse on the street in front of me, so I was first on scene and had to call our local version of 911 (I live in Australia). Of course I am asked where I am, the address and street, and I had no idea. I was at the bus stop I walk to everyday, surrounded by building with names I couldn't read very well at night, and no street signs near me. I was eventually able to work it out, but that was precious moments we lost that could have made things significantly worse in a different case.

The man was passed out cold (he had hit his head very hard when he fell) and had a very weak pulse and weak breathing, I performed CPR until the ambulance arrived and he started to regain consciousness. The ambulance took a very long time to arrive and then find us, I had to get other bystanders to stand out in the street to wave and shout. When the ambulance left he was fully conscious and able to converse with the officers.

This whole thing of course seemed absurd, as we were all carrying smartphones equipped with HD cameras, GPS, and radios.

In another case, during the Christchurch earthquakes in New Zealand, I was lucky to be involved in a volunteer group which started offering free support services to those on the ground. We ran a text information service where people could text in questions, including asking for the nearest help center based on their location (which they had to provide via text). We would likewise respond over text. We were able to help people find the help they needed, by making it available over text we also were able to reduce the already overloaded cellular services (voice calls are much more expensive than text). We helped dispatch appropriate emergency services to people in need, but it was still very much copying address information as text between various jury rigged systems (written by us during the incident).

I hope we can improve these systems in the coming years, it is especially important to improve them to be redundant to things such as cellular system overload (which is very common during major crisis).

Very nice, although I want to point out that this page contains many typos - you probably want to run a spell and grammar checker over your blog posts and your resume as many employers may screen due to these.

I initially had rsi pains in my wrists and pinkies, after I recovered I switched to a Kinesis and was convinced it helped keep the rsi away for 2 years or so.

Recently the pain came back worse than ever, this time accompanied with quite serious thumb pains, I certainly do not blame the Kinesis as it is most surely a combination of many factors (poor habits, stress, workload, etc.), but the layout does increase the load on the thumbs so I think that contributed.

For now I have switched back to a cheap Microsoft dome keyboard as it is easier to type with using only my forefinger and middle finger (and easily allows me to avoid using thumbs and pinkies).

Of course this is all just my personal experience, for years the Kinesis was lovely and I may still go back to it, as always YMMV.

Thanks for those words and that link.

I like that way of thinking of it, I see it as just reusing the existing stack frame as a call in a tail call position doesn't need anything from the current stack (returning to this frame adds no extra meaning to it).

Having never implemented them though I feel like my ideas still need some fleshing out, my naive approach seems to be similar to the idea of trampolining.

Really looking forward to reading the linked document, very thorough and looks to be just what I was looking for (it even covers architecture dependent aspects!).

Thanks, that document looks very impressive and will now sit at the top of my reading list :)

Oddly following that link gives me a 404 ('The requested URL /~dyb/papers/3imp.pdf‎ was not found on this server.', seems there is a trailing character '%E2%80%8E').

I was able to find it on google and open it, yielding the link http://www.cs.indiana.edu/~dyb/papers/3imp.pdf

I have been writing a scheme interpreter in c, and for me the most interesting aspect so far has been the level at which I am programming.

At the beginning it was very traditional c; symbol and AST manipulation were a PITA (at that point it was a malloc'd arrays of `expressions`). After I had a base language working I started to use the language I had implemented so far to further the implementation, this finally peaked where this weekend I did a large refactor to remove most of my c arrays and instead replace them with scheme pairs and lists.

For example, here [1] I implement define function form in terms of lambda, specifically new_lambda(env, cons(args, cons(body, null))).

In hindsight this seems so obvious, but I have found the whole process extremely interesting, specifically looking at how the implemented languages starts to influence the implementation language.

I really cannot stress enough how enjoyable the process of writing my interpreter has been, I thoroughly recommend it to anyone who is interesting in programming languages.

[1] https://github.com/mkfifo/plot/commit/07272bd69e51979ab71fa0...

I have been working on a small r7rs scheme interperter [1] and it has been extremely educational. I had never used scheme previously but learning it from sicp [2] has been rather enlightening, it surprisingly lived up to expectations.

I haven't considered if I will go down the compiler route, but either way that resource looks very interesting; especially the coverage on tail call optimisation at the assembly level.

Does anyone have any further resources discussing tail call optimisation? I would like something a bit more in depth.

The other topic I would like to read more on is continuations, as a still newbie-schemer I find the idea of implementing them to be quite daunting.

[1] https://github.com/mkfifo/plot [2] https://mitpress.mit.edu/sicp/

Part 2 has been posted http://akaptur.github.io/blog/2013/11/15/introduction-to-the...

But I still feel like both part 1 and part 2 are far too short; even if read together they provide very little information to digest.

Locally in git you have the HEAD@{n} notation to step back n steps through the reflog, so after a bad rebase a `git reset --hard HEAD@{1}` should be all you need.

I am not sure how easy it is to get money in/out to/of bitcoin from within Russia, at least in New Zealand it is generally a PITA and involves many hoops.

It could have a simple 'are you sure y/n' prompt, and you could then have a git config setting to disable this.

I was assuming after the fact as that information is not saved anywhere client side.

Also I am not sure what he did to push to 150 remotes, and in that case this output would be much more tedious to piece together (and that is assuming he was able to capture all of it).

However I disagree that force pushing is rare, I find it is a (sharp) tool I use most days (more often on private repos or branches).

I do like the idea of github providing some kind of web interface to view the reflog and reset branches to various points within it.

After my first bad force push (silly git push default on an unfamiliar machine) I now 'enforce' the `git push remote from_branch:to_branch` syntax on myself when force pushing, I also have adopted the habit of always accompanying any --force with a --dry-run.

The central repository is the only point that knows (with 100% certainty) which ref the branch was set to before the force push.

Each distributed node only knows the ref the branch was pointing at the last time they fetched, so their certainty on what the branch looked like before the force push is much lower.

Git provides all the pieces, we just need to put them together in the right way.

The issue is that a client may not have fetched for a while before performing the force push, so it may not have all the required refs for performing the rollback.

The server of course still has all the refs, so it shouldn't be too hard to add a command (run client side) to invoke the required server-side rollback.

In the case of git 'rewriting history' is not really the problem, and it leaves the old history intact (you cannot change git history, but you can create an alternative history).

The old history will possibly be garbage collected eventually, but for quite a while that history is still accessible.

I think the only missing piece is a simple (and obvious) client side 'undo/rollback that force push'.

The issue is that the git client may not have the history pre-force, so it may have insufficient information to do the rollback (at least in the current model), however the server still has all the refs (and they are listed in the reflog).

It is possible that the current tech used in robotics will somehow form the basis for the work over the next 1000 years or so, either directly or via some tangential discovery by researchers working with current tech.

Without the benefit of hindsight it is impossible to tell with certainty what techs are worthwhile exploring and what should simply be discarded, the idea of discarding is of course based on the false assumption that techs that are later unused never had a use (e.g. we may solve a software problem with current tech that will form the basis for future robotics software).

Thank you for mentioning jsmn, it was very enjoyable to read through jsmn's code.

The fact it only uses tor when 'normal access' isn't available means for the majority of usage it isn't adding any privacy.

Scissor switches can be quite comfortable, and the macbook air has quite nice switches (IMO I like the thinkpad x1 carbon's a little better, but it is close), and the location of the trackpad being under the keys is much more comfortable than having a physical mouse to the left or right.

For my desktop I have a kinesis advantage, but I often find using my thinkpad for long periods of time to be very comfortable, I just wish I could find a decent trackpad for my desktop(s).

Not quite, the 'Model M' actually refers to a collection of keyboards, some of which used rubber domes (see column 2 of [1] for a quick reference)

[1]https://en.wikipedia.org/wiki/Model_M#Features_by_part_numbe...

FWIW I type on a mechanical keyboard daily (cherry mx browns) but I am not a fan of the model m keys (buckling springs or rubber dome IIRC), they are very different in feeling.

My Thinkpad x1 carbon keyboard comes next, scissor switches can be quite nice.

Although this is subjective, the kinesis advantage keyboard has really helped me better deal with my RSI; it has clusters of keys under each thumb and is fully programmable so I am able to move problem keys around (for me pinky keys are quite uncomfortable).

For me shift, space, backspace, tab, win, ctrl, alt, esc and enter are all thumb operations.

However I wouldn't go as far as saying it has solved my RSI, but it is definitely part of the solution that allows me to program 40+ hours a week (more like 50-60, 40 hour week professional + hobby programming).

FWIW the other parts include regular exercise, alternating mouse hands and using a trackball on my 'off hand', and a keyboard-heavy system (vim, dwm, etc.).

This is extremely cool, I am becoming more interesting in the idea of trying to write a small toy language and articles like this excite and inform, great work.

Awesome project thanks for sharing.

A few months ago I started on a project to make a 'grip' style chording keyboard [0] also based on the teensy, sadly the project has stalled for a bit (graduated and got a full-time).

I have the keys wired [1] but haven't figure out a nice way to mount them yet, and the firmware isn't finished.

[0] http://geekhack.org/index.php?topic=43132 [1] http://i.imgur.com/zQiYmQC.jpg

EDIT: I always found it a bit sad that I was unable to find much documentation on how Engelbart's original chording keyboard worked, does anyone know of a source where I can read how the keys are chorded?

Very well written article, clearly explaining what is usually a rather complex topic for new programmers to understand, bookmarked for future use.

The other resource I use for similar situations is http://c-faq.com/decl/spiral.anderson.html [EDIT]: someone beat me to it

FWIW: The explanation by Dave G in the comments isn't quite right (I couldn't reply there, comments appear closed):

> void something(); // prototype of function that takes undetermined number of arguments

> void something(void); // prototype of function that takes no arguments

> void something() { return; } // function that takes no arguments

isn't quite right as `void something(){ return; }` is still a function that takes an undetermined number of arguments, it just cannot access them; calling `something(1,2,3)` is still valid.

> void unknown(){ return ;}

> int main(void){ something(1,2,3);}

is valid.

Truly stunning.

Thank you for mentioning SLIMV, I am a schemer-in-training and was 'afraid' I would have to abandon my beloved vim.