Lennart: The State & Future Of Systemd

[interested]

This is an intriguing view to me. Systemd makes Linux more competitive with Windows "for a rather simple user" like yourself... how?

If a rather simple user went and installed Ubuntu 12.04, how would his experience be deficient because of not having systemd?

Logging for one thing. On non-systemd Linux systems the log files are scattered all over the distro: some in the users home dir, some in /var/log, some of them in binary form, some in text files.

On systemd systems all the logging is collated into a single view of the system. The user doesn't even have to care about path's.

On non-systemd systems there are usually only very crude tools dedicated for viewing the log files. So in order to examine the log files, you have to use many different tools and understand the concept of piping. A "grep error <path>" will fail to find lines with "Error, Err, err" or where the keyword is "Failure, fail, etc"
There is also the circular problem of before you can grep, you need to now what is in the log file in order to know what to grep for in the log file.

On systemd systems there is a dedicated tool that helps with viewing and filtering the log file. The new user only have to learn one tool in order to view logfiles in an intelligent an useful way. In fact, just a copy-paste of a generic commands like "journalctl -p err" or "journalctl -b1 -p err" can supply them with information about what went wrong.

Not only that, since the systemd journal is structured and indexed and has a stable API, it is possible to make GUI's to actually view and sort in the log files. So a simple user can peruse the journal by clicking on an icon.
It is more or less impossible to make a GUI log file viewer for syslog files that actually does any kind of sorting of the view, since there is no API and the text logs are more or less unstructured.

systemd's journal is logging done right so even newbies will now be able to view and sort in their systems log files.

[gens]

windows has more market share because of marketing, nothing else

linux (and unix before that) was always a superior system
osx was better as far as graphics were concerned (vista sorted that out)

it also has nothing to do with the os being complex
especially since it doesn't get simpler then unix (linux is in that (simple) design philosophy, before you start)

so windows was always the worse OS from the two
and systemd aims to be a copy of it great (they are copying from osx also, to be fair)

also, while im at it, linux has been more novice friendly for years now
some guys made comparisons using ubuntu with people who never used a computer

so ye marketing
people are sheep, nothing new there



also systemd is not an OS
the linux kernel is the biggest part of an OS, systemd is another "OS" on top of it (just like android)

[interested]

So we could infer that systemd-based distros provide a better user experience than non-systemd distros?

Is there any evidence that systemd distros were at the top of the popularity charts?

Well considering that Debian, Ubuntu, Red Hat, Suse, and most if not all the derivatives of those distros have switched to systemd or in the process of switching, it really underscores that systemd is new new de facto way of administrating Linux. Even on smaller distros like Slackware or Gentoo, people are working on making systemd work.

On the same time all development of non-systemd infrastructure seems to have stopped in Linux. So in a few years probably +95% of all new Linux deployments will be systemd based.

Systemd has won a wholesale victory as the new default init systemd and OS core for Linux simply because it is vastly superior to the old legacy way of doing things, and that includes a much better end user experience.

[gens]

Not only that, since the systemd journal is structured and indexed and has a stable API, it is possible to make GUI's to actually view and sort in the log files. So a simple user can peruse the journal by clicking on an icon.
It is more or less impossible to make a GUI log file viewer for syslog files that actually does any kind of sorting of the view, since there is no API and the text logs are more or less unstructured.

what ?
wait, what ?
...what ?

so parsing some text is too complicated ?
parsing text is impossible ?
how is parsing text hard ?
do you have an example of a hard text to parse ?

i mean...
i guess it is too hard to parse a text file
it's not like you could open it in, like, a text editor or something
that would be to complicated with all dem distros putting logs in $HOME, 'cuz they all do that you know

[gens]

Well considering that Debian, Ubuntu, Red Hat, Suse, and most if not all the derivatives of those distros have switched to systemd or in the process of switching, it really underscores that systemd is new new de facto way of administrating Linux. Even on smaller distros like Slackware or Gentoo, people are working on making systemd work.

people are also making the plan9 gui work on linux, so i guess that will become standard
(hint: neither gentoo nor slacware will ever switch; also check out what that people need to do just to get it working)

[johnc]

Well considering that Debian, Ubuntu, Red Hat, Suse, and most if not all the derivatives of those distros have switched to systemd or in the process of switching, it really underscores that systemd is new new de facto way of administrating Linux. Even on smaller distros like Slackware or Gentoo, people are working on making systemd work.

On the same time all development of non-systemd infrastructure seems to have stopped in Linux. So in a few years probably +95% of all new Linux deployments will be systemd based.

Systemd has won a wholesale victory as the new default init systemd and OS core for Linux simply because it is vastly superior to the old legacy way of doing things, and that includes a much better end user experience.

The fact that distributions are moving to systemd (for a variety of reasons) does not lend credence to the argument that systemd makes a distro easier for simple users.

For simple users, what distro is better than [let's say] Ubuntu 12.04... because of systemd...?

[johnc]

Logging for one thing. On non-systemd Linux systems the log files are scattered all over the distro: some in the users home dir, some in /var/log, some of them in binary form, some in text files.

On systemd systems all the logging is collated into a single view of the system. The user doesn't even have to care about path's.

On non-systemd systems there are usually only very crude tools dedicated for viewing the log files. So in order to examine the log files, you have to use many different tools and understand the concept of piping. A "grep error <path>" will fail to find lines with "Error, Err, err" or where the keyword is "Failure, fail, etc"
There is also the circular problem of before you can grep, you need to now what is in the log file in order to know what to grep for in the log file.

On systemd systems there is a dedicated tool that helps with viewing and filtering the log file. The new user only have to learn one tool in order to view logfiles in an intelligent an useful way. In fact, just a copy-paste of a generic commands like "journalctl -p err" or "journalctl -b1 -p err" can supply them with information about what went wrong.

Not only that, since the systemd journal is structured and indexed and has a stable API, it is possible to make GUI's to actually view and sort in the log files. So a simple user can peruse the journal by clicking on an icon.
It is more or less impossible to make a GUI log file viewer for syslog files that actually does any kind of sorting of the view, since there is no API and the text logs are more or less unstructured.

systemd's journal is logging done right so even newbies will now be able to view and sort in their systems log files.

The systemd logging mechanism would not be my best example of systemd adding value, but I recognize this is a personal preference.

I find the systemd solution to be a bit like a first step towards a Windows-like logging setup, which I think is an absolute trainwreck and I refuse to ever go in there under any circumstances.

[matthewdavis]

what ?
wait, what ?
...what ?

so parsing some text is too complicated ?
parsing text is impossible ?
how is parsing text hard ?
do you have an example of a hard text to parse ?

i mean...
i guess it is too hard to parse a text file
it's not like you could open it in, like, a text editor or something
that would be to complicated with all dem distros putting logs in $HOME, 'cuz they all do that you know

So on the distros I work on (rhel based) systemd still passes logs to rsyslogd, so you can still parse on text files if you wish. But what is being said, is that you can parse on error codes and log entries that the app has determined to be an error message. And you no longer have to rely on the contents of the message to determine what type of message it is.

I realize syslog already has Facility & severity. But sometimes you not setup rsyslog to log those. systemd still has the messages saved in memory and you can search for, say 'All error messages from any service since boottime'

[crrodriguez]

Why fork and include an NTP daemon, why not just provide integration with 3rd party projects? Why does Lennart & Kay, embrace ever more features rather than fix bugs?

There is no fork neither is a full ntp daemon, systemd-timesyncd is a SNTP client intended for use on systems that do not require extreme accuracy.. (aprox 99% of users)
Why not provide integration with 3party projects ? Apparently we are not looking at the same system.. NTP daemons are mostly un-integrable with the rest of the system,
They are dumbass unix daemons, provide no sane way of interacting with them, no api, no dbus interface or other IPC mechanism. you have fork a control everything in the command line..

[gens]

So on the distros I work on (rhel based) systemd still passes logs to rsyslogd, so you can still parse on text files if you wish. But what is being said, is that you can parse on error codes and log entries that the app has determined to be an error message. And you no longer have to rely on the contents of the message to determine what type of message it is.

I realize syslog already has Facility & severity. But sometimes you not setup rsyslog to log those. systemd still has the messages saved in memory and you can search for, say 'All error messages from any service since boottime'

ye sure, exit code can be useful

still errors can be sorted and resolved from normal logs by a parser/framework, even with a gui
like the one i just googled that's been around for a while http://www.kde.org/applications/system/ksystemlog/

i personally never had difficulties looking at some log, be it kernel, X or system log
granted i also never worked in an enterprise environment