On Fri, Apr 25, 2014 at 01:30:00PM +0200, Lukáš Nykrýn wrote:
Dne 25.4.2014 13:24, Reindl Harald napsal(a):
>
>
>Am 25.04.2014 13:12, schrieb Lukáš Nykrýn:
>>Dne 25.4.2014 12:50, Reindl Harald napsal(a):
>>>Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
>>>>On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
>>>>>
>>>>>Only those that are maintained directly inside Fedora.
>>>>
>>>>Which is what we care about we cannot hold back progress in the
>>>>distribution based on someone, someplace, somewhere might be using
>>>>legacy cruff.
>>>
>>>have you ever heard "if it ain't broken don't fix it"
>>>network.service works fine until someone decides to break it intentionally
>>>
>>network initscript *is* broken
>
>no - such generalizations are always wrong
>it does not fit for every setup and it don't pretend that
>
>proven by over 30 F19/F20 setups in a wide range from virtualized servers
>with simple setups to physical hardware with multiple network cards, virtual
>TAP devices acting as routers, firewalls, WLAN accesspoints and VPN servers
>with up to 5 decdicated openvpn-instances with their own keys, ports and
>TAP devices it works for a lot of environments and they never will change
>because that is why virtualization is used
>
>>During rhel7 beta I have discovered a lot of design flaws when people tried to
use
>>it on some advance hardware. Boot in fedora is now quite asynchronous and
network
>>is unable to cope with that. For example we have already removed the hotplug
script.
>
>network.service is not for hotplug
>it is for static configurations
>
>>And I really don't want to end with NM on laptops, network on simple servers
>>and networkd elsewhere
>
>i really won't end with NM on simple virtual servers with one virtual NIC
>so just don't break network.service intentionally because it does not fit
>your usecases
>
>i don't demand you to you use network.service so don#t demand others
>using NM and completly rebuild complex working setups - that's not
>progress, that's just making development-noise to let people feel
>there was done some work the hard way and they have to chew it
>
I agree. I also don't think that NM is the best solution for such
use-cases. I believe that this is a place for networkd and I will
not remove network initscript until networkd covers that.
Or even keep it around in
its subpackage... maybe for a whole release
cycle. It doesn't really hold back other changes in any way.
Zbyszek