My point was that systemd was tested for 3 years over 5 releases of Fedora. And the vote was a split between systemd and upstart, which upstart being the least technical finished product (according to the Ubuntu devs). And why do you have a bias against Red Hat developers?
No matter how I swing it? How about I use my system, then I get So it's more like 5:1:1 in favour of systemd. The Debian charta is using the Schwatz set to determine with system wins.
> A.6.6: Schwartz set is {D,U} > A.6.8: There are no defeats in the Schwartz set, so the elector with > the casting vote chooses which of these options wins. > > Per 6.3.2, the casting vote is held by the Chairman, who is currently > Bdale.
First, systemd does not replaces everything. It was voted by the technical committee of Debian. It does not forces you to install daemons. logind is replacing consolekid. Your statement is just BS based on ignorance.
See http://en.wikipedia.org/wiki/S... The only systemd gets new is the core and the 5 daemons. systemd and journald are the core of systemd, logind is a replacement for consolekid (which is no more in development), networkd is optional, and user-session is just very simple to allow users to login and disallow login during shutdown.
sysvinit is full of hacks, like start-stop-daemon, the mysterious/etc/init.d/functions, environment variables hackery like "# Check that networking is up. [ "${NETWORKING}" = "no" ] && exit 6", loops, pid files, and so on. Which all belongs in a proper init system.
As PID 1 it is the parent process of all services, therefore it can observe them all. No PID file hackery needed.
What is this Powershell terminal you speak of? If I google it, I find only
I'm not talking about the language itself, but the fact that to use Powershell I appear to have to use a single window that I can't set to the width of the screen, doesn't have tabs, has primitive cut and paste (seriously? No keyboard shortcuts and keyboard only highlighting line by line?). There's no history that can persist between sessions.
Then why you not trust the Debian developers to make a very informed decision about adopting systemd? Fedora is using systemd since Fedora 15 (now we are at Fedora 20). That means 5 released of testing (three years) and adopted by Red Hat Enterprise Linux since version 7, the most enterprise-ish distribution. It works, it solves many issues, and it's easy and you can just as well use sysvinit scripts on a systemd distribution.
Thx for the vote overview. As far as I can tell, 4 people voted for systemd, 2 for upstart (1 systemd, and 1 undecided as second). That makes already 5 people who regard systemd as the better choice. Then 1 vote for upstart and 1 vote for sysvinit (as second). So it's more like 5:1:1 in favour of systemd. So, I would call that an overwhelming majority. Debian's policy have also some strange rules which vote overrides which.
It's still the same old DOS terminal. I mean, really, how hard can it be for Microsoft to develop something like Konsole or Yakuake? Freely resizable window, freely choseable fonts and font sizes, fully supported copy and past, clickable URLs, etc.
Tracking of the started services, services dependencies, log, activation, system targets, declarative configuration, IPC, and sure a lot more that belongs in a init system. See http://en.wikipedia.org/wiki/S...
How does systemd should know if Apache have a bad config? That is still the responsibility of Apache. But the other reply is much more insightful. See http://slashdot.org/comments.p...
That is interesting, I didn't know that. But currently I'm only using systemd on my desktop PC. That feature is really great to further increase uptimes. Even if you have to restart Apache, your users won't notice it.
I define hacks as some code that is retrofitted to do a task for which there is no mechanism. For example, sysvinit does not know if a service was really started or really terminated, hence you need hacks like "while kill -0 ${PID:-}" 2>/dev/null; do" Using loops to keep track if the service was really terminated, or using sleep to wait for a service, are hacks. Or to use file system ordering of file names to determine which service should be started before another service (the links in/etc/rcX.d). And then you need also "black boxes" like start-stop-daemon. Which is also a hack, because start/stop of daemons belongs in an init system.
Because systemd is doing it the correct way, and it pisses people off that they have to learn a new init system. The Unix way is not "do everything in a script". Also, who cares about the "Unix way". Computers are entirely different today then from 50 years old Unix mainframes. Further, systemd even follows the "Unix way", i.e. "do one thing, and do it properly". A lot of stuff of systemd are independent daemons and independent binaries. Gnome for example can use systemd-logind without that systemd is PID 1.
You can just as easily statically compile journalctl as you can do grep or any other text tool. journalctl does not depend on systemd, and it is not significantly larger then for example grep.
What is your point, and how it relates to binary logs? If your point is that on power failure, or hard disk failure the buffers are lost, then it's not limited to systemd.
Or maybe, their customers wanted a solid and modern init-system and that was the reason why RedHat started the development on systemd? Systemd is not a one-man show.
It was split between systemd and upstart. And even the Ubuntu people chose systemd as second choice. So, we can say that systemd had "overwhelming support." and sysvinit had no support at all.
So, why exactly do you not like the replacement? For all the packages in Debian the maintainers will make sure their software will run just as well as it ran under sysvinit. And for your own services, the configuration will get significantly more easy. I think your argument boils down to "I don't like systemd because it's new and I don't like new stuff".
Ok, so what. Xorg was forced upon users, too. New kernel versions are forced upon users, too. You are free to fork Debian, and put back Sysvinit. http://linux.slashdot.org/stor...
Ok, narcissistic. Did you read his very first sentence? "It's not just the init, it's also the applications that are being infected with Lennart-ware, e.g. gnumeric. It's a great spreadsheet, but recently it's been picking up various egregious hard-coded dependancies that simply don't make sense." He said that gnumeric gets a lot of deps that he does not agree on, basically because he runs his pure Gentoo desktop and of his personal vendate against Lennart "Lennart-ware, GNOME-Lenna-x". And I reply, who is he to decide.
Microsoft is not dependent on their users, because Windows is a de facto standard. If Windows 8 is not accepted, then users go back to Windows 7. If RedHat Linux is not accepted, then users can switch to Windows or to a different Linux distribution.
Slashdot Mirror
My point was that systemd was tested for 3 years over 5 releases of Fedora.
And the vote was a split between systemd and upstart, which upstart being the least technical finished product (according to the Ubuntu devs).
And why do you have a bias against Red Hat developers?
No matter how I swing it? How about I use my system, then I get So it's more like 5:1:1 in favour of systemd.
The Debian charta is using the Schwatz set to determine with system wins.
> A.6.6: Schwartz set is {D,U}
> A.6.8: There are no defeats in the Schwartz set, so the elector with
> the casting vote chooses which of these options wins.
>
> Per 6.3.2, the casting vote is held by the Chairman, who is currently
> Bdale.
http://lwn.net/Articles/585363...
First, systemd does not replaces everything. It was voted by the technical committee of Debian. It does not forces you to install daemons. logind is replacing consolekid. Your statement is just BS based on ignorance.
See http://en.wikipedia.org/wiki/S...
The only systemd gets new is the core and the 5 daemons. systemd and journald are the core of systemd, logind is a replacement for consolekid (which is no more in development), networkd is optional, and user-session is just very simple to allow users to login and disallow login during shutdown.
sysvinit is full of hacks, like start-stop-daemon, the mysterious /etc/init.d/functions, environment variables hackery like "# Check that networking is up.
[ "${NETWORKING}" = "no" ] && exit 6", loops, pid files, and so on. Which all belongs in a proper init system.
As PID 1 it is the parent process of all services, therefore it can observe them all. No PID file hackery needed.
rsyslog vs. journald you can read for yourself
http://blog.gerhards.net/2011/...
http://blog.gerhards.net/2011/...
http://lwn.net/Articles/470058...
xinetd and systemd
http://0pointer.de/blog/projec...
IMHO socket activation belongs into a init-system.
What is this Powershell terminal you speak of? If I google it, I find only
I'm not talking about the language itself, but the fact that to use Powershell I appear to have to use a single window that I can't set to the width of the screen, doesn't have tabs, has primitive cut and paste (seriously? No keyboard shortcuts and keyboard only highlighting line by line?). There's no history that can persist between sessions.
http://www.theregister.co.uk/2...
And some third party terminals like
https://code.google.com/p/cone...
Then why you not trust the Debian developers to make a very informed decision about adopting systemd?
Fedora is using systemd since Fedora 15 (now we are at Fedora 20). That means 5 released of testing (three years) and adopted by Red Hat Enterprise Linux since version 7, the most enterprise-ish distribution. It works, it solves many issues, and it's easy and you can just as well use sysvinit scripts on a systemd distribution.
Thx for the vote overview. As far as I can tell, 4 people voted for systemd, 2 for upstart (1 systemd, and 1 undecided as second). That makes already 5 people who regard systemd as the better choice. Then 1 vote for upstart and 1 vote for sysvinit (as second). So it's more like 5:1:1 in favour of systemd. So, I would call that an overwhelming majority. Debian's policy have also some strange rules which vote overrides which.
It's still the same old DOS terminal. I mean, really, how hard can it be for Microsoft to develop something like Konsole or Yakuake?
Freely resizable window, freely choseable fonts and font sizes, fully supported copy and past, clickable URLs, etc.
Tracking of the started services, services dependencies, log, activation, system targets, declarative configuration, IPC, and sure a lot more that belongs in a init system. See http://en.wikipedia.org/wiki/S...
"Which one requires fewer commands" Are you kidding? Bash have a history.
"gives me everything since the day"
journalctl --since "20 min ago"
I have Fedora 20 and log rotate is enabled like usual.
ls /var/log/kdm* /var/log/kdm.log /var/log/kdm.log-20141005 /var/log/kdm.log-20141012 /var/log/kdm.log-20141028
How does systemd should know if Apache have a bad config? That is still the responsibility of Apache. But the other reply is much more insightful.
See http://slashdot.org/comments.p...
That is interesting, I didn't know that. But currently I'm only using systemd on my desktop PC.
That feature is really great to further increase uptimes. Even if you have to restart Apache, your users won't notice it.
I define hacks as some code that is retrofitted to do a task for which there is no mechanism. For example, sysvinit does not know if a service was really started or really terminated, hence you need hacks like "while kill -0 ${PID:-}" 2> /dev/null; do" /etc/rcX.d).
Using loops to keep track if the service was really terminated, or using sleep to wait for a service, are hacks. Or to use file system ordering of file names to determine which service should be started before another service (the links in
And then you need also "black boxes" like start-stop-daemon. Which is also a hack, because start/stop of daemons belongs in an init system.
Because systemd is doing it the correct way, and it pisses people off that they have to learn a new init system.
The Unix way is not "do everything in a script". Also, who cares about the "Unix way". Computers are entirely different today then from 50 years old Unix mainframes.
Further, systemd even follows the "Unix way", i.e. "do one thing, and do it properly". A lot of stuff of systemd are independent daemons and independent binaries. Gnome for example can use systemd-logind without that systemd is PID 1.
Oh, sorry, you didn't said that. Sorry, I wake up very early today.
You can just as easily statically compile journalctl as you can do grep or any other text tool. journalctl does not depend on systemd, and it is not significantly larger then for example grep.
% ls -lh /usr/bin/journalctl /usr/bin/journalctl /usr/bin/grep /usr/bin/grep /usr/bin/journalctl /lib64/librt.so.1 (0x00007f5031c07000) /lib64/liblzma.so.5 (0x00007f50319e2000) /lib64/libgcrypt.so.11 (0x00007f5031762000) /lib64/libacl.so.1 (0x00007f5031559000) /lib64/libqrencode.so.3 (0x00007f503134c000) /lib64/libgcc_s.so.1 (0x00007f5031135000) /lib64/libc.so.6 (0x00007f5030d77000) /lib64/ld-linux-x86-64.so.2 (0x00000033b9800000) /lib64/libpthread.so.0 (0x00007f5030b5a000) /lib64/libgpg-error.so.0 (0x00007f5030954000) /lib64/libdl.so.2 (0x00007f5030750000) /lib64/libattr.so.1 (0x00007f503054b000)
-rwxr-xr-x. 1 root root 224K Sep 24 15:04
devent@localhost [383] ~ % ls -lh
-rwxr-xr-x. 1 root root 156K Feb 26 2014
% ldd
linux-vdso.so.1 => (0x00007fff917f8000)
librt.so.1 =>
liblzma.so.5 =>
libgcrypt.so.11 =>
libacl.so.1 =>
libqrencode.so.3 =>
libgcc_s.so.1 =>
libc.so.6 =>
libpthread.so.0 =>
libgpg-error.so.0 =>
libdl.so.2 =>
libattr.so.1 =>
Are you implying that systemd does not have a strict testing?
What is your point, and how it relates to binary logs?
If your point is that on power failure, or hard disk failure the buffers are lost, then it's not limited to systemd.
Or maybe, their customers wanted a solid and modern init-system and that was the reason why RedHat started the development on systemd?
Systemd is not a one-man show.
It was split between systemd and upstart. And even the Ubuntu people chose systemd as second choice. So, we can say that systemd had "overwhelming support." and sysvinit had no support at all.
Maybe, just maybe, those maintainers know their users and ignore the minority that is whining all over the forums?
So, why exactly do you not like the replacement? For all the packages in Debian the maintainers will make sure their software will run just as well as it ran under sysvinit. And for your own services, the configuration will get significantly more easy. I think your argument boils down to "I don't like systemd because it's new and I don't like new stuff".
Ok, so what. Xorg was forced upon users, too. New kernel versions are forced upon users, too.
You are free to fork Debian, and put back Sysvinit. http://linux.slashdot.org/stor...
Ok, narcissistic.
Did you read his very first sentence? "It's not just the init, it's also the applications that are being infected with Lennart-ware, e.g. gnumeric. It's a great spreadsheet, but recently it's been picking up various egregious hard-coded dependancies that simply don't make sense." He said that gnumeric gets a lot of deps that he does not agree on, basically because he runs his pure Gentoo desktop and of his personal vendate against Lennart "Lennart-ware, GNOME-Lenna-x". And I reply, who is he to decide.
Microsoft is not dependent on their users, because Windows is a de facto standard. If Windows 8 is not accepted, then users go back to Windows 7.
If RedHat Linux is not accepted, then users can switch to Windows or to a different Linux distribution.