Am 17.12.2015 um 21:47 schrieb Craig Garner:
I usually don't say anything and just read...it's not really my place. I just like to keep up with things going on. But, by the time you finish worrying about all the overhead and things get finalized, there's going to be so damn much RAM and processing power no one will care. Kind of like developing one white blood cell to defend your entire body.
this is pure nonsense and the attitude "going to be so damn much RAM and processing power no one will care" is the reason that machines these days are not nearby as fast as they could and should be compared with machines 10 years ago - brainless ressource wasting
when you have real production load and a ton of virtual machines and containers running on the same host and every one of them is wasting ressources the summary of all the overhead is something you care or should care about
On Thu, Dec 17, 2015 at 3:39 PM, Colin Walters <walters@xxxxxxxxxx <mailto:walters@xxxxxxxxxx>> wrote: On Thu, Dec 17, 2015, at 01:19 PM, Neil Horman wrote: > > In either case, you're going to wind up butchering a fair amount of what the rpm > is going to be doing anyway. If its so important to minimize that storage, rpm > dependencies shouldn't really be a big deal, because you know you're going to > have to either do some FS surgery anyway. What I'm actually arguing long term is to rearchitect the model of the subset of Fedora that is for server containers to support this - something like a "just the binaries" data blob, and then *optionally* turn that intermediate into an RPM that would have a systemd unit file. It could really be an RPM, just without the %post scripts relating to systemd and the unit files. In practice though, it's not a big deal as long as shared libraries don't end up pulling in systemd or other components. And for software that's container-only, the build process (Dockerfile or something better in the future) for containers just won't require it. > Yes, its more than one process. I think thats the better tradeoff though. What you're arguing is that *build* convenience for our current architecture outweighs the *runtime* cost. That doesn't make sense long term - they're different problems.
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx