Systemd 211 Piles On More Changes

[Vim_User]

That makes no sense. On a remote system which isn't an appliance, any server admin can just rely on /etc/fstab and not use this feature at all.

So you imply that this feature is not reliable enough for such a scenario? Why implementing a non reliable feature in the first place, then?

[JX8p]

That makes no sense. On a remote system which isn't an appliance, any server admin can just rely on /etc/fstab and not use this feature at all.

Translation: "This feature is unstable and dangerous. Do not use it."

[Rexilion]

One of the reasons behind that features is

That said, looks like if you have an fstab file it overrules the automagically behaviour. So for what you are complaining about?

It changes a well known piece of configuration for no additional benefit. Whether systemD handles it with it's own configuration or whether it goes thru fstab, at the end of the day a mount() call is placed. Where are the benefits? And why not extend the old and trusted method.

So you imply that this feature is not reliable enough for such a scenario? Why implementing a non reliable feature in the first place, then?

It's less reliable since it does not have any testing and could be changed at will by it's developers that's why.

Translation: "This feature is unstable and dangerous. Do not use it."

+1

[RahulSundaram]

So you imply that this feature is not reliable enough for such a scenario? Why implementing a non reliable feature in the first place, then?

It is not designed primarily for appliances and not for remote server management.

http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/

[RahulSundaram]

Translation: "This feature is unstable and dangerous. Do not use it."

Translation: I didn't read the specification and didn't understand the details yet feel compelled to comment based on faulty assumptions.

[Vim_User]

It is not designed primarily for appliances and not for remote server management.

http://www.freedesktop.org/wiki/Spec...artitionsSpec/

I don't get it, may be you can elaborate on that. What exactly makes this feature more reliable on containers/appliances then on remote machines? Why should I rely on it in one case, but not the other?

[RahulSundaram]

I don't get it, may be you can elaborate on that. What exactly makes this feature more reliable on containers/appliances then on remote machines? Why should I rely on it in one case, but not the other?

It is not a question of reliability but control. If you want something that you want to control the low level details of, like a remote server, it is typically customized according to your needs anyway and /etc/fstab or mount units is how you do that for partitions but if you care more about getting things going quickly in large numbers as in the case for containers, this optional feature in systemd makes it possible to deploy without necessarily having /etc/fstab customized on a per container basis. There is nothing stopping you from relying on this automation for remote servers or using /etc/fstab on containers if you want to, depending on your use cases. It is entirely optional and upto you.