hefeweizen

Correct, but I'm guessing the applications probably open files at a higher abstraction than a file handle [the curse/gift of Java], so it wouldn't be hard to decouple the file handle, and allow a trigger to close the file handle and sync on logout.

From a purely kernel perspective: it has been some time since I last looked at the kernel fs/dentry code, but from what I remember, the open file handle would hold refs for dentries that comprise the path [all the way up to mount root]. But even that wouldn't prevent other dentries from being cleared anyhow: only the open file would have unencrypted pages in the page cache. I would highly recommend reading the linux fscrypt code if you would like more details: it's very well structured and quite easy to get into!

Of course, the foolproof way would be to check lsof and nuke all processes that still have file handles open before logging out, but that's probably too much heresy :)

Linux fscrypt[1] [which Android uses for user data] doesn't work like that, you don't need to mount/unmount to decrypt: if the key is evicted from the linux keyring and the page cache is cleared, the user data will not be accessible on locked screen, even by root. It needs the a key in the kernel keyring to decrypt the pages associated with just the encrypted files. It's pretty neat!

[1] https://www.kernel.org/doc/html/v4.18/filesystems/fscrypt.ht...

"We are proud to launch Pants 2.0, our custom tailored solution for all your storage problems".

I think the GP is pointing out that people tend to overestimate how powerful these techniques are and that using the term AI might have something to do with that.

Not that it isn't impressive: it's just that we are pretty far off from anything resembling what "Artificial Intelligence" may come to embody (ignoring, for the moment, all fuzzy definitions of intelligence).

It's like building a paper airplane and worrying about the aging effects of space travel at light speed: maybe a good thought experiment but not that big a concern right now.

The "bicycle of the mind" platform vs aggregator argument is a bit contrived: the author is conflating features built on top of platforms with the platform itself. Most of the examples listed (Google Photos auto-edit, Maps suggestions, Gmail compose) are typically features built on top of platforms that can be (and are) used without these features.

Instead, I would think of these tools as an electric bicycle of the mind (to borrow from the article): the purpose of the motor is to help you on steeper hills. It is inherently still a bicycle.

Maybe stop trying to shoe-horn multi-decade companies with thousands of employees into ill-fitting philosophical silos? I'm all for arguments for/against companies but retro-fitting them into narratives and then proclaiming A is better than B is disingenuous.

> Not so surprising after Google's recent pricing changes.

Didn't that happen just a week or so ago? I don't think this can be attributed to the pricing change this early.

False, "Hey Siri" activates Siri on the iphone (just tried this out). So, it's not different.

I found the following link to be an interesting read on the topic: http://codecapsule.com/2014/10/18/implementing-a-key-value-s...

The author also has a 6-part series on programming for SSDs: here's a more descriptive blog post for general SSD access patterns and optimizations: http://codecapsule.com/2014/02/12/coding-for-ssds-part-5-acc...

How similar is this to multi-task learning?

Yeah, any new machine instance has to join the Swarm (and its equivalent in kubernetes-speak). But that can be decoupled from kubernetes or docker swarm mode.

As for image management, it would depend on how you would like to propagate new images. With a private docker registry, you could potentially point each new instance to the registry and take care of propagating new images. I favor this approach since it keeps everything separate and easier to manage.

In the context of Docker Swarm and Kubernetes, autoscaling refers to container level scaling ie. given a set of nodes, any autoscaling function would manage the number of containers that are currently running on these nodes.

For instance/node level autoscaling (which is closer to what you need), I would recommend using the autoscaling features provided by AWS/Google Cloud.

Slight nitpick, but this articles deals with "Docker Swarm mode" [1], which is different from Docker Swarm [2].

[1] https://docs.docker.com/engine/swarm/

[2] https://github.com/docker/swarm

[3] Difference between Docker Swarm and Swarm mode: http://stackoverflow.com/questions/40039031/what-is-the-diff...

In addition to other points against this measure, there are massive privacy implications. Loads of people could be reusing passwords or may reuse keywords for multiple passwords. A collection of such data by an organization can and will be misused.

Of course, it is a fallacy to assume that leaders from STEM backgrounds may be qualitatively better than others, or even perform better for their constituents. But then again, such leaders would definitely not ignore climate change wholesale.

If there is indeed a correlation between education in any of the STEM fields and "leadership qualities", would it not be better to reform education to introduce skills implicit to these fields at an early age (logic, reasoning, rational discourse, understanding of the scientific process) instead of selecting for these qualities later on?

VLDB '15. Previously discussed at: https://news.ycombinator.com/item?id=10207863