[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.



We have between 40 and 50 window managers in Debian. Nobody forces you
to use Gnome. How about switching to TWM!

No problem, I never actually used Gnome3, because I dislike it even more than systemd... I only tried it several times... :)

I.e. for example, systemd-journal looks like the most bloated part of
systemd to me, with its binary log format, QR codes and built-in HTTP
server - so maybe it could be disabled via a patch? Or even packaged
separately so you can choose whether to install it? Is anyone familiar
with systemd code - does it look possible and/or simple task to you?

As much as I understood, systemd-journal is the part which is the most
optional, and which you can avoid completely currently. Problem is: we
have no idea how long this is going to be truth (as it happened with
logind and other components).

Maybe it's optional, but there's no option to disable it currently. You can only configure it to not store logs and send them to syslog - so it will be still running.

I don't think it is reasonable to expect Debian systemd maintainers will
do the work of separating each components to make them independent. They
haven't stated that this is what they want to do.

I think Debian project is significant enough to have some influence on systemd development, i.e. at least send patches, and in this case Debian won't end up using any "non-standard" version. This can also reduce the risk of "vendor-lock", because the speed Lennart adds features to systemd is so fast that I won't be really surprised if he adds HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER next. And everyone will be forced to use that new feature [registry] if Debian project won't have any influence on systemd. That's what I call vendor-lock :)

As I understand systemd has relatively active community with many developers from different distros (am I right?) so it should be no problem for Debian developers to also join it.

I mean that Debian systemd maintainers could try to untangle that ball of
current design, where each component is used by another
and even try to upstream this work! :)

...and it really seems like a good decision to me, because it would really fix some of its problems and make systemd-haters feel better... :)

--
With best regards,
  Vitaliy Filippov


Reply to: