It scales up and handles PB of data as well.
141 karma · joined May 4, 2015
It scales up and handles PB of data as well.
If the devices storing data go offline we constantly monitor and refresh the pieces to maintain integrity.
With the wide geo-redundant storage even entire regions can be taken offline and durability is preserved. We recently had 7% of devices drop offline during the Texas power outages last month with no issues. We constantly monitor and repair the data as nodes go online and offline.
Yes, speeds do depend on users upload speeds, but we spread your files among thousands of peers. So while your 5 GB object might seem like a lot of data, each peer might only need to upload a megabyte or two. Operations are in parallel so you can get high throughput (think of lots of small straws taped together).
The unlimited storage is a separate backup product which right now is only only specific devices that have an upper limit on their size.
(Disclaimer/Source: Co-founder of CrowdStorage)
I think in practice what you would do (if your use case allowed it) is use CRDTs, but periodically checkpoint and trim them when you know everyone has synced. That gives you very similar properties to the video game world and still has the features of not losing peoples edits when they make them offline.
https://status.cloud.google.com/incident/cloud-networking/20...
My city is placing a similar proposal on the ballot this November (https://connectkaysville.com/).
Speed and ability to get the service varies greatly by distance and LOS to the tower.
Would this help increase the number of covid-19 patients that could be treated? Or do they not require ventilators? I wonder if the study they mentioned about it was ever completed?
Sometimes you just want something quick and a little bash script is perfect. For example, I use getmail to periodically fetch my email from all of my email providers, gmail, hotmail, etc.. Whenever I needed to get email quicker (like if I was sent a security code or something) I had to SSH into the server and manually call getmail to fetch it before the scheduled time. With pushback I have a little simple script that gives me the ability to do it from the pushback app and it is a real time saver.
Here is my script I used in case anyone is interested:
#!/bin/bash
while true; do
result="$(curl https://api.pushback.io/v1/send_sync \
-u <my_token>: \
-d 'id=Channel_379' \
-d 'title=Check Email?' \
-d 'body=Choose from the actions' \
-d 'action1=gmail' \
-d 'action2=hotmail' \
-d 'action3=personal')"
if [[ "$result" == "gmail" ]]; then
getmail -r gmail
elif [[ "$result" == "hotmail" ]]; then
getmail -r hotmail
elif [[ "$result" == "personal" ]]; then
getmail -r personal
fi
sleep 15
done
I've used it to also notify me when long running commands finish, as a way to add manual review to an otherwise automated process, etc.I have quite a few openwrt routers running with substantially less resources available to it than the worst android phones.
I don't know if go would be able to meet the cpu/memory constraints in that environment... from the blog post it seems like that wasn't even measured?
While not perfect, I've addressed some of the issues in a similar password scheme of mine: https://github.com/onionjake/doh
* you can write specs for domains' specific password requirements so the generator can guarantee it is accepted * the counters you append to your password when generated are not sensitive so can be saved/synced * I have not addressed needing to change your master password, but I'd also like to point out using a password hashing scheme doesn't preclude you from having more than one master password, perhaps to segment work passwords from personal ones. * sometimes domains change as well, so you can log the domains used it generate passwords, which might be sensitive from a Metadata standpoint, but from a hack-your-password sorta way. This also helps when I use it for passwords other than websites (like ssh key passphrases)
> Thing is: There's a solution for all these problems: All you have to do is actually generating a random password and store
I agree that generating random passwords gives a better user experience, which it is much more popular. I prefer holding all of my data even if I could store it remotely encrypted so hashing was the clear choice. I also kept the algorithm simple so that I could implement it from memory on a strange computer if needed. Definitely not for everyone!
Something we can all strive for professionally and while commenting on HN.
IIRC strace wouldn't work if you used any setuid binaries (horrible but our makefiles used sudo for some things).
There are also some tricky corner cases like sed -i which creates a new file then moves it.
Let me give an example of one way it hurts the existing git ecosystem. Someone decides to include their external source dependencies for their project as tarballs using lfs (which is probably dumb and not the use case that lfs is trying to support, but people will do it nonetheless). Now I want to mirror that repository inside of my companies firewall which hosts its git repositories using just git over ssh. Without lfs, I would just do 'git clone --mirror && git push --mirror' and I internally have a mirror that is easy to keep up-to-date, is dependable, supports extending the source in a way that is easy to contribute back, etc..
Now what options do I have with lfs (outside of gitlab)? Create a tarball with all the source +lfs in it? Create a new repository that doesn't use lfs and commit the files to that? Each of these is less than ideal and makes contributing back to the project harder.
Imagine instead a world where this happened: Github.com announces that they are adding large file support to git. These large files will be using an alternative object storage, but the existing git, http, and ssh protocols will be extended to support fetching these new objects. When support for it lands in the git mainline repository, suddenly everyone will be able to take advantage of it, regardless of how they choose to host their repositories!
I admire gitlab for creating an open source server implementation. I just wish that github would have done it a different way that would have been better for the overall git community (not just github users).
The additional command and configuration (and perhaps object storage) would be needed either way.
If it was fully integrated with git, you could do 'git fetch --all-objects-ever' and your repository could then be cloned and fetched from.