480 karma · joined February 15, 2013
Its been a battle to work 'backwards' from those binary artifacts to reproducible source builds. Thats just in the device segment.
For systems/integration vendors you'll find a Whole New World(TM) of vendors, vendor-specific-patches, and aftermarket-vendors that take what they can buy without a 'relationship' and try to build a product on top of that. Github is littered with repositories of bits of knowledge around those efferts.
Once in awhile, some of these efforts get enough momentum/interest to get pulled into a community project or if they're really lucky an upstream tree.
If you're not working with the lucky one though, you're basically working with 1000 disparate vendor source drops. Such is the embedded/specialty hardware lanscape these days. Pretty much every hardware vendor builds to a specific one-time deploy configuration for a customer.
There might be a market for that sort of ops integration service, but if a startup pops up that knows how to deal with all the details, they tend to be bought out.
I haven't had to touch any of that since February though, but I will be again soon. I hope kubeadm and its ilk have gotten better at handling the lifecycle of a long lived cluster. I've done all that in terraform (from scratch), and I'd really rather have a more standardized option that's not buy $HOSTED or $VENDOR solution.
The pty part is important because some software will assume you're running interactive if it sees that its STDIN/OUT is a pty, and change its functionality accordingly.
While similar to both currency and commodity, this is one of the situations where cryptocurrency acts as more of a fungible contract than either the currency or commodity. IANAL, but it seems to me that there isn't a whole lot of law written on that. I'd argue that Coinbase expended its fiduciary duty by warning their users of the fork.
Coinbase/kraken/et al., however, don't create/issue the cryptocoins, so it's probably a misnomer to call them exchanges. At best, they are brokerages.
Now say that a bunch of users decided to instruct their broker that's holding their security in trust to so assign the security to the user, and the brokerage sat on that transaction rather than perform the request in a timely fashion? I'd say that potentially counts as a whole host of other actionable events, depending on the intent of the brokerage operators. Not sure if I'd call that front running, but that sounds like a good start to investigate.
AKA, if the deniability of your protocol depends on the random keyspace of more than one actor, a vector that allows some actor to compress the space of permitted keys could allow an inference of more-likely potentially valid keys vs invalid keys, thus disproving or at least weakening the deniability of the protocol.
As for the malicious peer problem -- the malicious peer is the very model of state-sanctioned surveillance. I think it would be an exercise in willful blindness at the least to pretend that does not exist.
That said, its longevity and player retention I do think speak for itself. (Maybe the longevity more than the player rentention.)
I use it myself as my python runtime for some personal projects, and also to run locust.io when I need to loadtest stuff. Neither would have been practical say more than two years ago?
While of course not as fast as a block device mapping, the reduction of copies (virtfs provides zero-copy data passthrough) makes virtfs considerably faster than NFS or CIFS from the guest. This means that even if you're pointing the virtfs at a network mount, you'll still see a speed improvement from the reduction in copies needed to get data on/off the wire.
Of course, the security model is dependent on getting the programming right, this is why the most common qemu execution paths use selinux/apparmor to implement access control on top of just the virtualization.
If you want a real fun mind bender, try making qemu-KVM work from inside docker, without running a full privileged container. It's doable, but something of a challenge. FWIW, QEMU itself doesn't need root, only /dev/kvm access. (Which has also needed security attention in the past).
In terms of speed sensitive HPC workloads though, I bet v9fs is definitely used in production. Hopefully those people are also careful enough to use mandatory access control to sandbox QEMU, since thats definitely not a default libvirt-style setup.