BUS1 Is Working On A D-Bus Broker

[pal666]

You do realize that

you are worse than noob? yes, everyone realizes that

[waxhead]

OK, systemd and Wayland rant time.

I don't understand the difference between Wayland and X except that X has network trasparency and Wayland doesn't. The fact that I haven't used X forwarding in years and today it means stuffing windows as pixmaps every time they refresh is irrelevant, and the performance benefits are probably important to someone.

Wayland does not (last time I checked) have any drawing API's, it isolate input/output between windows and does not provide a IPC system.

The difference between systemd and the old way of doing things is performance benefits which are presumably important to someone - certainly not to desktop users - but now systemd includes a bunch of reimplementations of daemons that I used to know what they did, who implemented them, and most importantly, what protocols they used, how to configure them, and what they could be expected to do.

There is more to systemd than performance benefits. It is about consistency, having stuff manageable and by providing features that most users will "forget even exists". For example isolating things in cgroups and stuff like that. Stuff in systemd is usually well documented and it is not that difficult to configure and if you know what a service does itis easy to understand what it's expected to do.

Only knowing that this is Red Hat's blob and it does everything is as secure as only knowing that it's MS's blob and does everything. The difference between that and Linus' blob is, once again, that Linus' blob communicates with the rest of the system using well defined protocols, and also everyone follows its' development.

Not everyone I'm afraid. That's why you have different operating systems

Security and stability don't come from arguments over BSD or GPL or proprietary, they come from knowing what to expect from software.

Sort of agree in principle. If you expect that most software is stuffed with bugs and programming errors you got something going alright.

And the answer from the systemd fans is, learn systemd and its entire set of tools which are different from the normal tool every other program uses.

I use systemd and is happy about it so far, but I am actually not a fan. You're comment here applies to all sort of software, you need to learn if regardless what program it is.

Fiancé's laptop used to run Windows 8, but got auto-updated to Windows 10. The profile setting to change tooltip colors was removed in Windows 10, and the GUI to change it, but the setting was migrated from Windows 8 anyway, meaning she can't change it back to the default. That's what happens when you don't care about well defined protocols between components.

This is also what happens if you don't care about what is written on the text boxes the "operating system" throws in your face. If you read properly nothing would have been "auto-updated".

Why am I comparing systemd to Windows? Because I can't remember all the crazy error messages I've gotten from systemd when my computers haven't booted because I screwed something or other up.

Where exactly are you compaing systemd to windows? It is two quite different things. systemd is a init system as well as "toolchain" while Windows is the entire operating system. Windows as well as linux systems running on systemd have methods of showing everything that happens during boot. if you only know where to look. boot.ini on Windows and try to take away the quiet kernel parameter.

Also, while we're talking about booting up, why does everyone want to hide what the system is doing while booting up or replace the messages with their own messages? Isn't not knowing what's happening scarier than knowing what's happening?

Agree completely. The quite by default is nasty stuff.

....and just for the record... I am drunk as a skunk while writing this

[ssokolow]

To be honest, as much as I want to like systemd, it does worry me how often I've found (known and reported) ways to crash PID 1 while I've been experimenting with Ansible and Vagrant while prototyping a new deployment plan and VPS loadout.

(If you've never done it before, crashing PID 1 basically means that you have to press the "hard reset" button in your VM manager or VPS control panel to get things back in business, because any request to cleanly shut things down dies with a failure to communicate with PID 1.)

While they're my only complaints so far, "PID 1 is too fragile" and "journald is sloppy with its memory usage" are rather significant. (journald alone, with Storage=persistent has over twice the peak memory consumption of Storage=none plus a copy of inetutils-syslogd and the former varies widely while the latter configuration remains steady under all loads I tested.)

[Delgarde]

I'm reserving judgement on this until we know what it actually is, and until then I'll trust Linus to the the right thing.

You're being rational on the internet! BLASPHEMY!!!

[AsuMagic]

To be honest, as much as I want to like systemd, it does worry me how often I've found (known and reported) ways to crash PID 1 while I've been experimenting with Ansible and Vagrant while prototyping a new deployment plan and VPS loadout.

(If you've never done it before, crashing PID 1 basically means that you have to press the "hard reset" button in your VM manager or VPS control panel to get things back in business, because any request to cleanly shut things down dies with a failure to communicate with PID 1.)

While they're my only complaints so far, "PID 1 is too fragile" and "journald is sloppy with its memory usage" are rather significant. (journald alone, with Storage=persistent has over twice the peak memory consumption of Storage=none plus a copy of inetutils-syslogd and the former varies widely while the latter configuration remains steady under all loads I tested.)

THREE PAGES on a thread to finally see a proper argument against systemd. Thank you.

[unixfan2001]

But systemd is a overreaching peice of poorly written software that does many jobs not in the description of "initialization system"

Because systemd is NOT only an init system. It's the name for the entire project tree.. The systemd project is a system management suite providing basic building blocks for a functional Linux system.

Why do you need ipc? Especially why do you need it in the kernel? I can tell you that IPC in android is used mainly by google for determining when to render and remove rendered stuff and by hackers for exploits.

Did you seriously just ask why we need IPC? Interprocess Communication? Please kindly remove the "not" from your username.
You're the most ridiculous noob on this entire board. Your level of trolling beats out even debianxfce.

[waxhead]

To be honest, as much as I want to like systemd, it does worry me how often I've found (known and reported) ways to crash PID 1 while I've been experimenting with Ansible and Vagrant while prototyping a new deployment plan and VPS loadout.

(If you've never done it before, crashing PID 1 basically means that you have to press the "hard reset" button in your VM manager or VPS control panel to get things back in business, because any request to cleanly shut things down dies with a failure to communicate with PID 1.)

While they're my only complaints so far, "PID 1 is too fragile" and "journald is sloppy with its memory usage" are rather significant. (journald alone, with Storage=persistent has over twice the peak memory consumption of Storage=none plus a copy of inetutils-syslogd and the former varies widely while the latter configuration remains steady under all loads I tested.)

Can you please link to the bugreport(s)?!
If this manage to irritate enough people sooner or later it will be fixed either by the systemd guys or someone else.

I think systemd have lots of benefits, but I am not a fan boy. I dislike that systemd (as a suite) is taking over more and more ,but on the other hand it is not that bad either.

[F.Ultra]

The difference between systemd and the old way of doing things is performance benefits which are presumably important to someone - certainly not to desktop users - but now systemd includes a bunch of reimplementations of daemons that I used to know what they did, who implemented them, and most importantly, what protocols they used, how to configure them, and what they could be expected to do.

That the systemd project now also includes dns-cache, ntp-client and some other daemons does not mean that you have to use any of them. They are implemented because #1 in order to provide a common toolset (as in available daemons and not as in "forced to use") among distributions and #2 in order to make life easier for people using containers.

Why care that there might be a small daemon installed that can work as a local dns resolver when #1 it's disabled by default, and #2 if not you can disable it "systemctl disable <x>" and "apt install" / "yum install" the daemon that you are used to. Myself I use systemd everywhere but prefer i.e chronyd over systemd-timesync so that is what I use on all our servers.

[W.Irrkopf]

Well, there isn't an awful lot of there there, but if this is just a userland layer sitting on top of BUS1 (maybe to replace dbus-daemon), I don't imagine there being much problem.

On the other hand, if this is intended to act as an in-kernel D-Bus broker [...]

II just followed the link in the article and it gave Apache 2.0 License, this seems to indicate it's userspace It also looks like a strange choice by RedHat(?) to me, as that license is compatible to GPLv3 but not GPLv2 - why not go for GPLv2+? OK, if it is a standalone daemon, the license is "irrelevant" as long as it is open source, but in case it's a library that would be a problem.

[tomegun]

II just followed the link in the article and it gave Apache 2.0 License, this seems to indicate it's userspace It also looks like a strange choice by RedHat(?) to me, as that license is compatible to GPLv3 but not GPLv2 - why not go for GPLv2+? OK, if it is a standalone daemon, the license is "irrelevant" as long as it is open source, but in case it's a library that would be a problem.

Correct, this is a user-space daemon. Red Hat did not choose the license, apart from (as always) mandating that what we work on must be open source. This will not be a library, but a stand-alone daemon.