4:20 a.m.
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
9:07 p.m.
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.
--
Garry T. Williams
3:09 a.m.
On 07/10/14 16:03, Ian Malone wrote:
On 9 July 2014 14:15, Rahul Sundaram <metherid(a)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.
--
If you can't laugh at yourself, others will gladly oblige.
3:03 a.m.
On 9 July 2014 14:15, Rahul Sundaram <metherid(a)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').
--
imalone
http://ibmalone.blogspot.co.uk
9:39 a.m.
On Thu, 10 Jul 2014 09:05:03 -0400
Matthew Miller <mattdm(a)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
9:10 a.m.
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(a)parts-unknown.org> writes:
> >
> > > 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.
> >
> > 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.
> >
> > > 2) 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
8:38 a.m.
On Thu, Jul 10, 2014 at 4:34 AM, lee <lee(a)yun.yagibdah.de> wrote:
Rahul Sundaram <metherid(a)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
7:21 a.m.
On Wed, Jul 9, 2014 at 1:50 PM, Rahul Sundaram <metherid(a)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.)
5:30 a.m.
On Wed, 2014-07-09 at 13:35 +0200, lee wrote:
David Benfell <benfell(a)parts-unknown.org> writes:
> 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.
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.
> 2) 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:
>
> 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'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)
3:22 a.m.
Rahul Sundaram <metherid(a)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.
--
Fedora release 20 (Heisenbug)
9:34 p.m.
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
9:30 p.m.
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
8:23 p.m.
Rahul Sundaram <metherid(a)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.
--
Fedora release 20 (Heisenbug)
6:42 p.m.
Rahul Sundaram <metherid(a)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?
--
Fedora release 20 (Heisenbug)
6:08 p.m.
Rahul Sundaram <metherid(a)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.
--
Fedora release 20 (Heisenbug)
12:34 p.m.
On Wed, Jul 9, 2014 at 12:43 PM, Rahul Sundaram <metherid(a)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.
12:22 p.m.
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.
--
Regards,
Olav
12:15 p.m.
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.
11:43 a.m.
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
11:24 a.m.
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.
10:57 a.m.
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/InterfacePortabilityAndS...
Rahul
Rahul
9:50 a.m.
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
8:57 a.m.
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
8:57 a.m.
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").
--
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
8:45 a.m.
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
8:15 a.m.
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
8:02 a.m.
On Wed, 2014-07-09 at 09:49 +1000, Norman Gaywood wrote:
On 7 July 2014 08:34, Patrick O'Callaghan
<pocallaghan(a)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
6:35 a.m.
David Benfell <benfell(a)parts-unknown.org> writes:
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.
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.
2) 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:
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'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)
6:19 a.m.
Joe Zeff <joe(a)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.
--
Fedora release 20 (Heisenbug)
6:12 a.m.
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
4:41 a.m.
lee writes:
David Benfell <benfell(a)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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
2:36 a.m.
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.
2:25 a.m.
On 9 Jul 2014 00:33, "Rahul Sundaram" <metherid(a)gmail.com> wrote:
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.
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
2:03 a.m.
Rahul Sundaram <metherid(a)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.
--
Fedora release 20 (Heisenbug)
1:40 a.m.
David Benfell <benfell(a)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.
--
Fedora release 20 (Heisenbug)
6:49 p.m.
On 7 July 2014 08:34, Patrick O'Callaghan <pocallaghan(a)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.
--
Norman Gaywood, Computer Systems Officer
University of New England, Armidale,
NSW 2351, Australia
ngaywood(a)une.edu.au Phone: +61 (0)2 6773 2412
http://mcs.une.edu.au/~norm Fax: +61 (0)2 6773 3312
Please avoid sending me Word or Power Point attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
6:57 p.m.
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-8be09d59438b31c2a724547838f234cb...
Rahul
6:33 p.m.
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
11:45 a.m.
Joe Zeff <joe(a)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.
--
Fedora release 20 (Heisenbug)
5:46 p.m.
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..
5:35 p.m.
David Benfell <benfell(a)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.
--
Fedora release 20 (Heisenbug)
5:13 p.m.
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
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
5:07 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
4:18 p.m.
David Benfell <benfell(a)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:
https://lists.debian.org/debian-ctte/2014/02/msg00281.html
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?
--
Fedora release 20 (Heisenbug)
3:54 p.m.
Joe Zeff <joe(a)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.
--
Fedora release 20 (Heisenbug)
1:28 a.m.
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(a)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(a)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
1:17 a.m.
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
8:13 p.m.
lee writes:
Tom Horsley <horsley1953(a)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
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
7:06 p.m.
Patrick O'Callaghan <pocallaghan(a)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.
--
Fedora release 20 (Heisenbug)
5:27 p.m.
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 :-)
https://lkml.org/lkml/2014/4/2/420
I hope Linus is not influence for merger later on. I run BSD's
as well and this may bring difficulty.
7:37 p.m.
On 07/07/2014 04:47 PM, lee wrote:
Glenn Holmer<shadowm(a)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.
6:56 p.m.
Tom Horsley <horsley1953(a)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/
--
Fedora release 20 (Heisenbug)
6:47 p.m.
Glenn Holmer <shadowm(a)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?
--
Fedora release 20 (Heisenbug)
5:50 p.m.
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/420
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
5:57 p.m.
poma writes:
For you Roquefort will always be just a fungus.
It's beyond your comprehension.
Fascinating.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
5:53 p.m.
poma writes:
What is the "sediment" in the thread context?
I suspect the word that was meant here is 'sentiment'.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
5 p.m.
On 07.07.2014, Edward M wrote:
It may become problematic once KDBUS merges into the mainline
kernel.
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/420
4:27 p.m.
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
4:02 p.m.
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
3:39 p.m.
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..
1:38 p.m.
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 :-).
1:17 p.m.
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
12:17 p.m.
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
8:11 a.m.
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
8:02 a.m.
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.2F...
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.
--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."
6:19 a.m.
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
6:18 a.m.
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
6:16 a.m.
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
6 a.m.
Patrick O'Callaghan <pocallaghan(a)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".
--
Fedora release 20 (Heisenbug)
5:10 a.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
4:34 a.m.
Glenn Holmer <shadowm(a)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.
--
Fedora release 20 (Heisenbug)
4:07 a.m.
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.
--
Suvayu
Open source is the future. It sets us free.
4:03 a.m.
Michael Hennebry <hennebry(a)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 :(
--
Fedora release 20 (Heisenbug)
4:02 a.m.
Kevin Fenzi <kevin(a)scrye.com> writes:
On Sun, 6 Jul 2014 13:25:42 -0500 (CDT)
Michael Hennebry <hennebry(a)web.cs.ndsu.nodak.edu> wrote:
> On Sun, 6 Jul 2014, lee wrote:
>
> > Joe Zeff <joe(a)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.
--
Fedora release 20 (Heisenbug)
3:55 a.m.
On 07/06/2014 07:45 PM, lee wrote:
Joe Zeff <joe(a)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
3:51 a.m.
Ahmad Samir <ahmadsamir3891(a)gmail.com> writes:
On 06/07/14 18:44, lee wrote:
> Kevin Fenzi <kevin(a)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 ...
--
Fedora release 20 (Heisenbug)
3:40 a.m.
Sam Varshavchik <mrsam(a)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.
--
Fedora release 20 (Heisenbug)
3:38 a.m.
Garry T. Williams wrote:
There are a slew of references on the 'Net
Then give one ...
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin 2, Ireland
3:19 a.m.
Ed Greshko <ed.greshko(a)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?
--
Fedora release 20 (Heisenbug)
3:14 a.m.
Russell Miller <duskglow(a)gmail.com> writes:
On Jul 6, 2014, at 5:33 PM, David Benfell
<benfell(a)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.
--
Fedora release 20 (Heisenbug)
3:12 a.m.
Bill Oliver <vendor(a)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?
--
Fedora release 20 (Heisenbug)
3:08 a.m.
Kevin Fenzi <kevin(a)scrye.com> writes:
On Sun, 06 Jul 2014 18:18:46 +0200
lee <lee(a)yun.yagibdah.de> wrote:
> Kevin Fenzi <kevin(a)scrye.com> writes:
>
> > On Sun, 06 Jul 2014 09:52:24 +0200
> > lee <lee(a)yun.yagibdah.de> wrote:
> >
> >> Kevin Fenzi <kevin(a)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.
--
Fedora release 20 (Heisenbug)
9:57 p.m.
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
9:39 p.m.
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
8:12 p.m.
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
8:03 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
7:47 p.m.
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlO57hYACgkQ4JnKjVbCBvpVWACdEVPAcFiO4G0wSLAMqfqLrxXy
IMgAn1A4nzmJvCwgVlvIDL8KVrwDXH3U
=KzYF
-----END PGP SIGNATURE-----
7:40 p.m.
On Jul 6, 2014, at 5:33 PM, David Benfell <benfell(a)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(a)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
7:38 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
7:33 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
7:26 p.m.
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.
;-)
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
6:59 p.m.
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.
--
Garry T. Williams
6:40 p.m.
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlO53mkACgkQ4JnKjVbCBvosPgCeMtM9uiFVCXYpnwNghA8O+qrS
QwMAnRdb2zkhgoaTBPqLm2SyawjVfeGE
=gbot
-----END PGP SIGNATURE-----
6:36 p.m.
On 7-6-14 10:39:11 lee wrote:
"Garry T. Williams" <gtwilliams(a)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.
--
Garry T. Williams
6:35 p.m.
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(a)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(a)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
6:24 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On July 6, 2014 3:16:43 PM PDT, Olav Vitters <olav(a)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(a)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.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iQJfBAEBCgBJBQJTudqpQhxEYXZpZCBCZW5mZWxsICgqc2lnaCouIFRyeWluZyBh
Z2Fpbi4pIDxiZW5mZWxsQHBhcnRzLXVua25vd24ub3JnPgAKCRAVeuMeEjZgK4Sl
EACKEYyVWFnwDCYBlkjsZ7Dh3emvW1U+Jf6RZeoY79aOKE79sbMHGchTrqCY8RDu
dnx4kNE5pqaX9duN+kUvvxVdx4s1J68HyAufsZnMBXdC6Wdnp+v8ju1EanW+7L1Z
YQ3fOeDK208dfrzb/GFc3UEAYHSm+cVNKgoPe9fp9UJtcdm2fIlMxJtZsAL6RByd
uGjDzSDk0tCqgH2u58RHUsw3YgSa90ndM3Ueq16a1lbgn0CpL/CzI7awD09BOM7t
hW9Pxi/ICEtrWmbN9nZ223gtVeZqd80OHwsVGFx7O+bJlJ7vE38a/zelnlolGYc4
CPNhxMB1rRdyLcDUjM7IiYecanrANSBFaZMVJVjHl7e6VhD1FwPtXssdSIP2LZ5s
VxsOW2EM6OFPZkAgdIbVFmYitUPCWT9MKtP5upfAuM/1XLqUzTX37iSwH10zqcA7
NmLWn26LTFXl8YlxpAUvG10vNWeS39OJ/A32zp18qYFP21zR6XUTKrIugqEEKsff
mK/3qLDlbTEL9cWvtwoVhQlaGNv0Q+JCwC9jbr82r6kfijOe/vTX+OwhmjEIkjRh
1lRCdLoWTso+BXpE4YXodZRuErk7QSRupVHyCXpkBqH3sebUcrylbsPJVeJEVBli
/H9kNNUek5FkDdWg8PaW15U81ZyBTQYjslK7xfP2DE5Cfw==
=+ORG
-----END PGP SIGNATURE-----
4:23 p.m.
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
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
5:38 p.m.
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
5:36 p.m.
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.
5:35 p.m.
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
5:34 p.m.
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
5:28 p.m.
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
9:45 a.m.
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
5:16 p.m.
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
4:58 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
4:48 p.m.
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.
--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."
4:42 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
4:40 p.m.
On Sun, 6 Jul 2014, Kevin Fenzi wrote:
On Sun, 6 Jul 2014 13:25:42 -0500 (CDT)
Michael Hennebry <hennebry(a)web.cs.ndsu.nodak.edu> wrote:
> On Sun, 6 Jul 2014, lee wrote:
>
>> Joe Zeff <joe(a)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.
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods
3:48 p.m.
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.
3:43 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
3:43 p.m.
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.
--
Regards,
Olav
3:41 p.m.
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.
--
Regards,
Olav
3:34 p.m.
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 :-).
3:34 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
3:16 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
3:22 p.m.
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.
3:12 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
3:01 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
1:28 p.m.
On Sun, 6 Jul 2014 13:25:42 -0500 (CDT)
Michael Hennebry <hennebry(a)web.cs.ndsu.nodak.edu> wrote:
On Sun, 6 Jul 2014, lee wrote:
> Joe Zeff <joe(a)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
1:25 p.m.
On Sun, 6 Jul 2014, lee wrote:
Joe Zeff <joe(a)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.
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods
12:40 p.m.
On 06/07/14 18:44, lee wrote:
Kevin Fenzi <kevin(a)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.
--
Ahmad Samir
12:30 p.m.
On Sun, 06 Jul 2014 18:18:46 +0200
lee <lee(a)yun.yagibdah.de> wrote:
Kevin Fenzi <kevin(a)scrye.com> writes:
> On Sun, 06 Jul 2014 09:52:24 +0200
> lee <lee(a)yun.yagibdah.de> wrote:
>
>> Kevin Fenzi <kevin(a)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
12:15 p.m.
Patrick O'Callaghan <pocallaghan(a)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.
--
Fedora release 20 (Heisenbug)
12:08 p.m.
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.
--
Michael hennebry(a)web.cs.ndsu.NoDak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods
11:52 a.m.
Glenn Holmer <shadowm(a)lyonlabs.org> writes:
On 07/06/2014 03:53 AM, lee wrote:
> Glenn Holmer <shadowm(a)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?
http://www.lyonlabs.org/just-rtfm.jpg
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.
--
Fedora release 20 (Heisenbug)
11:49 a.m.
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 :-).
11:44 a.m.
Kevin Fenzi <kevin(a)scrye.com> writes:
On Sun, 06 Jul 2014 09:48:04 +0200
lee <lee(a)yun.yagibdah.de> wrote:
> David Benfell <benfell(a)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?
--
Fedora release 20 (Heisenbug)
11:37 a.m.
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.
--
Suvayu
Open source is the future. It sets us free.
11:18 a.m.
Kevin Fenzi <kevin(a)scrye.com> writes:
On Sun, 06 Jul 2014 09:52:24 +0200
lee <lee(a)yun.yagibdah.de> wrote:
> Kevin Fenzi <kevin(a)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?
--
Fedora release 20 (Heisenbug)
10:04 a.m.
On Sun, 06 Jul 2014 09:48:04 +0200
lee <lee(a)yun.yagibdah.de> wrote:
David Benfell <benfell(a)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
10:03 a.m.
On Sun, 06 Jul 2014 09:52:24 +0200
lee <lee(a)yun.yagibdah.de> wrote:
Kevin Fenzi <kevin(a)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
10:01 a.m.
On Sun, 06 Jul 2014 06:27:17 +0100
Balint Szigeti <balint.szgt(a)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
9:16 a.m.
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
9:04 a.m.
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.
--
Suvayu
Open source is the future. It sets us free.
9 a.m.
On 07/06/2014 03:53 AM, lee wrote:
Glenn Holmer <shadowm(a)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
--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."
6:30 a.m.
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/projec...
https://web.archive.org/web/20140603153419/http://0pointer.de/blog/projec...
For your comfort.
--
If you can't laugh at yourself, others will gladly oblige.
8:32 a.m.
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
8:21 a.m.
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
6:05 a.m.
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.
--
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
6:01 a.m.
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".
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin 2, Ireland
2:43 a.m.
Kevin Fenzi <kevin(a)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.
--
Fedora release 20 (Heisenbug)
5:32 a.m.
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".
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin 2, Ireland
4:37 a.m.
-----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(a)yun.yagibdah.de> wrote:
David Benfell <benfell(a)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(a)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 SIGNATURE-----
Version: APG v1.1.1
iQJfBAEBCgBJBQJTuRjaQhxEYXZpZCBCZW5mZWxsICgqc2lnaCouIFRyeWluZyBh
Z2Fpbi4pIDxiZW5mZWxsQHBhcnRzLXVua25vd24ub3JnPgAKCRAVeuMeEjZgK5FW
D/40127qgX4F9OcKxMDrE8qj6eQpjzOfJdk7ZoC7tqXMSAOWr+4+jTrA6k0pLU5L
fNLlUqv0tuRCM8AYwZwPcgTCDgBLywanBTE1HkxPuOnMlQ2+upXS+V340SjnqYnk
NOKguSpnfxmNb8mlec17o2LDRA0sNmAF+wtTF6VqZ9RAI5z970fyjnPfve56hqZJ
EVCYmD9oivzdrZclyQ8+uHbghH6OWwxbU8V7z9INoMwm1DHeYqcc6D7m5adPph6i
Sfwvnu0iRoPG5juLWK0E3bq27HwkZ5XzZ/oyZogmd4ywBlNJkzIftaYNpRAhm6mj
niPamLT1v9ytrVkfLs62U2ncibIMA2k9TJHRH8E7QksJr/GaAfp49SfEMVPMV6UT
SUxSYPFUQX00Iwj2ucg9Qnm/6ON9Uu6KggWO+YOwnQNFRfG98apg3KDxO5ynWGlT
39fnylYqO6c3l4CBnhpXEFWSDJK0BiJz7dyAhdL3ORnlldxGMwleVL4i4QIQWuW9
f0OqmvbKqGOtNfvOKb9OnaGZXQ3tSPzsz+NM3gPWblm7DyaemDal/qOD05HfZWX8
lefxc0umpj0ed9BcmpYGjcw5mnwsBnjVbDAZe6yRbLlqaVF0/myq+43N6xIO2ptX
5SKzvUpT9Qhm0udq7WxjkLHbaw2s7hZ28i+GGRsbMh5tTQ==
=PQkm
-----END PGP SIGNATURE-----
12:29 a.m.
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
3:53 a.m.
Glenn Holmer <shadowm(a)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?
--
Fedora release 20 (Heisenbug)
3:44 a.m.
Timothy Murphy <gayleard(a)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
...
--
Fedora release 20 (Heisenbug)
3:39 a.m.
"Garry T. Williams" <gtwilliams(a)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.
--
Fedora release 20 (Heisenbug)
2:55 a.m.
Tom Horsley <horsley1953(a)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.
--
Fedora release 20 (Heisenbug)
2:52 a.m.
Kevin Fenzi <kevin(a)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)
2:48 a.m.
David Benfell <benfell(a)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)
1:11 a.m.
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
12:33 a.m.
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
12:27 a.m.
On Sat, 2014-07-05 at 20:15 -0600, Kevin Fenzi wrote:
On Sat, 5 Jul 2014 22:10:40 -0400
Tom Horsley <horsley1953(a)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
12:13 a.m.
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
11:49 p.m.
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
11:34 p.m.
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).
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
9:15 p.m.
On Sat, 5 Jul 2014 22:10:40 -0400
Tom Horsley <horsley1953(a)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
9:10 p.m.
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 :-).
9 p.m.
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
--
If you can't laugh at yourself, others will gladly oblige.
8:56 p.m.
On Sat, 05 Jul 2014 18:40:42 -0700
David Benfell <benfell(a)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
8:48 p.m.
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.
8:47 p.m.
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. :-) :-)
--
If you can't laugh at yourself, others will gladly oblige.
8:40 p.m.
Kevin Fenzi writes:
On Sat, 05 Jul 2014 18:10:45 -0700
David Benfell <benfell(a)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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
8:29 p.m.
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlO4pl0ACgkQ4JnKjVbCBvqqiACffZt4XGBMKis8XbMRBz6V6Am4
6MEAnAkrcaLRDaABpE28qJwicrYHpnH/
=z5l8
-----END PGP SIGNATURE-----
8:26 p.m.
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.
--
_
°v°
/(_)\
^ ^ Mark LaPierre
Registered Linux user No #267004
https://linuxcounter.net/
****
8:25 p.m.
On Sat, 05 Jul 2014 18:10:45 -0700
David Benfell <benfell(a)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:0pointe...
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
7:48 p.m.
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_.28runl...
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."
7:09 p.m.
-----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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlO4k6oACgkQ4JnKjVbCBvptrQCeIJoEJ4jlpqlz6KzLb/qhdEFM
ceEAnjobwACkhpEnvujkpU3lXUHpHSad
=DOyQ
-----END PGP SIGNATURE-----
7:05 p.m.
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 :-).
7:01 p.m.
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
6:58 p.m.
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
6:30 p.m.
Allegedly, on or about 05 July 2014, Garry T. Williams sent:
Fails to load, here, does it work for you? I even left the browser
attempting it for a few minutes.
--
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
6:47 p.m.
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
6:41 p.m.
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
6:37 p.m.
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
6:33 p.m.
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.
6:21 p.m.
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!!!!
--
[tim@localhost ~]$ uname -rsvp
Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64
All mail to my mailbox is automatically deleted, there is no point
trying to privately email me, I will only read messages posted to the
public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
12:03 p.m.
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.
1:30 p.m.
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...
1:26 p.m.
On Sat, 05 Jul 2014 20:23:52 +0200
Timothy Murphy <gayleard(a)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
1:23 p.m.
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
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin 2, Ireland
1:12 p.m.
On Sat, 05 Jul 2014 20:05:37 +0200
Timothy Murphy <gayleard(a)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
1:05 p.m.
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.
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin 2, Ireland
1:01 p.m.
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.
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin 2, Ireland
1 p.m.
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.
9:11 a.m.
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..
9:03 a.m.
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
--
Garry T. Williams
8:54 a.m.
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
8:48 a.m.
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?
--
Garry T. Williams
8:44 a.m.
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.
--
Garry T. Williams
8:35 a.m.
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
8:33 a.m.
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
8:30 a.m.
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
8:10 a.m.
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"?
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
School of Mathematics, Trinity College, Dublin 2, Ireland
6:49 a.m.
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 :-).
6 a.m.
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
5:47 a.m.
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 :-).
10:27 p.m.
On Jul 9, 2014, at 8:20 PM, Rahul Sundaram <metherid(a)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
10:20 p.m.
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
5:27 a.m.
"Garry T. Williams" <gtwilliams(a)gmail.com> writes:
On 7-6-14 10:39:11 lee wrote:
> "Garry T. Williams" <gtwilliams(a)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.
--
Fedora release 20 (Heisenbug)
4:32 p.m.
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.
6:09 a.m.
On 10.7.2014 13:30, Balint Szigeti wrote:
On Wed, 2014-07-09 at 13:35 +0200, lee wrote:
> David Benfell <benfell(a)parts-unknown.org
<mailto:benfell@parts-unknown.org>> writes:
>
> > 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.
>
> 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.
>
> > 2) 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
3:34 a.m.
Rahul Sundaram <metherid(a)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.
--
Fedora release 20 (Heisenbug)
4:39 a.m.
-----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(a)yun.yagibdah.de> wrote:
Kevin Fenzi <kevin(a)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(a)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 SIGNATURE-----
Version: APG v1.1.1
iQJfBAEBCgBJBQJTuRlcQhxEYXZpZCBCZW5mZWxsICgqc2lnaCouIFRyeWluZyBh
Z2Fpbi4pIDxiZW5mZWxsQHBhcnRzLXVua25vd24ub3JnPgAKCRAVeuMeEjZgK8do
D/4suG+4bka2XzGLu1Hyx9+mfFnnO6OLu1yZYEPGVo4p1WT1CQOQalzSCiJ9vQFn
a+T534DTdhQGCxKIfxN+coio7+NUSn5e3g3W/jAubwMNEtFirX6E6Os5IIIptdZW
+O58nCWIhAbVruSaE8H2+r/BzfsU2tcldLECLtMZYb/wOuREltWJmzSoSjDt/1CN
f1kRB5bguVJgiF7YghrQDm6FjANogey5ZBGC/ifBfQ4Y3kzCDKEEV9nsZaCjvv6X
tmT5KCW1AeM313yYP7P7tcNvq9fyIACxi+jO5Hy9lwKP6oRHhTiJOKiu3oNfl6E6
YOuE3S4OqcPnITYv2coRAt7mfFIv+O97/hLTFFzk5ySko/eBHGfmqau35HGnxUhX
lCzfLI0jHryqeB5lNAHaSmOZOGA/H2GyVoqaLxwXw2wuJAOMCMdxhVg0TFX7Ymuw
QfN/tRfrodt2Wt5/RGm7hKKWu9NTLYHcO6SS93/UTNYMGO8+7V418V5JS6Acr4b9
uhZocok5SJc5vsiSrOGTAFjcuLd3vXlY/4K4xIQa5GrDr9vaLOSmzPjKqyf4m6oQ
SQy0di351dVLje7ClVb94oVynp+ouP4Wk7m2ClFkmQRv9midoNmRU7GJBM8WJn4Y
mQvty7caOZreBJ9EZObWI1lhb/v62UwDRxlSCWWyaTlFAQ==
=IAxI
-----END PGP SIGNATURE-----
8:10 p.m.
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.
--
David Benfell
See https://parts-unknown.org/node/2 if you do not understand the
attachment.
8:05 a.m.
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:39 a.m.
Rahul Sundaram <metherid(a)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.
--
Fedora release 20 (Heisenbug)
3:20 a.m.
On Wed, Jul 9, 2014 at 3:36 AM, Joe Zeff <joe(a)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".
12:50 p.m.
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
3595
days inactive
3600
days old
221 comments
34 participants
participants (34)
-
Adrian Sevcenco -
Ahmad Samir -
Alan Evans -
Balint Szigeti -
David Benfell -
Ed Greshko -
Edward M -
Garry Williams -
Glenn Holmer -
Heinz Diehl -
Ian Malone -
James Hogarth -
Joe Zeff -
Kevin Fenzi -
lee -
Mark LaPierre -
Matthew Miller -
Michael Hennebry -
Norman Gaywood -
Olav Vitters -
Patrick O'Callaghan -
poma -
Rahul Sundaram -
Rolf Turner -
Russell Miller -
Sam Varshavchik -
Suvayu Ali -
Tim -
Timothy Murphy -
Tom H -
Tom Horsley -
Tom Rivers -
Veli-Pekka Kestilä -
William Oliver