Re: F21 System Wide Change: Smaller Cloud Image Footprint

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2014-04-17 21:54 GMT+02:00 Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx>:
On Thu, Apr 17, 2014 at 09:47:21PM +0200, Miloslav Trmač wrote:
> > (NetworkManager and initscripts) and one that's available but not used by
> > default anywhere (systemd-networkd). This would simply swap the status of
> > systemd-networkd and initscripts.
> Is NetworkManager already at the *100% complete* feature parity that would
> make this possible?  (Keeping in mind that "possible" and "a good idea" are
> still not the same...)

I don't think I accept your premise here. 100% (possibly spread between
networkd and NetworkManager) would be necessary for dropping initscripts
completely, but that's not being proposed.

You were arguing that we would be going from 2 used + 1 unused systems to a different set of 2 used + 1 unused; for that to happen, users of initscripts must have somewhere to migrate to.

> > It is _largely_ the case that complex networking is done outside of the
> > guests and presented to the guests as simple interfaces. Usually that's
> > one device with DHCP, but there may be additional interfaces with DHCP
> > or static interfaces.
> Well, this particular possibility is strictly black/white—either the
> completely different configuration and API is exposed, or it isn't; if
> there are any alternatives to configure at all, it is exposed.

Not following you.

As a background, I really don't want the fragmentation; I don't see the benefits, and I very much see the costs.  In the original mail I have tried to outline a scenario in which there would "technically" be fragmentation, but only in a setup that users would never touch so it would be "invisible".  But as soon as this is something users need to interact with, it's no longer "invisible" and we are in the, for me undesirable, full fragmentation scenario.
    Mirek

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux