jajcus at jajcus.net
Thu Jul 3 09:17:52 CEST 2014
On 02/07/14 21:06, Jan Rękorajski wrote:
>> What do you mean by 'cut down'? And what do you consider the 'bloat'.
>> Most the things introduced since 208 may be really useful, and the rest
>> won't break anything.
> ... that's unfortunately not true :( Right now the obstacle is networkd
> and I do consider this daemon a bloat, maybe it improved over time but
> when it came out it was primitive bordering on pathetic _and_ it would just
> kill your network if you had anything more than simple dhcp address.
> Especially with the advanced configs we have in PLD, networkd must be
> disabled by default.
1. from the announcements I got a feeling that networkd is fully
optional and enabled by default only for specific cases (virtualization)
2. PLD rc-scripts, even though has many advanced settings and support
for some very weird setups, is also pathetic and unusable for many
simple and typical use cases.
Let's take the default configuration:
– it would start and auto-configure (DHCP) only the first ethernet
interface, whatever it is during the boot (which is quite unpredictable
when there is more than one)
– it won't even start the DHCP client when there is no link on the
interface. The network won't work until someone manually restarts the
interface. This is a big fuck-up, which only could have make sense 10
years ago when DHCP clients were not able to monitor link state by
– there is no way to easily support multiple interfaces with multiple
DNS configuration sources.
All these affect a laptop with Ethernet, WiFi and mobile interfaces used
interchangeably. Of course, dropping all the ifcfg-* configs and using
NetworkManager fixes that, but having a low-level working solution for
that is a good idea too. And that is exactly what networkd provides.
And even some servers need some lightweight, automatic and dynamic
network configuration in times when a server may be a virtual entity
which can be moved around the globe without a reboot.
We could, of course, try to fix rc-scripts with more and more shell
hacking (still trying to keep backward-compatibility), but why force us
to maintain that, when there are other, simple, tested and maintained
networkd probably should not be enabled by default if the network is
already configured PLD-way, but otherwise it is good to have it.
I think it could be a good idea to use it by default when there is no
other network configuration. There is a change it will 'just work' in
the most common scenarios. We cannot provide this with our rc-scripts.
>>> Systemd upgrade is not someting we can "just bump and rebuild",
>>> and I don't have the time for it (job change, moving house, etc.)
>> Maybe someone else can take care of that. It could be me, but not now.
> Anyone can do it, but has to be very, very carefull when doing so.
More information about the pld-devel-en