Systemd Rolls Out Its Own Mount Tool (phoronix.com)
Posted by EditorDavid on Sunday August 21, 2016 @09:34PM from the daemons-that-mount-files dept.
An anonymous Slashdot reader writes: I'm surprised this hasn't surfaced on Slashdot already, but yesterday Phoronix reported that systemd will soon be handling file system mounts, along with all the other stuff that systemd has encompassed. The report generated the usual systemd arguments over on Reddit.com/r/linux with Lennart Poettering, systemd developer and architect, chiming in with a few clarifications. Lennart argued it will greatly improve the handling of removable media like USB sticks. debian linux os
Comments:
.. by silentcoder ( 1241496 ) writes: on Monday August 22, 2016 @05:27AM (#52746501) Indeed. We didn't mind simpleinit, or upstart or openRC or slackware's BSD-init - all of these were different init systems in the past. We didn't mount autofs or any of a dozen mount helpers added on top of the unix basic during the years.
To suggest that the opposition to SystemD is generically opposing change is to ignore that the people opposing it have been embracing change in all the areas where it plays for decades and are STILL embracing change in those areas - we're just not embracing THIS change because we believe it's badly designed. Having this many basic tools in a common code-base with massive interdependency that makes it near impossible to swap tools out with other tools or run any of them without running all of them... THAT Is a terrible design.
Hell, we don't even do that on the desktop where it may almost make sense. For over a decade KDE has had performance improvements if you run KDE apps in a KDE desktop - but never, once, did we have a KDE app you couldn't run under Gnome or OpenBox or any other DE you want. The coupling was always weak - use the features when available, don't depend on them. And vice versa - all the apps ran under all the desktops. You didn't struggle to run gimp or libreOffice if you chose KDE as your desktop - despite neither of them being written for it. In fact, there were patches you could install to integrate them better which were entirely optional.
That's a good design.
by silentcoder ( 1241496 ) writes: on Monday August 22, 2016 @07:23AM (#52746779) You know it's weird, but there is literally not a single thing on your list that Linux hasn't been used for successfully and doing successfully for the better part of 20 years. None of these are new problems. So since systemD is only 6 years old and most major distro's didn't adopt it until the last 3, I guess all of us were just suffering some mass delusion when we watched all this stuff working beautifully back in 2000 when nobody had ever concevied of systemD - and progressively get better every year since.
Now nobody is saying that there cannot be better solutions for this - what I can tell you is that a better solution CANNOT come from a massive bunch of tightly coupled tools with opague interfaces that are so utterly cross dependent that none of them can run (at least without massive hacks) unless you also run all the others.
The ONLY way to EVER do a good solution - especially at the system level - is to build it out of lots of LOOSELY coupled tiny bits that don't care how you put them together or what you put them together with (including pieces that the creators never knew existed). That design has allowed an OS first compiled in 1969 to scale to the largest supercomputers and the smallest embedded devices alike, to survive 50 years of computing history jumping from platform to platform and architecture to architecture, resilient across one major revolution after the other - because it could adapt to any need and any use-case. Because you never had to redesign it to meet a new challenge, you just had to add a few small tools to the mix, and put the others together in a new way.
The lego-blocks approach is the heart and soul of the unix philosophy - and it's a philosophy worth preserving because that philosophy is literally the ONLY thing that has caused Unix to be the single longest-living architecture in computer history. It's an architecture that's so easy to evolve that no revolution was out of it's reach. From mainframes to PC's to phones - it went where the hardware went and was consistently the most reliable and cheapest and fit-for-purpose answer because it was designed to be easy to rebuild by simply taking the blocks and hooking them up in a new way that Kernighan and Ritchie never imagined.
In other words - everything SystemD is not.
We love doing things in new ways, we love change - but we're GOOD at spotting the difference between progress and regression - and systemd is NOT progress, systemD is doing on Linux the exact same mistakes that every operating system besides unix in history has made. If it remains dominant too long - the outcome will be that Linux goes the way of Multics or VMS because, like those, it will not be able to survive the next revolution. ..
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
carisma_sensei
no subject
Date: 2016-11-03 01:01 am (UTC)Posted by EditorDavid on Sunday August 21, 2016 @09:34PM from the daemons-that-mount-files dept.
An anonymous Slashdot reader writes: I'm surprised this hasn't surfaced on Slashdot already, but yesterday Phoronix reported that systemd will soon be handling file system mounts, along with all the other stuff that systemd has encompassed. The report generated the usual systemd arguments over on Reddit.com/r/linux with Lennart Poettering, systemd developer and architect, chiming in with a few clarifications. Lennart argued it will greatly improve the handling of removable media like USB sticks. debian linux os
Comments:
.. by silentcoder ( 1241496 ) writes: on Monday August 22, 2016 @05:27AM (#52746501) Indeed. We didn't mind simpleinit, or upstart or openRC or slackware's BSD-init - all of these were different init systems in the past. We didn't mount autofs or any of a dozen mount helpers added on top of the unix basic during the years.
To suggest that the opposition to SystemD is generically opposing change is to ignore that the people opposing it have been embracing change in all the areas where it plays for decades and are STILL embracing change in those areas - we're just not embracing THIS change because we believe it's badly designed. Having this many basic tools in a common code-base with massive interdependency that makes it near impossible to swap tools out with other tools or run any of them without running all of them... THAT Is a terrible design.
Hell, we don't even do that on the desktop where it may almost make sense. For over a decade KDE has had performance improvements if you run KDE apps in a KDE desktop - but never, once, did we have a KDE app you couldn't run under Gnome or OpenBox or any other DE you want. The coupling was always weak - use the features when available, don't depend on them. And vice versa - all the apps ran under all the desktops. You didn't struggle to run gimp or libreOffice if you chose KDE as your desktop - despite neither of them being written for it. In fact, there were patches you could install to integrate them better which were entirely optional.
That's a good design.
by silentcoder ( 1241496 ) writes: on Monday August 22, 2016 @07:23AM (#52746779) You know it's weird, but there is literally not a single thing on your list that Linux hasn't been used for successfully and doing successfully for the better part of 20 years. None of these are new problems. So since systemD is only 6 years old and most major distro's didn't adopt it until the last 3, I guess all of us were just suffering some mass delusion when we watched all this stuff working beautifully back in 2000 when nobody had ever concevied of systemD - and progressively get better every year since.
Now nobody is saying that there cannot be better solutions for this - what I can tell you is that a better solution CANNOT come from a massive bunch of tightly coupled tools with opague interfaces that are so utterly cross dependent that none of them can run (at least without massive hacks) unless you also run all the others.
The ONLY way to EVER do a good solution - especially at the system level - is to build it out of lots of LOOSELY coupled tiny bits that don't care how you put them together or what you put them together with (including pieces that the creators never knew existed). That design has allowed an OS first compiled in 1969 to scale to the largest supercomputers and the smallest embedded devices alike, to survive 50 years of computing history jumping from platform to platform and architecture to architecture, resilient across one major revolution after the other - because it could adapt to any need and any use-case. Because you never had to redesign it to meet a new challenge, you just had to add a few small tools to the mix, and put the others together in a new way.
The lego-blocks approach is the heart and soul of the unix philosophy - and it's a philosophy worth preserving because that philosophy is literally the ONLY thing that has caused Unix to be the single longest-living architecture in computer history. It's an architecture that's so easy to evolve that no revolution was out of it's reach. From mainframes to PC's to phones - it went where the hardware went and was consistently the most reliable and cheapest and fit-for-purpose answer because it was designed to be easy to rebuild by simply taking the blocks and hooking them up in a new way that Kernighan and Ritchie never imagined.
In other words - everything SystemD is not.
We love doing things in new ways, we love change - but we're GOOD at spotting the difference between progress and regression - and systemd is NOT progress, systemD is doing on Linux the exact same mistakes that every operating system besides unix in history has made. If it remains dominant too long - the outcome will be that Linux goes the way of Multics or VMS because, like those, it will not be able to survive the next revolution. ..
http://linux.slashdot.org/story/16/08/21/2259219/systemd-rolls-out-its-own-mount-tool
http://translate.google.com/translate?hl=ru&sl=auto&tl=ru&u=http://linux.slashdot.org/story/16/08/21/2259219/systemd-rolls-out-its-own-mount-tool