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?
1Pasword for ages had ability to sync your computer and iDevices on the same WiFi network by opening direct connections. A bit more inconvenient than cloud base sync, but convenience was always death to security :-) Self hosting may be the answer.
> 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.
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).
New Zealand has actually rolled out location relay for 111 [1]. They've also managed to do it in a way that seems to keep privacy in mind, the location is deleted after 60 minutes. It's only for Android phones though.
Anyway, it's a great initiative, and one where the possible privacy implications seem to have been mitigated, while providing a massive benefit.
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.
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.
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.
The best way to deal with tail call "optimization" is to not treat it as an optimization at all. Tail calls are a syntactic property of source code. You can easily determine whether a given call is in a tail position by recursively traversing the AST. Then you just have to generate tail calls in a way that uses constant stack space. This is mostly a matter of properly designing the calling convention. See: www.complang.tuwien.ac.at/schani/diplarb.ps.
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!).
If you've got the freedom to design your calling convention, you don't need trampolines or anything like that.
The basic idea is to compile every call in a tail position to a jump. You just need to clean up your stack before making the call, and make sure to arrange your calling convention such that A can call B, which can jump to C, which can return directly to A.
In the A -> B -> C example, this means:
1) Using a callee-pops convention so that callees pop arguments off the stack rather than callers. If B and C take different numbers of arguments, A doesn't know how many arguments to pop. So functions should pop their arguments off the stack themselves before they return.
2) B must restore its callee-save registers before jumping to C, which will save those registers itself if it clobbers them.
3) To accommodate variadic functions, there has to be a hidden argument to let callees know how many arguments were actually pushed by the caller, so they can pop the right number.
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 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.
the USD was so much more preferred for such a long time, especially as the ruble was losing 10% of its value each month at one point, that the Russians have made settling cash transactions in non-ruble's illegal.
They also introduced a plethora of cash import and export laws, since at one point 90%+ of all transactions and 60%+ of GDP was black/grey market cash and in USD. Russia is still a cash heavy economy, now its just ruble's instead of dollars.
It means you find it hard to buy or sell rubles outside of Russia, and inside exchanging USD is expensive since the purchaser (edit: exchange businesses) needs to have a license for exchange and a license to hold USD.
off course people still use the dollar, but its no longer a case that you have a black market cash exchanger standing on every street corner, or every restaurant and bar etc. accepting USD. It is why more recently some politicians have called on a complete ban on foreign currencies, and a ban on any cash payments for goods over a certain value.
The difference between now and 10 years ago for foreigners is that credit cards are more broadly accepted and easy to use, as are ATM's for foreign cards. I wouldn't even bother going through the hoops of dealing with cash or exchanging cash were I visiting.
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.
