How about this for the plot: Witness a high profile crime & then get a witness protection just to avoid getting tracked by FAANG! :)
579 karma · joined January 23, 2015
How about this for the plot: Witness a high profile crime & then get a witness protection just to avoid getting tracked by FAANG! :)
Higher is better?
May be its not the Windows but 90s & early 2000s ... don't know.
https://twitter.com/signalapp/status/1348785240819466242?s=1...
There are lot of low-hanging fruits which are quality of life improvement e.g #1 ask from my non-technical family members: Background wallpaper :)
Another feature: WhatsApp migration
+ Its open source, if they are willing to accept PRs things could accelerate
Signal team did an AMA in last few days [1]
[Few of the Q/A]
Q: Is there any plans to make user ID system, so that we can add friends without knowing the phone numbers?
Ans: Yeah, we're working on it!
Q: Hi, is it possible to backup chat history?
Ans: Thanks, we know this is a big deal and think about it a lot. We're working on ways to do it that would be privacy preserving...
Q: These things would really make the experience for my family and I complete
Support for backups and transfer on Android. Not manual, but automatic like iOS
Support for ChromeOS via Android Tablet support
Support for simple markdown like bold, strike through etc.
Ans: Great list, we're working on all of these!
[1] https://www.reddit.com/r/technology/comments/kt91qk/signal_p...
I can relate to this. One way to look at this is that dev-team is where majority of IP is created and not in teams like support/qa/docs/PMs. Over the period of time, they are also the reservoir of domain knowledge.
This often results into nuisances like:
1. Instead of reading product docs people will ask questions directly over slack (e.g Do we support Windows 2008? Do we have feature X?)
2. Adding dev team in a slack channels in which sales can directly ask questions which ideally should be answered by Product Managers.
I think the state machine required to yield, async & await is baked into the language.
But yes, one can implement the Future trait to take finer control.
Social media is a catalyst and internet is the mega-phone/amplifier which makes lot of things precipitate quickly than before.
Indian families are also similar, but never before (at least in India) so many young people have to work away from their home (normally some small town). This puts enormous pressure on young, double income couples in cities.
1. Don't make people scroll one-page to actually see the software list/cards
2. My first reaction is to find the search text box which is not easy to locate. Make it prominent, front and in centre.
[1] https://tech.hindustantimes.com/tech/news/niti-aayog-ceo-ami...
With in-mem DBs, there is no dollar cost for reads + writes and the IOPS will be way better than dynamoDB.
AWS has redis offering as elasticache.
[1] No indexes, strongly consistent get & put, < 10 GB
I would say is that a lot of hard problems (of last 20-30 yrs) are getting commoditised (e.g. S3, DynamoDB, Redis) and barrier to entry reduced. This would mean increasing the work is "glue & pipes".
That sums up very nicely. This reminds me of a quote:
"Passing an exam with good grades/marks only show that you are really good in passing the exam" -- By (don't remember)
After substantial population is vaccinated there should not be any need for lockdowns & closures.
But the same people will be affected due to economic headwinds (directly or indirectly) if vaccine is not available soon.
So it is also a question of financial stability & bring confidence back of doing things normally.
The covid vaccine lifecycle has been way more short than other vaccines. Naturally the probability of some going wrong is higher.
The scientists, countries and the entire world is taking a calculated risk. Desperate times call for desperate measures.
Will not write the whole file. Instead each page of the database (default = 4KB) will be separate put.
The use case is: one-writer multiple readers.
The readers will read an old snapshot of the database (from s3) and writer will write to the active one. This way a lot of readers can open the DB in read-only mode.
As for writer, each page will be a separate put. The writes will be appended to a log(s) locally and the page will be synced in the background. This helps to exploit lot of parallel PUTs to S3. Once the sync happens the disk space for that page will be reclaimed.
For the writer:
v = open_new_version()
//inserts + updates
//commit
close_version(v)
For readers:
open_version_for_read(v)
//select
The vfs will also have snapshotting capabilities i.e. you can have multiple versions of sqlite db.
Even the big ones. A lot of applications (e.g backup vendors) had to resort to use EBS volumes because of lack of read-after-update consistency.
The barrier to entry for lot of developers has been reduced.
My prediction: A lot of storage infra (FS, DB) with native support for S3 will get commoditised now.
That is only within the same AZ right? Only snapshots are cross-AZ replicated?
PS: why, oh why ppl use this hard-to-read gray font color? Is there allergy to the black font color on white background?
1. How to handle success
2. Dealing with failures
As far open sourcing the code is concerned, I remember the author said that it would open-up some secrets which players would otherwise will have to discover. E.g existence of "inn of the red rooster"