Mailinglist Archive: opensuse (856 mails)

< Previous Next >
Re: [opensuse] Re: on something being monolithic and proprietary.
  • From: Todd Rme <toddrme2178@xxxxxxxxx>
  • Date: Tue, 25 Oct 2016 19:16:31 -0400
  • Message-id: <CADb7s=tHG0d1gSifnLqAX+55VD5xysw0+4ar+kN2L6oYSK5nHQ@mail.gmail.com>
On Tue, Oct 25, 2016 at 5:43 PM, L. A. Walsh <suse@xxxxxxxxx> 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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >
This Thread