skull-squadron
commented
8 years ago Closing, just because it seems like patching from files seems like a fragile, unmaintainable approach when there's mostly the same source supposedly being supported and developed "publicly" (either it is, or it isn't). I could be wrong.
It seems https://github.com/misheska/basebox-packer became https://github.com/boxcutter/ubuntu/tree/master/floppy
Minirant in an issue (directed upstream)
TL;DR
All I want as a greedy, leeching user* is for vmhgfs, ballooning, timesync, paravirt devices and disk shrinking to work on supported platforms consistently without monkeycloud, patch hell... because I want to automate the f&!$ out of everything for desktop / bare-metal virtualized development and deployments, not be a job-security assured, FreeBSD sysadmin (sorry, FreeBSD... you maybe cool (ZFS, dtrace, WhatsApp), secure (jails, pf), cleanly separate from userland and the purest descendant of old UNIX, but you just don't get process supervision or unattended configuration management without egregious amounts of timesink (
portsnap fetchrefuses to run interactively, their UNIX init system doesn't restart processes that crash)).* Having endured over $23k in VMware "training" and "testing" BS because work paid for it One possible better way to handle this is to vendor dependencies by copying them in this repo and mention their source, rather than depend on fragile linkrot repos that are all about rebranding.
Upstream rant (because people here might actually read it)
Here's the upstream forks... It's pretty sad when a patch project currently has 2x forks and way more stars. The situation of their project + the products comes across as inadequately maintained while badly trying to pretend to not tool the community.
That the shipped vmware-tools tarballs / open-vm-tools haven't kept up with out-of-the-box functionality and ease of use is asinine... it creates confusion. They should probably nuke the shipped tarballs without losing functionality for enterprise users, ship actual binary/source packages of open-vm-tools per enough versions of platforms and ship open-vm-tools tarball as the generic linux fallback. It should also be easy to go to their page and accomplish the same task as the in-product tools installers. The simple fact of maintaining the two allows the tarballs to get old and open source repo to flounder, leading to a Tragedy of the Commons... pick one way and support that. (Readers: If anyone else you know works for a megacorp and can suggest to their execs to yell at VMware execs, please consider some nicely-delivered suggestions that they can take credit for.)
Even more meta
Where multiple, private and corporate channels and gentle encouragements fail, anonymous, public shame (such as making TechCrunch / HN / etc.) seems to have the desired impact. One could make an entertaining screen-cap movie of a default, out-of-the-box install not working for platform X. Compare it to several other products perhaps, but edit it down to the necessary bits to demonstrate epic fail and have some cool music for long, boring parts. (I would but I'm remote, away from the home lab.)