http://ewontfix.com/15/ http://ewontfix.com/14/
Just read them and protest to developer drop this piece of sh*t! This implementation is going to become Linux to Windows. The system will have main almighty process which can't be updated without restart. If that process will be corrupted the all system is f****d. Why did we choose it? I really do NOT understand
Balint
On Sat, 05 Jul 2014 10:20:16 +0100 Balint wrote:
I really do NOT understand
Mainly because it falls into the "new and therefore better" rabbit hole fedora (and it seems all other linux distros) is dedicated to jumping down.
It really does enable my system to boot infinitely faster than the alternatives, but it is too bad it doesn't confine itself to just getting the system booted, then get out of the way. (But at least that will provide an opportunity for a fork of the project someday that does just boot the system - then the fork will be new and therefore better :-).
On 05/07/2014 11:47, Tom Horsley wrote:
On Sat, 05 Jul 2014 10:20:16 +0100 Balint wrote:
I really do NOT understand
Mainly because it falls into the "new and therefore better" rabbit hole fedora (and it seems all other linux distros) is dedicated to jumping down.
It really does enable my system to boot infinitely faster than the alternatives, but it is too bad it doesn't confine itself to just getting the system booted, then get out of the way. (But at least that will provide an opportunity for a fork of the project someday that does just boot the system - then the fork will be new and therefore better :-).
well, good explanation. I hope Linux will not become 'windows' because systemd will gain the 'power' above everything..... :D
On Sat, 05 Jul 2014 12:00:21 +0100 Balint wrote:
well, good explanation. I hope Linux will not become 'windows' because systemd will gain the 'power' above everything..... :D
Yea, I classify systemd as the very first "computer fungus". It seems to want to grow over everything. It has already consumed udev and ConsoleKit that I know of, and now wants to drag in dbus (and integrate it with the kernel for God's sake).
I figure it is only a matter of time before Lennart wants some compiler feature to use in the source and drags g++ into the systemd tree :-).
Tom Horsley wrote:
It really does enable my system to boot infinitely faster than the alternatives,
Is this really true? Fedora-20 boots reasonably fast on my fairly old laptop (Thinkpad T61), but I didn't notice any change when Fedora went over to systemd. (I think my CentOS-6.5 desktop boots just as fast, if not faster.)
What exactly does systemd do differently that would speed up booting?
One trivial complaint I have with systemd is that I have to type more - "sudo systemctl restart NetworkManager.service" against "sudo service NetworkManager restart". Not much difference, perhaps, but to me the necessity of adding ".service" shows that the developer just didn't think of the user's convenience. I know there are rare cases where one has to say something else, but why not make the default to add ".service" if nothing is given? Or perhaps TAB could complete it?
And what (if anything) is the replacement for "chkconfig --list"?
On Sat, 2014-07-05 at 15:10 +0200, Timothy Murphy wrote:
What exactly does systemd do differently that would speed up booting?
One trivial complaint I have with systemd is that I have to type more
It allows the various components to have specific dependencies so they can start as soon as everything is in place. Older mechanisms such as the traditional System V init scripts were much more limited and could only do this with very ad hoc and buggy per-service tests, so they mostly didn't.
"sudo systemctl restart NetworkManager.service" against "sudo service NetworkManager restart". Not much difference, perhaps, but to me the necessity of adding ".service" shows that the developer just didn't think of the user's convenience. I know there are rare cases where one has to say something else, but why not make the default to add ".service" if nothing is given? Or perhaps TAB could complete it?
+1. One of my pet gripes about systemd is that it introduces a lot of new terminology without a clear explanation. I still don't understand the difference between a target and a service.
poc
On 07/05/2014 04:10 PM, Timothy Murphy wrote:
Tom Horsley wrote:
It really does enable my system to boot infinitely faster than the alternatives,
Is this really true? Fedora-20 boots reasonably fast on my fairly old laptop (Thinkpad T61), but I didn't notice any change when Fedora went over to systemd. (I think my CentOS-6.5 desktop boots just as fast, if not faster.)
What exactly does systemd do differently that would speed up booting?
One trivial complaint I have with systemd is that I have to type more - "sudo systemctl restart NetworkManager.service" against "sudo service NetworkManager restart". Not much difference, perhaps, but to me the necessity of adding ".service"
on my f20 i can do systemctl restart sshd moreover you can do an alias like serviced="sudo systemctl" (serviced because service is still used for /etc/init.d inhabitants) but also you can do this: sudo service sshd restart Redirecting to /bin/systemctl restart sshd.service
also the reverse is possible: sudo systemctl disable sys_basher.init.service sys_basher.init.service is not a native service, redirecting to /sbin/chkconfig. Executing /sbin/chkconfig sys_basher.init off
shows that the developer just didn't think of the user's convenience. I know there are rare cases where one has to say something else, but why not make the default to add ".service" if nothing is given? Or perhaps TAB could complete it?
the autocomplete is working
And what (if anything) is the replacement for "chkconfig --list"?
"systemctl --no-pager -a" for "all loaded units/properties, including dead/empty ones" "systemctl --no-pager list-unit-files" for all units installed in system
for the current loaded units/sockets you have systemctl list-units systemctl list-sockets
as for the boot timings you have systemd-analyze and "systemd-analyze blame"
Overall check the man pages .. there are a lot of interesting things you can do with systemd but it takes some time to get used to ... i am still not comfortable with all the options of journalctl and i am wondering how it will go when i will migrate my servers to centos 7..
Adrian
On 07/05/2014 04:30 PM, Patrick O'Callaghan wrote:
On Sat, 2014-07-05 at 15:10 +0200, Timothy Murphy wrote:
What exactly does systemd do differently that would speed up booting?
One trivial complaint I have with systemd is that I have to type more
It allows the various components to have specific dependencies so they can start as soon as everything is in place. Older mechanisms such as the traditional System V init scripts were much more limited and could only do this with very ad hoc and buggy per-service tests, so they mostly didn't.
"sudo systemctl restart NetworkManager.service" against "sudo service NetworkManager restart". Not much difference, perhaps, but to me the necessity of adding ".service" shows that the developer just didn't think of the user's convenience. I know there are rare cases where one has to say something else, but why not make the default to add ".service" if nothing is given? Or perhaps TAB could complete it?
+1. One of my pet gripes about systemd is that it introduces a lot of new terminology without a clear explanation. I still don't understand the difference between a target and a service.
a service is a service .. a target is : "A unit configuration file whose name ends in ".target" encodes information about a target unit of systemd, which is used for grouping units and as well-known synchronization points during start-up."
as said in man systemd.target (which i found by "apropos systemd target")
HTH, Adrian
On 7-5-14 10:20:16 Balint wrote:
I really do NOT understand
Yes, that is true.
Log of update that includes a new systemd:
Jun 26 08:01:45 vfr sudo[28872]: garry : TTY=pts/2 ; PWD=/home/garry ; USER=root ; COMMAND=/bin/dnf upgrade ... Jun 26 08:07:16 vfr systemd[1]: Serializing state to /run/systemd/dump-1-nP2xi3 Jun 26 08:07:16 vfr systemd[1]: Reexecuting. Jun 26 08:07:16 vfr systemd[1]: systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
No reboot, of course.
On 7-5-14 15:10:35 Timothy Murphy wrote:
One trivial complaint I have with systemd is that I have to type more - "sudo systemctl restart NetworkManager.service" against "sudo service NetworkManager restart". Not much difference, perhaps, but to me the necessity of adding ".service" shows that the developer just didn't think of the user's convenience. I know there are rare cases where one has to say something else, but why not make the default to add ".service" if nothing is given? Or perhaps TAB could complete it?
Have you actually tried a tab?
On Sat, 2014-07-05 at 16:35 +0300, Adrian Sevcenco wrote:
+1. One of my pet gripes about systemd is that it introduces a lot
of
new terminology without a clear explanation. I still don't
understand
the difference between a target and a service.
a service is a service
A rose is a rose is a rose. I know what people mean by service in the traditional Unix sense, where it's only loosely defined if at all. Is that what systemd means by service? I suspect it means something more precise, but it's not clear.
.. a target is : "A unit configuration file whose name ends in ".target" encodes information about a target unit of systemd, which is used for grouping units and as well-known synchronization points during start-up."
as said in man systemd.target (which i found by "apropos systemd target")
Well if you're just going to look up the manual, anybody can do that :-)
More to the point, to understand "target" I now have to understand "unit". According to systemd(1), under the heading "Concepts", we find that "systemd provides a dependency system between various entities called "units" of 12 different types". 12 different types! I'm getting a sinking feeling already ...
The point I want to make is that though systemd may be the greatest thing since sliced bread, the effort required to read and understand the docs, plus the verbose nature of the command system, doesn't win it any friends.
poc
On 7-5-14 14:30:39 Patrick O'Callaghan wrote:
+1. One of my pet gripes about systemd is that it introduces a lot of new terminology without a clear explanation.
Have you looked at the manual pages? I know of no other project that has the breadth and depth of documentation that systemd has. Your statement is, on its face, incorrect.
Also (among many others):
http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd-for-admins-1.html
On 05.07.2014, Patrick O'Callaghan wrote:
It allows the various components to have specific dependencies so they can start as soon as everything is in place. Older mechanisms such as the traditional System V init scripts were much more limited and could only do this with very ad hoc and buggy per-service tests, so they mostly didn't.
Do we need that? I mean, what's the advantage of having a speedier startup wrt the introduction of massive complexity? Do we need the saved seconds for something useful? How much time do we actually use to manage/struggle with systemd in comparison to a potentially slower but more mature and less complex system?
Just curious..
Heinz Diehl writes:
On 05.07.2014, Patrick O'Callaghan wrote:
It allows the various components to have specific dependencies so they can start as soon as everything is in place. Older mechanisms such as the traditional System V init scripts were much more limited and could only do this with very ad hoc and buggy per-service tests, so they mostly didn't.
Do we need that? I mean, what's the advantage of having a speedier startup wrt the introduction of massive complexity? Do we need the saved seconds for something useful? How much time do we actually use to manage/struggle with systemd in comparison to a potentially slower but more mature and less complex system?
Just curious..
If the goal was to speed up startup, by executing stuff in parallel that does not have dependencies on each other, that could've been done in many other, simpler ways.
Garry T. Williams wrote:
Have you looked at the manual pages? I know of no other project that has the breadth and depth of documentation that systemd has.
This is probably a minority view but I don't think a man page should try to tell you everything about a command.
When I first used Unix (version 5) it was explicitly stated that a man page should literally fit on one page.
In particular I don't think it is necessary to list dozens of options, some of which are rarely if ever used, just because they exist. (I recall that there used to be a regular competition for the most useless option one could add to "cat".)
To me, a man page should address the likely needs of 95% of users, and should use any spare space to give examples of usage. A pointer to a reference work would be a useful addition.
On 07/05/14 06:33, Adrian Sevcenco wrote:
i am still not comfortable with all the options of journalctl and i am wondering how it will go when i will migrate my servers to centos 7..
Use Centos 6.x, it should be supported untill 2020. Probably by then systemd is replaced or improved.
Garry T. Williams wrote:
I know there are rare cases where one has to say something else, but why not make the default to add ".service" if nothing is given? Or perhaps TAB could complete it?
Have you actually tried a tab?
Mea colpa. It never occurred to me that this might actually be implemented - but now I find it reduces my usage time by 40%. Molto grazie.
On Sat, 05 Jul 2014 20:05:37 +0200 Timothy Murphy gayleard@alice.it wrote:
Garry T. Williams wrote:
I know there are rare cases where one has to say something else, but why not make the default to add ".service" if nothing is given? Or perhaps TAB could complete it?
Have you actually tried a tab?
Mea colpa. It never occurred to me that this might actually be implemented - but now I find it reduces my usage time by 40%. Molto grazie.
Additionally, since about f17, '.service' is assumed...
ie,
systemctl status foobar
is the same as
sysemctl status foobar.service
kevin
On Saturday, July 05, 2014 12:12:30 PM Kevin Fenzi wrote:
Additionally, since about f17, '.service' is assumed...
ie,
systemctl status foobar
is the same as
sysemctl status foobar.service
Again, many thanks - tested and verified.
Now the only thing I can moan about is the lack of chkconfig --list
On Sat, 05 Jul 2014 20:23:52 +0200 Timothy Murphy gayleard@alice.it wrote:
On Saturday, July 05, 2014 12:12:30 PM Kevin Fenzi wrote:
Additionally, since about f17, '.service' is assumed...
ie,
systemctl status foobar
is the same as
sysemctl status foobar.service
Again, many thanks - tested and verified.
Now the only thing I can moan about is the lack of chkconfig --list
Not exactly the same, but I like:
systemctl list-unit-files
you can grep that output for enabled/disabled/etc.
kevin
On Sat, 05 Jul 2014 20:23:52 +0200 Timothy Murphy wrote:
Now the only thing I can moan about is the lack of chkconfig --list
systemctl --full list-unit-files | grep enabled
or grep .service, etc.
Not that I can remember that command. I have it in my notes and have to look up the syntax every time...
Allegedly, on or about 05 July 2014, Patrick O'Callaghan sent:
More to the point, to understand "target" I now have to understand "unit". According to systemd(1), under the heading "Concepts", we find that "systemd provides a dependency system between various entities called "units" of 12 different types". 12 different types! I'm getting a sinking feeling already ...
The old system was considered bad, because it had 6 run levels, of which a few of them were never used. Now we have 12?
A NINE BLADED SWORD!!!!
Allegedly, on or about 05 July 2014, Garry T. Williams sent:
http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd-for-admins-1.html
Fails to load, here, does it work for you? I even left the browser attempting it for a few minutes.
On 07/05/2014 04:21 PM, Tim wrote:
The old system was considered bad, because it had 6 run levels, of which a few of them were never used. Now we have 12?
I didn't exactly like systemd when it first came out, but I've gotten used to it. And, like it or not, Linux as a whole isn't going to go back to the old init style of booting. My advice is that we all learn to stop worrying and love systemd.
On Sun, 2014-07-06 at 09:00 +0930, Tim wrote:
Allegedly, on or about 05 July 2014, Garry T. Williams sent:
http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd-for-admins-1.html
Fails to load, here, does it work for you? I even left the browser attempting it for a few minutes.
Failing here too.
poc
On Sat, 2014-07-05 at 20:01 +0200, Timothy Murphy wrote:
Have you looked at the manual pages? I know of no other project
that
has the breadth and depth of documentation that systemd has.
This is probably a minority view but I don't think a man page should try to tell you everything about a command.
When I first used Unix (version 5) it was explicitly stated that a man page should literally fit on one page.
In particular I don't think it is necessary to list dozens of options, some of which are rarely if ever used, just because they exist. (I recall that there used to be a regular competition for the most useless option one could add to "cat".)
To me, a man page should address the likely needs of 95% of users, and should use any spare space to give examples of usage. A pointer to a reference work would be a useful addition.
I'm an old Unix hand so for me the man page *is* the reference in most cases, though for something as large and complex as systemd I have no issue with there being supplementary material as long as I don't need to access it just to remember a basic command. In fact I get annoyed at many of the desktop tools which don't have a proper man page because they expect you to reach for a browser or one of the lame built-in help tools. However that's another story.
poc
On Sat, 5 Jul 2014, Joe Zeff wrote:
On 07/05/2014 04:21 PM, Tim wrote:
The old system was considered bad, because it had 6 run levels, of which a few of them were never used. Now we have 12?
I didn't exactly like systemd when it first came out, but I've gotten used to it. And, like it or not, Linux as a whole isn't going to go back to the old init style of booting. My advice is that we all learn to stop worrying and love systemd.
My impression is that there seems to be a desire to increase the complexity of linux to the point that it is no longs something that people can administer themselves. Everything has to be esoteric, so that fewer and fewer people find it accessible. I used to tell my friends that linux was actually *easer* to deal with than Windows, once you got over the initial learning cureve associated with making the change.
I used to tell people that Windows was "easy" because they had already invested thousands of hours trying to make it work, and now they were semi-comfortable with what they have. Linux is different, so much of what they learned doesn't directly translate, but once they got the differences, it would make more sense and be much easier.
I no longer say that.
billo
On Sat, 2014-07-05 at 10:03 -0400, Garry T. Williams wrote:
On 7-5-14 14:30:39 Patrick O'Callaghan wrote:
+1. One of my pet gripes about systemd is that it introduces a lot of new terminology without a clear explanation.
Have you looked at the manual pages?
Yes. I quoted one of them in my comment.
I know of no other project that has the breadth and depth of documentation that systemd has.
Then you can't have seen much documentation for large-scale tools such as databases, windowing systems, text processors etc., not to mention the Linux kernel.
To go back to the same example as before, the concept of "unit" seems to me not well-defined. The man page says a unit is an object, but then it talks about various types of units, some of which are associated with events, others with sets of processes, others with system states, while still others are recursively sets of other units. This seems to me symptomatic of a lot of technical documentation, i.e. the author knows what he's talking about but doesn't appreciate the need to get the reader to understand it. At certain points I find myself wondering if he actually meant to say "objective" rather than "object", but that wouldn't fit either. Since the concept of unit appears to be basic to understanding what systemd is all about, this is a serious deficiency IMHO.
Your statement is, on its face, incorrect.
My statement is an opinion, as is yours.
Also (among many others):
http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd-for-admins-1.html
I've looked at both of them before now (currently they aren't responding), and at some others. I maintain my view that there is a better explanation of systemd waiting to be written.
poc
I find systemd a great deal easier to deal with than sysvint/upstart.
I made a systemd unit file the other day for a local service and it took me about 30 seconds. A sysvinit file would have taken copying a bunch of biolerplate and would have taken a good deal longer.
Does systemd have bugs or issues? sure.
Does it sometimes expand into areas that perhaps it shouldn't? sure.
Is it an improvement over upstart/sysvinit? I would say absolutely so.
kevin
On Sat, 5 Jul 2014 23:47:09 +0000 (UTC) Bill Oliver wrote:
I no longer say that.
That's because the primary driving force behind linux changes is google. If you can google how to do something in a few minutes, then it is obviously necessary to completely re-write it as soon as possible so people who make a living charging for linux support will be able to stay in business :-).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/06/14 08:01, Kevin Fenzi wrote:
I find systemd a great deal easier to deal with than sysvint/upstart.
I made a systemd unit file the other day for a local service and it took me about 30 seconds. A sysvinit file would have taken copying a bunch of biolerplate and would have taken a good deal longer.
Does systemd have bugs or issues? sure.
Does it sometimes expand into areas that perhaps it shouldn't? sure.
Is it an improvement over upstart/sysvinit? I would say absolutely so.
Add me to the +1.
- -- If you can't laugh at yourself, others will gladly oblige.
On 07/05/2014 06:21 PM, Tim wrote:
Allegedly, on or about 05 July 2014, Patrick O'Callaghan sent:
More to the point, to understand "target" I now have to understand "unit". According to systemd(1), under the heading "Concepts", we find that "systemd provides a dependency system between various entities called "units" of 12 different types". 12 different types! I'm getting a sinking feeling already ...
The old system was considered bad, because it had 6 run levels, of which a few of them were never used. Now we have 12?
Twelve different types of *units*, of which service and target are two. A target is like a runlevel (it groups units together), except that more than one can be active at a time. A target can be marked "AllowIsolate=yes", which means that it can be treated like a sysvinit runlevel (start everything listed in it and stop everything else).
Note also that backward-compatible symlinks are provided in /usr/lib/systemd/system for the targets that correspond to the "classical" sysvinit runlevels:
runlevel0.target -> poweroff.target runlevel1.target -> rescue.target runlevel2.target -> multi-user.target runlevel3.target -> multi-user.target runlevel4.target -> multi-user.target runlevel5.target -> graphical.target runlevel6.target -> reboot.target
https://fedoraproject.org/wiki/Systemd#How_do_I_change_the_target_.28runleve...
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
Kevin Fenzi writes:
Is it an improvement over upstart/sysvinit? I would say absolutely so.
A false dichotomy.
The question is not simply whether we should stick with the old init scripts or go with systemd, but really, what is the best way to start up a linux system?
It is indeed possible to use one service (unit?) file as a recipe for other services. I have done this in the past, when I was on Arch Linux, which adopted systemd whole hog, and many AUR packages had not been upgraded.
That's probably not really the case we're concerned about. The problem, as illustrated in, now, two threads, is what has to be understood, when all of a sudden things aren't working the way they should, and you're under the gun to get them fixed. right. f***ing. now.
The way I found the solution to my problem with postfix, nsd, and ejabberd (and possibly other services I haven't noticed yet) was hardly systematic. In trying to look at the network.target file, I hit tab for tab completion and got an unexpected pause because at that point, it was ambiguous.
Then, and only then, did I discover there was even a network-online.target. Please understand, the time when things are broken is not the time when I want to explore rat holes. As it turned out, this *wasn't* a rat hole, but yet an additional layer of complexity.
A layer of complexity, by the way, whose purpose has yet to be explained, and which rests on top of all the other complexity that others in this thread have complained about.
Which returns us back--and I hope I'm recalling the initial posting in this thread correctly--to the beginning of this thread. Do we really need this complexity for the sake of a few seconds?
But there's something more insidious about this as well.
The mantra I learned as a system administrator was, if it ain't broken, don't fix it. The message I'm getting from this thread, when people point out (correctly, as far as I know) that all the distributions are going for the latest greatest shiny thing, is that they're abandoning that mantra.
Yes, I'll agree that init is not ideal. But at this point, I'm not at all persuaded that the distributions shouldn't have looked at Lennart and said, you're out of your flipping mind. But then, at the risk, of opening up another flame war, they might have done the same about pulseaudio, which I leave alone right up to the moment I have problems--any problems--with sound, and then eliminate as a usually successful first stab at a solution.
One problem here is that while I can blow away pulseaudio without qualms, I can't do the same with systemd. I'm committed. Whether I like it or not.
On Sat, 05 Jul 2014 18:10:45 -0700 David Benfell benfell@parts-unknown.org wrote:
...snip...
Then, and only then, did I discover there was even a network-online.target. Please understand, the time when things are broken is not the time when I want to explore rat holes. As it turned out, this *wasn't* a rat hole, but yet an additional layer of complexity.
A layer of complexity, by the way, whose purpose has yet to be explained, and which rests on top of all the other complexity that others in this thread have complained about.
Were you tying your services to specific IP addresses?
I'm curious why this would have changed for you folks so recently. Was this a bug with systemd-208-19.fc20?
Which returns us back--and I hope I'm recalling the initial posting in this thread correctly--to the beginning of this thread. Do we really need this complexity for the sake of a few seconds?
No. We need it for all the other reasons.
Lennarts blog host seems to be having some problem, but from google cache:
http://webcache.googleusercontent.com/search?q=cache:rm-N94-I044J:0pointer.d...
Theres tons and tons of things that systemd does well that there was no way to do in the sysvinit world.
But there's something more insidious about this as well.
The mantra I learned as a system administrator was, if it ain't broken, don't fix it. The message I'm getting from this thread, when people point out (correctly, as far as I know) that all the distributions are going for the latest greatest shiny thing, is that they're abandoning that mantra.
sysvinit was broken and couldn't do lots of things that modern distros wanted to do.
kevin
On 07/05/14 19:30, Tim wrote:
Allegedly, on or about 05 July 2014, Garry T. Williams sent:
http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd-for-admins-1.html
Fails to load, here, does it work for you? I even left the browser attempting it for a few minutes.
Nope, I doesn't work for me either.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/06/14 09:25, Kevin Fenzi wrote:
sysvinit was broken and couldn't do lots of things that modern distros wanted to do.
Yes, even Ubuntu is going to adopt it as their default. http://www.markshuttleworth.com/archives/1316
- -- If you can't laugh at yourself, others will gladly oblige.
Kevin Fenzi writes:
On Sat, 05 Jul 2014 18:10:45 -0700 David Benfell benfell@parts-unknown.org wrote:
Were you tying your services to specific IP addresses?
I have ten IP addresses, one for each of several domains and subdomains. At the time I made this decision, SNI didn't work, at least for me, and from what I can see, it still seems problematic.
I'm curious why this would have changed for you folks so recently. Was this a bug with systemd-208-19.fc20?
I believe so. It only appeared a few days ago. I hadn't been messing with any of this stuff, so at first I hoped it was just some weird one-off problem. The second time, well....
Which returns us back--and I hope I'm recalling the initial posting in this thread correctly--to the beginning of this thread. Do we really need this complexity for the sake of a few seconds?
No. We need it for all the other reasons.
Lennarts blog host seems to be having some problem, but from google cache:
http://webcache.googleusercontent.com/search?q=cache:rm-N94-I044J: 0pointer.de/blog/projects/why.html+&cd=1&hl=en&ct=clnk&gl=us
Theres tons and tons of things that systemd does well that there was no way to do in the sysvinit world.
What I see here is mostly stuff I don't understand. I got by just fine without it. So why, really, do I need it? That explanation appears to be missing--unless you just automatically choose the latest, greatest, shiny thing.
On 07/06/14 09:26, Mark LaPierre wrote:
On 07/05/14 19:30, Tim wrote:
Allegedly, on or about 05 July 2014, Garry T. Williams sent:
http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd-for-admins-1.html
Fails to load, here, does it work for you? I even left the browser attempting it for a few minutes.
Nope, I doesn't work for me either.
Both links downloaded for me. But, I had to wait maybe 5 minutes before they completed. Try again, just go out for some coffee. :-) :-)
Kevin Fenzi writes:
Lennarts blog host seems to be having some problem, but from google cache:
http://webcache.googleusercontent.com/search?q=cache:rm-N94-I044J: 0pointer.de/blog/projects/why.html+&cd=1&hl=en&ct=clnk&gl=us
Theres tons and tons of things that systemd does well that there was no way to do in the sysvinit world.
HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!
Sorry.
On Sat, 05 Jul 2014 18:40:42 -0700 David Benfell benfell@parts-unknown.org wrote:
Kevin Fenzi writes:
...snip...
No. We need it for all the other reasons.
Lennarts blog host seems to be having some problem, but from google cache:
http://webcache.googleusercontent.com/search?q=cache:rm-N94-I044J: 0pointer.de/blog/projects/why.html+&cd=1&hl=en&ct=clnk&gl=us
Theres tons and tons of things that systemd does well that there was no way to do in the sysvinit world.
What I see here is mostly stuff I don't understand. I got by just fine without it. So why, really, do I need it? That explanation appears to be missing--unless you just automatically choose the latest, greatest, shiny thing.
A few that I really appreciate:
If you did a 'service stop foobar' it would try and stop foobar, but if the pid file was stale, foobar started other stuff that wasn't tied to foobar as a parent, or any other of a number of situations I have run into, parts of foobar would still be running. With systemd, if you stop a unit, it's really stopped. All of it.
If you started a sysvinit service foobar and wanted to look at it's output, you had to hope the needed info was also in a log file or kill the service and restart it in some non standard mode to watch it's output. With systemd/journald, ALL output is saved and easy to query.
If for some reason you had to modify a complex sysvinit script, you then would have to merge in all changes with package updates over time. With systemd you can use a .d directory to add/change things without overwriting the provided systemd unit file.
Anyhow, sorry you don't like systemd...
kevin
On 07/06/14 09:47, Ed Greshko wrote:
On 07/06/14 09:26, Mark LaPierre wrote:
On 07/05/14 19:30, Tim wrote:
Allegedly, on or about 05 July 2014, Garry T. Williams sent:
http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd-for-admins-1.html
Fails to load, here, does it work for you? I even left the browser attempting it for a few minutes.
Nope, I doesn't work for me either.
Both links downloaded for me. But, I had to wait maybe 5 minutes before they completed. Try again, just go out for some coffee. :-) :-)
FWIW, this try took 10 minutes....
[egreshko@f20f point]$ date ; wget http://0pointer.de/blog/projects/systemd-for-admins-1.html ; date
Sun Jul 6 09:46:19 CST 2014 --2014-07-06 09:46:19-- http://0pointer.de/blog/projects/systemd-for-admins-1.html Resolving 0pointer.de (0pointer.de)... 85.214.72.216 Connecting to 0pointer.de (0pointer.de)|85.214.72.216|:80... connected. HTTP request sent, awaiting response... 200 OK <------Stuck here for a long time.... Length: 18349 (18K) [text/html] Saving to: ‘systemd-for-admins-1.html’
100%[========================================>] 18,349 27.3KB/s in 0.7s 2014-07-06 09:56:55 (27.3 KB/s) - ‘systemd-for-admins-1.html’ saved [18349/18349]
Sun Jul 6 09:56:55 CST 2014
On 7-6-14 00:58:23 Patrick O'Callaghan wrote:
To go back to the same example as before, the concept of "unit" seems to me not well-defined. The man page says a unit is an object,
systemd(1) states:
CONCEPTS systemd provides a dependency system between various entities called "units" of 12 different types. Units encapsulate various objects that are relevant for system boot-up and maintenance. The majority of units are configured in unit configuration files, whose syntax and basic set of options is described in systemd.unit(5), however some are created automatically from other configuration, dynamically from system state or programmatically at runtime. Units may be "active" (meaning started, bound, plugged in, ..., depending on the unit type, see below), or "inactive" (meaning stopped, unbound, unplugged, ...), as well as in the process of being activated or deactivated, i.e. between the two states (these states are called "activating", "deactivating"). A special "failed" state is available as well, which is very similar to "inactive" and is entered when the service failed in some way (process returned error code on exit, or crashed, or an operation timed out). If this state is entered, the cause will be logged, for later reference. Note that the various unit types may have a number of additional substates, which are mapped to the five generalized unit states described here.
but then it talks about various types of units, some of which are associated with events,
Perhaps you mean Timer units? Or maybe you mean Device units?
others with sets of processes,
Target units? Or maybe you mean just the common Service unit?
others with system states,
I cannot guess what you mean here?
while still others are recursively sets of other units.
Target.
This seems to me symptomatic of a lot of technical documentation, i.e. the author knows what he's talking about but doesn't appreciate the need to get the reader to understand it. At certain points I find myself wondering if he actually meant to say "objective" rather than "object",
The systemd(1) manual page uses the term "entity" -- not object to refer to units. And it says units encapsulate various objects. Perhaps this is the source of confusion?
but that wouldn't fit either. Since the concept of unit appears to be basic to understanding what systemd is all about, this is a serious deficiency IMHO.
Right after the paragraph I quoted above, the manual page lists the 12 unit types along with a short description of each one *and* a link to its own manual page.
The simple concrete example is a Service unit for a daemon. I wrote a daemon to work around a bug in the kernel that disabled my laptop's backlight control. I needed the daemon to start at boot and stop at shutdown. My unit file (encapsulating the requirements for my little daemon) is:
[Unit] Description = Enable Backlight Control
[Service] ExecStart = /usr/local/bin/backlight Restart = always
[Install] WantedBy = multi-user.target
This tells systemd what program to start and when it should be started. The declarative language for unit files is described in the manual pages and encompasses a rich set of operators to express complex dependencies. I needed only one: my daemon must be started whenever systemd determines that the multi-user Target is its objective. This corresponds to what we used to call system level 2. My standard Fedora 20 installation on my laptop defines graphical.target as the default.target. That is, my normal boot sequence is into the desktop. That target, in turn, Requires and is ordered After multi-user.target.
See systemd.service(5) and systemd.target(5).
One more step is required to actually get the daemon to start at boot- time: the unit has to be enabled. This just symlinks the unit file to the multi-user.target.wants directory. (See systemctl(1) for an explanation of enable versus start.) This may be what you referred to as units that "are recursively sets of other units."
The analogy is placing a script in /etc/init.d and then linking its name in the /etc/rc5.d directory. Until you create a link in the rc5.d directory, the script will not be executed during boot-up. With systemd, we don't have to *name* the symlink in a way to define the ordering we want. All of the dependencies are expressed in the unit files defining the units and systemd creates a run queue that respects these dependencies.
I find this much simpler than the sysvinit schemes. Plus, we now have the ability to declare dependencies instead of prescribe ordering. Of course my example is drop-dead simple in either world, but systemd allows way more expressive power than this example. The nice thing is, you don't have to write code (shell scripts) to get what you need.
You might want to examine sshd.service in /usr/lib/systemd/system to see a slightly more complex setup. (Ignore the deprecated After=syslog.target dependency.)
Yes, this is all very different from sysvinit. But the documentation is more than adequate.
On Sat, 5 Jul 2014 19:56:09 -0600 Kevin Fenzi wrote:
With systemd/journald, ALL output is saved and easy to query.
With journald all output is saved in a binary format file that is impossible to query when examining a crashed system because is is always corrupted (especially when there are systemd bugs causing the crash). 9 times out of 10, you won't be able to boot the system again unless you remove the corrupted journal file (and it only takes a couple of days of searching to discover that is the problem :-).
On Sat, 5 Jul 2014 22:10:40 -0400 Tom Horsley horsley1953@gmail.com wrote:
On Sat, 5 Jul 2014 19:56:09 -0600 Kevin Fenzi wrote:
With systemd/journald, ALL output is saved and easy to query.
With journald all output is saved in a binary format file that
(which is fully documented)
is impossible to query when examining a crashed system because is is always corrupted (especially when there are systemd bugs causing the crash). 9 times out of 10, you won't be able to boot the system again unless you remove the corrupted journal file (and it only takes a couple of days of searching to discover that is the problem :-).
Sorry to hear you ran into this.
I've run into one journald bug like that last year sometime in rawhide... but it was pretty quickly fixed and there was a workaround the same day I think.
kevin
Garry T. Williams writes:
On 7-5-14 22:07:17 Garry T. Williams wrote:
whenever systemd determines that the multi-user Target is its objective. This corresponds to what we used to call system level 2.
Heh. How quickly I forget. That should be *run* level *3*.
How quickly indeed. Run level 3 did not include a display manager. That was run level 5, at least on the variants I'm remembering (my very dim recollection is that Debian--I might be confused--did run levels differently, many moons ago). To my limited knowledge, systemd does not make that particular fine a grain of control possible (and, for my purposes, this doesn't matter).
From: Tom H https://lists.debian.org/debian-user/2014/07/msg00172.html Why are you trolling both the Debian and Fedora lists with this nonsense simultaneously? ...
Ref. [debian-user] why do we use systemd? https://lists.debian.org/debian-user/2014/07/msg00144.html
poma
On 07/05/2014 08:30 PM, Tom Horsley wrote:
On Sat, 05 Jul 2014 20:23:52 +0200 Timothy Murphy wrote:
Now the only thing I can moan about is the lack of chkconfig --list
systemctl --full list-unit-files | grep enabled
or grep .service, etc.
...
$ systemctl -t service list-unit-files | grep enabled
poma
On Sat, 2014-07-05 at 20:15 -0600, Kevin Fenzi wrote:
On Sat, 5 Jul 2014 22:10:40 -0400 Tom Horsley horsley1953@gmail.com wrote:
On Sat, 5 Jul 2014 19:56:09 -0600 Kevin Fenzi wrote:
With systemd/journald, ALL output is saved and easy to query.
With journald all output is saved in a binary format file that
(which is fully documented)
is impossible to query when examining a crashed system because is is always corrupted (especially when there are systemd bugs causing the crash). 9 times out of 10, you won't be able to boot the system again unless you remove the corrupted journal file (and it only takes a couple of days of searching to discover that is the problem :-).
Sorry to hear you ran into this.
I've run into one journald bug like that last year sometime in rawhide... but it was pretty quickly fixed and there was a workaround the same day I think.
kevin
but is it impossible to configure systemd to save logfile into text files instead of journal file? or we should have syslog service (i.e. rsyslog) for this
balint
On 07/05/2014 08:23 PM, Timothy Murphy wrote:
On Saturday, July 05, 2014 12:12:30 PM Kevin Fenzi wrote:
Additionally, since about f17, '.service' is assumed...
ie,
systemctl status foobar
is the same as
sysemctl status foobar.service
Again, many thanks - tested and verified.
Now the only thing I can moan about is the lack of chkconfig --list
Due to its complexity, do not expect too short directives like that. Instead utilize aliases, see Adrian's notes. By the way, what is 'chkconfig', anyway.
poma
On Sun, 2014-07-06 at 06:49 +0200, poma wrote:
From: Tom H https://lists.debian.org/debian-user/2014/07/msg00172.html Why are you trolling both the Debian and Fedora lists with this nonsense simultaneously? ...
Ref. [debian-user] why do we use systemd? https://lists.debian.org/debian-user/2014/07/msg00144.html
poma
because I use Debian and Fedora as well. I have to admin I wouldn't have to post the same mail in two mail list but I was upset 'a little bit' to systemd.
The only reason that I wanted to reach, make the system(s) better if we don't get rid of it.
Balint
On 07/06/2014 07:33 AM, Balint Szigeti wrote:
On Sun, 2014-07-06 at 06:49 +0200, poma wrote:
From: Tom H https://lists.debian.org/debian-user/2014/07/msg00172.html Why are you trolling both the Debian and Fedora lists with this nonsense simultaneously? ...
Ref. [debian-user] why do we use systemd? https://lists.debian.org/debian-user/2014/07/msg00144.html
poma
because I use Debian and Fedora as well. I have to admin I wouldn't have to post the same mail in two mail list but I was upset 'a little bit' to systemd.
The only reason that I wanted to reach, make the system(s) better if we don't get rid of it.
Balint
Whatever is troubling you, you can always seek advice at systemd Development Mailing List http://lists.freedesktop.org/mailman/listinfo/systemd-devel So, subscribe.
Life ain't gonna stop for anyone.
poma
"Garry T. Williams" gtwilliams@gmail.com writes:
The analogy is placing a script in /etc/init.d and then linking its name in the /etc/rc5.d directory.
I find this much simpler than the sysvinit schemes.
You have taken well over 100 lines to give a description about how to get a daemon started with systemd, not to mention the hours you must have spent reading all the documentation to figure out how to do what you wanted.
It took you only 2 lines to describe how to do the same thing with sysvinit.
I don't understand how you can find systemd "much simpler" than sysvinit. Where and how is it simpler than sysvinit? It takes only about 2% of the effort, if that much, to start a daemon with sysvinit than it takes to do the same with systemd.
For systemd, you even have to learn a whole new "programming language" to create configuration files which is useless anywhere else. Efficiency is negative here.
Kevin Fenzi kevin@scrye.com writes:
Is it an improvement over upstart/sysvinit? I would say absolutely so.
Where is the improvement? Systemd is extremely cryptic, complicated and obfuscating. Not even the configuration files are where they belong.
If it's true what's said on the links the OP provided, systemd should be removed immediately.
Tom Horsley horsley1953@gmail.com writes:
On Sat, 5 Jul 2014 19:56:09 -0600 Kevin Fenzi wrote:
With systemd/journald, ALL output is saved and easy to query.
With journald all output is saved in a binary format file that is impossible to query when examining a crashed system because is is always corrupted (especially when there are systemd bugs causing the crash). 9 times out of 10, you won't be able to boot the system again unless you remove the corrupted journal file (and it only takes a couple of days of searching to discover that is the problem :-).
Seriously? That alone puts systemd out of the question due to unreliability.
Kevin Fenzi kevin@scrye.com writes:
output. With systemd/journald, ALL output is saved and easy to query.
How do you query this output? I just look at the logfile, and when it's not there, I never see it. What's the advantage of hiding output like that?
Glenn Holmer shadowm@lyonlabs.org writes:
On 07/05/2014 06:21 PM, Tim wrote:
Allegedly, on or about 05 July 2014, Patrick O'Callaghan sent: The old system was considered bad, because it had 6 run levels, of which a few of them were never used. Now we have 12?
Twelve different types of *units*, of which service and target are two. A target is like a runlevel (it groups units together), except that more
Then systemd is broken by design. A shepherd is *not* a type of sheep.
This is really scary when I think of what other confusions the authors of systemd must suffer from when they come up with something like that. They don't even understand what "disabled" means.
And why would so many types of units be needed?
Timothy Murphy gayleard@alice.it writes:
Garry T. Williams wrote:
I know there are rare cases where one has to say something else, but why not make the default to add ".service" if nothing is given? Or perhaps TAB could complete it?
Have you actually tried a tab?
Mea colpa. It never occurred to me that this might actually be implemented - but now I find it reduces my usage time by 40%. Molto grazie.
It only works when you have autocompletion enabled, which I have disabled because it only gets in the way.
You don't need to type .service, though. It's much more difficult to remember what the exact name was, and it's complicated to look up a name ...
David Benfell benfell@parts-unknown.org writes:
Kevin Fenzi writes: pulseaudio, which I leave alone right up to the moment I have problems--any problems--with sound, and then eliminate as a usually successful first stab at a solution.
How do you eliminate pulseaudio on Fedora? It doesn't do anything but get in the way.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Sorry if this is top-posted...
I assume one would just uninstall the packages. But I haven't tried on Fedora as my Fedora box is a server on a rack located a long ways away. I don't use sound on it.
What I have occasionally seen with this operation is that one must also accept the removal of a meta-package. This is harmless.
On July 6, 2014 12:48:04 AM MST, lee lee@yun.yagibdah.de wrote:
David Benfell benfell@parts-unknown.org writes:
Kevin Fenzi writes: pulseaudio, which I leave alone right up to the moment I have problems--any problems--with sound, and then eliminate as a usually successful first stab at a solution.
How do you eliminate pulseaudio on Fedora? It doesn't do anything but get in the way.
-- Fedora release 20 (Heisenbug) -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
- -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I think mainly that you don't need logrotate. journald takes care of it automatically.
On July 6, 2014 12:52:24 AM MST, lee lee@yun.yagibdah.de wrote:
Kevin Fenzi kevin@scrye.com writes:
output. With systemd/journald, ALL output is saved and easy to query.
How do you query this output? I just look at the logfile, and when it's not there, I never see it. What's the advantage of hiding output like that?
-- Fedora release 20 (Heisenbug) -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
- -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Sunday, July 06, 2014 07:29:38 AM poma wrote:
By the way, what is 'chkconfig', anyway.
It sets or lists services in the old system, eg "chkconfig crond on" or "chkconfig --list".
Kevin Fenzi wrote:
Theres tons and tons of things that systemd does well that there was no way to do in the sysvinit world.
...
sysvinit was broken and couldn't do lots of things that modern distros wanted to do.
When people say "There are lots of ..." I always think "Why don't you just tell me one, the one you think is most important".
Allegedly, on or about 06 July 2014, Ed Greshko sent:
Both links downloaded for me. But, I had to wait maybe 5 minutes before they completed. Try again, just go out for some coffee. :-) :-)
Can't be stuffed having it waste my time to that degree. The site is a failure.
On 07/06/14 19:05, Tim wrote:
Allegedly, on or about 06 July 2014, Ed Greshko sent:
Both links downloaded for me. But, I had to wait maybe 5 minutes before they completed. Try again, just go out for some coffee. :-) :-)
Can't be stuffed having it waste my time to that degree. The site is a failure.
OK... Then
https://web.archive.org/web/20140630154456/http://0pointer.de/blog/projects/... https://web.archive.org/web/20140603153419/http://0pointer.de/blog/projects/...
For your comfort.
On Sat, 2014-07-05 at 22:07 -0400, Garry T. Williams wrote:
The systemd(1) manual page uses the term "entity" -- not object to refer to units. And it says units encapsulate various objects. Perhaps this is the source of confusion?
The word "entity" is not used anywhere in the systemd(1) man page. The plural "entities" is used exactly once, in the phrase "systemd provides a dependency system between various entities called "units" of 12 different types". So apparently entity==unit.
The term "object" is used twice. Once is in reference to "file system objects" which I assume has the usual meaning. The other is in "Units encapsulate various objects that are relevant for system boot-up and maintenance".
So to sum up: systemd manages dependency relations between entities called units. Units encapsulate objects in 12 different ways. Objects are <insert hand-waving here>
I repeat that I am not attacking systemd here, I'm criticizing the way it's described. It may seem perfectly clear to those who already understand it, but it's not at all clear to those who are used to something different.
poc
On 06.07.2014 15:21, Patrick O'Callaghan wrote:
On Sat, 2014-07-05 at 22:07 -0400, Garry T. Williams wrote:
The systemd(1) manual page uses the term "entity" -- not object to refer to units. And it says units encapsulate various objects. Perhaps this is the source of confusion?
The word "entity" is not used anywhere in the systemd(1) man page. The plural "entities" is used exactly once, in the phrase "systemd provides a dependency system between various entities called "units" of 12 different types". So apparently entity==unit.
The term "object" is used twice. Once is in reference to "file system objects" which I assume has the usual meaning. The other is in "Units encapsulate various objects that are relevant for system boot-up and maintenance".
So to sum up: systemd manages dependency relations between entities called units. Units encapsulate objects in 12 different ways. Objects are <insert hand-waving here>
I repeat that I am not attacking systemd here, I'm criticizing the way it's described. It may seem perfectly clear to those who already understand it, but it's not at all clear to those who are used to something different.
poc
You can propose your terminology.
poma
On 07/06/2014 03:53 AM, lee wrote:
Glenn Holmer shadowm@lyonlabs.org writes:
On 07/05/2014 06:21 PM, Tim wrote:
Allegedly, on or about 05 July 2014, Patrick O'Callaghan sent: The old system was considered bad, because it had 6 run levels, of which a few of them were never used. Now we have 12?
Twelve different types of *units*, of which service and target are two. A target is like a runlevel (it groups units together), except that more
Then systemd is broken by design. A shepherd is *not* a type of sheep.
systemd is broken because you don't like the terms it uses? Really? "Target" makes perfect sense: to reach a certain target, enable the units in its list.
And why would so many types of units be needed?
http://www.lyonlabs.org/just-rtfm.jpg
On Sat, Jul 05, 2014 at 09:34:32PM -0700, David Benfell wrote:
Garry T. Williams writes:
On 7-5-14 22:07:17 Garry T. Williams wrote:
whenever systemd determines that the multi-user Target is its objective. This corresponds to what we used to call system level 2.
Heh. How quickly I forget. That should be *run* level *3*.
How quickly indeed. Run level 3 did not include a display manager. That was run level 5, at least on the variants I'm remembering (my very dim recollection is that Debian--I might be confused--did run levels differently, many moons ago). To my limited knowledge, systemd does not make that particular fine a grain of control possible (and, for my purposes, this doesn't matter).
I think systemd allows for this.
3 → multi-user target 5 → graphical target
FWIW, I think systemd documentation is quite extensive, but definitely not for regular people. It is documentation written by developers for other developers.
On 06.07.2014 16:04, Suvayu Ali wrote:
On Sat, Jul 05, 2014 at 09:34:32PM -0700, David Benfell wrote:
Garry T. Williams writes:
On 7-5-14 22:07:17 Garry T. Williams wrote:
whenever systemd determines that the multi-user Target is its objective. This corresponds to what we used to call system level 2.
Heh. How quickly I forget. That should be *run* level *3*.
How quickly indeed. Run level 3 did not include a display manager. That was run level 5, at least on the variants I'm remembering (my very dim recollection is that Debian--I might be confused--did run levels differently, many moons ago). To my limited knowledge, systemd does not make that particular fine a grain of control possible (and, for my purposes, this doesn't matter).
I think systemd allows for this.
3 → multi-user target 5 → graphical target
FWIW, I think systemd documentation is quite extensive, but definitely not for regular people. It is documentation written by developers for other developers.
Your interpretation is quite narrow. What about admins, enthusiasts and all those who avere sale in zucca.
poma
On Sun, 2014-07-06 at 15:32 +0200, poma wrote:
I repeat that I am not attacking systemd here, I'm criticizing the
way
it's described. It may seem perfectly clear to those who already understand it, but it's not at all clear to those who are used to something different.
poc
You can propose your terminology.
To do that I would first have to understand it.
poc
On Sun, 06 Jul 2014 06:27:17 +0100 Balint Szigeti balint.szgt@gmail.com wrote:
but is it impossible to configure systemd to save logfile into text files instead of journal file? or we should have syslog service (i.e. rsyslog) for this
yes, you can run rsyslog and gateway all the messages to it.
kevin
On Sun, 06 Jul 2014 09:52:24 +0200 lee lee@yun.yagibdah.de wrote:
Kevin Fenzi kevin@scrye.com writes:
output. With systemd/journald, ALL output is saved and easy to query.
How do you query this output? I just look at the logfile, and when it's not there, I never see it. What's the advantage of hiding output like that?
journalctl -u servicename
(I usually add -b which gives you messages only since last boot).
kevin
On Sun, 06 Jul 2014 09:48:04 +0200 lee lee@yun.yagibdah.de wrote:
David Benfell benfell@parts-unknown.org writes:
Kevin Fenzi writes: pulseaudio, which I leave alone right up to the moment I have problems--any problems--with sound, and then eliminate as a usually successful first stab at a solution.
Pretty please fix your quoting. I did not say this. ;)
How do you eliminate pulseaudio on Fedora? It doesn't do anything but get in the way.
yum remove alsa-plugins-pulseaudio
used to do it. It would still be installed, but not loaded/used.
kevin
On Sun, Jul 06, 2014 at 04:16:35PM +0200, poma wrote:
On 06.07.2014 16:04, Suvayu Ali wrote:
On Sat, Jul 05, 2014 at 09:34:32PM -0700, David Benfell wrote:
Garry T. Williams writes:
On 7-5-14 22:07:17 Garry T. Williams wrote:
whenever systemd determines that the multi-user Target is its objective. This corresponds to what we used to call system level 2.
Heh. How quickly I forget. That should be *run* level *3*.
How quickly indeed. Run level 3 did not include a display manager. That was run level 5, at least on the variants I'm remembering (my very dim recollection is that Debian--I might be confused--did run levels differently, many moons ago). To my limited knowledge, systemd does not make that particular fine a grain of control possible (and, for my purposes, this doesn't matter).
I think systemd allows for this.
3 → multi-user target 5 → graphical target
FWIW, I think systemd documentation is quite extensive, but definitely not for regular people. It is documentation written by developers for other developers.
Your interpretation is quite narrow. What about admins, enthusiasts and all those who avere sale in zucca.
Actually by regular user I meant anyone who is not a developer. I am myself an enthusiast/admin(for my home systems), and I find systemd docs very hard to follow.
On Sun, 6 Jul 2014 18:37:03 +0200 Suvayu Ali wrote:
Actually by regular user I meant anyone who is not a developer. I am myself an enthusiast/admin(for my home systems), and I find systemd docs very hard to follow.
Me too, but every time I need to spend an hour discovering some systemd feature, I add it to my notes, so eventually most of the things I need to do all the time will be in a much smaller document :-).
On Sun, 6 Jul 2014, Patrick O'Callaghan wrote:
I'm an old Unix hand so for me the man page *is* the reference in most cases, though for something as large and complex as systemd I have no issue with there being supplementary material as long as I don't need to access it just to remember a basic command. In fact I get annoyed at many of the desktop tools which don't have a proper man page because they expect you to reach for a browser or one of the lame built-in help tools. However that's another story.
If it has a GUI, it doesn't need documentation. Didn't you know that.
Kevin Fenzi kevin@scrye.com writes:
On Sun, 06 Jul 2014 09:52:24 +0200 lee lee@yun.yagibdah.de wrote:
Kevin Fenzi kevin@scrye.com writes:
output. With systemd/journald, ALL output is saved and easy to query.
How do you query this output? I just look at the logfile, and when it's not there, I never see it. What's the advantage of hiding output like that?
journalctl -u servicename
(I usually add -b which gives you messages only since last boot).
That doesn't make sense. What if you're trying to solve a problem, suspecting a particular service, and the problem is somewhere else? You'd never see the relevant messages because they remain hidden.
You'd have to browse all messages, and an ordinary logfile is perfectly suited for that. What's the advantage of using an unreadable format and added complexity supposed to be?
Joe Zeff joe@zeff.us writes:
On 07/06/2014 12:43 AM, lee wrote:
Not even the configuration files are where they belong.
Actually, they're exactly where they belong. They just aren't where you expect them to be.
They belong under /etc, not hidden somewhere in /var.
Patrick O'Callaghan pocallaghan@gmail.com writes:
On Sat, 2014-07-05 at 22:07 -0400, Garry T. Williams wrote:
The systemd(1) manual page uses the term "entity" -- not object to refer to units. And it says units encapsulate various objects. Perhaps this is the source of confusion?
The word "entity" is not used anywhere in the systemd(1) man page. The plural "entities" is used exactly once, in the phrase "systemd provides a dependency system between various entities called "units" of 12 different types". So apparently entity==unit.
There could be other entities somewhere that aren't units and aren't mentioned in the man page. Or perhaps they are but aren't called that.
However, according to [1], "entity" is a synonym for "unit". So what exactly does the quoted sentence from the man page try to explain?
[1]: http://thesaurus.com/browse/unit
The term "object" is used twice. Once is in reference to "file system objects" which I assume has the usual meaning. The other is in "Units encapsulate various objects that are relevant for system boot-up and maintenance".
So to sum up: systemd manages dependency relations between entities called units. Units encapsulate objects in 12 different ways. Objects are <insert hand-waving here>
It's much simpler: "systemd provides a dependency system between <insert hand-waving here> which are/is encapsulated in 12 different types".
So what does it actually do?
And I can only guess that it's called "systemd" because it provides a "system" and is a daemon. But is it a daemon? Looking at [2], it is not because it's controlled by a user (through systemctl and journalsomething and perhaps other things I don't know about).
Actually, it's more like an MCP, if you've seen Tron.
[2]: https://en.wikipedia.org/wiki/Daemon_(computing)
I repeat that I am not attacking systemd here, I'm criticizing the way it's described. It may seem perfectly clear to those who already understand it, but it's not at all clear to those who are used to something different.
The documentation is just badly written. What do you expect when "disabled" means something like "not so much enabled" and "mask" means "disabled"? I made a bug report about that, and they decline to even fix a simple thing like that.
Kevin Fenzi kevin@scrye.com writes:
On Sun, 06 Jul 2014 09:48:04 +0200 lee lee@yun.yagibdah.de wrote:
David Benfell benfell@parts-unknown.org writes:
Kevin Fenzi writes: pulseaudio, which I leave alone right up to the moment I have problems--any problems--with sound, and then eliminate as a usually successful first stab at a solution.
Pretty please fix your quoting. I did not say this. ;)
Sorry, I should have deleted that line.
How do you eliminate pulseaudio on Fedora? It doesn't do anything but get in the way.
yum remove alsa-plugins-pulseaudio
used to do it. It would still be installed, but not loaded/used.
Hm, yes, I could actually remove it without removing anything else, thank you! Finally!
Now I even have hardware mixing and no stupid pulseaudio wasting CPU and resources for nothing :))
Just would I remove pulseaudio altogether?
Glenn Holmer shadowm@lyonlabs.org writes:
On 07/06/2014 03:53 AM, lee wrote:
Glenn Holmer shadowm@lyonlabs.org writes:
On 07/05/2014 06:21 PM, Tim wrote:
Allegedly, on or about 05 July 2014, Patrick O'Callaghan sent: The old system was considered bad, because it had 6 run levels, of which a few of them were never used. Now we have 12?
Twelve different types of *units*, of which service and target are two. A target is like a runlevel (it groups units together), except that more
Then systemd is broken by design. A shepherd is *not* a type of sheep.
systemd is broken because you don't like the terms it uses? Really?
It is not true that a shepherd is a type of sheep. Wrong usage of terms --- or call it flawed logic --- is by design, meaning it's broken by design, regardless whether I like it or not.
"Target" makes perfect sense: to reach a certain target, enable the units in its list.
A target is not a unit then.
And why would so many types of units be needed?
I don't want to read the documentation. Some of it was quoted here in a posting, and that piece was badly written and confusing.
On Sun, 06 Jul 2014 18:18:46 +0200 lee lee@yun.yagibdah.de wrote:
Kevin Fenzi kevin@scrye.com writes:
On Sun, 06 Jul 2014 09:52:24 +0200 lee lee@yun.yagibdah.de wrote:
Kevin Fenzi kevin@scrye.com writes:
output. With systemd/journald, ALL output is saved and easy to query.
How do you query this output? I just look at the logfile, and when it's not there, I never see it. What's the advantage of hiding output like that?
journalctl -u servicename
(I usually add -b which gives you messages only since last boot).
That doesn't make sense. What if you're trying to solve a problem, suspecting a particular service, and the problem is somewhere else? You'd never see the relevant messages because they remain hidden.
journalctl | grep whatever
or
journalctl | less
and page though things?
You'd have to browse all messages, and an ordinary logfile is perfectly suited for that. What's the advantage of using an unreadable format and added complexity supposed to be?
It lets you do things like easily grep the messages from just the last boot, or isolate things from particular services, export it in other formats, lets you easily log from containers or user space items.
Anyhow, it sounds like you are pretty firmly set in your dislike for systemd/journald. Not sure continued discussion will change your mind any...
kevin
On 06/07/14 18:44, lee wrote:
Kevin Fenzi kevin@scrye.com writes:
[...]
yum remove alsa-plugins-pulseaudio
used to do it. It would still be installed, but not loaded/used.
Hm, yes, I could actually remove it without removing anything else, thank you! Finally!
Now I even have hardware mixing and no stupid pulseaudio wasting CPU and resources for nothing :))
Just would I remove pulseaudio altogether?
Removing the alsa-plugins-pulseaudio package and editing /etc/pulse/client.conf and adding a line: autospawn = no
so that the pulseaudio daemon doesn't get started (I have to this with GNOME3 otherwise gnome-shell will start pulseaudio).
Or just uninstall the pulseaudio package. Note that you can't remove some of the pulseaudio library packages (pulseaudio-libs and pulseaudio-libs-glib2) because some packages directly link against those libs.
On Sun, 6 Jul 2014, lee wrote:
Joe Zeff joe@zeff.us writes:
On 07/06/2014 12:43 AM, lee wrote:
Not even the configuration files are where they belong.
Actually, they're exactly where they belong. They just aren't where you expect them to be.
They belong under /etc, not hidden somewhere in /var.
Configuration files under /var ? Wow.
From The LInux Doucmentation Project,
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/var.html :
1.18. /var
Contains *variable* data like system logging files, mail and printer spool directories, and transient and temporary files.
*Emphasis* mine.
On Sun, 6 Jul 2014 13:25:42 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Sun, 6 Jul 2014, lee wrote:
Joe Zeff joe@zeff.us writes:
On 07/06/2014 12:43 AM, lee wrote:
Not even the configuration files are where they belong.
Actually, they're exactly where they belong. They just aren't where you expect them to be.
They belong under /etc, not hidden somewhere in /var.
Configuration files under /var ? Wow.
...snip...
What systemd config files are under /var?
kevin
Patrick O'Callaghan writes:
The term "object" is used twice. Once is in reference to "file system objects" which I assume has the usual meaning. The other is in "Units encapsulate various objects that are relevant for system boot-up and maintenance".
Sorry, even your attempt to parse this (and it's a valiant effort) yields what, for me, is gobbledygook. And yes, this is one of the things that makes me unhappy with systemd.
*What*, for example, is "the usual meaning" of "file system objects?" A file? Why not just say "file?" And if the documentation really means files or pipes or devices, then why not say "files or pipes or devices?"
This kind of verbiage simply adds an additional layer of abstraction that removes the text ever farther from whatever it's talking about and reduces comprehensibility.
poma writes:
You can propose your terminology.
You're asking him to do Poettering's technical writing when he isn't even sure he understands Poettering correctly.
Not only is that an imposition, it's an unfair one.
Glenn Holmer writes:
systemd is broken because you don't like the terms it uses? Really? "Target" makes perfect sense: to reach a certain target, enable the units in its list.
This kind of argumentation does not help the case for systemd.
'Broken' might be the wrong word. But if the documentation is impenetrable, in which case your following snark only adds insult to injury, then yes, systemd is unusable.
This is what is known as intellectual bullying. It excuses you from having to explain by blaming the other fellow for not understanding.
On 07/06/2014 01:01 PM, David Benfell wrote:
*What*, for example, is "the usual meaning" of "file system objects?" A file? Why not just say "file?" And if the documentation really means files or pipes or devices, then why not say "files or pipes or devices?"
I'm only guessing, but it looks to me like the documentation was written by developers with poor writing skills, and approved by other developers who knew what the first ones meant. At no time was anybody consulted who didn't already understand the subject matter completely. One wonders what would happen if somebody would open a bugzilla on the man page claiming that it's impossible to understand, especially if there were a number of comments by other "mere users" complaining about the exact same thing.
Kevin Fenzi writes:
How do you query this output? I just look at the logfile, and when it's not there, I never see it. What's the advantage of hiding output like that?
journalctl -u servicename
In all the times I've looked at the man pages for journalctl, I've never noticed this. Instead all I've ever found is some other weirdness about _SYSTEMD_UNIT= (I think, but don't actually remember) which I can never even hope to remember.
Looking at the man page, *now* that you point it out, I see the option. Buried among so much other unintelligible material.
Poettering reminds me of a teenager who thinks the world would be perfect if everybody just did things his (gender-biased language *might* be appropriate here) way. The difference is that distributions are giving Poettering his way.
And in the process, they're tossing out all the well-established ways of doing things. And users are supposed to learn and understand incomprehensible material at the same time they're trying to fix something.
Systemd needs to be a vast improvement to justify this. And it seems that not everyone even agrees that it's an improvement at all.
I really prefer using grep and less on a plain text log file that gets rotated so it is of manageable length. It's simple. It works. It's reliable. Which is just what I need when something is broken.
On Sun, 06 Jul 2014 13:22:56 -0700 Joe Zeff wrote:
One wonders what would happen if somebody would open a bugzilla on the man page claiming that it's impossible to understand, especially if there were a number of comments by other "mere users" complaining about the exact same thing.
Why do you wonder? It would be immediately closed as "too vague" and not documenting a specific error, perhaps with an additional comment about "patches welcome".
In other words, the exact same treatment as bugzillas about disk partitioning in the new anaconda being impossible to understand :-).
On Sun, Jul 06, 2014 at 04:34:35PM -0400, Tom Horsley wrote:
On Sun, 06 Jul 2014 13:22:56 -0700 Joe Zeff wrote:
One wonders what would happen if somebody would open a bugzilla on the man page claiming that it's impossible to understand, especially if there were a number of comments by other "mere users" complaining about the exact same thing.
Why do you wonder? It would be immediately closed as "too vague" and not documenting a specific error, perhaps with an additional comment about "patches welcome".
File a bug upstream (with systemd) please. Better to file a bug than to assume people will behave badly.
On Sun, Jul 06, 2014 at 01:34:24PM -0700, David Benfell wrote:
Poettering reminds me of a teenager who thinks the world would be perfect if everybody just did things his (gender-biased language *might* be appropriate here) way. The difference is that distributions are giving Poettering his way.
Please take this stuff off list. Psycho analysing another Fedora user and developer is inappropriate. It doesn't belong here, please refrain from posting such stuff.
Kevin Fenzi writes:
journalctl | grep whatever
or
journalctl | less
and page though things?
In my experience, this is really, really slow. To make it reasonably responsive you have to tune the journal accumulation so tightly that you are pretty much sacrificing any history at all.
On 07/06/2014 01:34 PM, Tom Horsley wrote:
Why do you wonder? It would be immediately closed as "too vague" and not documenting a specific error, perhaps with an additional comment about "patches welcome".
So open a bugzilla listing specific problems with the man page, such as using terms that are never defined. (Listing the terms you're objecting to would be a Good Idea.) Explain in the initial report that you'd be willing to update the page, but (surprise, surprise) don't understand what it's trying to say well enough to re-write it.
Olav Vitters writes:
On Sun, Jul 06, 2014 at 01:34:24PM -0700, David Benfell wrote:
Poettering reminds me of a teenager who thinks the world would be perfect if everybody just did things his (gender-biased language *might* be appropriate here) way. The difference is that distributions are giving Poettering his way.
Please take this stuff off list. Psycho analysing another Fedora user and developer is inappropriate. It doesn't belong here, please refrain from posting such stuff.
If Mr. Poettering objects to such analysis, he should stop performing it on those who disagree with him.
And I do not see your authority to make such a request. Which says something about your own psychological condition.
David Benfell writes:
Systemd needs to be a vast improvement to justify this. And it seems that not everyone even agrees that it's an improvement at all.
Here's something that I can't figure out: with this entire thread in mind, why is all of this is being said /now/???
What happened?
I can understand reading stuff like this if systemd was new to Fedora 20. But it's not. It's been here for how many releases now? I forget (intentionally).
I remember when, as soon as systemd arrived at the debutante ball, it was painfully obvious to me what a horrible abomination it was. I distinctly recall bitching about it immediately, but my voice was just one of a few.
This flame war is, what, two years too late?
As soon as I saw that PID 1 is no longer only:
1) reaping orphan zombies, and
2) somehow recording, in some way, the current system run level, in some kind of a fashion, and, in response to an external command to change the run level, update the official scoreboard, and kick off some external process to have it take effect
As soon as I saw all sorts of things that PID 1 was going to be doing now, all the BS alarms started honking like crazy. Holyfrakingcrap, what in blazes is this monster doing, now? Who in their right mind would write init, PID 1, this way?
All the complaints I'm reading now – incomprehensible documentation, inaccessible and corruptible-by-design log files, confusing configuration – and all that jazz, all of these complaints can really be distilled down to one, fundamental problem: an utter lack of understanding of how things should work. What PID 1 should be doing, and what it should be doing. And how other parts of the system should work. All the other fallout flows from this root (pardon the pun) problem: not knowing what the frak you're doing, here.
sysinit's replacement could've certainly had functionality comparable to what systemd provides. But, four-plus decades of Unix, Posix, and Linux expererience mandates that a proper design for something like that would be completely different than the massive, monolithic state machine of a hairball that systemd turned out to be. systemd is exactly the opposite of how something like systemd should've been designed. You couldn't get these results more 180 degrees out of phase.
But all of this should've been obvious several years ago, not now. I just wish there was this hue and cry while there was still a chance to stop this disaster in its tracks.
Oh, well.
On Sun, 6 Jul 2014, Kevin Fenzi wrote:
On Sun, 6 Jul 2014 13:25:42 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Sun, 6 Jul 2014, lee wrote:
Joe Zeff joe@zeff.us writes:
On 07/06/2014 12:43 AM, lee wrote:
Not even the configuration files are where they belong.
Actually, they're exactly where they belong. They just aren't where you expect them to be.
They belong under /etc, not hidden somewhere in /var.
Configuration files under /var ? Wow.
...snip...
What systemd config files are under /var?
I don't know. I thought lee did.
Sam Varshavchik writes:
David Benfell writes:
Systemd needs to be a vast improvement to justify this. And it seems that not everyone even agrees that it's an improvement at all.
Here's something that I can't figure out: with this entire thread in mind, why is all of this is being said /now/???
What happened?
I can understand reading stuff like this if systemd was new to Fedora 20. But it's not. It's been here for how many releases now? I forget (intentionally).
I remember when, as soon as systemd arrived at the debutante ball, it was painfully obvious to me what a horrible abomination it was. I distinctly recall bitching about it immediately, but my voice was just one of a few.
This flame war is, what, two years too late?
I haven't been on Fedora for two years, so I can't speak to that. But your voice was not alone. You should have seen the imbroglio on the Arch Users list.
If memory serves, the operators actually shut down that list for a day or two to allow tempers to cool down.
And I might add that at that time, I was inclined to view systemd somewhat more favorably than I do now.
On 07/06/2014 03:16 PM, David Benfell wrote:
This is what is known as intellectual bullying. It excuses you from having to explain by blaming the other fellow for not understanding.
Did you read my original reply (to Tim) where I tried to explain it and included links? That's about how I described it when I gave a systemd presentation for my local Linux users group.
But when someone replies to that by saying that systemd is broken because "a shepherd is not a sheep", well... that's just splitting grammatical hairs to try and prove that the documentation is obtuse. The cartoon is appropriate; it describes people who have a knee-jerk reaction instead of taking the time to read what others have written about systemd (as you evidently have; I've been following your networking posts with interest). And for those who find the official documentation too difficult, there are plenty of blogs and articles out there that explain it more plainly. I know, I had to dig through them to do that presentation. And by the way, the preso included that cartoon... which got a big laugh.
Michael Hennebry writes:
On Sun, 6 Jul 2014, Kevin Fenzi wrote:
What systemd config files are under /var?
I don't know. I thought lee did.
Poking around the only thing I see here is /var/service, which I'm not even sure is systemd, but which, at least on Fedora, is a symbolic link back into /etc. I've never paid enough attention to the file hierarchy standard to be able to say what is appropriate here.
On Sun, Jul 06, 2014 at 02:23:44PM -0700, David Benfell wrote:
Olav Vitters writes:
On Sun, Jul 06, 2014 at 01:34:24PM -0700, David Benfell wrote:
Poettering reminds me of a teenager who thinks the world would be perfect if everybody just did things his (gender-biased language *might* be appropriate here) way. The difference is that distributions are giving Poettering his way.
Please take this stuff off list. Psycho analysing another Fedora user and developer is inappropriate. It doesn't belong here, please refrain from posting such stuff.
If Mr. Poettering objects to such analysis, he should stop performing it on those who disagree with him.
Bullshit, he hasn't done anything to you personally. There is no reason to behave like you're doing here.
And I do not see your authority to make such a request. Which says something about your own psychological condition.
I'm asking nicely, why respond like this?
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
There's your authority.
On Sun, 2014-07-06 at 12:49 -0400, Tom Horsley wrote:
On Sun, 6 Jul 2014 18:37:03 +0200 Suvayu Ali wrote:
Actually by regular user I meant anyone who is not a developer. I am myself an enthusiast/admin(for my home systems), and I find systemd docs very hard to follow.
Me too, but every time I need to spend an hour discovering some systemd feature, I add it to my notes, so eventually most of the things I need to do all the time will be in a much smaller document :-).
Perhaps you can do us all a favour and publish your notes :-)
poc
On Sun, 2014-07-06 at 13:01 -0700, David Benfell wrote:
*What*, for example, is "the usual meaning" of "file system objects?" A file? Why not just say "file?" And if the documentation really means files or pipes or devices, then why not say "files or pipes or devices?"
I assume it means "something with a name in the filesystem".
poc
On Sun, 2014-07-06 at 13:22 -0700, Joe Zeff wrote:
I'm only guessing, but it looks to me like the documentation was written by developers with poor writing skills, and approved by other developers who knew what the first ones meant.
I guess that's what I was trying to say, so +1
poc
On Sun, 06 Jul 2014 23:28:22 +0100 Patrick O'Callaghan wrote:
Perhaps you can do us all a favour and publish your notes :-)
I'm sure they are just as cryptic as everything else, but they are cryptic in a way I can understand :-). It would also be hard to separate out just the systemd stuff.
On Sun, 2014-07-06 at 16:48 -0500, Glenn Holmer wrote:
And for those who find the official documentation too difficult, there are plenty of blogs and articles out there that explain it more plainly. I know, I had to dig through them to do that presentation.
So could you explain to us again why you think the official documentation is good?
poc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On July 6, 2014 3:16:43 PM PDT, Olav Vitters olav@vitters.nl wrote:
On Sun, Jul 06, 2014 at 02:23:44PM -0700, David Benfell wrote:
Olav Vitters writes:
On Sun, Jul 06, 2014 at 01:34:24PM -0700, David Benfell wrote:
Poettering reminds me of a teenager who thinks the world would be perfect if everybody just did things his (gender-biased language *might* be appropriate here) way. The difference is that distributions are giving Poettering his way.
Please take this stuff off list. Psycho analysing another Fedora
user
and developer is inappropriate. It doesn't belong here, please
refrain
from posting such stuff.
If Mr. Poettering objects to such analysis, he should stop performing it on those who disagree with him.
Bullshit, he hasn't done anything to you personally. There is no reason to behave like you're doing here.
And I do not see your authority to make such a request. Which says something about your own psychological condition.
I'm asking nicely, why respond like this?
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
There's your authority.
-- Regards, Olav -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
So in your view, I have no right to object to his behavior but you have a right to object to my objection?
Something ain't right there. - -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 07/07/14 11:24, David Benfell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On July 6, 2014 3:16:43 PM PDT, Olav Vitters olav@vitters.nl wrote:
On Sun, Jul 06, 2014 at 02:23:44PM -0700, David Benfell wrote:
Olav Vitters writes:
On Sun, Jul 06, 2014 at 01:34:24PM -0700, David Benfell wrote:
Poettering reminds me of a teenager who thinks the world would be perfect if everybody just did things his (gender-biased language *might* be appropriate here) way. The difference is that distributions are giving Poettering his way.
Please take this stuff off list. Psycho analysing another Fedora
user
and developer is inappropriate. It doesn't belong here, please
refrain
from posting such stuff.
If Mr. Poettering objects to such analysis, he should stop performing it on those who disagree with him.
Bullshit, he hasn't done anything to you personally. There is no reason to behave like you're doing here.
And I do not see your authority to make such a request. Which says something about your own psychological condition.
I'm asking nicely, why respond like this?
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
There's your authority.
-- Regards, Olav -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
So in your view, I have no right to object to his behavior but you have a right to object to my objection?
Something ain't right there.
The difference is that Olav is polite and you are abusive.
cheers,
Rolf Turner
On 7-6-14 10:39:11 lee wrote:
"Garry T. Williams" gtwilliams@gmail.com writes:
The analogy is placing a script in /etc/init.d and then linking its name in the /etc/rc5.d directory.
I find this much simpler than the sysvinit schemes.
You have taken well over 100 lines to give a description about how to get a daemon started with systemd, not to mention the hours you must have spent reading all the documentation to figure out how to do what you wanted.
Of course, my message was an attempt to explain what a Unit is to Patrick. The bulk of my reply was not describing how to get a daemon started with systemd.
As to the hours of reading, well, yes. systemd was new when I first encountered it. How else could I learn how it works without actually reading the documentation?
It took you only 2 lines to describe how to do the same thing with sysvinit.
Yes.
But have you looked at the sysvinit script to compare it to the Service unit that accomplishes the same thing? Here's an example:
http://0pointer.de/public/abrtd
The point is that there is lots of boilerplate in every sysvinit script to do the simplest task. The systemd Service unit corresponding to the abrt init script is way simpler. And it can accomplish stuff the bare script cannot, like automatic restart upon failure.
This might help in comparing the two:
http://0pointer.de/blog/projects/systemd-for-admins-3.html
I don't understand how you can find systemd "much simpler" than sysvinit. Where and how is it simpler than sysvinit? It takes only about 2% of the effort, if that much, to start a daemon with sysvinit than it takes to do the same with systemd.
For systemd, you even have to learn a whole new "programming language" to create configuration files which is useless anywhere else. Efficiency is negative here.
Reading the documentation, I know that the unit files do not contain *any* "programming language". They are declarative. That was very intensional in systemd's design. Indeed, there have been many discussions and patches submitted to add that very thing to the unit files on the systemd development mailing list. These have been uniformly rejected because of this basic design.
Yes, you do have to read and understand the documentation to successfully use systemd. I'll leave it to others to comment on the usefulness of a Unit file outside of Fedora.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/07/14 07:24, David Benfell wrote:
So in your view, I have no right to object to his behavior but you have a right to object to my objection?
Something ain't right there.
Usually, 99% of the time?, objections to a person's behavior is a direct result of exchanges on this list. I can't recall another instance where someone has taken issue with another who isn't on the list to defend himself.
- -- If you can't laugh at yourself, others will gladly oblige.
On 7-6-14 14:21:05 Patrick O'Callaghan wrote:
different types". So apparently entity==unit.
No, the manual page clearly states that a Unit *is a* entity. That is not an identity relationship. Think class and subclass.
I was just trying to find the cause of the confusion.
Actually, I am done now. There are a slew of references on the 'Net if you do not want to read the manual pages or if you find them hard to understand.
Bill Oliver writes:
On Sun, 6 Jul 2014, David Benfell wrote:
So in your view, I have no right to object to his behavior but you have a right to object to my objection?
Something ain't right there.
Some things are above criticism. It's important that you know your place.
;-)
Rolf Turner writes:
The difference is that Olav is polite and you are abusive.
If you regard what I say as abusive, then you should, perhaps, be challenging this entire thread, which impugns the motivations, not only of Mr. Poettering, not only of the Fedora development team, but of every distribution that has adopted his work.
Adolescent behavior is adolescent behavior, Mr. Poettering richly deserves the accusation, and what I'm seeing here is not so much a protest against abuse as a cliquish attempt at control.
To which I can only say, get over it. It's not healthy.
Ed Greshko writes:
Usually, 99% of the time?, objections to a person's behavior is a direct result of exchanges on this list. I can't recall another instance where someone has taken issue with another who isn't on the list to defend himself.
It seems to me that his work is a very loud voice in every distribution that adopts systemd (and, for that matter, pulseaudio). To not be allowed to challenge that voice, just because it is allegedly not present, is to ignore that which *is* present.
On Jul 6, 2014, at 5:33 PM, David Benfell benfell@parts-unknown.org wrote:
Rolf Turner writes:
The difference is that Olav is polite and you are abusive.
If you regard what I say as abusive, then you should, perhaps, be challenging this entire thread, which impugns the motivations, not only of Mr. Poettering, not only of the Fedora development team, but of every distribution that has adopted his work.
Adolescent behavior is adolescent behavior, Mr. Poettering richly deserves the accusation, and what I'm seeing here is not so much a protest against abuse as a cliquish attempt at control.
To which I can only say, get over it. It's not healthy.
I regard what you say as abusive because you are using the accusation of mental illness as a weapon. That is intolerable.
Yet another poster hits the killfile.
--Russell
-- David Benfell See https://parts-unknown.org/node/2 if you do not understand the attachment. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/07/14 08:38, David Benfell wrote:
Ed Greshko writes:
Usually, 99% of the time?, objections to a person's behavior is a direct result of exchanges on this list. I can't recall another instance where someone has taken issue with another who isn't on the list to defend himself.
It seems to me that his work is a very loud voice in every distribution that adopts systemd (and, for that matter, pulseaudio). To not be allowed to challenge that voice, just because it is allegedly not present, is to ignore that which *is* present.
IMO, you should challenge him directly and not on this list.
I so no purpose in disparaging someone. I especially see no purpose in disparaging someone who isn't here to defend themselves.
I would start to wonder how you speak about your friends behind their backs.
- -- If you can't laugh at yourself, others will gladly oblige.
Russell Miller writes:
I regard what you say as abusive because you are using the accusation of mental illness as a weapon. That is intolerable.
I agree. It is intolerable.
For the record, I never accused anyone of mental illness and I am not qualified to offer diagnoses. I only remarked on their behavior--and on some rather blatant double standards.
On Sun, 6 Jul 2014, David Benfell wrote:
Russell Miller writes:
I regard what you say as abusive because you are using the accusation of mental illness as a weapon. That is intolerable.
I agree. It is intolerable.
For the record, I never accused anyone of mental illness and I am not qualified to offer diagnoses. I only remarked on their behavior--and on some rather blatant double standards.
There is no greater feeling in the world than to grab the opportunity to be offended on behalf of someone else who doesn't get the chance to be offended on their own. Cherish it.
billo
On 06.07.2014 16:45, Patrick O'Callaghan wrote:
On Sun, 2014-07-06 at 15:32 +0200, poma wrote:
I repeat that I am not attacking systemd here, I'm criticizing the
way
it's described. It may seem perfectly clear to those who already understand it, but it's not at all clear to those who are used to something different.
poc
You can propose your terminology.
To do that I would first have to understand it.
poc
You do not understand your own terminology!? :)
poma
On 06.07.2014 22:12, David Benfell wrote:
poma writes:
You can propose your terminology.
You're asking him to do Poettering's technical writing when he isn't even sure he understands Poettering correctly.
Not only is that an imposition, it's an unfair one.
Thanks, but no thanks. Actually it's quite fair to ask, if he does not agree with the defined.
poma
On 07/06/2014 07:45 PM, lee wrote:
Joe Zeff joe@zeff.us writes:
On 07/06/2014 12:43 AM, lee wrote:
Not even the configuration files are where they belong.
Actually, they're exactly where they belong. They just aren't where you expect them to be.
They belong under /etc, not hidden somewhere in /var.
as all things in var there are temporary state files
root@hal: ~ # ls -lR /var/lib/systemd /var/lib/systemd: total 12 drwxr-xr-x. 2 root root 4096 Jun 25 22:15 catalog drwxr-xr-x. 2 root root 4096 Jun 21 19:29 coredump -rw-------. 1 root root 512 Jul 7 08:03 random-seed
/var/lib/systemd/catalog: total 12 -rw-r--r-- 1 root root 9570 Jun 25 22:15 database
/var/lib/systemd/coredump: total 0
maybe you meant /usr/lib/systemd where initial files for services are? (but /usr/lib is ok .. i see no problem with that)
configuration directory (for both systemd and systemd services) are in /etc/systemd (btw : the services configurations and declarations from /etc/systemd overwrites those from /usr/lib/systemd)
moreover you can separately configure a service without modifying the .service file (which usually is linked in /etc/systemd) : "Along with a unit file foo.service, a directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the file itself is parsed. This is useful to alter or add configuration settings to a unit, without having to modify their unit files. Make sure that the file that is included has the appropriate section headers before any directive." (man systemd.unit)
HTH, Adrian
On Mon, Jul 07, 2014 at 10:38:16AM +0200, Timothy Murphy wrote:
Garry T. Williams wrote:
There are a slew of references on the 'Net
Then give one ...
Or if you could share your slides from the talk you gave, that would be nice. I sincerely would like to understand systemd, and so far all references I find on the Internet are as heavy in jargon as the man pages. To clarify a bit, I'm usually okay with reading man pages, so I'm not expecting to find something written in plain english for the non-technical user.
Adrian Sevcenco writes:
moreover you can separately configure a service without modifying the .service file (which usually is linked in /etc/systemd) :
Possibly my information is out of date. I thought you were to put such service files in /etc/systemd/system and systemctl looks here first when told to enable a service (which is to say, a service file in /etc/systemd/system will supercede one in /usr/lib/systemd/system at the time of an enable command).
I know that /etc/systemd/system continues to work. I've been using it.
Glenn Holmer shadowm@lyonlabs.org writes:
But when someone replies to that by saying that systemd is broken because "a shepherd is not a sheep", well... that's just splitting grammatical hairs to try and prove that the documentation is obtuse.
Then you haven't thought far enough. The documentation is poorly written, an approach is used which is plain wrong and thus confusing, there is no clarity of terms, concepts and structure. The authors of systemd don't even understand what "disabled" means.
When they have all this wrongness, confusion, obfuscation and lack of clarity and simplicity in the documentation, how could the source of the program be any better? Why should I think that the design of the software is any better than the documentation? It's probably far worse.
Look at the documentation for exim to see an example for good documentation. You'll see that things are very well thought out, and the documentation is entirely clear. I suppose the source of exim goes along with that.
That I don't want to read poor documentation is one thing. That I don't want to read documentation to do a simple thing --- i. e. start a daemon --- is another. If not systemd but sysvinit was used, I wouldn't need to read any documentation to achieve this because I have already read the documentation.
But no, thanks to systemd it's anything but simple to do something simple, and I'm forced to waste my time with reading poor documentation.
It's even of no advantage to me to read this documentation because the only thing it applies to is systemd. It's way more advantageous for me to learn to write shell scripts which I can use with sysvinit and for other things as well. Learning how to create the so-called entities systemd requires is not useful for anything but systemd, so systemd is highly inefficient.
Patrick O'Callaghan pocallaghan@gmail.com writes:
On Sun, 2014-07-06 at 13:01 -0700, David Benfell wrote:
*What*, for example, is "the usual meaning" of "file system objects?" A file? Why not just say "file?" And if the documentation really means files or pipes or devices, then why not say "files or pipes or devices?"
I assume it means "something with a name in the filesystem".
They just couldn't find a word that is more obfuscating and didn't want to re-use "entity".
Russell Miller duskglow@gmail.com writes:
On Jul 6, 2014, at 5:33 PM, David Benfell benfell@parts-unknown.org wrote:
Rolf Turner writes:
The difference is that Olav is polite and you are abusive.
If you regard what I say as abusive, then you should, perhaps, be challenging this entire thread, which impugns the motivations, not only of Mr. Poettering, not only of the Fedora development team, but of every distribution that has adopted his work.
Adolescent behavior is adolescent behavior, Mr. Poettering richly deserves the accusation, and what I'm seeing here is not so much a protest against abuse as a cliquish attempt at control.
To which I can only say, get over it. It's not healthy.
I regard what you say as abusive because you are using the accusation of mental illness as a weapon. That is intolerable.
He didn't do that.
Ed Greshko ed.greshko@greshko.com writes:
On 07/07/14 08:38, David Benfell wrote:
Ed Greshko writes:
Usually, 99% of the time?, objections to a person's behavior is a direct result of exchanges on this list. I can't recall another instance where someone has taken issue with another who isn't on the list to defend himself.
It seems to me that his work is a very loud voice in every distribution that adopts systemd (and, for that matter, pulseaudio). To not be allowed to challenge that voice, just because it is allegedly not present, is to ignore that which *is* present.
IMO, you should challenge him directly and not on this list.
He didn't challenge anyone. Why do you want him to challenge someone?
Kevin Fenzi kevin@scrye.com writes:
On Sun, 06 Jul 2014 18:18:46 +0200 lee lee@yun.yagibdah.de wrote:
Kevin Fenzi kevin@scrye.com writes:
On Sun, 06 Jul 2014 09:52:24 +0200 lee lee@yun.yagibdah.de wrote:
Kevin Fenzi kevin@scrye.com writes:
output. With systemd/journald, ALL output is saved and easy to query.
How do you query this output? I just look at the logfile, and when it's not there, I never see it. What's the advantage of hiding output like that?
journalctl -u servicename
(I usually add -b which gives you messages only since last boot).
That doesn't make sense. What if you're trying to solve a problem, suspecting a particular service, and the problem is somewhere else? You'd never see the relevant messages because they remain hidden.
journalctl | grep whatever
or
journalctl | less
and page though things?
You can probably do that, but 'less /var/log/syslog' is easier.
You'd have to browse all messages, and an ordinary logfile is perfectly suited for that. What's the advantage of using an unreadable format and added complexity supposed to be?
It lets you do things like easily grep the messages from just the last boot, or isolate things from particular services, export it in other formats, lets you easily log from containers or user space items.
I've never had trouble looking at the logs. Now I do because I might only see part of the messages.
Anyhow, it sounds like you are pretty firmly set in your dislike for systemd/journald. Not sure continued discussion will change your mind any...
What I don't like is when things are made more complicated than they need to be. Where is the advantage of systemd to me, and why would it be needed? Then read the links the OP provided ...
It's like pulseaudio. It has no advantages for me and only disadvantages. It's awfully complicated and cryptic. If you do need features it offers, it's nice to have, yet that doesn't mean that everyone should be forced to use it. It took until F19 until it worked. It took several times asking on this list since F17 to finally get rid of it. That may show you how "simple" it is.
Bill Oliver vendor@billoblog.com writes:
On Sun, 6 Jul 2014, David Benfell wrote:
So in your view, I have no right to object to his behavior but you have a right to object to my objection?
Something ain't right there.
Some things are above criticism. It's important that you know your place.
Things like?
Sam Varshavchik mrsam@courier-mta.com writes:
David Benfell writes:
Systemd needs to be a vast improvement to justify this. And it seems that not everyone even agrees that it's an improvement at all.
Here's something that I can't figure out: with this entire thread in mind, why is all of this is being said /now/???
People have come to dislike systemd and take their pleasure in saying it because someone brought it up here. It doesn't matter anyway because the Fedora project has abandoned the users by not listening to them in its striving to lead all the development of FOSS.
Ahmad Samir ahmadsamir3891@gmail.com writes:
On 06/07/14 18:44, lee wrote:
Kevin Fenzi kevin@scrye.com writes:
[...]
yum remove alsa-plugins-pulseaudio
used to do it. It would still be installed, but not loaded/used.
Hm, yes, I could actually remove it without removing anything else, thank you! Finally!
Now I even have hardware mixing and no stupid pulseaudio wasting CPU and resources for nothing :))
Just would I remove pulseaudio altogether?
Removing the alsa-plugins-pulseaudio package and editing /etc/pulse/client.conf and adding a line: autospawn = no
I had to disable --- err, "mask" it --- to prevent it from being started, and I removed execute permissions from the binary.
so that the pulseaudio daemon doesn't get started (I have to this with GNOME3 otherwise gnome-shell will start pulseaudio).
Or just uninstall the pulseaudio package. Note that you can't remove some of the pulseaudio library packages (pulseaudio-libs and pulseaudio-libs-glib2) because some packages directly link against those libs.
Hm, yes, I actually could remove it. It seems funny that I'm getting a new leave "gnome-keyring-pam", amongst others ...
Michael Hennebry hennebry@web.cs.ndsu.nodak.edu writes:
On Sun, 6 Jul 2014, Kevin Fenzi wrote:
What systemd config files are under /var?
I don't know. I thought lee did.
It has some files in /var, too, whatever those are. It's all over the place :(
Kevin Fenzi kevin@scrye.com writes:
On Sun, 6 Jul 2014 13:25:42 -0500 (CDT) Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
On Sun, 6 Jul 2014, lee wrote:
Joe Zeff joe@zeff.us writes:
On 07/06/2014 12:43 AM, lee wrote:
Not even the configuration files are where they belong.
Actually, they're exactly where they belong. They just aren't where you expect them to be.
They belong under /etc, not hidden somewhere in /var.
Configuration files under /var ? Wow.
...snip...
What systemd config files are under /var?
I guess I meant /usr, sorry --- I never can remember where they hid them. They don't belong into /usr, either. There seem to be a few duplicates (or whatever they are) in /etc. It's just an awful mess and one of the reasons why I don't like systemd.
"Garry T. Williams" gtwilliams@gmail.com writes:
On 7-6-14 10:39:11 lee wrote:
"Garry T. Williams" gtwilliams@gmail.com writes:
The analogy is placing a script in /etc/init.d and then linking its name in the /etc/rc5.d directory.
I find this much simpler than the sysvinit schemes.
You have taken well over 100 lines to give a description about how to get a daemon started with systemd, not to mention the hours you must have spent reading all the documentation to figure out how to do what you wanted.
Of course, my message was an attempt to explain what a Unit is to Patrick. The bulk of my reply was not describing how to get a daemon started with systemd.
That shows the problem: Systemd attempts to replace something which is simple and straightforward and does work with something that is anything but simple or straightforward, doesn't work and involves a dozen types of entities which are neither evident nor structured.
As to the hours of reading, well, yes. systemd was new when I first encountered it. How else could I learn how it works without actually reading the documentation?
When I want to do a simple thing like starting a daemon, I don't want to learn how systemd works but get the job done.
It took you only 2 lines to describe how to do the same thing with sysvinit.
Yes.
But have you looked at the sysvinit script to compare it to the Service unit that accomplishes the same thing?
I can read the script but not the entity.
The point is that there is lots of boilerplate in every sysvinit script to do the simplest task.
That makes it easy to copy an existing script and to adjust the copy to your needs.
The systemd Service unit corresponding to the abrt init script is way simpler. And it can accomplish stuff the bare script cannot, like automatic restart upon failure.
Look at the script to start chronyd Debian uses and the entity Fedora uses for the same thing. The script does more than the entity does, and it tells me directly what it does while the entity doesn't tell me at all. I don't know if the entity can do what the script does.
Which real problem does systemd actually solve? There is no real need to start things in parallel (I don't even like it because I can't see the messages anymore because they are displayed too fast to read and show up even after the login promt is displayed). There is no real need --- even no point --- to restart something in case it fails because when something fails, merely restarting it doesn't fix the problem and I'd rather have it failed so that I'll notice and can fix it. There is no problem with copying common content from one script to another.
I don't understand how you can find systemd "much simpler" than sysvinit. Where and how is it simpler than sysvinit? It takes only about 2% of the effort, if that much, to start a daemon with sysvinit than it takes to do the same with systemd.
For systemd, you even have to learn a whole new "programming language" to create configuration files which is useless anywhere else. Efficiency is negative here.
Reading the documentation, I know that the unit files do not contain *any* "programming language". They are declarative.
What is better about inventing a new language nobody knows compared to using an existing one lots of ppl already know?
That was very intensional in systemd's design.
That was a bad decision. Why shouldn't I be allowed to make an entity I create do something?
Indeed, there have been many discussions and patches submitted to add that very thing to the unit files on the systemd development mailing list. These have been uniformly rejected because of this basic design.
Which very thing?
Yes, you do have to read and understand the documentation to successfully use systemd. I'll leave it to others to comment on the usefulness of a Unit file outside of Fedora.
Debian and centos use sysvinit; I don't know what others use.
On Mon, 2014-07-07 at 11:07 +0200, Suvayu Ali wrote:
On Mon, Jul 07, 2014 at 10:38:16AM +0200, Timothy Murphy wrote:
Garry T. Williams wrote:
There are a slew of references on the 'Net
Then give one ...
Or if you could share your slides from the talk you gave, that would be nice. I sincerely would like to understand systemd, and so far all references I find on the Internet are as heavy in jargon as the man pages. To clarify a bit, I'm usually okay with reading man pages, so I'm not expecting to find something written in plain english for the non-technical user.
+1
BTW, I am a technical user (i.e. I'm more technically inclined than most people and less so than some), but I object to that being used as a crutch by people who don't take the trouble to write clearly. Writing clear documentation is just as hard as writing good code. The single most important factor in the early adoption of Unix (showing my age here) was the fact that everything was documented and the docs are for the most part models of clarity.
poc
On Mon, 2014-07-07 at 04:57 +0200, poma wrote:
On 06.07.2014 22:12, David Benfell wrote:
poma writes:
You can propose your terminology.
You're asking him to do Poettering's technical writing when he isn't even sure he understands Poettering correctly.
Not only is that an imposition, it's an unfair one.
Thanks, but no thanks. Actually it's quite fair to ask, if he does not agree with the defined.
Asked and answered.
poc
On Mon, 2014-07-07 at 04:39 +0200, poma wrote:
On 06.07.2014 16:45, Patrick O'Callaghan wrote:
On Sun, 2014-07-06 at 15:32 +0200, poma wrote:
I repeat that I am not attacking systemd here, I'm criticizing the
way
it's described. It may seem perfectly clear to those who already understand it, but it's not at all clear to those who are used to something different.
poc
You can propose your terminology.
To do that I would first have to understand it.
poc
You do not understand your own terminology!? :)
Yeah sure, that's what I meant. Not.
poc
On 07/07/2014 04:34 AM, lee wrote:
The authors of systemd don't even understand what "disabled" means.
A pretty bold statement. Disabled means the same thing it does in sysvinit: the service won't start at boot time.
https://fedoraproject.org/wiki/Systemd#How_do_I_start.2Fstop_or_enable.2Fdis...
When they have all this wrongness, confusion, obfuscation and lack of clarity and simplicity in the documentation, how could the source of the program be any better? Why should I think that the design of the software is any better than the documentation? It's probably far worse.
[shrug] When I started learning systemd, I assumed that it was my understanding that was faulty. I studied until I understood it, beginning with the Fedora and Arch docs (which are exellent) and then returning to the systemd documentation, which then made much more sense.
That I don't want to read poor documentation is one thing. That I don't want to read documentation to do a simple thing --- i. e. start a daemon --- is another. If not systemd but sysvinit was used, I wouldn't need to read any documentation to achieve this because I have already read the documentation.
How long did it take you to learn sysvinit and shell scripting? Yes I know, you have to learn something new now. It happens, computer technology does not stand still.
But no, thanks to systemd it's anything but simple to do something simple, and I'm forced to waste my time with reading poor documentation.
As I suggested above, you might find it a good idea to read some more general documentation first before wading into the systemd man pages:
https://fedoraproject.org/wiki/Systemd
https://wiki.archlinux.org/index.php/systemd
http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/
http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
http://0pointer.de/blog/projects/systemd.html
http://rhsummit.files.wordpress.com/2014/04/summit_demystifying_systemd1.pdf
And to hear it straight from Lennart Poettering:
https://access.redhat.com/videos/403833
I highly recommend watching that video from beginning to end.
On 07.07.2014 13:19, Patrick O'Callaghan wrote:
On Mon, 2014-07-07 at 04:39 +0200, poma wrote:
On 06.07.2014 16:45, Patrick O'Callaghan wrote:
On Sun, 2014-07-06 at 15:32 +0200, poma wrote:
I repeat that I am not attacking systemd here, I'm criticizing the
way
it's described. It may seem perfectly clear to those who already understand it, but it's not at all clear to those who are used to something different.
poc
You can propose your terminology.
To do that I would first have to understand it.
poc
You do not understand your own terminology!? :)
Yeah sure, that's what I meant. Not.
poc
You see, you expect systemd to be understandable, however you alone weren't understandable here. :)
Perhaps 'man systemd-what-i-thought' would be helpful to many people here, but those who complain anyway are lazy per se, or they do not care, or are themselves ignorant or are just lame provocateurs etc.
What I do not understand why you are trying to align with that group despite your great experience in the branche. We should seek advice from you, not vice versa. ;)
poma
On 07/07/2014 01:10 PM, David Benfell wrote:
Adrian Sevcenco writes:
moreover you can separately configure a service without modifying the .service file (which usually is linked in /etc/systemd) :
Possibly my information is out of date. I thought you were to put such service files in /etc/systemd/system and systemctl looks here first when
yeah, exactly! i just did not mention the full path
told to enable a service (which is to say, a service file in /etc/systemd/system will supercede one in /usr/lib/systemd/system at the time of an enable command).
yes, this is correct.. i was mentioning that for foobar.service you can make a directory named foobar.service.d in which in .conf files will be parsed to modify the default settings from foobar.service file.
I know that /etc/systemd/system continues to work. I've been using it.
i know :)
Adrian
On Mon, 2014-07-07 at 15:11 +0200, poma wrote:
You do not understand your own terminology!? :)
Yeah sure, that's what I meant. Not.
poc
You see, you expect systemd to be understandable, however you alone weren't understandable here. :)
Seriously? The only person who appears to have misunderstood what I said is you. I say "appears" because at first I thought you were joking. In fact I'm still not sure you aren't. Just in case there is any remaining ambiguity, the referent for "it" in my comment was "systemd" (you know, the thing we're talking about here?). It's simply not credible that the referent could be the non-existent terminology that I haven't invented.
Perhaps 'man systemd-what-i-thought' would be helpful to many people here, but those who complain anyway are lazy per se, or they do not care, or are themselves ignorant or are just lame provocateurs etc.
What I do not understand why you are trying to align with that group despite your great experience in the branche. We should seek advice from you, not vice versa. ;)
I see it all now. The people who complain that they don't understand the terminology are lazy or ignorant or have an agenda. There's no way any of the responsibility for that lies with the docs themselves. Why didn't I realize that before?
poc
On Mon, 07 Jul 2014 19:17:49 +0100 Patrick O'Callaghan wrote:
I see it all now. The people who complain that they don't understand the terminology are lazy or ignorant or have an agenda. There's no way any of the responsibility for that lies with the docs themselves. Why didn't I realize that before?
Don't worry, even if there are no docs at all, it is still your fault because you could have been breathlessly following the design on mailing lists and IRC and you chose not to spend every waking moment of your life seeking out obscure open source projects and participating in them :-).
On 06.07.2014, Balint Szigeti wrote:
The only reason that I wanted to reach, make the system(s) better if we don't get rid of it.
But keep in mind that there are alternatives. Thus, systemd isn't unavoidable. I'm permitting myself to mention that I've been using openrc on my Arch machine quite some time, and it works great..
On 07/07/14 13:39, Heinz Diehl wrote:
But keep in mind that there are alternatives. Thus, systemd isn't unavoidable. I'm permitting myself to mention that I've been using openrc on my Arch machine quite some time, and it works great..
It may become problematic once KDBUS merges into the mainline kernel.
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
On 07.07.2014 20:38, Tom Horsley wrote:
On Mon, 07 Jul 2014 19:17:49 +0100 Patrick O'Callaghan wrote:
I see it all now. The people who complain that they don't understand the terminology are lazy or ignorant or have an agenda. There's no way any of the responsibility for that lies with the docs themselves. Why didn't I realize that before?
Don't worry, even if there are no docs at all, it is still your fault because you could have been breathlessly following the design on mailing lists and IRC and you chose not to spend every waking moment of your life seeking out obscure open source projects and participating in them :-).
For you Roquefort will always be just a fungus. It's beyond your comprehension.
poma
On 07.07.2014, Edward M wrote:
It may become problematic once KDBUS merges into the mainline kernel.
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
This thread showcases once more the all-dominating and rude attitudes of some of the systemd devs. At least, the kdbus merge is unlikely to happen in the near future :-)
On 07/07/14 15:00, Heinz Diehl wrote:
On 07.07.2014, Edward M wrote:
It may become problematic once KDBUS merges into the mainline kernel.
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
This thread showcases once more the all-dominating and rude attitudes of some of the systemd devs. At least, the kdbus merge is unlikely to happen in the near future :-)
I hope Linus is not influence for merger later on. I run BSD's as well and this may bring difficulty.
On 08.07.2014 00:00, Heinz Diehl wrote:
On 07.07.2014, Edward M wrote:
It may become problematic once KDBUS merges into the mainline kernel.
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
This thread showcases once more the all-dominating and rude attitudes of some of the systemd devs. At least, the kdbus merge is unlikely to happen in the near future :-)
https://lkml.org/lkml/2014/4/2/544 From Greg KH <> ... "I understand the sediment, but really people..."
What is the "sediment" in the thread context?
poma
poma writes:
What is the "sediment" in the thread context?
I suspect the word that was meant here is 'sentiment'.
poma writes:
For you Roquefort will always be just a fungus. It's beyond your comprehension.
Fascinating.
Patrick O'Callaghan pocallaghan@gmail.com writes:
BTW, I am a technical user (i.e. I'm more technically inclined than most people and less so than some), but I object to that being used as a crutch by people who don't take the trouble to write clearly. Writing clear documentation is just as hard as writing good code. The single most important factor in the early adoption of Unix (showing my age here) was the fact that everything was documented and the docs are for the most part models of clarity.
+1
Writing clear, good documentation is more difficult than writing good code (at least it is for me).
Unfortunately, the quality of documentation has significantly declined over the years, with very few exceptions, and users seem to have become more clueless as well --- which is probably not surprising because without good documentation and software being forced upon them, what could they do.
Tom Horsley horsley1953@gmail.com writes:
On Mon, 07 Jul 2014 12:27:53 +0200 lee wrote:
Debian and centos use sysvinit; I don't know what others use.
Not for long.
Debian says that wheezy comes with it[1], yet it didn't (other than perhaps as an option) as I can see from what I have installed. It would suck to be forced to use it, and it would prove ppl lying who are claiming that free software is about freedom ...
[1]: https://archive.fosdem.org/2013/schedule/event/debian_systemd/
Glenn Holmer shadowm@lyonlabs.org writes:
On 07/07/2014 04:34 AM, lee wrote:
The authors of systemd don't even understand what "disabled" means.
A pretty bold statement. Disabled means the same thing it does in sysvinit: the service won't start at boot time.
But it might start any time later because it's not disabled when you disable it.
[shrug] When I started learning systemd, I assumed that it was my understanding that was faulty. I studied until I understood it, beginning with the Fedora and Arch docs (which are exellent) and then returning to the systemd documentation, which then made much more sense.
Shouldn't it have a documentation that makes sense when you read it?
How long did it take you to learn sysvinit and shell scripting?
It didn't take long at all. What you need to know about sysvinit doesn't take much to explain, and I didn't have to learn shell scripting for it. The scripts are easy to read and just tell you what they do.
Yes I know, you have to learn something new now. It happens, computer technology does not stand still.
I'd rather learn more perl or elisp or shell scripting than systemd. Systemd "scripts" are exclusively useful for systemd and nothing else. Perl, elisp and shell scripts are much more versatile and useful for lots of different things.
But no, thanks to systemd it's anything but simple to do something simple, and I'm forced to waste my time with reading poor documentation.
As I suggested above, you might find it a good idea to read some more general documentation first before wading into the systemd man pages:
It would be a better idea that something else than systemd is used.
As others have pointed out, it does far more than starting things during boot and acts like an MCP after that. It is not a daemon but tries to make ppl think that it is.
So far, nobody seems to have clearly shown in this discussion what the crucial advantages of systemd are. What reasons would I have to like it?
On 07/07/2014 04:47 PM, lee wrote:
Glenn Holmershadowm@lyonlabs.org writes:
On 07/07/2014 04:34 AM, lee wrote:
The authors of systemd don't even understand what "disabled" means.
A pretty bold statement. Disabled means the same thing it does in sysvinit: the service won't start at boot time.
But it might start any time later because it's not disabled when you disable it.
In systemd, a service that's disabled won't be directly started at boot, but another service can still start it either at boot or later. To keep a service from being started by systemd under any circumstances, you need to mask it. I think that the idea is to make a distinction between services that are only started when something needs them and services that aren't started at all.
lee writes:
Tom Horsley horsley1953@gmail.com writes:
On Mon, 07 Jul 2014 12:27:53 +0200 lee wrote:
Debian and centos use sysvinit; I don't know what others use.
Not for long.
Debian says that wheezy comes with it[1], yet it didn't (other than perhaps as an option) as I can see from what I have installed.
Confirmed. I put wheezy on my mother's computer not that long ago. I wasn't even looking for systemd at that time, and whenever I log into her system to administer it, I'm still using the old init scripts.
It would suck to be forced to use it, and it would prove ppl lying who are claiming that free software is about freedom ...
I had been under the impression that their decision would take effect with a future release. According to this:
https://wiki.debian.org/systemd
"systemd was included in Debian wheezy as a technology preview"
However, it appears that even though they have taken their vote, and chosen systemd, they have not yet developed service files for all their packages (neither has Fedora), and that they will support alternatives:
https://lists.debian.org/debian-ctte/2014/02/msg00281.html
OK that's it! I sincerely recommend the moderators to close this shameful thread where certain creatures are capable of spitting on the systemd and its developers without any remorse!
poma
Poma said:
OK that's it! I sincerely recommend the moderators to close this shameful thread where
certain creatures are capable of spitting on >the systemd and its developers without any remorse!
I think Greg had the right idea. *plonk*.
To be frank, as I mentioned on another thread on another list, I think systemd is the "abomination of desolation" for Linux. It's completely counter to everything Linux and UNIX is about, and it's an utter mess. It's actually driving me, after nearly 20 years messing with Linux, to consider a BSD derivative.
But you... you're just being noisy, combative, and are polluting my mailbox. Have a nice day.
--Russell
On Mon, Jul 7, 2014 at 11:17 PM, poma pomidorabelisima@gmail.com wrote:
OK that's it! I sincerely recommend the moderators to close this shameful thread where certain creatures are capable of spitting on the systemd and its developers without any remorse!
poma
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Joe Zeff joe@zeff.us writes:
In systemd, a service that's disabled won't be directly started at boot, but another service can still start it either at boot or later.
That means that the service is *not* disabled.
To keep a service from being started by systemd under any circumstances, you need to mask it.
And that means that it is disabled.
I think that the idea is to make a distinction between services that are only started when something needs them and services that aren't started at all.
I don't mind this idea. Yet when I disable something, I expect it to be disabled.
David Benfell benfell@parts-unknown.org writes:
https://wiki.debian.org/systemd
"systemd was included in Debian wheezy as a technology preview"
However, it appears that even though they have taken their vote, and chosen systemd, they have not yet developed service files for all their packages (neither has Fedora), and that they will support alternatives:
I wonder what the outcome of it was. There seem to have been only seven votes, and a bug report was made about a few ppl who like systemd taking over.
The ppl who want systemd to be the default could experience difficulties to achieve that if the maintainers of relevant packages don't support them, and how will the maintainers like the idea of supporting several alternatives?
And only seven votes? Are they serious?
lee writes:
And only seven votes? Are they serious?
I didn't realize they'd only gotten seven votes (presumably of the maintainers who advocate systemd). I do understand that quorum rules need to be loose enough to allow anything at all to get done.
But this seems *too* loose.
lee writes:
I don't mind this idea. Yet when I disable something, I expect it to be disabled.
This is another terminology issue, which I think should be viewed separately from the merits/demerits of systemd itself. And I'm inclined to agree that the terms are poorly chosen.
I guess the concept of 'mask' is as in to disguise, as in to hide. For me, that's two steps of abstraction and I don't normally infer the second from the first. So it throws me too.
David Benfell benfell@parts-unknown.org writes:
lee writes:
And only seven votes? Are they serious?
I didn't realize they'd only gotten seven votes (presumably of the maintainers who advocate systemd). I do understand that quorum rules need to be loose enough to allow anything at all to get done.
But this seems *too* loose.
It seemed to be only seven from other messages in the thread and some pages I found searching. Perhaps they have some committee which is supposed to decide things like this and which happens to have seven members.
It remains to be seen if they have a way to do a sane conversion from whatever init system users are using now to systemd during a distribution upgrade. Maybe they don't need one for a while ago, Debian has made a decision, be it an unconscious one or not, to break things when it suits them. I only have it because I couldn't get xen to work with centos and it works with Debian.
On Sat, Jul 5, 2014 at 7:03 AM, Garry T. Williams wrote:
On 7-5-14 14:30:39 Patrick O'Callaghan wrote:
+1. One of my pet gripes about systemd is that it introduces a lot of new terminology without a clear explanation.
Have you looked at the manual pages? I know of no other project that has the breadth and depth of documentation that systemd has. Your statement is, on its face, incorrect.
Quantity of documentation is not the same as clear explanation. In many contexts, clarity and verbosity are inversely proportional..
Hi
On Tue, Jul 8, 2014 at 6:07 PM, David Benfell wrote:
lee writes:
And only seven votes? Are they serious?
I didn't realize they'd only gotten seven votes (presumably of the maintainers who advocate systemd). I do understand that quorum rules need to be loose enough to allow anything at all to get done.
But this seems *too* loose.
This is not random Debian maintainers. This is the Debian technical committee empowered with making such decisions. A GR (General resolution) is the only way to override the tech committee and that requires some Debian maintainer to propose one and so far noone has done so
Rahul
On 7 July 2014 08:34, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Sun, 2014-07-06 at 13:01 -0700, David Benfell wrote:
*What*, for example, is "the usual meaning" of "file system objects?" A file? Why not just say "file?" And if the documentation really means files or pipes or devices, then why not say "files or pipes or devices?"
I assume it means "something with a name in the filesystem".
What about a file without a name? :-)
If you delete all filenames of a file while it is opened by a process, it still uses filesystem space but has no name.
Hi
On Tue, Jul 8, 2014 at 7:49 PM, Norman Gaywood wrote:
What about a file without a name? :-)
If you delete all filenames of a file while it is opened by a process, it still uses filesystem space but has no name.
There are other cases as well
http://kernelnewbies.org/Linux_3.11#head-8be09d59438b31c2a724547838f234cb33c...
Rahul
On 9 Jul 2014 00:33, "Rahul Sundaram" metherid@gmail.com wrote:
This is not random Debian maintainers. This is the Debian technical
committee empowered with making such decisions. A GR (General resolution) is the only way to override the tech committee and that requires some Debian maintainer to propose one and so far noone has done so
Actually over on the debian-project list after the technical committee had decided on systemd there was a call from someone for a GR overriding this but it failed to get enough support to be called to vote.
Rahul Sundaram metherid@gmail.com writes:
This is not random Debian maintainers. This is the Debian technical committee empowered with making such decisions. A GR (General resolution) is the only way to override the tech committee and that requires some Debian maintainer to propose one and so far noone has done so
Apparently the project secretary has a hand in it, and sponsors are needed. So maybe it's not as easy as it seems.
Too bad that the users never get to vote.
David Benfell benfell@parts-unknown.org writes:
lee writes:
I don't mind this idea. Yet when I disable something, I expect it to be disabled.
This is another terminology issue, which I think should be viewed separately from the merits/demerits of systemd itself. And I'm inclined to agree that the terms are poorly chosen.
Why should it be seen separately? Poorly chosen terms is a feature of systemd like any other it may have, and this feature leads straightaway to unexpected and undesired results when used. That the authors even deny fixing it is ... well, I'm not sure how to call that.
I guess the concept of 'mask' is as in to disguise, as in to hide. For me, that's two steps of abstraction and I don't normally infer the second from the first. So it throws me too.
When something is disguised or hidden, it is not disabled. It is camouflaged or concealed. Camouflage, concealment, hiding, disguise and masking can all be used for *preventing* from being disabled.
On 07/08/2014 11:40 PM, lee wrote:
When something is disguised or hidden, it is not disabled. It is camouflaged or concealed. Camouflage, concealment, hiding, disguise and masking can all be used for*preventing* from being disabled.
No. When a service is disabled it can still be started after boot, but when it's masked, it can't be started at all.
Do understand that I'm defending neither systemd nor the deveolper's choice of terminology. I'm merely correcting what looks like a misstatement of how it works.
On Wed, Jul 9, 2014 at 3:36 AM, Joe Zeff joe@zeff.us wrote:
On 07/08/2014 11:40 PM, lee wrote:
When something is disguised or hidden, it is not disabled. It is camouflaged or concealed. Camouflage, concealment, hiding, disguise and masking can all be used for*preventing* from being disabled.
No. When a service is disabled it can still be started after boot, but when it's masked, it can't be started at all.
Exactly.
Think of "systemctl disable <service>" and "systemctl mask <service>" as being similar to "blacklist <module>" and "install <module> /bin/true" respectively in "/etc/modprobe.conf.d/<module>.conf".
lee writes:
David Benfell benfell@parts-unknown.org writes:
Why should it be seen separately? Poorly chosen terms is a feature of systemd like any other it may have, and this feature leads straightaway to unexpected and undesired results when used. That the authors even deny fixing it is ... well, I'm not sure how to call that.
I guess the two questions I'm reaching for are:
1) Is systemd conceptually broken, just a really bad idea from the start? Some people say yes, and some of them argue well.
2) Or, is it just that systemd is buried underneath an avalanche of horrendous documentation and poorly chosen terminology?
To these, I might add a third:
3) Is systemd simply too large a leap to be wise? Clearly, many folks in the distributions are enamored with it; they're all adopting it. As is apparent here, some users like it as well (and if we succumb to a false dichotomy, well, I'm not all that wild about sysvinit scripts either). And a certain amount of the rebuttal to opponents seems to be of the sort that we should just take the time to learn it.
I guess the concept of 'mask' is as in to disguise, as in to hide. For me, that's two steps of abstraction and I don't normally infer the second from the first. So it throws me too.
When something is disguised or hidden, it is not disabled. It is camouflaged or concealed. Camouflage, concealment, hiding, disguise and masking can all be used for *preventing* from being disabled.
Fair enough.
Hi
On Wed, Jul 9, 2014 at 3:03 AM, lee wrote:
Apparently the project secretary has a hand in it, and sponsors are needed. So maybe it's not as easy as it seems.
It is fairly easy to bring any proposal to vote. Debian has done it numerous times.
Too bad that the users never get to vote.
There is no way to determine accurately who is a open source project user or who is a random troll online. You basically have to let the whole internet vote which I far from convince is a useful thing especially for system level software. All major distributions at this point have switched to systemd or in the process of doing so which should tell you the value of it.
Rahul
David Benfell benfell@parts-unknown.org writes:
I guess the two questions I'm reaching for are:
- Is systemd conceptually broken, just a really bad idea from the
start? Some people say yes, and some of them argue well.
So far, I've seen only arguments that would support that systemd is a really bad idea because it's broken by design --- or should reasonably be designed differently.
- Or, is it just that systemd is buried underneath an avalanche of
horrendous documentation and poorly chosen terminology?
You could look at the source to find an answer. Perhaps it's great --- but I doubt it.
To these, I might add a third:
- Is systemd simply too large a leap to be wise? Clearly, many folks
in the distributions are enamored with it; they're all adopting it. As is apparent here, some users like it as well (and if we succumb to a false dichotomy, well, I'm not all that wild about sysvinit scripts either). And a certain amount of the rebuttal to opponents seems to be of the sort that we should just take the time to learn it.
I'm not sure what you're asking. Besides, if we're supposed to learn it, it should have good documentation and be a good thing first. Otherwise it's a waste of time.
Let me add a fourth question: What does it matter? We're not getting to decide what will be used.
Joe Zeff joe@zeff.us writes:
On 07/08/2014 11:40 PM, lee wrote:
When something is disguised or hidden, it is not disabled. It is camouflaged or concealed. Camouflage, concealment, hiding, disguise and masking can all be used for*preventing* from being disabled.
No. When a service is disabled it can still be started after boot, but when it's masked, it can't be started at all.
That the service can still be started means that it is *not* disabled.
Do understand that I'm defending neither systemd nor the deveolper's choice of terminology. I'm merely correcting what looks like a misstatement of how it works.
The bug --- or call it misstatement if you like --- is with systemd in that things can still be started even when they are disabled.
On Wed, 2014-07-09 at 09:49 +1000, Norman Gaywood wrote:
On 7 July 2014 08:34, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Sun, 2014-07-06 at 13:01 -0700, David Benfell wrote:
*What*, for example, is "the usual meaning" of "file system objects?" A file? Why not just say "file?" And if the documentation really means files or pipes or devices, then why not say "files or pipes or devices?"
I assume it means "something with a name in the filesystem".
What about a file without a name? :-)
If you delete all filenames of a file while it is opened by a process, it still uses filesystem space but has no name.
I know, but we're talking about things which can be referred to from elsewhere, meaning they have a name.
poc
Hi
On Wed, Jul 9, 2014 at 7:19 AM, lee wrote:
The bug --- or call it misstatement if you like --- is with systemd in that things can still be started even when they are disabled.
Err. no. Before systemd, the equivalent of mask simply didn't exist and there was no systematic way to disable dynamically started services. So in sysvinit, if a service is D-Bus activated, you had no good way to control that. systemd for the first time harmonized that process.
Rahul
On 7/9/2014 07:12, Rahul Sundaram wrote:
All major distributions at this point have switched to systemd or in the process of doing so which should tell you the value of it.
With respect, just because there is consensus among governing entities doesn't necessarily mean that the decision is good for everyone. Consensus != Fact. History is replete with examples.
I've been following this discussion and it appears obvious to me that there are some serious issues both philosophical and practical with the adoption of systemd. To dismiss these issues and assign worth to the adoption of systemd merely because, as you have said, "everyone else is doing it" sounds illogical and ill-advised.
My mom always said, "If everyone else is jumping off the bridge, would you follow?"
Tom
Allegedly, on or about 08 July 2014, David Benfell sent:
This is another terminology issue, which I think should be viewed separately from the merits/demerits of systemd itself. And I'm inclined to agree that the terms are poorly chosen.
If it'd been my choice, disabled would have meant exactly what the word suggests it means to the average person, and for services that could be run on-demand, would have used a status called on-demand.
It's be enough having to put up with real world metaphors being shoehorned into computing technology (e.g. desktops, folders, and files), but it's worse when illogically applied (where "disabled" simply means "not straight away").
Hi
On Wed, Jul 9, 2014 at 9:45 AM, Tom Rivers wrote:
With respect, just because there is consensus among governing entities doesn't necessarily mean that the decision is good for everyone. Consensus != Fact. History is replete with examples.
Sure but if you want to go against the consensus, you will have to do something more concrete. That is what history shows as well. The precise form of the course of action can be say rallying behind an alternative implementation and doing the work to demonstrate that it serves the needs that systemd does. So far, there are parts of systemd including logind which simply does not have any alternative that is actually maintained. One could develop such things or file bug reports against the only active implementation.
Rahul
On 7/9/2014 09:57, Rahul Sundaram wrote:
Sure but if you want to go against the consensus, you will have to do something more concrete.
That is precisely why I challenged your assertion that the value of systemd was because everyone was adopting it. The reason you gave for dismissing all of the gripes about systemd was anything but concrete.
So far, there are parts of systemd including logind which simply does not have any alternative that is actually maintained.
This is more of the kind of concrete argument I have come to expect from you from my time on these lists. So basically the world desperately needs what logind does and since there was no alternative, all the other negative aspects of systemd must be tolerated as a result. I'm willing to accept such reasoning if this is the case. No solution is ever perfect, to be sure.
I am more of a software developer than a system architecture person so I will freely admit to not understanding the nuances of the whole systemd adoption issue. However, my experience over the years with programming and system design make me sensitive to non-substantive arguments for the adoption of something new for its own sake.
Thanks for the clarification, Rahul.
Tom
Hi
On Wed, Jul 9, 2014 at 10:50 AM, Tom Rivers wrote:
On 7/9/2014 09:57, Rahul Sundaram wrote:
Sure but if you want to go against the consensus, you will have to do something more concrete.
That is precisely why I challenged your assertion that the value of systemd was because everyone was adopting it. The reason you gave for dismissing all of the gripes about systemd was anything but concrete.
You are conflating two different discussions here. I just pointed out that there is a consensus among a diverse set of distributions which have adopted systemd as the default in response to a discussion about voting in Debian. That has nothing to do with addressing potential issues. If there are concrete criticisms, they should ideally be in the form of bug reports to reach the developers directly. However when I come across misunderstandings, I point them out. I must note that so far haven't read much in the thread in terms of concrete issues and if there are any, burying it in the midst of a long thread isn't helpful which goes back to my suggestion on filing bug reports instead.
So basically the world desperately needs what logind does and since there
was no alternative, all the other negative aspects of >systemd must be tolerated as a result.
Well no, that isn't what I said but if anyone is pushing for alternatives, they should understand that systemd isn't just a init system and some of the tools that are part of systemd project have no real alternatives at all (logind is just one example). The interfaces are well documented and developing a replacement is feasible if needed (not that I buy into that claim).
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStab...
Rahul
Rahul
On Wed, 9 Jul 2014 11:57:26 -0400 Rahul Sundaram wrote:
if anyone is pushing for alternatives, they should understand that systemd isn't just a init system
Which is, of course, the primary thing that is wrong with it :-).
Unix/linux grew successfully for years by dividing things into small independent pieces and making them work on one thing well.
Systemd is now engulfing practically all of linux. A bug in one piece can make dozens of other things fail, and it is so large and complex that there *will* be bugs in pieces of it.
When there were separate bits, you could simply turn off the bits you had no need for.
A monolithic systemd can't be turned off or even down. In fact it has been instructive to watch the memory indicator in my gkrellm monitor on my not very big system at work. It has been steadily moving up every fedora release.
Hi
On Wed, Jul 9, 2014 at 12:24 PM, Tom Horsley wrote:
On Wed, 9 Jul 2014 11:57:26 -0400 Rahul Sundaram wrote:
if anyone is pushing for alternatives, they should understand that systemd isn't just a init system
Which is, of course, the primary thing that is wrong with it :-).
Unix/linux grew successfully for years by dividing things into small independent pieces and making them work on one thing well.
Systemd is now engulfing practically all of linux. A bug in one piece can make dozens of other things fail, and it is so large and complex that there *will* be bugs in pieces of it.
This isn't the case. systemd isn't monolithic. it is a collection of tools with a shared codebase where most of the tools are optional. Even Fedora doesn't use many of them yet although adoption of the tools will likely increase over time because they are actually useful which isn't something I can say about philosophical discussions.
Rahul
On Wed, 9 Jul 2014 12:43:57 -0400 Rahul Sundaram wrote:
This isn't the case. systemd isn't monolithic. it is a collection of tools with a shared codebase where most of the tools are optional.
Its a collection of tools, all of which talk to an ever increasing monolithic systemd daemon which now includes init, consolekit, xinetd, logind, dbusd, and God knows what else in a single program.
Just because the bloat also includes separate programs doesn't make the systemd daemon magically not be monolithic.
On Wed, Jul 09, 2014 at 01:15:53PM -0400, Tom Horsley wrote:
On Wed, 9 Jul 2014 12:43:57 -0400 Rahul Sundaram wrote:
This isn't the case. systemd isn't monolithic. it is a collection of tools with a shared codebase where most of the tools are optional.
Its a collection of tools, all of which talk to an ever increasing monolithic systemd daemon which now includes init, consolekit, xinetd, logind, dbusd, and God knows what else in a single program.
It consists of various programs, it is not one daemon/program.
Just because the bloat also includes separate programs doesn't make the systemd daemon magically not be monolithic.
Here you already mention it consists of various programs. Anyway, by your logic coreutils is bloat. Though with systemd you probably don't need it to boot a system :-P
Aside from this if you make a claim ("monolithic") as a response to someone explaining exactly why it isn't, saying it is so a pretty weak response.
On Wed, Jul 9, 2014 at 12:43 PM, Rahul Sundaram metherid@gmail.com wrote:
On Wed, Jul 9, 2014 at 12:24 PM, Tom Horsley wrote:
Systemd is now engulfing practically all of linux. A bug in one piece can make dozens of other things fail, and it is so large and complex that there *will* be bugs in pieces of it.
This isn't the case. systemd isn't monolithic. it is a collection of tools with a shared codebase where most of the tools are optional. Even Fedora doesn't use many of them yet although adoption of the tools will likely increase over time because they are actually useful which isn't something I can say about philosophical discussions.
This unfortunate meme's probably come about to counter silly accusations of "systemd isn't Unix" but it's just as silly as the accusation.
util-linux and coreutils are a collection of independent tools.
You might not need to use all of the systemd tools but its tools aren't independent. For example, Ubuntu patches logind in order to use it with upstart rather than with systemd.
Hi
On Wed, Jul 9, 2014 at 1:34 PM, Tom H wrote:
You might not need to use all of the systemd tools but its tools aren't independent.
That is similar to how optional features are handled in many collections. If you use some features, they might pull in other requirements but the features themselves are optional.
For example, Ubuntu patches logind in order to use it with upstart rather than with systemd.
systemd explicitly documented which interfaces they consider independent and which ones they don't and I linked to the document earlier. Ubuntu's use of logind is backporting + reimplementation of some interfaces using a shim and they are moving away from it to systemd itself since the reimplementation is lagging behind in features and functionality and the Debian move to systemd made it easier for them to follow that path.
Rahul
Rahul Sundaram metherid@gmail.com writes:
Hi
On Wed, Jul 9, 2014 at 3:03 AM, lee wrote:
Apparently the project secretary has a hand in it, and sponsors are needed. So maybe it's not as easy as it seems.
It is fairly easy to bring any proposal to vote. Debian has done it numerous times.
Then they should do it again.
Too bad that the users never get to vote.
There is no way to determine accurately who is a open source project user or who is a random troll online. You basically have to let the whole internet vote which I far from convince is a useful thing especially for system level software.
That doesn't mean that users shouldn't get to vote.
All major distributions at this point have switched to systemd or in the process of doing so which should tell you the value of it.
That someone or something switches to something doesn't mean that what is being switched to has any particular value or is any good.
I think in further posts you even say that there is no alternative available for things brought about by systemd. Switching to something because there is no alternative means that it wasn't possible to make a choice. Am I to assume that all major distributions were forced to use systemd?
I don't know about logind. Why would that be required? I can still log in without just fine when systemd isn't used.
Rahul Sundaram metherid@gmail.com writes:
If there are concrete criticisms, they should ideally be in the form of bug reports to reach the developers directly.
I made a bug report suggesting to fix their misunderstanding of what "disabled" means. It would have been very easy to fix, but they declined.
Why should I make any further bug reports about systemd when they don't want to even fix important things like this?
Rahul Sundaram metherid@gmail.com writes:
Hi
On Wed, Jul 9, 2014 at 7:19 AM, lee wrote:
The bug --- or call it misstatement if you like --- is with systemd in that things can still be started even when they are disabled.
Err. no. Before systemd, the equivalent of mask simply didn't exist and there was no systematic way to disable dynamically started services. So in sysvinit, if a service is D-Bus activated, you had no good way to control that. systemd for the first time harmonized that process.
That is irrelevant. I don't know what you don't understand --- "disabled" means disabled, i. e. cannot be started. Systemd is buggy because when you disable a service, the service can still be started. That means that the service is not disabled.
Besides, dbus shouldn't start any services, that would be insane.
Hi
On Wed, Jul 9, 2014 at 7:08 PM, lee wrote:
That is irrelevant.
How? The fact that dynamically started services can only directly be controlled by systemd in a systematic manner is directly relevant. It explains the real difference between disabled and mask.
I don't know what you don't understand --- "disabled" means disabled, i. e. cannot be started.
No. That isn't what it means in sysvinit. It simply means that it isn't started on boot.
Besides, dbus shouldn't start any services, that would be insane.
You can't just deny reality. d-bus is how services have dynamically been started by a number of years. Before systemd, there was no way other way to do it.
Rahul
Hi
On Wed, Jul 9, 2014 at 9:23 PM, lee wrote:
Then they should do it again.
That is a Debian maintainers decision.
That doesn't mean that users shouldn't get to vote.
It just means voting isn't how distribution choose system components.
Switching to something
because there is no alternative means that it wasn't possible to make a choice. Am I to assume that all major distributions were forced to use systemd?
Forced? This is open source software. If distributions wanted to have alternatives they are free to develop one or continue maintaining things like ConsoleKit. They voluntarily choose to use systemd because it was the best maintained choice
I don't know about logind. Why would that be required? I can still log in without just fine when systemd isn't used.
Perhaps you should look up what logind does yourself to understand why it is required. It is fairly basic information if you want to engage in a debate about systemd.
Rahul
Hi
On Wed, Jul 9, 2014 at 7:42 PM, lee wrote:
I made a bug report suggesting to fix their misunderstanding of what "disabled" means. It would have been very easy to fix, but they declined.
Why should I make any further bug reports about systemd when they don't want to even fix important things like this?
I would suggest that the misunderstanding is on your part instead as noted in another reply. However even if it weren't true, we all get bug reports closed from time to time with a resolution different from what we want. The right approach in that case is to post to the list and try and build consensus and provide strong arguments to make your case. If people agree with us, perhaps we can change the developers position but on the other hand, if we fail to build that consensus, we just agree to disagree and move on. If we take our balls and run home everytime someone disagrees with us, we can never really participate in any open source project.
Rahul
On Jul 9, 2014, at 8:20 PM, Rahul Sundaram metherid@gmail.com wrote:
would suggest that the misunderstanding is on your part instead as noted in another reply. However even if it weren't true, we all get bug reports closed from time to time with a resolution different from what we want. The right approach in that case is to post to the list and try and build consensus and provide strong arguments to make your case. If people agree with us, perhaps we can change the developers position but on the other hand, if we fail to build that consensus, we just agree to disagree and move on. If we take our balls and run home everytime someone disagrees with us, we can never really participate in any open source project.
I think every project has its own lexicon, and as long as what the words mean in the context of the project is clear, I really don't care.
Systemd has far more fundamental problems than what "disabled" is called vs. "masked".
While this has been an interesting discussion, I think it's probably well past time to put it to bed. My inbox is screaming for a break.
--Russell
On 9 July 2014 14:15, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Wed, Jul 9, 2014 at 7:19 AM, lee wrote:
The bug --- or call it misstatement if you like --- is with systemd in that things can still be started even when they are disabled.
Err. no. Before systemd, the equivalent of mask simply didn't exist and there was no systematic way to disable dynamically started services. So in sysvinit, if a service is D-Bus activated, you had no good way to control that. systemd for the first time harmonized that process.
The fact that this discussion keeps coming back and that it keeps catching people out is something of a symptom that the names have been chosen wrongly. Yes you could call it 'banana' when a service is off by default and started by demand and 'handkerchief' when it is prevented from starting altogether, but words that actually clued people in to what they did would be more useful. You could call off on and on off and tell people they're thick because they didn't RTFM. But it's not helpful. As it is, 'disabled' has turned out to be a highly confusing name for the state it has been used to describe since its use is slightly at odds with its everyday meaning and what turns out to be expected by people familiar with chkconfig (which you might not expect since it doesn't use the name itself, though its man page does choose to use 'to disable a service' to describe 'off').
On 07/10/14 16:03, Ian Malone wrote:
On 9 July 2014 14:15, Rahul Sundaram metherid@gmail.com wrote:
Hi
On Wed, Jul 9, 2014 at 7:19 AM, lee wrote:
The bug --- or call it misstatement if you like --- is with systemd in that things can still be started even when they are disabled.
Err. no. Before systemd, the equivalent of mask simply didn't exist and there was no systematic way to disable dynamically started services. So in sysvinit, if a service is D-Bus activated, you had no good way to control that. systemd for the first time harmonized that process.
The fact that this discussion keeps coming back and that it keeps catching people out is something of a symptom that the names have been chosen wrongly. Yes you could call it 'banana' when a service is off by default and started by demand and 'handkerchief' when it is prevented from starting altogether, but words that actually clued people in to what they did would be more useful. You could call off on and on off and tell people they're thick because they didn't RTFM. But it's not helpful. As it is, 'disabled' has turned out to be a highly confusing name for the state it has been used to describe since its use is slightly at odds with its everyday meaning and what turns out to be expected by people familiar with chkconfig (which you might not expect since it doesn't use the name itself, though its man page does choose to use 'to disable a service' to describe 'off').
I'm not confused.
Rahul Sundaram metherid@gmail.com writes:
Hi
On Wed, Jul 9, 2014 at 7:08 PM, lee wrote:
That is irrelevant.
How?
Because disabled means disabled and not something like ondemand.
I don't know what you don't understand --- "disabled" means disabled, i. e. cannot be started.
No. That isn't what it means in sysvinit. It simply means that it isn't started on boot.
When the starting of something is disabled, it cannot be started. It doesn't matter when you try to start it.
Besides, dbus shouldn't start any services, that would be insane.
You can't just deny reality. d-bus is how services have dynamically been started by a number of years. Before systemd, there was no way other way to do it.
Then it has been insane for years.
Rahul Sundaram metherid@gmail.com writes:
Hi
On Wed, Jul 9, 2014 at 9:23 PM, lee wrote:
Then they should do it again.
That is a Debian maintainers decision.
That doesn't mean that they shouldn't do it again.
That doesn't mean that users shouldn't get to vote.
It just means voting isn't how distribution choose system components.
Which doesn't mean that that it is a good way to do so.
Switching to something
because there is no alternative means that it wasn't possible to make a choice. Am I to assume that all major distributions were forced to use systemd?
Forced? This is open source software. If distributions wanted to have alternatives they are free to develop one or continue maintaining things like ConsoleKit. They voluntarily choose to use systemd because it was the best maintained choice
See, they didn't really have a choice. Developing an alternative or continuing to maintain alternatives requires resources which they might not have or rather devote to something else.
I don't know about logind. Why would that be required? I can still log in without just fine when systemd isn't used.
Perhaps you should look up what logind does yourself to understand why it is required. It is fairly basic information if you want to engage in a debate about systemd.
Again there's no argument here that speaks for systemd.
Rahul Sundaram metherid@gmail.com writes:
Hi
On Wed, Jul 9, 2014 at 7:42 PM, lee wrote:
I made a bug report suggesting to fix their misunderstanding of what "disabled" means. It would have been very easy to fix, but they declined.
Why should I make any further bug reports about systemd when they don't want to even fix important things like this?
I would suggest that the misunderstanding is on your part instead as noted in another reply.
Please look up the meaning of "disabled" in some dictionaries and ask some arbitrary people what it means.
However even if it weren't true, we all get bug reports closed from time to time with a resolution different from what we want. The right approach in that case is to post to the list and try and build consensus and provide strong arguments to make your case. If people agree with us, perhaps we can change the developers position but on the other hand, if we fail to build that consensus, we just agree to disagree and move on. If we take our balls and run home everytime someone disagrees with us, we can never really participate in any open source project.
First you (at least I think it was you) suggest to make bug reports instead of discussing things on a mailing list, now you suggest the opposite?
The bug report has been closed with a denial to fix the bug. That's all there is to it, with no point in trying to search for some sort of backdoor to bring it back. By denying to fix a bug this obvious, the developers are beyond hope. Try it if it pleases you to do their bidding.
I guess I could make a fork of systemd which fixes this bug. But nobody would care, so why waste my time on it.
On Wed, 2014-07-09 at 13:35 +0200, lee wrote:
David Benfell benfell@parts-unknown.org writes:
I guess the two questions I'm reaching for are:
- Is systemd conceptually broken, just a really bad idea from the
start? Some people say yes, and some of them argue well.
So far, I've seen only arguments that would support that systemd is a really bad idea because it's broken by design --- or should reasonably be designed differently.
- Or, is it just that systemd is buried underneath an avalanche of
horrendous documentation and poorly chosen terminology?
You could look at the source to find an answer. Perhaps it's great --- but I doubt it.
Seriously? Looking the source? Except developers who will dig in the source code? None user will dig the source code, they just will leave the distribution or worse the all Linux area if they can't solve their problem. I think, if the user can't find solution, (s)he will accept it, but if there will be too many, they just escape.
To these, I might add a third:
- Is systemd simply too large a leap to be wise? Clearly, many folks
in the distributions are enamored with it; they're all adopting it. As is apparent here, some users like it as well (and if we succumb to a false dichotomy, well, I'm not all that wild about sysvinit scripts either). And a certain amount of the rebuttal to opponents seems to be of the sort that we should just take the time to learn it.
I'm not sure what you're asking. Besides, if we're supposed to learn it, it should have good documentation and be a good thing first. Otherwise it's a waste of time.
Let me add a fourth question: What does it matter? We're not getting to decide what will be used.
-- Fedora release 20 (Heisenbug)
On 10.7.2014 13:30, Balint Szigeti wrote:
On Wed, 2014-07-09 at 13:35 +0200, lee wrote:
David Benfell <benfell@parts-unknown.org mailto:benfell@parts-unknown.org> writes:
I guess the two questions I'm reaching for are:
- Is systemd conceptually broken, just a really bad idea from the
start? Some people say yes, and some of them argue well.
So far, I've seen only arguments that would support that systemd is a really bad idea because it's broken by design --- or should reasonably be designed differently.
- Or, is it just that systemd is buried underneath an avalanche of
horrendous documentation and poorly chosen terminology?
You could look at the source to find an answer. Perhaps it's great --- but I doubt it.
Seriously? Looking the source? Except developers who will dig in the source code? None user will dig the source code, they just will leave the distribution or worse the all Linux area if they can't solve their problem. I think, if the user can't find solution, (s)he will accept it, but if there will be too many, they just escape.
Escape where, OSX has similar thing which seems to be even less documented (only my impression might be wrong). Solaris has moved something similar. AIX has never been truly SYSV and needs special hardware. BSD's will work but have their own set of fun and are geared in my experience more to people who like to mess with the code. And some of them are planning to move to the thing used in OSX (or in it's opensource upstream). Windows also has extensive ways to manage how processes will start in startup etc.
Maybe the thing is that world has moved forward and there is needs which traditional sysv init doesn't answer anymore. And any way you feel about systemd something similar would have come anyway and it actually did and people weren't happy so in came systemd instead. If there is real problems with systemd I am sure someone will sooner or later fork it and do different version. That's the choice in free/open software it's freedom of making your own if the current solution doesn't work for you. Nothing of this freedom is taken away.
It's just that those people who actually do work for getting the distributions out have seen that systemd is only maintained solution at the moment. I think it's somehow telling that no one else is even trying to make better solution to the problems. It doesn't mean there isn't ways to improve systemd (or make a replacement), it just means no one is willing to do it.
-vpk
On Wed, Jul 9, 2014 at 1:50 PM, Rahul Sundaram metherid@gmail.com wrote:
On Wed, Jul 9, 2014 at 1:34 PM, Tom H wrote:
You might not need to use all of the systemd tools but its tools aren't independent.
That is similar to how optional features are handled in many collections. If you use some features, they might pull in other requirements but the features themselves are optional.
For example, Ubuntu patches logind in order to use it with upstart rather than with systemd.
systemd explicitly documented which interfaces they consider independent and which ones they don't and I linked to the document earlier. Ubuntu's use of logind is backporting + reimplementation of some interfaces using a shim and they are moving away from it to systemd itself since the reimplementation is lagging behind in features and functionality and the Debian move to systemd made it easier for them to follow that path.
I understand and agree but nonetheless maintain that we shouldn't call systemd a "collection of tools with a shared codebase where most of the tools are optional" since the systemd executables aren't as independent of one another as those of util-linux and coreutils. Although you more or less hint at this with "with a shared codebase", most people don't.
(I use Ubuntu 14.10 on my laptop and systemd 204 is available so by the time that it's released systemd-shim might be relegated to 14.04 LTS.)
Everyone! Please read
https://lists.fedoraproject.org/pipermail/users/2014-July/451692.html
I am not kidding.
This morning, there are a dozen new messages all recycling around points that have already been made hundreds of posts ago in this thread. Regardless of the merit of these points, this is a vortex of echos. And, really, the merit is dubious even when the points are good -- systemd was selected for Fedora 15, and of course we're building 21 now. There's nothing here which wasn't weighed *years ago*. Overwhelming threads make our mailing lists useless to existing users and intimidating to new ones.
It's time to stop spinning in place and work on something constructive.
On Thu, Jul 10, 2014 at 4:34 AM, lee lee@yun.yagibdah.de wrote:
Rahul Sundaram metherid@gmail.com writes:
On Wed, Jul 9, 2014 at 7:42 PM, lee wrote:
I made a bug report suggesting to fix their misunderstanding of what "disabled" means. It would have been very easy to fix, but they declined.
Why should I make any further bug reports about systemd when they don't want to even fix important things like this?
I would suggest that the misunderstanding is on your part instead as noted in another reply.
Please look up the meaning of "disabled" in some dictionaries and ask some arbitrary people what it means.
There's a difference between "disabled" and "permanently disabled"; no need to look at a dictionary.
Did you see my earlier post about kernel module loading? [1]
A kernel module can be blacklisted but it can be loaded if need be. In the same way:
If A depends on B and B is masked: you start A, B doesn't start and A doesn't start.
If A depends on B and B is disabled: you start A, B starts and A starts.
[1] https://lists.fedoraproject.org/pipermail/users/2014-July/451640.html
On Thu, 2014-07-10 at 14:09 +0300, Veli-Pekka Kestilä wrote:
On 10.7.2014 13:30, Balint Szigeti wrote:
On Wed, 2014-07-09 at 13:35 +0200, lee wrote:
David Benfell benfell@parts-unknown.org writes:
I guess the two questions I'm reaching for are:
- Is systemd conceptually broken, just a really bad idea from the
start? Some people say yes, and some of them argue well.
So far, I've seen only arguments that would support that systemd is a really bad idea because it's broken by design --- or should reasonably be designed differently.
- Or, is it just that systemd is buried underneath an avalanche of
horrendous documentation and poorly chosen terminology?
You could look at the source to find an answer. Perhaps it's great --- but I doubt it.
Seriously? Looking the source? Except developers who will dig in the source code? None user will dig the source code, they just will leave the distribution or worse the all Linux area if they can't solve their problem. I think, if the user can't find solution, (s)he will accept it, but if there will be too many, they just escape.
Escape where, OSX has similar thing which seems to be even less documented (only my impression might be wrong). Solaris has moved something similar. AIX has never been truly SYSV and needs special hardware. BSD's will work but have their own set of fun and are geared in my experience more to people who like to mess with the code. And some of them are planning to move to the thing used in OSX (or in it's opensource upstream). Windows also has extensive ways to manage how processes will start in startup etc.
That's great. Because they don't have choice we can do everything with them. :( It looks like, a small group of the community makes decisions and the other people don't have choice. No alternatives.... :(
Maybe the thing is that world has moved forward and there is needs which traditional sysv init doesn't answer anymore. And any way you feel about systemd something similar would have come anyway and it actually did and people weren't happy so in came systemd instead. If there is real problems with systemd I am sure someone will sooner or later fork it and do different version. That's the choice in free/open software it's freedom of making your own if the current solution doesn't work for you. Nothing of this freedom is taken away.
It's just that those people who actually do work for getting the distributions out have seen that systemd is only maintained solution at the moment. I think it's somehow telling that no one else is even trying to make better solution to the problems. It doesn't mean there isn't ways to improve systemd (or make a replacement), it just means no one is willing to do it.
-vpk
On Thu, 10 Jul 2014 09:05:03 -0400 Matthew Miller mattdm@fedoraproject.org wrote:
Everyone! Please read
https://lists.fedoraproject.org/pipermail/users/2014-July/451692.html
I am not kidding.
This morning, there are a dozen new messages all recycling around points that have already been made hundreds of posts ago in this thread. Regardless of the merit of these points, this is a vortex of echos. And, really, the merit is dubious even when the points are good -- systemd was selected for Fedora 15, and of course we're building 21 now. There's nothing here which wasn't weighed *years ago*. Overwhelming threads make our mailing lists useless to existing users and intimidating to new ones.
It's time to stop spinning in place and work on something constructive.
Hey Folks.
I'm not a usual moderator of this list, but Matt asked me to step in and at least kill this thread.
Can we get back to:
"community assistance, encouragement, and advice for Fedora users. "
Thanks,
kevin