On Tue, Oct 25, 2016 at 5:43 PM, L. A. Walsh <suse@tlinx.org> wrote:
Linda Walsh wrote:
ianseeks wrote:
I stand by the use of monolithic being completely bogus, no matter how you try and redefine the meaning of monolith. http://www.dictionary.com/browse/monolithic?s=t
---
Then you stand without a defintion. dictionary.com doesn't define monolithic w/r/t software -- though that SysD is large and its design is set in stone would apply in an abstract sense.
Better would be a reference that includes software, like: https://en.wikipedia.org/wiki/Monolithic_application
A monolithic application is self-contained, and independent from other computing applications. The design philosophy is that the application is responsible not just for a particular task, but can perform every step needed to complete a particular function.[1][2] Today, some personal finance applications are monolithic in the sense that they help the user carry out a complete task, end to end, and are "private data silos" rather than parts of a larger system of applications that work together.
You cut a key part of the article: "Modularity is achieved to various extents by different modularization approaches. Code-based modularity allows developers to reuse and repair parts of the application, but development tools are required to perform these maintenance functions (e.g. the application may need to be recompiled). Object-based modularity provides the application as a collection of separate executable files which may be independently maintained and replaced without redeploying the entire application (e.g. Microsoft "dll" files; Sun/UNIX "shared object" files). Some object messaging capabilities allow object-based applications to be distributed across multiple computers (e.g. Microsoft COM+). Service-oriented architectures use specific communication standards/protocols to communicate between modules" systemd fits the second definition perfectly. You can replace individual parts of systemd without having to recompile the entire thing. In fact systemd works fine without most of these supposedly monolithic components being present at all. In fact it is a textbook example of the "service-oriented architecture" described in the last sentence of that paragraph.
Sysd is not something that works with other parts to achieve its output. It's design philosophy is to assume control of all pertinent stages and system functions. As time progresses, more functions are deemed necessary for it to do its job and are absorbed.
First, system doesn't "absorb" anything, particular projects have decided to join the general systemd umbrella because they thought it would be beneficial to their project, just as various projects have decided to join the gnome or kde umbrella. It is always, always, always up to the project to decide to join the systemd umbrella, systemd has no power to "absorb" any project. systemd opponents make it sound like systemd is somehow forcing other projects to join against their will. And it was really only a handful of projects that joined systemd, and that hasn't been happening much recently. Second, systemd works with a huge number of existing third-party tools, libraries, programs, and system functions. Yes, it provides a way to control those tools, libraries, and system functions, but again that is the exact opposite of "monolothic", since those tools, libraries, programs, and system functions can be easily replaced at runtime.
Another way to think about it -- is that monolithic software is the opposite of "modular", where you can re-use different pieces of software to accomplish the same task.
The only reason this isn't possible with systemd is because no one has bothered to write different these pieces of software. There is nothing in the design of system that would prevent you from ripping out a particular part of systemd and replacing it with a compatible alternative. It is just that no of the systemd opponents can be bothered to write such alternatives. There is also nothing in the design of systemd that would prevent anyone from ripping out a part of systemd and using it with a completely unrelated project, as long as whatever they want to use it with provided the features it needs. This is the exact opposite of monolithic, according to the page you linked to. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org