Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #7915 > unrolled thread

Why I dislike systemd

Back to article view | Back to comp.misc

Contents

  Why I dislike systemd Rich <rich@example.invalid> - 2015-06-15 10:04 +0000
    Re: Why I dislike systemd Huge <Huge@nowhere.much.invalid> - 2015-06-15 11:17 +0000
    Re: Why I dislike systemd Dan Espen <despen@verizon.net> - 2015-06-15 09:46 -0400
      Re: Why I dislike systemd RS Wood <rsw@therandymon.com> - 2015-06-15 17:24 +0300
        Re: Why I dislike systemd Marko Rauhamaa <marko@pacujo.net> - 2015-06-15 18:45 +0300
          Re: Why I dislike systemd Dan Espen <despen@verizon.net> - 2015-06-15 12:33 -0400
            Re: Why I dislike systemd Marko Rauhamaa <marko@pacujo.net> - 2015-06-15 21:16 +0300
              Re: Why I dislike systemd Dan Espen <despen@verizon.net> - 2015-06-15 15:19 -0400
                Re: Why I dislike systemd Marko Rauhamaa <marko@pacujo.net> - 2015-06-15 23:11 +0300
                  Re: Why I dislike systemd Dan Espen <despen@verizon.net> - 2015-06-15 16:53 -0400
                    Re: Why I dislike systemd Marko Rauhamaa <marko@pacujo.net> - 2015-06-16 00:14 +0300
                      Re: Why I dislike systemd Dan Espen <despen@verizon.net> - 2015-06-15 21:02 -0400
                        Re: Why I dislike systemd Marko Rauhamaa <marko@pacujo.net> - 2015-06-16 07:48 +0300
                          Re: Why I dislike systemd Dan Espen <despen@verizon.net> - 2015-06-16 11:08 -0400
          Re: Why I dislike systemd Richard Kettlewell <rjk@greenend.org.uk> - 2015-06-15 19:20 +0100
          Re: Why I dislike systemd Mike Spencer <mds@bogus.nodomain.nowhere> - 2015-06-15 16:19 -0300
        Re: Why I dislike systemd Richard Kettlewell <rjk@greenend.org.uk> - 2015-06-15 20:13 +0100
      Re: Why I dislike systemd Bob Eager <news0005@eager.cx> - 2015-06-15 15:50 +0000
        Re: Why I dislike systemd Dan Espen <despen@verizon.net> - 2015-06-15 12:14 -0400
        Re: Why I dislike systemd Richard Kettlewell <rjk@greenend.org.uk> - 2015-06-15 17:18 +0100

#7915 — Why I dislike systemd

http://www.steven-mcdonald.id.au/articles/systemd.shtml

Quoting from the URL above:

   As a Linux sysadmin in the 2010s, it's hard not to have an opinion on
   systemd. But what I find baffling about it is how divisive it is; nearly
   everyone (or at least the most vocal crowd) seems to either love it or
   hate it. When I tell people that systemd was the catalyst for my
   defection to OpenBSD last year, their usual reaction is to assume that I
   am part of the "hate it" group. Nope.

   In truth, systemd itself was a very small part of the reason I jumped
   ship. Its introduction made me realise two important things. First, the
   design problems with modern Linux run deeper than any one piece of
   software, I just hadn't noticed until I had a fresh one to learn.
   Second, and this is specific to Debian, the "universal operating system"
   mantra is fundamentally flawed; you cannot support all use cases when
   confronted with two alternatives that each function best when adopted to
   the exclusion of all others.

   But you didn't come here to read my life story. Back to systemd.

   Let me be clear. systemd is not the work of the devil, it probably
   doesn't contain any NSA backdoors, and it isn't the worst piece of
   software the big Linux distributions are shipping by default. It does
   address some real problems with Linux, and its approach does have its
   merits.

   It's often said that a half-truth is worse than a lie. In the case of
   systemd, a half-improvement is worse than a complete flop. People are
   focusing on the features they want to use and ignoring the ones that
   will come back to bite them later.

   No, my biggest problem with systemd is that it is repeating the mistakes
   of System V all over again. It's just given them a change of clothes to
   appeal to the 21st century.

   ...

[toc] | [next] | [standalone]

#7916

On 2015-06-15, Rich <rich@example.invalid> wrote:
> http://www.steven-mcdonald.id.au/articles/systemd.shtml
>
> Quoting from the URL above:

[28 lines snipped]

>    No, my biggest problem with systemd is that it is repeating the mistakes
>    of System V all over again. It's just given them a change of clothes to
>    appeal to the 21st century.

Speaking as someone poised on the brink of retirement, I wonder if this
is related to the fact that the computer industry is now sufficiently
old that all the people from the early days are retiring and/or dying
and taking their experience with them?

I'm sure getting tired of seeing the same stuff come around for the third
time ...

-- 
Today is Sweetmorn, the 20th day of Confusion in the YOLD 3181
                  I don't have an attitude problem.
    If you have a problem with my attitude, that's your problem.

[toc] | [prev] | [next] | [standalone]

#7918

Rich <rich@example.invalid> writes:

> http://www.steven-mcdonald.id.au/articles/systemd.shtml
>
> Quoting from the URL above:
>

First real claim of a problem:

  It's unpredictable

  Log into a computer running systemd. Try to find the answer to "which
  units are going to be started on next boot?".


I'm not an expert but it looks like:

systemctl list-units

is the answer.  list-units is the "default command",
so just typing 'systemctl' is sufficient.

No reason to finish reading the article...

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#7919

... and that's the real issue, isn't it, that a huge proportion of 
the complaining turns out to be uneducated or misinformed.  I'm 
not convinced I like systemd, but I'm not convinced I dislike it, 
either.  I do agree init could use an update.

At a minimum, the ongoing debate is leading to some interesting 
alternatives, like the EpochInit system I linked to earlier this 
week, openRC (there was just a mention of it in a Manjaro 
article), or that one with the humorous name, uselessd.  In fact, 
I googled it and came up with this page:
http://alternativeto.net/software/systemd/
and was surprised by how many alternatives there are.  Let the
best technical solution prevail!

[toc] | [prev] | [next] | [standalone]

#7920

RS Wood <rsw@therandymon.com>:

> ... and that's the real issue, isn't it, that a huge proportion of the
> complaining turns out to be uneducated or misinformed.

Much of the complaining seems to come from the system administrators'
corner. Veteran UNIX system administrators have wanted to feel they have
the ultimate power over their systems. They don't really acknowledge the
existence of black boxes. The system components are just that:
components, and the system administrator is the divine being that moulds
the system into his own image.

Now, systemd is part of a grand scheme to tie the hands of the system
administrators. Instead of Super-Users, they are demoted into lowly
operators, who are given very limited degrees of freedom. They hate
that.

> I'm not convinced I like systemd, but I'm not convinced I dislike it,
> either. I do agree init could use an update.

As a developer, I'm big on black boxes. Crystal-clear inputs, outputs,
policies and protocols make it possible to build and maintain complex
systems. Improvising leads to nightmarish situations. In one company, we
seriously considered encrypting the configuration files because our
customers and sales engineers took too many liberties with them.

Unfortunately, systemd does not replace the improvised mess that is
init.d with a rigorous methodology. For example, who is supposed to
write the systemd configuration file for the "postfix" MTA?

 (a) the system administrator

 (b) the distro maker

 (c) the "postfix" developers

As it stands, the distro makers took on that responsibility for
political reasons. However, the distro maker is not going to include the
systemd configuration for my new service. So am I, the developer,
supposed to write the systemd configuration files or is that a job for
my customer, the system administrator?

I suppose that's a job for me, the developer. However, I run into many
small issues:

 * How do I quote an arbitrary command into an ExecStart entry?

 * Where do I place my .service file?

 * What are the correct systemd targets to depend on?

Distro documentation caters to the system administrator. What I need is
developer guides for the different distros.

[Analogous problems plague also SELinux. Systemd is a piece of cake
compared to SELinux.]

> In fact, I googled it and came up with this page:
> http://alternativeto.net/software/systemd/ and was surprised by how
> many alternatives there are. Let the best technical solution prevail!

Technical superiority is a moot point. If you develop for RedHat or
Debian, you integrate with systemd, period. You don't go against systemd
any more than you would choose a BSD system call on Linux because you
think it's technically superior.


Marko

[toc] | [prev] | [next] | [standalone]

#7925

Marko Rauhamaa <marko@pacujo.net> writes:

> RS Wood <rsw@therandymon.com>:
>
>> ... and that's the real issue, isn't it, that a huge proportion of the
>> complaining turns out to be uneducated or misinformed.
>
> Much of the complaining seems to come from the system administrators'
> corner. Veteran UNIX system administrators have wanted to feel they have
> the ultimate power over their systems. They don't really acknowledge the
> existence of black boxes. The system components are just that:
> components, and the system administrator is the divine being that moulds
> the system into his own image.
>
> Now, systemd is part of a grand scheme to tie the hands of the system
> administrators. Instead of Super-Users, they are demoted into lowly
> operators, who are given very limited degrees of freedom. They hate
> that.
>
>> I'm not convinced I like systemd, but I'm not convinced I dislike it,
>> either. I do agree init could use an update.
>
> As a developer, I'm big on black boxes. Crystal-clear inputs, outputs,
> policies and protocols make it possible to build and maintain complex
> systems. Improvising leads to nightmarish situations. In one company, we
> seriously considered encrypting the configuration files because our
> customers and sales engineers took too many liberties with them.
>
> Unfortunately, systemd does not replace the improvised mess that is
> init.d with a rigorous methodology.

How are the .service files not a rigorous methodology?
They beat scripts to death on that front.

> For example, who is supposed to
> write the systemd configuration file for the "postfix" MTA?
>
>  (a) the system administrator
>
>  (b) the distro maker
>
>  (c) the "postfix" developers

Since the developers don't know the names of other services
that a .service may need, the distro.

> As it stands, the distro makers took on that responsibility for
> political reasons.

Technical reasons as explained above.

> However, the distro maker is not going to include the
> systemd configuration for my new service. So am I, the developer,
> supposed to write the systemd configuration files or is that a job for
> my customer, the system administrator?

Your job.  No one else has the info.

> I suppose that's a job for me, the developer. However, I run into many
> small issues:
>
>  * How do I quote an arbitrary command into an ExecStart entry?

Looks like you just type the command without quotes.  If you need
substitution,  there are things like %I, %f allowed.  Read the docs.
man systemd.service(5).

>  * Where do I place my .service file?

man systemd look for DIRECTORIES

>  * What are the correct systemd targets to depend on?

I think that's at the distro level, but I expect that most distros use
the same names for their .service files.

> Distro documentation caters to the system administrator. What I need is
> developer guides for the different distros.

I have not observed anything like that.

> [Analogous problems plague also SELinux. Systemd is a piece of cake
> compared to SELinux.]

Right after I install, selinux gets removed/disabled.

>> In fact, I googled it and came up with this page:
>> http://alternativeto.net/software/systemd/ and was surprised by how
>> many alternatives there are. Let the best technical solution prevail!
>
> Technical superiority is a moot point. If you develop for RedHat or
> Debian, you integrate with systemd, period. You don't go against systemd
> any more than you would choose a BSD system call on Linux because you
> think it's technically superior.

I haven't seen an alternative I'd consider an improvement.

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#7926

Dan Espen <despen@verizon.net>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> For example, who is supposed to write the systemd configuration file
>> for the "postfix" MTA?
>>
>>  (a) the system administrator
>>
>>  (b) the distro maker
>>
>>  (c) the "postfix" developers
>
> Since the developers don't know the names of other services that a
> .service may need, the distro.
>
>> As it stands, the distro makers took on that responsibility for
>> political reasons.
>
> Technical reasons as explained above.
>
>> However, the distro maker is not going to include the
>> systemd configuration for my new service. So am I, the developer,
>> supposed to write the systemd configuration files or is that a job for
>> my customer, the system administrator?
>
> Your job.  No one else has the info.

First you say, the distro, and now, it's the developer. So the reason is
political, not technical ("postfix" developers don't provide systemd
files so RedHat will have to).

>>  * How do I quote an arbitrary command into an ExecStart entry?
>
> Looks like you just type the command without quotes.

It's more complicated than that.

What if the command pathname contains a space character?

<URL: http://www.freedesktop.org/software/systemd/man/systemd.servic
e.html> states:

  The command to execute must an absolute path name. It may contain
  spaces, but control characters are not allowed.

So how does one express whitespace? Quotes are not allowed in the
command name because the first character must be a slash (/).

Furthermore, the rest of the arguments are quoted in a complex, yet
barely documented manner. I ended up enclosing the startup logic in a
bash script and invoking that script from the .service file.

>>  * Where do I place my .service file?
>
> man systemd look for DIRECTORIES

We concluded as much: /usr/lib/systemd/system. The man page advises to
consult pkg-config, but pkg-config might not be available on the target
machine, IIRC.

>> [Analogous problems plague also SELinux. Systemd is a piece of cake
>> compared to SELinux.]
>
> Right after I install, selinux gets removed/disabled.

As a developer, I don't have that privilege. I have to do the "right
thing" for the user, who could depend on systemd and selinux.


Marko

[toc] | [prev] | [next] | [standalone]

#7930

Marko Rauhamaa <marko@pacujo.net> writes:

> Dan Espen <despen@verizon.net>:
>
>> Marko Rauhamaa <marko@pacujo.net> writes:
>>> For example, who is supposed to write the systemd configuration file
>>> for the "postfix" MTA?
>>>
>>>  (a) the system administrator
>>>
>>>  (b) the distro maker
>>>
>>>  (c) the "postfix" developers
>>
>> Since the developers don't know the names of other services that a
>> .service may need, the distro.
>>
>>> As it stands, the distro makers took on that responsibility for
>>> political reasons.
>>
>> Technical reasons as explained above.
>>
>>> However, the distro maker is not going to include the
>>> systemd configuration for my new service. So am I, the developer,
>>> supposed to write the systemd configuration files or is that a job for
>>> my customer, the system administrator?
>>
>> Your job.  No one else has the info.
>
> First you say, the distro, and now, it's the developer. So the reason is
> political, not technical ("postfix" developers don't provide systemd
> files so RedHat will have to).

Maybe I mis-read the question, but the question seemed to be about "my new
service".  How does the distro know anything about a user developed
service.
If the question is about postfix, the distro does the service file.

>>>  * How do I quote an arbitrary command into an ExecStart entry?
>>
>> Looks like you just type the command without quotes.
>
> It's more complicated than that.
>
> What if the command pathname contains a space character?
>
> <URL: http://www.freedesktop.org/software/systemd/man/systemd.servic
> e.html> states:
>
>   The command to execute must an absolute path name. It may contain
>   spaces, but control characters are not allowed.
>
> So how does one express whitespace? Quotes are not allowed in the
> command name because the first character must be a slash (/).
>
> Furthermore, the rest of the arguments are quoted in a complex, yet
> barely documented manner. I ended up enclosing the startup logic in a
> bash script and invoking that script from the .service file.

Without reading the man page, I'm going to guess the space in a command
would be backslashed.

Now I read the command line section and it doesn't seem specific on
the backslash, but I still think it will work.
They do mention if you desire all the features of a shell command line
you can get them by doing soemthing like:

           ExecStart=/bin/sh -c 'dmesg | tac'


-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#7932

Dan Espen <despen@verizon.net>:

> Maybe I mis-read the question, but the question seemed to be about "my
> new service". How does the distro know anything about a user developed
> service. If the question is about postfix, the distro does the service
> file.

Well, there's a double standard. That's for sure. In particular, it
isn't clear what is meant to be the division of labor between the
sysadmin, the distro and the developer. It's not spelled out.

Could the sysadmin replace the distro-provided systemd files? Should
they? Should the developer be prepared for the sysadmin to override the
developer's settings? These issues should be spelled out in the
developer's guide as well as the sysadmin's guide.

> Without reading the man page, I'm going to guess the space in a
> command would be backslashed.
>
> Now I read the command line section and it doesn't seem specific on
> the backslash, but I still think it will work. They do mention if you
> desire all the features of a shell command line you can get them by
> doing soemthing like:
>
>            ExecStart=/bin/sh -c 'dmesg | tac'

Unfortunately, they didn't provide a precise spec. The bit they did
provide was messy including all kinds of backslashing, quoting and
double dollar signs. It would have been helpful to provide an algorithm
(a python program, perhaps) that quotes an arbitrary argv[] onto the
ExecStart line.

What's more, the ExecStart escaping is not applicable to all settings.
So each setting is parsed differently.

(You really can't do it from the man page alone. I've fought my way
through much of this stuff putting together a product.)


Marko

[toc] | [prev] | [next] | [standalone]

#7933

Marko Rauhamaa <marko@pacujo.net> writes:

> Dan Espen <despen@verizon.net>:
>
>> Maybe I mis-read the question, but the question seemed to be about "my
>> new service". How does the distro know anything about a user developed
>> service. If the question is about postfix, the distro does the service
>> file.
>
> Well, there's a double standard. That's for sure. In particular, it
> isn't clear what is meant to be the division of labor between the
> sysadmin, the distro and the developer. It's not spelled out.
>
> Could the sysadmin replace the distro-provided systemd files? Should
> they? Should the developer be prepared for the sysadmin to override the
> developer's settings? These issues should be spelled out in the
> developer's guide as well as the sysadmin's guide.

Very unclear to me what you are getting at.

For any common administrative function, I would expect a command line
tool and a gui tool to change the setting.

I would NOT expect that setting to be in a .service file.

So, what are the cases where .service files need to be changed?
Probably similar to the cases where we changed start/stop scripts.
Debugging.  There are no rules for that kind of thing.

Still, if you think something is missing, it's not going to get
fixed by magic.

>> Without reading the man page, I'm going to guess the space in a
>> command would be backslashed.
>>
>> Now I read the command line section and it doesn't seem specific on
>> the backslash, but I still think it will work. They do mention if you
>> desire all the features of a shell command line you can get them by
>> doing soemthing like:
>>
>>            ExecStart=/bin/sh -c 'dmesg | tac'
>
> Unfortunately, they didn't provide a precise spec. The bit they did
> provide was messy including all kinds of backslashing, quoting and
> double dollar signs. It would have been helpful to provide an algorithm
> (a python program, perhaps) that quotes an arbitrary argv[] onto the
> ExecStart line.
>
> What's more, the ExecStart escaping is not applicable to all settings.
> So each setting is parsed differently.
>
> (You really can't do it from the man page alone. I've fought my way
> through much of this stuff putting together a product.)

Ideally, the man page should be sufficient.
The way to make that happen is to send bug reports.

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#7934

Dan Espen <despen@verizon.net>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> Could the sysadmin replace the distro-provided systemd files? Should
>> they? Should the developer be prepared for the sysadmin to override the
>> developer's settings? These issues should be spelled out in the
>> developer's guide as well as the sysadmin's guide.
>
> [...]
>
> So, what are the cases where .service files need to be changed?

Don't know. Where is it explained?

As it stands, I have had to make the product treat .service files
analogously to configuration files. Product updates must honor possible
manual changes made by the sysadmin.

The answer could probably be gleaned from RedHat's source RPMs. The
question is if the .service files are tagged with %config. If the
sysadmin edits a .service file, can it jeopardize a distro upgrade?


Marko

[toc] | [prev] | [next] | [standalone]

#7935

Marko Rauhamaa <marko@pacujo.net> writes:

> Dan Espen <despen@verizon.net>:
>
>> Marko Rauhamaa <marko@pacujo.net> writes:
>>> Could the sysadmin replace the distro-provided systemd files? Should
>>> they? Should the developer be prepared for the sysadmin to override the
>>> developer's settings? These issues should be spelled out in the
>>> developer's guide as well as the sysadmin's guide.
>>
>> [...]
>>
>> So, what are the cases where .service files need to be changed?
>
> Don't know. Where is it explained?

Where is what explained?

> As it stands, I have had to make the product treat .service files
> analogously to configuration files. Product updates must honor possible
> manual changes made by the sysadmin.
>
> The answer could probably be gleaned from RedHat's source RPMs. The
> question is if the .service files are tagged with %config. If the
> sysadmin edits a .service file, can it jeopardize a distro upgrade?

If you change a distro file you might get an .rpmnew file
instead of an updated config file.

I have 3 on my system right now.

I've never had one cause a problem,


-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#7936

Dan Espen <despen@verizon.net>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> The answer could probably be gleaned from RedHat's source RPMs. The
>> question is if the .service files are tagged with %config. If the
>> sysadmin edits a .service file, can it jeopardize a distro upgrade?
>
> If you change a distro file you might get an .rpmnew file instead of
> an updated config file.

Yes, if the RPM spec file marked the file with %config.

In fact, the answer (for Fedora) is here:

   Systemd unit .service files must not be marked as %config files.

   <URL: https://fedoraproject.org/wiki/Packaging:Systemd#EnvironmentFile
   s_and_support_for_.2Fetc.2Fsysconfig_files>

That means the .service files must be regarded as untouchable "binary"
files.


Marko

[toc] | [prev] | [next] | [standalone]

#7941

Marko Rauhamaa <marko@pacujo.net> writes:

> Dan Espen <despen@verizon.net>:
>
>> Marko Rauhamaa <marko@pacujo.net> writes:
>>> The answer could probably be gleaned from RedHat's source RPMs. The
>>> question is if the .service files are tagged with %config. If the
>>> sysadmin edits a .service file, can it jeopardize a distro upgrade?
>>
>> If you change a distro file you might get an .rpmnew file instead of
>> an updated config file.
>
> Yes, if the RPM spec file marked the file with %config.
>
> In fact, the answer (for Fedora) is here:
>
>    Systemd unit .service files must not be marked as %config files.
>
>    <URL: https://fedoraproject.org/wiki/Packaging:Systemd#EnvironmentFile
>    s_and_support_for_.2Fetc.2Fsysconfig_files>
>
> That means the .service files must be regarded as untouchable "binary"
> files.

Interesting.

We're left with the mystery of why you think "don't change"
and binary are synonyms.

If you want to turn on debug or run some other test, I see no
reason why they can't be changed.   If you just want to read
them, they are definitely not binary.


-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#7927

Marko Rauhamaa <marko@pacujo.net> writes:
> Unfortunately, systemd does not replace the improvised mess that is
> init.d with a rigorous methodology. For example, who is supposed to
> write the systemd configuration file for the "postfix" MTA?
>
>  (a) the system administrator
>
>  (b) the distro maker
>
>  (c) the "postfix" developers
>
> As it stands, the distro makers took on that responsibility for
> political reasons. However, the distro maker is not going to include the
> systemd configuration for my new service. So am I, the developer,
> supposed to write the systemd configuration files or is that a job for
> my customer, the system administrator?

I don’t really see why it’s the init system’s job to say who will do
that, or how it would enforce if it tried to.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#7931

Marko Rauhamaa <marko@pacujo.net> writes:

> Much of the complaining seems to come from the system administrators'
> corner. Veteran UNIX system administrators have wanted to feel they have
> the ultimate power over their systems. 

Never been a pro sysadmin or paid IT person, just former Unix user now
running Linux on the desk and the lap.  And I want to feel I have that
ultimate power over my systems.

> They don't really acknowledge the existence of black boxes. The
> system components are just that: components, and the system
> administrator is the divine being that moulds the system into his
> own image.
> 
> Now, systemd is part of a grand scheme to tie the hands of the system
> administrators. Instead of Super-Users, they are demoted into lowly
> operators, who are given very limited degrees of freedom. They hate
> that.

If systemd ties my hands like that, then I, too, shall hate it.

By analogy with physical objects, used to be that if you wanted to
know how something worked, you took out the screws and bolts, took it
apart, then put it back together [1], tightened the screws and bolts.
When they make devices that are glued shut [2], moulded in place,
assembled with destroy-to-remove snap joints or other black-box
tricks, you have to go to extreme, sometimes unsuccessful, length to
find out how something works.  This is an affront to all
right-thinking persons.

> [snip]
>
> Unfortunately, systemd does not replace the improvised mess that is
> init.d with a rigorous methodology. For example, who is supposed to
> write the systemd configuration file for the "postfix" MTA?

Mantra for the 21st century: Life-long learning is supposed to be
about learning *new* stuff, not about learning the same stuff over and
over as new  and putatively cool clothing/UI/experience-enhancements
are devised for it.  Word.

>  Improvising leads to nightmarish situations. 

Yeah.  I find my systems growing slightly nightmarish as I devise ad
hoc ways to defeat or subvert all the cool improvement crap that shows
up with every new release or version of almost everything.


- Mike


[1] Yes, there was the occasional pingfukkit, typically tiny or
    numerous spring-loaded parts that tended to end up in the far
    corner of the shop.  Experience taught you how to anticipate and
    deal with these.

[2] I recently found a device assembled with a screw which was
    apparently used just to hold it together with the glue set.
    Removing the non-functional screw still required defeating the
    glued housing. This actually cost *more* to do than just using the
    screw would have. Abstrads.

-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#7929

RS Wood <rsw@therandymon.com> writes:
> ... and that's the real issue, isn't it, that a huge proportion of the
> complaining turns out to be uneducated or misinformed.  I'm not
> convinced I like systemd, but I'm not convinced I dislike it, either.
> I do agree init could use an update.
>
> At a minimum, the ongoing debate is leading to some interesting
> alternatives, like the EpochInit system I linked to earlier this week,
> openRC (there was just a mention of it in a Manjaro article), or that
> one with the humorous name, uselessd.  In fact, I googled it and came
> up with this page:
> http://alternativeto.net/software/systemd/
> and was surprised by how many alternatives there are.  Let the
> best technical solution prevail!

It’s been an ongoing debate for many years, perhaps starting with SMF
and picking up pace with launchd and its failure to achieve adoption
outside Apple (about 10Y ago).

https://www.marc.info/?l=debian-user&m=141545953707862&w=1 mentions some
other contributions to the conversation.

The tricky bit is that integrators have to actually decide what to use
and what to support, and make it work (and keep it working as the
surrounding environment evolves), rather than just coming up with
interesting projects.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#7921

On Mon, 15 Jun 2015 09:46:50 -0400, Dan Espen wrote:

> I'm not an expert but it looks like:
> 
> systemctl list-units
> 
> is the answer.  list-units is the "default command",
> so just typing 'systemctl' is sufficient.

Does that list for the current boot, or the next boot?

[toc] | [prev] | [next] | [standalone]

#7922

Bob Eager <news0005@eager.cx> writes:

> On Mon, 15 Jun 2015 09:46:50 -0400, Dan Espen wrote:
>
>> I'm not an expert but it looks like:
>> 
>> systemctl list-units
>> 
>> is the answer.  list-units is the "default command",
>> so just typing 'systemctl' is sufficient.
>
> Does that list for the current boot, or the next boot?

It looks to me like it's listing stuff installed but not disabled.
So, both.

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#7924

Bob Eager <news0005@eager.cx> writes:
> On Mon, 15 Jun 2015 09:46:50 -0400, Dan Espen wrote:
>> I'm not an expert

ditto

>> but it looks like:
>> 
>> systemctl list-units
>> 
>> is the answer.  list-units is the "default command",
>> so just typing 'systemctl' is sufficient.
>
> Does that list for the current boot, or the next boot?

It don’t think it’ll reliably tell you the next-boot behavior.  For
instance if a unit file has been modified but systemd not yet reloaded,
there’ll be a difference.  However apart from that detail I think Dan’s
right.

This is one of the other things the linked article complains about, but
AFAICS it’s no different from the behavior of many other Unix daemons -
if you modify the config file then you need to tell the daemon to reload
it.  (e.g. /etc/inittab with sysv init.)

Moreover, sysvinit can’t tell you next-boot behavior with much
certainty.  You can get an idea of which init scripts will be run by
looking in the rc[2-5].d directories but their behavior depends on
configuration files and, potentially, on anything else you can encode in
a shell script.  A human may inspect them all to see what they’ll do but
a machine can’t determine what actually gets started other than by
running them.

So, even to the extent that the complaint is justified, there doesn’t
seem to be any regression from sysvinit on this point.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.misc

csiph-web