I wanted to join as a reviewer, but you don't accept reviewers from outside the US. Is this something what you are working on and has a chance to change in the foreseeable future? I work for a public US tech company but I'm located in Europe.
My two goals are to maximise my disposable income and to get to know people who could improve my life (by further career opportunities, by being good cofounders in the future, or simply by inspiring me, being worth talk to or learn from). The second goal is hard to achieve when working remotely (I used to work remotely for several years). The first goal: I know that SV is an expensive place to live, but I have an impression that companies hiring remotely pay so much less than SV wages, that even considering cost of living you can save more living in SV.
I had some roller-coaster in recent years and I need some peace of mind for the next few years. What I mean is to work for a company which most likely won't go under in the next 12 months (hence "reasonably well funded") and with enough resources to get things done; and kinda to focus on one area rather than having to take care of everything and then more. I don't mean I'm looking for a low stress job. Just a bit less stress, bit more certainty and bit less responsibilities than when running/bootstrapping your own company (I did that in the past and will probably do it again, but in a few years).
It sounds like a more established company might be a better landing place. Established companies are probably more likely to accept the risks associated with relocating someone in their forties and have more experience with doing so. Those companies also are less likely to go under and large companies offer more opportunities to meet people.
In the end, if you want to move to California, decide to move to California. Make the tradeoffs. Figure out the details. Work through the problems. If it doesn't work out, it doesn't work out.
It requires one of the computers to be online all the time and run its software (aka server). Also, it's even more niche than GoodSync. There's no way I'll trust my sensitive data to some totally unknown software.
I was under impression that it's a backup utility. It doesn't work realtime, you need to execute its CLI. It also doesn't really do full sync, but one-way sync. If I have some files newer on my machine but other files newer in cloud, it won't handle it well. Am I correct?
You can create a self-signed certificate for Google domains and trust it on your machines. Then you can MITM. This won't work well if you want to do it at a scale, with a number of 3rd party users, but if the only user is you or your family, it should do the trick.
mkcert[1] is probably the easiest way to generate root certificate and leaf certificate(s). Then you can use a proxy like Squid to intercept the traffic[2]. You’d also need a local DNS server to point hosts like fonts.googleapis.com to your own web server.
"Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.
We deem this acceptable because the proxy or MITM can only be effective if the client machine has already been configured to trust the proxy’s issuing certificate — that is, the client is already under the control of the person who controls the proxy (e.g. the enterprise’s IT administrator). If the client does not trust the private trust anchor, the proxy’s attempt to mediate the connection will fail as it should."
Does anyone know how Chrome does do distinguish a private trust anchor from all the other root certificates that are provided by the operating system? (Comodo, Comsign, Digicert et al)
Out of curiosity: why do you keep such documents in repositories instead of simply in a filesystem (on an encrypted volume, backed up and possibly synced across devices)? Tax spreadsheets usually don't change, so there's no need for version history (if anything, new rows for new years are added, but without changing past data).
I ask this because I'm trying to figure out a solution for myself for keeping sensitive personal information and I never thought about storing such documents in a repository. Maybe I am missing something and your use case will open my eyes. Thanks!
For me one big benefit is that it's distributed. I like to keep my important documents backed up on all the computers i have, on a USB drive stored in a safe location and also store the data with a cloud provider.
Now, if i update one document on computer A, and another document using computer B, i have to sync it to all other devices which is a PITA without git. You get into the situation where you don't know if the version on the USB drive was newer or older than the one on computer B etc, whereas with git all this is available in the version tree and there are nice merge tools available.
I've been planning to do this even for photos, for all the reasons above, but haven't taken the full step yet.
Wouldn't encrypted files with a service like Dropbox help? Containers usually sync well (only syncs changed parts). Only downside is that you can't access files without decryption software.
Dropbox, as all other "just-works" sync services, don't handle merge conflicts very good. Suddenly you have thousands of Filename_EditedByX(3).txt in every folder and dont know which one of them is the newest and don't have their most common ancestor version easily available for a 3-way merge.
To be fair, they cannot handle merge conflicts with encrypted containers. I find that merge conflicts almost always cause more trouble than the work of avoiding them from the start. As long as you don't share data (with containers unlikely), merge conflicts should be extremely rare (and anticipated).
I used to keep the data on Dropbox but switched to a repo because it felt to have better safety against user error. It's not all that hard to accidentally delete or modify a file in a filesystem. Given the commit process it's much harder to do in a repo.
My tax sheets are updated throughout the year for various reasons (bonuses, side gigs, property sales, etc.), so I rely on the version history. I also keep a lot of other stuff that I update more rapidly (mostly in text documents.)
