4,304 karma · joined March 14, 2010
I'm surprised no camera manufacturer has created an easy way to get all your photos to Google Photos / iCloud/ Dropbox / etc. They have some wireless photo transfer things, but they're clunky and unusable. Just connect the camera to WiFi and auto-upload everything to the service of my choice. I'm guessing it's a mix of:
* Camera manufacturers are hardware companies and can't do software and cloud stuff.
* It wouldn't interact well with swapping SD cards, which is what all the pros want.
* The camera would need to stay powered when off to upload photos. Current cameras have a hard power switch.
A nuclear reactor in space would require an enormous heat sink to get useful energy out.
I wouldn't go that far. Big companies put a lot of effort into saving $12/seat.
But, if you can convince them they get >$18 of value from it they're usually happy to pay. With hobbyists it's more emotional. $6 is "just a coffee" and can be justified just to try it out. At $18/m is one of your household bills, and many will decide they enjoy watching Netflix more than messing around with Tailscale.
ClearCase is a terrible version control system I wouldn't wish on my worst enemy, but it did have some good points that git still doesn't have. Large binary file support, configuration records, winkin, views.
With various big companies going towards giant monorepos and the local git repo just being a view into the super-centralized repo, I think they will re-invent parts of ClearCase.
Wait, does this work? Are superposition detection devices theoretically possible? Got any reference with more on this?
VC systems do constantly send back packet loss statistics and adjust the video quality to avoid saturating a link. Any buffering in routers along the way will add delay, so you want to keep the bitrate low enough to keep buffers empty.
Video codecs like h264 or VP9 are the opposite: Decoding is just following an algorithm, but an encoder can save bits by spending more effort searching for patterns in the data.
I do remember merges being horrible in svn. Just branching off trunk, doing some work and merging back is fine, but if you try to merge from trunk to your branch to "catch up" you're in for some pain when you later want to merge to trunk.
Also svn treats adding and deleting file as different from just editing, more so than git does.
It was only 1G and 2G (GSM) that needed to avoid overlap.
As a manager I find their really curious. I guess they were trying to avoid leaks. I wonder how they chose who to lay off. Most recent performance rating? Next level managers impression?
These days traceroute to a random .jp or .au just gets you to the nearest CloudFlare or AWS, which is a bit sad in a way.
Encryption in general was in a pretty bad state in the '90s: original http was unencrypted and early mobile phone standards that are still in use have very weak encryption.