Systemd 217 Will Introduce Its New "Consoled" User Console Daemon

[Naib]

+1

For systemd guys and gals: keep up the awesome work.

Opposition is good sign that you are making definite progress.

You are cutting away rotten meat, no wonder that corpses jumped up and started slumbering around.

Even if it doesn't succeed in first attempt ( which I think it will), it is highly likely that it will be used as good solid base for next, more advanced project.

Opposition is not a good sign that definite progress is being made... Opposition is a sign that what is being done is questionable, more vocal responses is an indication that concerns are not being listened to.

While a replacement VT is great, again WTF tie it into SystemD ... Make it its own standalone application.
That is one of the main complaints with SystemD ... Monolithic... sure its modular you can compile in or out what you want BUT it is still monolithic and it doesn't have to be... That is part of the snakeoil; UselessD showed that udev doesn't actually have to be in the same package for the concept to work so the PR dept of SystemD are fraudulently pushing their own agenda under the guise of technical.

[[Knuckles]]

Opposition is not a good sign that definite progress is being made... Opposition is a sign that what is being done is questionable, more vocal responses is an indication that concerns are not being listened to.

While a replacement VT is great, again WTF tie it into SystemD ... Make it its own standalone application.
That is one of the main complaints with SystemD ... Monolithic... sure its modular you can compile in or out what you want BUT it is still monolithic and it doesn't have to be... That is part of the snakeoil; UselessD showed that udev doesn't actually have to be in the same package for the concept to work so the PR dept of SystemD are fraudulently pushing their own agenda under the guise of technical.

Again it's not monolithic. It's a separate binary. It's maintained as part of the systemd project, but is its separate thing. I'm running Ubuntu 14.04 which *does not use systemd as an init system* and I have some systemd binaries running:

k@l:~$ ps aux | grep systemd
root       421  0.0  0.0  52004  2116 ?        Ss   08:33   0:00 /lib/systemd/systemd-udevd --daemon
root       875  0.0  0.0  43452  1864 ?        Ss   08:33   0:00 /lib/systemd/systemd-logind

That's because they can be standalone. No systemd needed.

[scottishduck]

Opposition is not a good sign that definite progress is being made... Opposition is a sign that what is being done is questionable, more vocal responses is an indication that concerns are not being listened to.

While a replacement VT is great, again WTF tie it into SystemD ... Make it its own standalone application.
That is one of the main complaints with SystemD ... Monolithic... sure its modular you can compile in or out what you want BUT it is still monolithic and it doesn't have to be... That is part of the snakeoil; UselessD showed that udev doesn't actually have to be in the same package for the concept to work so the PR dept of SystemD are fraudulently pushing their own agenda under the guise of technical.

Dunno if you noticed but the kernel is the same deal. Get over it.

[YoungManKlaus]

Opposition is not a good sign that definite progress is being made... Opposition is a sign that what is being done is questionable, more vocal responses is an indication that concerns are not being listened to.

Actually, its simply a sign that you are doing stuff differently than other people. That can be good, or can be bad, but inherently is neither.

Monolithic... sure its modular you can compile in or out what you want BUT it is still monolithic

I never heard anyone (except A.S.T.) complain about that when its about the kernel

[Naib]

Again it's not monolithic. It's a separate binary. It's maintained as part of the systemd project, but is its separate thing. I'm running Ubuntu 14.04 which *does not use systemd as an init system* and I have some systemd binaries running:

k@l:~$ ps aux | grep systemd
root       421  0.0  0.0  52004  2116 ?        Ss   08:33   0:00 /lib/systemd/systemd-udevd --daemon
root       875  0.0  0.0  43452  1864 ?        Ss   08:33   0:00 /lib/systemd/systemd-logind

That's because they can be standalone. No systemd needed.

no, its monolithic. It is modular though. you need to have systemd present to be able to use one of its components. That is monolithic

[pal666]

I am generally a bit suspicious about the whole "let's get as much of the OS as possible into systemd" which feels a bit anti-unix

it is extremely pro-unix. you are just confused with what systemd is. it is not pid1, it is base system, like freebsd base. is freebsd unixy enough for you ? now you can try to find something which is in systemd, but not in freebsd base.

[pal666]

no, its monolithic. It is modular though. you need to have systemd present to be able to use one of its components. That is monolithic

that is bullshit definition of monolithic

[Naib]

that is bullshit definition of monolithic

Lennart Poettering claims that systemd is not monolithic by pointing out that it is made of upwards of 69 separate binaries. This is a non sequitur fallacy, because "modular" and "monolithic" are not mutually exclusive terms.

A program is modular if it is decomposable into distinct functional units such that each unit addresses a specific concern. Systemd, the Linux kernel, and X.org are all examples of modular software. Systemd addresses its concerns with its binaries, the Linux kernel with loadable kernel modules, and X.org with its drivers and extensions.

Now, a program is monolithic if its components (if it has any at all) are tightly coupled--that is, components depend on one another to the point where using them independently requires re-implementing the missing components. Examples include Linux and X.org--in Linux's case, you can't use a kernel module without the kernel, the kernel can't run without the requisite kernel modules to interface with the hardware, and you can't use a Linux kernel module with other kernels or as a stand-alone program. Similarly, you can't use an X video driver without the X server, you can't use the X server without at least one video driver, and you can't use X's video drivers with other graphics managers or as stand-alone programs.

Under these definitions, systemd qualifies as both modular and monolithic. You cannot run journald without systemd, and cannot run systemd without journald. None of the *ctl programs work without systemd, nor do its collection of *d daemons. You used to be able to run logind separately but not anymore, and udev will likely be next to hard-depend on systemd.

By contrast, examples of modular, non-monolithic software include GNU coreutils, the s6 supervisor system, DJB's daemontools, and the GNU compiler collection. Not only are these applications broken into modules, but you can use the modules largely independently of one another, composing them together to accomplish more complex tasks than the individual modules themselves can handle.

To be fair, "modular vs non-modular" and "monolithic vs non-monolithic" are continuous trade-offs. Systemd is less monolithic and more modular than, say, the "ls" program. But it is way more monolithic than any of the non-monolithic examples above.

http://judecnelson.blogspot.ie/2014/09/systemd-biggest-fallacies.html

[pal666]

Lennart Poettering claims that systemd is not monolithic by pointing out that it is made of upwards of 69 separate binaries. This is a non sequitur fallacy, because "modular" and "monolithic" are not mutually exclusive terms.

A program is modular if it is decomposable into distinct functional units such that each unit addresses a specific concern. Systemd, the Linux kernel, and X.org are all examples of modular software. Systemd addresses its concerns with its binaries, the Linux kernel with loadable kernel modules, and X.org with its drivers and extensions.

Now, a program is monolithic if its components (if it has any at all) are tightly coupled--that is, components depend on one another to the point where using them independently requires re-implementing the missing components. Examples include Linux and X.org--in Linux's case, you can't use a kernel module without the kernel, the kernel can't run without the requisite kernel modules to interface with the hardware, and you can't use a Linux kernel module with other kernels or as a stand-alone program. Similarly, you can't use an X video driver without the X server, you can't use the X server without at least one video driver, and you can't use X's video drivers with other graphics managers or as stand-alone programs.

Under these definitions, systemd qualifies as both modular and monolithic. You cannot run journald without systemd, and cannot run systemd without journald. None of the *ctl programs work without systemd, nor do its collection of *d daemons. You used to be able to run logind separately but not anymore, and udev will likely be next to hard-depend on systemd.

By contrast, examples of modular, non-monolithic software include GNU coreutils, the s6 supervisor system, DJB's daemontools, and the GNU compiler collection. Not only are these applications broken into modules, but you can use the modules largely independently of one another, composing them together to accomplish more complex tasks than the individual modules themselves can handle.

To be fair, "modular vs non-modular" and "monolithic vs non-monolithic" are continuous trade-offs. Systemd is less monolithic and more modular than, say, the "ls" program. But it is way more monolithic than any of the non-monolithic examples above.


http://judecnelson.blogspot.ie/2014/...fallacies.html

qouting some braindead blog will not make you look smarter. systemd compotents do not depend on each other, they depend on published interfaces. every loser like you is free to implement those interfaces. your definition is still bullshit.

[Naib]

A software system is called "monolithic" if it has a monolithic architecture, in which functionally distinguishable aspects (for example data input and output, data processing, error handling, and the user interface), are not architecturally separate components but are all interwoven


ALL aspects of SystemD is interwoven. It is monolithic, it is modular...
sort out your defnition