Hacker News new | past | comments | ask | show | jobs | submit | more rrdharan's comments login


Any idea if that works in modern VMware Workstation? It's currently on version 17, whereas that post was for version 6.5.

VMware Workstation has such disjointed development spurts that it wouldn't surprise me if the feature had been ripped out at some point. Other useful features such as machine groups have been. :(



I guess we can say it was too cool.


Thanks. Yeah, I kind of expected that. :(


It was removed in 2011.


> When's the last time ls, cat, date, tar, etc needed to be updated on your linux system? probably almost never.

Bad example: http://www.slackware.com/security/viewer.php?l=slackware-sec...

They find stuff like this fairly often in GNU coreutils even to this day.. it’s the main reason there’s a Rust coreutils effort.


It's probably still a good example. Looking up the CVEs for various search terms:

coreutils: 17 results

linux kernel: 6752 results

x11: 184 results

qt: 152 results

gtk: 68 results

docker: 340 results

rust: 455 results

python: 940 results

node: 110 results

javascript: 5657 results

firefox: 3268 results

chrome: 3763 results

safari: 1465 results

webkit: 1346 results

The large monolithic codebases have a lot more CVEs. I'd also argue that patching a fix on code made up of small, modular parts is much easier to do, and much lower hanging fruit for any casual developer to submit a PR for a fix.


The large ~~monolithic~~ codebases have a lot more CVEs

Who would've guessed. Also the older ones also got more CVE's than newer ones, even if they aren't that big.


> This is to let the military use AI to help kill people.

So are your tax dollars, and some portion of any money you spend or any productive engagement you have with the economy wherever you live on this planet.


My tax dollars are used to bomb the middle east and there is absolutely nothing I can do about it. Voting is useless.


Donate to humanitarian aid organizations to offset your tax bomb dollars


Almost universally those funds are stolen in the name of administrative overhead


This is not a convincing argument for not engaging in voluntary trade with the morally bankrupt.

It is, however, a pretty good argument for the moral basis for tax minimization and avoidance.


> And gradual rollout of config files quite often seems like overkill.

Indeed, but it is still mandated at large companies (e.g. Google) because of exactly this scenario.


The timeline backup is encrypted clientside before upload.

Meaning no casual FBI or police warrant is gonna vacuum it up (at least not from Google, they’ll just go to the cell providers / towers instead as siblings have pointed out).

Obviously yes NSA and CIA and various other nation state attackers will just get it directly off your phone or evil maid you or surveil you in any number of other more traditional ways.


Someone mentioned geofence warrants, i.e. cops/feds asking "Hey Google, tell us which accounts had devices found in these time-space coordinates!", I guess they'd be asking mobile providers to do more logging as an alternative.

A Google account is probably more useful than a SIM card, which might be anonymous or have exchanged hands from the registered buyers, if you as a cop can ask Google to hand over the emails or IPs used by this account, you can find the person's identity and address (if using home IPs subpoena-able by asking the ISP).

I wonder if it's not just American police, imagine this question being asked by Russian FSB, or the "good guys" in the form of the Israeli authorities.


The cell providers actually do erase this data. I tried to subpoena it for a murder suspect to help show he wasn't at the scene, but he left it too late, and Verizon said that they delete their data after 5 years. I don't know the timescales of the other networks.

Not to say that the NSA don't have it all backed up -- I'm sure they do -- but for warrant (i.e. legal process purposes) it probably has a shorter timespan than the Timeline data stuck on Google's infra.


I work at Google on database systems and would still pick the VMware codebase (specifically the virtual machine monitor component).

It was by far the most impressive piece of software engineering I’ve ever had privilege of perusing.


I had not heard of this person and it turns out there’s an entire Wikipedia entry for those interested in the backstory:

https://en.m.wikipedia.org/wiki/Ashley_Gj%C3%B8vik


Saying Google didn’t have to reinvent containers when Google invented containers is .. something (https://en.wikipedia.org/wiki/Cgroups).


And for a brief couple years Google had an offering the world could use that exposed that invention. Via the stock, well respected LXC tool.

They created something, only to never ever use it in public eye. To go keep reinventing and keep NIH'ing. The android virtualization stack is fucking wild, and hardly used, offers such a meager fraction of what ChromeOS was doing.

Not a bad callout, but this seems like a particularly glorious & vicious slam... that doesn't change the big picture on iota.


Android is reusing the ChromeOS vmm, crosvm. How is it less capable?


They invented containers on Linux kernel.

Containers on UNIX and mainframes predate Google's existence.


It's somewhat unusual for Google to open source and mainline this bit of functionality. Last time I heard, Google's internal production Linux kernel still has 9000+ patches[0] on top of vanilla Linux. And I'm still waiting for them to open source switchto[1].

[0]: https://lwn.net/Articles/871195/

[1]: https://www.youtube.com/watch?v=KXuZi9aeGTw



Cgroups is a kernel feature, parent is talking about the userspace stack for managing containers. Google uses LXC in crosvm, and didn't have to program it from scratch.


cgroups are neither necessary nor sufficient for Linux containers


Have you read about the British postmaster scandal? Be careful what you wish for…


commented on the wrong post?


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: