If you think that it does because installing gimp on Debian also install libsystemd, then that's because the Debian package maintainers have set libsystemd as a dependency to dbus; and gimp uses dbus.
Sure you can. You can roll your own. You just have to do the job. Someone has to do it. And if the distributions are not interested in doing it, then someone else has to do it. It's really as simple as that. Don't expect other people to do stuff for you just the way you like it. They have their goals in mind too. You don't like where things are going, then fix it.
Text files take too long to read and have problems with things like rotation. By using its own format systemd can include meta data and indexing that allows the journal to be search faster and more precise.
Because it can't be troubleshooted if all you have is something to read text files with. When all you have is a single user shell, for example. Or you've put the hard drive in a different system, which is whatever you had on hand and could even be Windows with an ext3 plugin.
Why would less work in single user mode but not journalctl? And nothing stops you or anyone else from writing a journal reader for Windows. The on-disk file format is not a secret.
Because it comes from the author of PulseAudio, who is world renowned for the stability of his products. And low CPU consumption, when they work.
PulseAudio runs on FreeBSD as well, just so you know.
Because it contradicts the Unix philosophy of having a lot of little utilities that each do one thing. It may not be a big deal for a full time sysadmin, but if your main job isn't that it's a lot easier to just read about the small parts that interest you and disable the rest.
systemctl disable $foo
And that's supposed to be easier just because $foo is implemented with a shell script instead of a.service file?
2. If he can write Linux kernel drivers, why does he need to ask Slashdot, or why doesn't he google it? Because I don't know anything about BSD, and I'm not looking for "learn BSD in 10 easy mouse clicks". Although the signal to noise ratio on here sometimes approaches zero, there is the occasional informed opinion, and with a bit of luck, there will be some pointer to some actual pertinent information.
If you want simplicity then systemd is exactly what you're looking for. Take a look at just about any.service file. It's miles easier to read an understand than the corresponding LSB init script.
Our company runs our own servers; we run Ubuntu Linux. Our web sites are PHP. All I know is to run apt-get every Sunday and Ubuntu can update whatever it wants to. These are in-company web sites with login user names and passwords. No e-commerce involved; no public involved.
In case you ever run a public Ubuntu-based server make sure that you never install packages from the universe or multiverse components of the package archive. They are not updated by the Ubuntu security team and can therefore include unpatched vulnerabilities, which include a large number of php5 packages.
Why aren't there "long-term support versions" similar to what Ubuntu offers? Only security flaws are patched in such versions.
Ubuntu only supports a handful of packages, specifically those in the main and restricted sections of the package archive. This includes the main php5 package but a large number of modules are kept in universe and are not supported at all.
However, I realize patching security flaws can break existing software also, but if you only patch security flaws rather than add and change features for the line, the magnitude of problems from updates would be smaller.
It depends on the vulnerability. I had things break when the bash vulnerability was patched some time ago. There is no solution other than test that things work before you apply the update.
Or use a distribution which provides updated and supported versions of the tools you need. Red Hat for example provides a base version of PHP if you want something which is stable throughout the entire life cycle of the operating system, but they also provide software collections with a shorter 18 month life cycle if you want a newer version of say PHP.
I do not know the answer for the Debian, but if you did RTFA, you would notice that it is precisely what the Devuan is doing: creating and packaging software which provide the interface of systemd services without the systemd itself.
Yes, that's what they are doing.
The (retorical) question which I have already asked on difference occasions here is whether the Debian is a good place to do such development.
One strong undertone from the CTTE's init system selection debate was that Debian doesn't want to do the development and wants to maximize the reuse of the code from the other distros. This turned into a weird attitude when systemd vs. upstart was evaluated. The upstart devs and maintainers have committed themselves to implement whatever Debian needs. The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package". And that was later respun by a couple of CTTE members as "upstart still needs development while systemd doesn't".
That is also why I raise the question about changes to the Debian organization in Devuan: How could Devuan be more software developer friendlier? At the moment the barrier to entry is very high, leaving developers at mercy of the respective Debian packager. Or leaving the developer basically out if it has something to do with the low-level stuff like init system.
You're talking about Debian and Devuan like it's two monolithic organizations. It's not. It's people. And and if you want "Debian" to do something then real human Debian developers will have to do the job. It doesn't matter what any committee decides if no one is interested in actually doing the work.
The Devuan developers are obviously up for the task. That's great. They do what they want to do. It's just too bad that they for whatever reason couldn't do it in Debian. I don't blame them. It takes an arm and a leg to get into Debian nowdays, so if it's easier for them to create a fork then maybe that says something about the Debian project too.
Slashdot Mirror
And by the way, libsystemd is not an init system. It's a library.
Gimp does not require systemd.
If you think that it does because installing gimp on Debian also install libsystemd, then that's because the Debian package maintainers have set libsystemd as a dependency to dbus; and gimp uses dbus.
Sure you can. You can roll your own. You just have to do the job. Someone has to do it. And if the distributions are not interested in doing it, then someone else has to do it. It's really as simple as that. Don't expect other people to do stuff for you just the way you like it. They have their goals in mind too. You don't like where things are going, then fix it.
A lot of packages are gaining direct or indirect dependencies on systemd
Yes, because it does useful stuff that software needs.
and it is becoming a huge pain to run a systemd free system.
So, just run systemd then. Not more pain.
So software written in C is bad now? What if you find a bug in the kernel, or in ls? You do know that ls is also written in C?
Yes, I do. And I get patches for it every couple of weeks, often with a large number of CVEs fixed.
Text files take too long to read and have problems with things like rotation. By using its own format systemd can include meta data and indexing that allows the journal to be search faster and more precise.
Here's the source code. Just go and have a look.
http://cgit.freedesktop.org/sy...
So it's C instead of shell, the same programming language that probably most of the software you're running is written in anyway.
Because it can't be troubleshooted if all you have is something to read text files with. When all you have is a single user shell, for example. Or you've put the hard drive in a different system, which is whatever you had on hand and could even be Windows with an ext3 plugin.
Why would less work in single user mode but not journalctl? And nothing stops you or anyone else from writing a journal reader for Windows. The on-disk file format is not a secret.
Because it comes from the author of PulseAudio, who is world renowned for the stability of his products. And low CPU consumption, when they work.
PulseAudio runs on FreeBSD as well, just so you know.
Because it contradicts the Unix philosophy of having a lot of little utilities that each do one thing. It may not be a big deal for a full time sysadmin, but if your main job isn't that it's a lot easier to just read about the small parts that interest you and disable the rest.
systemctl disable $foo
And that's supposed to be easier just because $foo is implemented with a shell script instead of a .service file?
2. If he can write Linux kernel drivers, why does he need to ask Slashdot, or why doesn't he google it?
Because I don't know anything about BSD, and I'm not looking for "learn BSD in 10 easy mouse clicks". Although the signal to noise ratio on here sometimes approaches zero, there is the occasional informed opinion, and with a bit of luck, there will be some pointer to some actual pertinent information.
https://www.freebsd.org/doc/ha...
Recommended.
If you want simplicity then systemd is exactly what you're looking for. Take a look at just about any .service file. It's miles easier to read an understand than the corresponding LSB init script.
A large amount of untested, potentially unsecure, unaudited code
Sounds like software to me. Bash was unsecure and unaudited. So I guess you're in csh land now?
Well, Microsoft is doing their part.
http://msdn.microsoft.com/en-u...
Parts of .NET is open source. But Visual Studio, are you sure about that?
The hardware provider should push Android 5.0, not update legacy releases.
Then I guess he's not working on OpenBSD.
http://www.openbsd.org/errata5...
He has not been involved with Tumblr since ca 2010 if I remember correctly.
That's not how it works. You subscribe to "Netflix," not to specific content.
Our company runs our own servers; we run Ubuntu Linux. Our web sites are PHP. All I know is to run apt-get every Sunday and Ubuntu can update whatever it wants to. These are in-company web sites with login user names and passwords. No e-commerce involved; no public involved.
In case you ever run a public Ubuntu-based server make sure that you never install packages from the universe or multiverse components of the package archive. They are not updated by the Ubuntu security team and can therefore include unpatched vulnerabilities, which include a large number of php5 packages.
Why aren't there "long-term support versions" similar to what Ubuntu offers? Only security flaws are patched in such versions.
Ubuntu only supports a handful of packages, specifically those in the main and restricted sections of the package archive. This includes the main php5 package but a large number of modules are kept in universe and are not supported at all.
However, I realize patching security flaws can break existing software also, but if you only patch security flaws rather than add and change features for the line, the magnitude of problems from updates would be smaller.
It depends on the vulnerability. I had things break when the bash vulnerability was patched some time ago. There is no solution other than test that things work before you apply the update.
Bah, an engineer is someone that runs a locomotive.
Or use a distribution which provides updated and supported versions of the tools you need. Red Hat for example provides a base version of PHP if you want something which is stable throughout the entire life cycle of the operating system, but they also provide software collections with a shorter 18 month life cycle if you want a newer version of say PHP.
Slashdot is large enough for everyone. You don't have to be interested in every story.
Exactly.
I do not know the answer for the Debian, but if you did RTFA, you would notice that it is precisely what the Devuan is doing: creating and packaging software which provide the interface of systemd services without the systemd itself.
Yes, that's what they are doing.
The (retorical) question which I have already asked on difference occasions here is whether the Debian is a good place to do such development.
One strong undertone from the CTTE's init system selection debate was that Debian doesn't want to do the development and wants to maximize the reuse of the code from the other distros. This turned into a weird attitude when systemd vs. upstart was evaluated. The upstart devs and maintainers have committed themselves to implement whatever Debian needs. The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package". And that was later respun by a couple of CTTE members as "upstart still needs development while systemd doesn't".
That is also why I raise the question about changes to the Debian organization in Devuan: How could Devuan be more software developer friendlier? At the moment the barrier to entry is very high, leaving developers at mercy of the respective Debian packager. Or leaving the developer basically out if it has something to do with the low-level stuff like init system.
You're talking about Debian and Devuan like it's two monolithic organizations. It's not. It's people. And and if you want "Debian" to do something then real human Debian developers will have to do the job. It doesn't matter what any committee decides if no one is interested in actually doing the work.
The Devuan developers are obviously up for the task. That's great. They do what they want to do. It's just too bad that they for whatever reason couldn't do it in Debian. I don't blame them. It takes an arm and a leg to get into Debian nowdays, so if it's easier for them to create a fork then maybe that says something about the Debian project too.
"who is going to make all these packages compatible with sysv init"
Exactly. Did someone step up within Debian to do it?