4 ms·
Except these automount tools provided exactly the same functionality that is currently provided by systemd. And did it better
by pi-e-sigma 3y ago
Except these automount tools provided exactly the same functionality that is currently provided by systemd. And did it better
- bravetraveler 3y agoI contest 'better'. What's the difference? It's mounted... no? Allowing 'systemd' to be aware of mounts lets you create dependencies between your mounts and services. For example: 'Requires=mnt-myfs.mount' (and 'After'). Use 'PartOf' if you want the service to get restarted during an unmount/re-mount. This integration is mint! Anything not systemd [when it's already managing your services] trying to orchestrate is, by nature, second-rate One may note the removal of the fstab generator. It's overblown. Any distribution including systemd vendors it.
- pi-e-sigma 3y agoYou obviously haven't used any of them and I have a feeling that in fact you haven't used anything but systemd because your remarks about systemd ability to create dependencies between mounts and services as something amazing is just hilarious.
- bravetraveler 3y agoSigh. I was hoping to be a bit more productive. I haven't used them, obviously, I asked - 'what's the difference'. They haven't even been named. Is this a troll? You obviously miss my point. In this hypothetical I'm picturing a systemd system with services and mounts. The recommendation appeared to be... have another service [or something] try to provide something that 'systemd', which is already present, can handle completely fine. So, I repeat, what's the difference? What am I missing? What's better than having the thing managing your services also manage your mounts? Between the lines I'm saying this isn't fancy work. I want these mounted and useful relationships and that's it. They serve a purpose; I need a compelling reason to replace init.
- deleted 3y ago[deleted]