systemd's syslogd replacement supports JSON output(freedesktop.org)
freedesktop.org
systemd's syslogd replacement supports JSON output
http://www.freedesktop.org/wiki/Software/systemd/json/
53 comments
This is of course exactly the killer feature that would convert me into a true systemd believer. The only thing better would be to have an ASN.1 representation of the logs as the native format, for the sake of portability. After all, if you don't have tools to analyze your logs for you, you might as well not even have logs.
Is this a good time to define Poettering's Law - any simple and useful Unix service will eventually get rewritten into a monstrous uber service that requires a supercomputer just to run, what should be, a simple service.
Which is easy for you to state, were it not for the fact that the "simple service" is broken in various ways.
Let's start with the implementation-specific brokenness. I configured a log host with rsyslog. Rsyslog's configuration format, as well as documentation, is completely abysmal. And once in a while, rsyslog would use 100% CPU for no reason. A quick strace reveals that it keeps reading or writing to a file descriptor, but getting EAGAIN as error. Looks like a bug to me. And oh yeah, there's a race condition in rsyslog with regard to privilege lowering, so that sometimes it would great directories owned as root, and then it would lower its privilege, and then it would be unable to write to its own created directory. Just great.
The above are all fixable. But what bothers me more is that syslog is entirely unauthenticated. Any process can write to syslog, claiming that it is any process. A malicious user can write a syslog entry saying that "init[1]: the system is unstable. please reboot now!". As an administrator, you will not be able to tell whether the message actually came from init (or PID 1) or not. A quick look at systemd's journal mechanism reveals systemd at least has thought about these problems: http://www.freedesktop.org/software/systemd/man/systemd.jour.... It would log the process's PID, UID, GID and more, and the sender is unable to fake that.
Let's start with the implementation-specific brokenness. I configured a log host with rsyslog. Rsyslog's configuration format, as well as documentation, is completely abysmal. And once in a while, rsyslog would use 100% CPU for no reason. A quick strace reveals that it keeps reading or writing to a file descriptor, but getting EAGAIN as error. Looks like a bug to me. And oh yeah, there's a race condition in rsyslog with regard to privilege lowering, so that sometimes it would great directories owned as root, and then it would lower its privilege, and then it would be unable to write to its own created directory. Just great.
The above are all fixable. But what bothers me more is that syslog is entirely unauthenticated. Any process can write to syslog, claiming that it is any process. A malicious user can write a syslog entry saying that "init[1]: the system is unstable. please reboot now!". As an administrator, you will not be able to tell whether the message actually came from init (or PID 1) or not. A quick look at systemd's journal mechanism reveals systemd at least has thought about these problems: http://www.freedesktop.org/software/systemd/man/systemd.jour.... It would log the process's PID, UID, GID and more, and the sender is unable to fake that.
systemd can log the PID, UID and GID of a message because its using a Linux-specific feature of datagram based local sockets; such a feature cannot be supported on other Unix systems. But there are other reasons to use syslogd/rsyslogd/syslog-ng besides logging to local files, and that's to forward the logs to a centralized logging service. Of course, there are issues with that, as the default syslog protocol also allows any process, anywhere, to claim it is any other process (and if root, even fake its own source address) but it's being addressed (I know rsyslogd is, I'm not sure about other syslogd replacements).
My issue with systemd is that forwarding logs to a central server is an afterthought, if even that. And the problem with that is that it won't be as secure or work as well if it's part of the design. And another issue with the "afterthought support for remote logging" is that I still need to run syslogd/rsyslogd/syslog-ng because I have a ton of other network equipment (routers) that can forward their logs via the syslog protocol (which I have used on networks I've managed---by doing that, I've been able to receive notifications of OSPF routing changes, for instance). And if I have syslogd/rsyslogd/syslog-ng already running, what are the benefits of systemd logging?
My issue with systemd is that forwarding logs to a central server is an afterthought, if even that. And the problem with that is that it won't be as secure or work as well if it's part of the design. And another issue with the "afterthought support for remote logging" is that I still need to run syslogd/rsyslogd/syslog-ng because I have a ton of other network equipment (routers) that can forward their logs via the syslog protocol (which I have used on networks I've managed---by doing that, I've been able to receive notifications of OSPF routing changes, for instance). And if I have syslogd/rsyslogd/syslog-ng already running, what are the benefits of systemd logging?
Regarding PID/UID/GID logging: if it has to use a Linux-specific feature to be less broken in that regard, then I'm all for it. In my opinion, authentication is such an important security feature that other Unices should just implement similar mechanisms (or, preferably, the same mechanism). Right now I've only seen the BSD people complaining that systemd uses Linux-specific features, but doing nothing to solve the problem.
Regarding central logging: indeed, that is a problem. Has Lennart ever spoken about this issue?
Regarding central logging: indeed, that is a problem. Has Lennart ever spoken about this issue?
The impression I've gotten is that he isn't interested in centralized logging, as that is outside of what he is trying to do.
I could be wrong though.
I could be wrong though.
Reading this I thought: how does one authenticate a pid or uid in a daemon? I am assuming Unix domain sockets, which don't provide you with the caller's pid or uid.
Doing some googling I found there are indeed nonportable interfaces for this. First I found getpeerucred which is a Sun thing. Then I found Linux has a SO_PEERCRED socket option. [Edit: and there seems to exist getpeereid and LOCAL_CRED on some BSDs]
Still seems like a weird or otherwise shaky thing to me. It feels like it breaks the abstraction of a socket.
Doing some googling I found there are indeed nonportable interfaces for this. First I found getpeerucred which is a Sun thing. Then I found Linux has a SO_PEERCRED socket option. [Edit: and there seems to exist getpeereid and LOCAL_CRED on some BSDs]
Still seems like a weird or otherwise shaky thing to me. It feels like it breaks the abstraction of a socket.
Unix domain sockets are the way to pass open file descriptors between processes, though (why? I don't know, it just is). I think that because of that, the mechanism was extended to also pass along the PID, UID and GID. I did use the open file descriptor with SO_PEERCRED options to implement a Linux-only daemon to open privileged sockets on behalf of a process: https://github.com/spc476/ipacld (something I'm surprised has never been written before).
I think the easier way is to create the socket with high privileges, then drop down to lower privilege.
But why have the keys to the entire kingdom when all you need is a single key to a single room?
The daemon I wrote is very small, so there isn't much code to audit. The client that calls the daemon doesn't need to be root at all. The daemon can also make a lot of different checks (right UID, right GID, right executable image, etc.) before passing the privileged port back to the client.
Edit: fixing the last sentence.
The daemon I wrote is very small, so there isn't much code to audit. The client that calls the daemon doesn't need to be root at all. The daemon can also make a lot of different checks (right UID, right GID, right executable image, etc.) before passing the privileged port back to the client.
Edit: fixing the last sentence.
Well, you could probably set up a sudoers file that allowed launching your daemon but blocked everything else. A hacky solution, but it does not involve giving up all the keys.
I seem to recall reading ages ago how Hurd was going to solve issues like this, and make privileges into something else, tweakable by restarting some user mode process. But I guess there may be something to the other reply about "worse is better" - workable with some hacks is better than ideological purity and non working. (Not to say your daemon doesn't work, I am angling more towards a kernel that doesn't have that arbitrary low-port check.)
I seem to recall reading ages ago how Hurd was going to solve issues like this, and make privileges into something else, tweakable by restarting some user mode process. But I guess there may be something to the other reply about "worse is better" - workable with some hacks is better than ideological purity and non working. (Not to say your daemon doesn't work, I am angling more towards a kernel that doesn't have that arbitrary low-port check.)
A lot of stuff is built on the "worse is better" philosophy. Introducing a daemon like yours will complicate the OS a little bit more. So instead, OS developers outsource the complexity to the apps, and only implement a quick hack to make this possible. In practice, the running-as-root-then-drop-privilege pattern works well enough so nobody bothered making a more complex, but potentially more secure, solution.
No, what happened was init scripts. Something completely alien to the original init tab concept. It was an extremely ugly hack that worked only because of extensive documentation and effort by much larger amount of people than systemd has now. Both systemd and journal are an actual solution. Try journalctl on your system, it actually makes sense! The silly thing even has bash completion of filtering criteria! And they are both lightning fast.
something that was not necessary. Init scripts can be nice and clean [1]. And yes, I'm all for a init replacement. Something new, nice and clean. But I take the shell script hackery over a dbus dependency. But that's just my personal opinion.
I have neither used it nor looked at the code, but [2] seems to be what I want. It's by the libdietc author, so i expect the code to be small, elegant and not maintained very well.
[1] http://www.freebsd.org/doc/en/articles/rc-scripting/rcng-dum...
[2] http://www.fefe.de/minit/
I have neither used it nor looked at the code, but [2] seems to be what I want. It's by the libdietc author, so i expect the code to be small, elegant and not maintained very well.
[1] http://www.freebsd.org/doc/en/articles/rc-scripting/rcng-dum...
[2] http://www.fefe.de/minit/
That's again a myth. There is no dbus dependency. You can use dbus to do activation but you don't have to. Now, there is a dependency on libdbus which just means systemd is using the dbus serialisation format for its ipc (which, I repeat, don't have to happen over dbus).
Systemd seems to be quite mysterious, because the myth of the dbus dependency comes from the lead developer trying to debunk myths.
http://0pointer.de/blog/projects/the-biggest-myths.html
>When you build systemd, it only requires three dependencies: glibc, libcap and dbus.
In the paragraph "bloated".
http://0pointer.de/blog/projects/the-biggest-myths.html
>When you build systemd, it only requires three dependencies: glibc, libcap and dbus.
In the paragraph "bloated".
It's because I'm not really precise (but neither is Lennart). Technically, libdbus is a part of dbus. It allows two applications to communicate with each other using the dbus serialisation and abstracts the transport layer. You can use it over a Unix socket and then it's just a serialisation format like any application using IPC would need. Then, using dbus is no more stupid than anything else. Actually, it's pretty clever as there already is quite a lot of tools understanding this format.
However, libdus is not what people usually talk about when they talk of dbus. The core part of dbus and what could bother server administrator is the message bus daemon which allows any applications to expose their functionalities and talk to any others. Now, systemd can use the message bus to allow applications to ask for service activation. But, it's not required and you can run the init system without it.
However, libdus is not what people usually talk about when they talk of dbus. The core part of dbus and what could bother server administrator is the message bus daemon which allows any applications to expose their functionalities and talk to any others. Now, systemd can use the message bus to allow applications to ask for service activation. But, it's not required and you can run the init system without it.
I do want to mention binary logs piss me off, but I just set up journald to output to syslog and everything is fine. I just ignore journalctl. I personally find it to be quite slow, but I can just set it to not log its binary blobs.
You coin the law, and you can put your name on it. Let's see if it holds up.
I use systemd and find it to be significantly faster boot-wise than Upstart and the sysv scripts. One doesn't do socket initialization and the other is a bunch of slow ass shell scripts. It doesn't matter if systemd is beefy if the actual task of starting services is lightning fast.
Just for comparison, last year I was triple booting Debian Testing, Ubuntu 12.04, and Arch. I use KDE on all 3 (I do active development on KDE in the Arch one) and logged my boot times over 6 months. I misplaced those records but the effective boot times were around 15 seconds for Debian, 25 for Ubuntu, and 5 for Arch. Mainly because tasks in Ubuntu like NetworkManager or tmpfs mounting were taking 5 - 10 seconds and nothing else was running.
Just for comparison, last year I was triple booting Debian Testing, Ubuntu 12.04, and Arch. I use KDE on all 3 (I do active development on KDE in the Arch one) and logged my boot times over 6 months. I misplaced those records but the effective boot times were around 15 seconds for Debian, 25 for Ubuntu, and 5 for Arch. Mainly because tasks in Ubuntu like NetworkManager or tmpfs mounting were taking 5 - 10 seconds and nothing else was running.
There some competing trends in the *nix world today.
On the one hand, there are some huge, monolithic packages like Xorg that have split in to many smaller, more independent packages.
On the other hand, we have something like systemd absorbing ever more functionality, becoming more monolithic with feature bloat.
I am personally more in favor of having many small, simple tools that each do one function well and can be easily integrated together, and understood independently of each other, rather than going the monolithic route.
To me, systemd is one gigantic step backwards from this vision, even if it has some (or even many) good ideas.
On the one hand, there are some huge, monolithic packages like Xorg that have split in to many smaller, more independent packages.
On the other hand, we have something like systemd absorbing ever more functionality, becoming more monolithic with feature bloat.
I am personally more in favor of having many small, simple tools that each do one function well and can be easily integrated together, and understood independently of each other, rather than going the monolithic route.
To me, systemd is one gigantic step backwards from this vision, even if it has some (or even many) good ideas.
A quick look into systemd reveals that it's comprised of multiple components. For example the journal service is a separate daemon. What part of this does not align with your vision?
EDIT: looks like the "monolithic" myth has already been busted: http://0pointer.de/blog/projects/the-biggest-myths.html
I would say the distinction between systemd and older systems is that systemd follows the "better is better" mantra of design, while older systems follow the "worse is better" mantra of design. Older systems often feel like quick hacks. For example SysV init is a collection of init scripts. Yeah it is "simple" in that the init service itself is simple, but writing the scripts themselves is anything but simple, and they are brittle as well. How often have you seen init scripts failing during startup or boot? And why must you write daemon management code over and over again your init scripts? All this does is pushing complexity out of the init service and into the scripts. Systemd is taking complexity upon itself so that the scripts can be simple.
EDIT: looks like the "monolithic" myth has already been busted: http://0pointer.de/blog/projects/the-biggest-myths.html
I would say the distinction between systemd and older systems is that systemd follows the "better is better" mantra of design, while older systems follow the "worse is better" mantra of design. Older systems often feel like quick hacks. For example SysV init is a collection of init scripts. Yeah it is "simple" in that the init service itself is simple, but writing the scripts themselves is anything but simple, and they are brittle as well. How often have you seen init scripts failing during startup or boot? And why must you write daemon management code over and over again your init scripts? All this does is pushing complexity out of the init service and into the scripts. Systemd is taking complexity upon itself so that the scripts can be simple.
It's monolithic because you can't pick and choose the components.
You have to use all of systemd, or none of it. You can't replace bits of it, or use just parts of it.
You have to use all of systemd, or none of it. You can't replace bits of it, or use just parts of it.
And how exactly does Xorg allow you to use parts of it? More importantly, what parts of systemd do you not want to use or do you want to replace, and why?
EDIT: what you're saying appears to be untrue. According to http://0pointer.de/blog/projects/the-biggest-myths.html, they provide configure switches for enabling or disabling many things, not unlike how the Linux kernel allows you to enable or disable features.
You know, there are so many people here bashing on Lennart, I'm wondering whether any of you have done your homework at all or because you just bash Lennart for the sake of it. I'm not even using systemd and I found these things in 5 minutes.
EDIT: what you're saying appears to be untrue. According to http://0pointer.de/blog/projects/the-biggest-myths.html, they provide configure switches for enabling or disabling many things, not unlike how the Linux kernel allows you to enable or disable features.
You know, there are so many people here bashing on Lennart, I'm wondering whether any of you have done your homework at all or because you just bash Lennart for the sake of it. I'm not even using systemd and I found these things in 5 minutes.
I'd like to not use udev. I have a custom Linux that runs both on standardized(internally defined) servers and also virtualized(known hardware) servers. As such, I'm well under 900ms boot times that systemd mentions by using SysV init. But the systemd project does not accept patches (http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/) to disable what is considered a core component.
Alright, point taken. Then systemd is not for you. However I want to argue that not all software should cater to everybody. While modularity (which in this discussion is apparently defined as "the ability to disable or swap components") is often seen as a good thing, there are quite a lot of downsides as well:
- Certain guarantees and consistencies disappear. Instead of having a system that you know you can rely on, it suddenly becomes entirely dependent on the configuration options. While it sounds nice if any part can be enabled, disabled, moved or swapped, then the system's predictability goes down. Furthermore, some combinations may be incompatible because abstractions are inherently leaky. Good luck finding out whether you're suffering from a compatibility problem or not. You can compare this to the many complaints about Android fragmentation. Because everybody can customize Android, writing an app that works on all Android devices becomes extremely difficult.
- Installation complexity goes way up. It's much easier to install a system if it states "I need this, this and this", instead of "I can use this, or this, or this, if it's configured in X, Y and Z way".
- Certain features cannot be implemented in a simple manner because you have to cater to the lowest common denominator. XFree86 was like that. Because it had to be portable, it cannot assume any kernel capabilities. And as a result XFree86 came with its own mode setting code, its own ELF binary loader, had to run as root, etc etc.
- Certain guarantees and consistencies disappear. Instead of having a system that you know you can rely on, it suddenly becomes entirely dependent on the configuration options. While it sounds nice if any part can be enabled, disabled, moved or swapped, then the system's predictability goes down. Furthermore, some combinations may be incompatible because abstractions are inherently leaky. Good luck finding out whether you're suffering from a compatibility problem or not. You can compare this to the many complaints about Android fragmentation. Because everybody can customize Android, writing an app that works on all Android devices becomes extremely difficult.
- Installation complexity goes way up. It's much easier to install a system if it states "I need this, this and this", instead of "I can use this, or this, or this, if it's configured in X, Y and Z way".
- Certain features cannot be implemented in a simple manner because you have to cater to the lowest common denominator. XFree86 was like that. Because it had to be portable, it cannot assume any kernel capabilities. And as a result XFree86 came with its own mode setting code, its own ELF binary loader, had to run as root, etc etc.
> However I want to argue that not all software should cater to everybody.
The issue here is that the Linux kernel developers are starting to make decisions that assume systemd is being used. For example, the (proposed?) new cgroups API is being built with the idea that systemd will manage it, and anything else that wants to interact with it will go through systemd.
The issue here is that the Linux kernel developers are starting to make decisions that assume systemd is being used. For example, the (proposed?) new cgroups API is being built with the idea that systemd will manage it, and anything else that wants to interact with it will go through systemd.
That isn't what I read at all. The cgroups maintainer wants a flat cgroups list so that the code is easier to maintain, but Lennart said he must have hierarchical tree so that systemd can take full control over at least a part of the tree. That's hardly "being built with the idea that systemd will manage it".
You've read wrong, unfortunately. http://lwn.net/Articles/557082/ describes that:
> Unprivileged access to the cgroup hierarchy will be strongly discouraged; the hope is to have a single, privileged process handling all of the cgroup management tasks. That process will, in turn, provide some sort of higher-level interface to the rest of the system.
and that:
> This hierarchy becomes private property of systemd. systemd will set it up. Systemd will maintain it. Systemd will rearrange it. Other software that wants to make use of cgroups can do so only through systemd's APIs.
That is, systemd will implement a manager on top of the new cgroups API, and all cgroups users will be assumed to go through systemd.
> Unprivileged access to the cgroup hierarchy will be strongly discouraged; the hope is to have a single, privileged process handling all of the cgroup management tasks. That process will, in turn, provide some sort of higher-level interface to the rest of the system.
and that:
> This hierarchy becomes private property of systemd. systemd will set it up. Systemd will maintain it. Systemd will rearrange it. Other software that wants to make use of cgroups can do so only through systemd's APIs.
That is, systemd will implement a manager on top of the new cgroups API, and all cgroups users will be assumed to go through systemd.
systemd manages cgroups on systemd based system. The systems that do not use systemd can implement their own cgroup managers. The kernel makes no assumptions on what manager you use on userspace. Other managers could also reimplement the systemd dbus API for managing the cgroups.
> The systems that do not use systemd can implement their own cgroup managers. [...] Other managers could also reimplement the systemd dbus API for managing the cgroups.
True, except that the systemd developers are in charge of defining this API and have no reason to consult with other cgroups manager developers when defining it. This is, to make an analogy, equivalent to allowing Microsoft to unilaterally define all web standards from now on. The competitors are always going to be playing catch-up, and there's going to be tons of edge cases where the competitors don't quite work the same.
True, except that the systemd developers are in charge of defining this API and have no reason to consult with other cgroups manager developers when defining it. This is, to make an analogy, equivalent to allowing Microsoft to unilaterally define all web standards from now on. The competitors are always going to be playing catch-up, and there's going to be tons of edge cases where the competitors don't quite work the same.
Could you elaborate a bit more on your hardware setup? How are your hardware devices getting initialized that quick?
I can't disable the journal, for example. If I run something more full-featured, I'll still be streaming things through the journal.
It's not at all like the kernel does it. With Linux, there are multiple competing implementations of most features, pushed by people with competing interests. There is a lot more room for debate and experimentation.
It's not at all like the kernel does it. With Linux, there are multiple competing implementations of most features, pushed by people with competing interests. There is a lot more room for debate and experimentation.
According to 'man journald.conf', you can set "Storage=none".
If by "monolithic" you mean the lack of multiple competing implementations, then lots and lots of things are monolithic. Apache and Nginx would be monolithic by your definition.
If by "monolithic" you mean the lack of multiple competing implementations, then lots and lots of things are monolithic. Apache and Nginx would be monolithic by your definition.
(Storage=none is streaming things through the journal, which I have no use for)
Apache2 and Nginx are modular. Let me tell you the story of a small web application.
Once upon a time, requests were hitting an Apache server, dispatched to mod_python, and an embedded interpreter was keeping itself warm running Python code to answer the requests.
As the site grew, and the state of the art evolved, a programmer wrapped the application in a wsgi container, and gave it to a mod_wsgi container so that it would run at its own pace.
One day, the programmer brought home an nginx server it had found freezing in the tundra, and gave it a job serving static content in front of Apache. Nginx brought his uwsgi friend and they took turns running the site, nginx serving images and scripts, uwsgi replacing mod_wsgi.
This is what a competitive space looks like. Apache has competing modules, there are http servers and wsgi servers, some of them embedded, some of them external, http servers can collaborate or replace each other when a better thing comes along.
You don't see an http server deciding it will be the sole http server on the system, swallowing a wsgi server and waging war to all others.
Apache2 and Nginx are modular. Let me tell you the story of a small web application.
Once upon a time, requests were hitting an Apache server, dispatched to mod_python, and an embedded interpreter was keeping itself warm running Python code to answer the requests.
As the site grew, and the state of the art evolved, a programmer wrapped the application in a wsgi container, and gave it to a mod_wsgi container so that it would run at its own pace.
One day, the programmer brought home an nginx server it had found freezing in the tundra, and gave it a job serving static content in front of Apache. Nginx brought his uwsgi friend and they took turns running the site, nginx serving images and scripts, uwsgi replacing mod_wsgi.
This is what a competitive space looks like. Apache has competing modules, there are http servers and wsgi servers, some of them embedded, some of them external, http servers can collaborate or replace each other when a better thing comes along.
You don't see an http server deciding it will be the sole http server on the system, swallowing a wsgi server and waging war to all others.
I love systemd, but from a lot of experience with it over 3 years now, that doesn't disable the journal daemon, it only prevents output piping to its binary logs. You can still poll the journal daemon for events and output it elsewhere (ex, syslog).
Does journald impose a sufficient performance penalty that you want to remove it entirely?
Ubuntu just started using logind in 13.04, but haven't adopted the rest of systemd. Some parts (journal, systemd core, udev) can't be detached, but a lot of the peripheral software outside the init -> maintain services -> log events process are optional.
Ubuntu is splitting logind from systemd with no help from the systemd maintainers, because some gnome projects have started requiring logind. That effort is spent undoing Lennart's work swallowing most of the consolekit code base into systemd. The systemd maintainers won't accept patches that make logind a separate project again.
systemd-logind doesn't use code from consolekit. It has been written from scratch. ConsoleKit itself has been unmaintained for a long time.
>You can't replace bits of it, or use just parts of it.
You can replace pretty much everything. You need only systemd, systemd-udev and systemd-journald. Virtually everything else is optional. It also allows you to use syslog with journald. It allows you use use crond instead of the timer units. You could use ConsoleKit instead of systemd-logind as session manager... and so on and so forth.
You can replace pretty much everything. You need only systemd, systemd-udev and systemd-journald. Virtually everything else is optional. It also allows you to use syslog with journald. It allows you use use crond instead of the timer units. You could use ConsoleKit instead of systemd-logind as session manager... and so on and so forth.
I agre with your final paragraph and I rather like the consolidation that systemd offers. I'm certainly not going to miss fiddling with consolekit and I'm looking forwards to managing my user session via systemd. It reduces the number of things I need to learn to have a decent level of control over my system.
Sounds like Sutherland's Wheel of Reincarnation in action. All you have to do to predict the next generation of a technology is run further along the wheel.
> On the one hand, there are some huge, monolithic packages like Xorg that have split in to many smaller, more independent packages.
You should note that this is generally looked at as a bad move. Creating two separate packages for each protocol (one headers, one implementation), separate packages for each individual app etc. lead to a lot of unnecessary overhead for everybody (developers, release managers, package maintainers etc). Over the last couple years people have suggested to merge some of the packages back into the main xserver repository.
You should note that this is generally looked at as a bad move. Creating two separate packages for each protocol (one headers, one implementation), separate packages for each individual app etc. lead to a lot of unnecessary overhead for everybody (developers, release managers, package maintainers etc). Over the last couple years people have suggested to merge some of the packages back into the main xserver repository.
Before this thread devolves into the same arguments all over again, maybe everyone could read the following:
http://0pointer.de/blog/projects/the-biggest-myths.html
http://0pointer.de/blog/projects/the-biggest-myths.html
Lennart, please add the f*ng mail reader in there already and be finished with it.
After hearing both sides of the argument over and over again (for systemd and against systemd), my only regret is that Ubuntu is not replacing upstart with systemd, so that Loonix will have a uniform boot system.
To all the systemd naysayers, please read the docs before commenting, 90% of the comments against systemd look like they've been written by someone who:
a) hasn't used systemd
b) hasn't read anything relevant about systemd
Basically most comments come straight out of the blog post about systemd myths. That's really, really sad.
To all the systemd naysayers, please read the docs before commenting, 90% of the comments against systemd look like they've been written by someone who:
a) hasn't used systemd
b) hasn't read anything relevant about systemd
Basically most comments come straight out of the blog post about systemd myths. That's really, really sad.
[deleted]
The way this is going, Linux will end up as a single process operating system, that will do everything at web scale. All outputs in glorious binary format.
Funny, the crowd got distracted over Gnone3, Unity or Mir, or the latest worry of the day, yet never saw the big threat in their camp.
Linux isn't done until the text processor won't run.
Funny, the crowd got distracted over Gnone3, Unity or Mir, or the latest worry of the day, yet never saw the big threat in their camp.
Linux isn't done until the text processor won't run.
systemd is hardly monolithic as it is build of over 80 binaries. A normal system with systemd runs at least four processes: systemd (PID1), systemd-udev, systemd-journald and systemd-logind. There's various smaller services that are run on startup and other occasions. Then there are many configration utilities like timedatectl (systemd-timedated), hostnamectl (systemd-hostnamed) and localectl (systemd-localed).