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

Groups > comp.misc > #5429 > unrolled thread

Lunduke says "lxde desktop is nothing to write home about"

Back to article view | Back to comp.misc

Contents

  Lunduke says "lxde desktop is nothing to write home about" RS Wood  <rsw@therandymon.com> - 2014-10-24 20:41 +0000
    Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-10-24 23:57 +0300
      Re: Lunduke says "lxde desktop is nothing to write home about" Rich <rich@example.invalid> - 2014-10-25 01:55 +0000
        Re: Lunduke says "lxde desktop is nothing to write home about" RS Wood <rsw@therandymon.com> - 2014-10-26 19:23 +0000
      Re: Lunduke says "lxde desktop is nothing to write home about" Anssi Saari <as@sci.fi> - 2014-10-27 22:17 +0200
        Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-10-27 22:56 +0200
          Re: Lunduke says "lxde desktop is nothing to write home about" Kara M'bola <maxupixu@in.val.it> - 2014-10-28 11:27 +0000
        Re: Lunduke says "lxde desktop is nothing to write home about" "D.D." <usenet.xyzzyx@spamgourmet.com> - 2014-10-28 04:34 -0700
          Re: Lunduke says "lxde desktop is nothing to write home about" Anssi Saari <as@sci.fi> - 2014-10-31 19:04 +0200
            Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-10-31 19:51 +0200
              Re: Lunduke says "lxde desktop is nothing to write home about" Dan Espen <despen@verizon.net> - 2014-10-31 14:55 -0400
                Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-10-31 23:48 +0200
                  Re: Lunduke says "lxde desktop is nothing to write home about" Dan Espen <despen@verizon.net> - 2014-10-31 18:58 -0400
                    Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-11-01 01:23 +0200
                      Re: Lunduke says "lxde desktop is nothing to write home about" Dan Espen <despen@verizon.net> - 2014-10-31 21:50 -0400
                        Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-11-01 09:14 +0200
                          Re: Lunduke says "lxde desktop is nothing to write home about" Dan Espen <despen@verizon.net> - 2014-11-01 10:15 -0400
                            Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-11-01 16:26 +0200
                              Re: Lunduke says "lxde desktop is nothing to write home about" Dan Espen <despen@verizon.net> - 2014-11-01 10:40 -0400
                                Re: Lunduke says "lxde desktop is nothing to write home about" Torsten Bronger <bronger@physik.rwth-aachen.de> - 2014-11-01 16:07 +0100
                                  Re: Lunduke says "lxde desktop is nothing to write home about" Dan Espen <despen@verizon.net> - 2014-11-01 13:20 -0400
                                    Re: Lunduke says "lxde desktop is nothing to write home about" Torsten Bronger <bronger@physik.rwth-aachen.de> - 2014-11-01 23:48 +0100
                                      Re: systemd documentation Dan Espen <despen@verizon.net> - 2014-11-01 19:53 -0400
                                        Re: systemd documentation Torsten Bronger <bronger@physik.rwth-aachen.de> - 2014-11-02 01:11 +0100
                                          Re: systemd documentation Dan Espen <despen@verizon.net> - 2014-11-01 21:25 -0400
                                      Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-11-02 10:37 +0200
                                        Re: Lunduke says "lxde desktop is nothing to write home about" Dan Espen <despen@verizon.net> - 2014-11-02 10:13 -0500
                                Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-11-01 18:09 +0200
                                  Re: Lunduke says "lxde desktop is nothing to write home about" Dan Espen <despen@verizon.net> - 2014-11-01 13:16 -0400
                                    Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-11-01 22:05 +0200
                                      Re: Lunduke says "lxde desktop is nothing to write home about" Dan Espen <despen@verizon.net> - 2014-11-01 19:39 -0400
                                        Re: Lunduke says "lxde desktop is nothing to write home about" Marko Rauhamaa <marko@pacujo.net> - 2014-11-02 10:57 +0200
          Re: Lunduke says "lxde desktop is nothing to write home about" Anssi Saari <as@sci.fi> - 2014-11-14 20:21 +0200

Page 2 of 2 — ← Prev page 1 [2]

#5505

Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> Hallöchen!
>
> Dan Espen writes:
>
>> Marko Rauhamaa <marko@pacujo.net> writes:
>>
>>> Dan Espen <despen@verizon.net>:
>>>
>>>> Marko Rauhamaa <marko@pacujo.net> writes:
>>>>
>>>>> You could write a tiny systemd-compliant toy daemon in C or
>>>>> Python, say, and post it here. Alternatively, you could post a
>>>>> link to such an example on the Web.
>>>>
>>>> Have fun:
>>>>
>>>> https://wiki.archlinux.org/index.php/Systemd/Services
>>>
>>> Thanks, but there's not a single line of daemon source code there.
>>
>> Are you looking at the links I post?
>>
>> At least one of those daemons is xautolock.
>> Tell me you don't know how to find the source code for xautolock.
>
> I wouldn't call this sensible documentation nevertheless.

You wouldn't call _WHAT_ sensibile documentatiion?

I guess you didn't get the point either.
xautolock and Xvfb have been around for ages.
They work fine under systemd.

If you know how to write a daemon, to run it under systemd
all you need is a .service file.

-- 
Dan Espen

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

#5507

Hallöchen!

Dan Espen writes:

> [...]
>
> You wouldn't call _WHAT_ sensibile documentatiion?

All resources you've suggested so far.

I've little idea about systemd or daemon programming, but I
recognise good programming resources when I see them.

Tschö,
Torsten.

-- 
Torsten Bronger    Jabber ID: torsten.bronger@jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com

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

#5509 — Re: systemd documentation

Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> Hallöchen!
>
> Dan Espen writes:
>
>> [...]
>>
>> You wouldn't call _WHAT_ sensibile documentatiion?
>
> All resources you've suggested so far.
>
> I've little idea about systemd or daemon programming, but I
> recognise good programming resources when I see them.

Hmm: "I don't know what it is, but it's not good".

I Google searched for what the OP wanted to know about.
All that stuff looked pretty good to me.

The docs say you just have to
follow the normal daemon rules and create a .service file.
A few seconds looking at the .service file for xautolock
convinced me I could have any daemon running under systemd
with a tiny bit of work.  No actual programming involved.

Then going farther and using the notification APIs,
after a quick read of the sd_notify page, I think I
could code up a call to notify systemd that my daemon
was really ready to go in a few minutes.

I've seen a lot of programming resources since I started
coding.  I don't agree with your conclusion.

-- 
Dan Espen

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

#5510 — Re: systemd documentation

Hallöchen!

Dan Espen writes:

> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>
>> Dan Espen writes:
>>
>>> [...]
>>>
>>> You wouldn't call _WHAT_ sensibile documentatiion?
>>
>> All resources you've suggested so far.
>>
>> I've little idea about systemd or daemon programming, but I
>> recognise good programming resources when I see them.
>
> Hmm: "I don't know what it is, but it's not good".

I do know what good documentation is.

Tschö,
Torsten.

-- 
Torsten Bronger    Jabber ID: torsten.bronger@jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com

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

#5511 — Re: systemd documentation

Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> Hallöchen!
>
> Dan Espen writes:
>
>> Torsten Bronger <bronger@physik.rwth-aachen.de> writes:
>>
>>> Dan Espen writes:
>>>
>>>> [...]
>>>>
>>>> You wouldn't call _WHAT_ sensibile documentatiion?
>>>
>>> All resources you've suggested so far.
>>>
>>> I've little idea about systemd or daemon programming, but I
>>> recognise good programming resources when I see them.
>>
>> Hmm: "I don't know what it is, but it's not good".
>
> I do know what good documentation is.

All we have is your claim.

If you want, cite the document, and the problem.
I'm not seeing any problems.
I see people claiming there is something wrong with
systemd over and over, but the claims are always,
"I don't know what it is, but it's bad".

As I dig into the various claims, I don't see any problems.

I had a lot of pulseaudio problems, but systemd is working
fine and seems to only make my Linux system run better.

I really like the concept that boot up, running and shutdown
are one problem.  SUN solved this years ago.  Now Linux
has a solution and it seems to be working fine.

-- 
Dan Espen

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

#5512

Torsten Bronger <bronger@physik.rwth-aachen.de>:

> I've little idea about systemd or daemon programming, but I recognise
> good programming resources when I see them.

Lack of good documentation doesn't automatically mean a technical
approach is bad but it does make it difficult to jump on the bandwagon.

Much of systemd documentation addresses transitioning to it from init
scripts. So the focus is not on making requirements for the daemons but
on getting systemd up and running with the multitude of legacy daemons.
Since there is no one way a legacy service interacts with its
surroundings so the systemd developers have tried to glean from the
extant init scripts all existing interaction models and added support
for those.

I write daemons for work. I'd be very interested in knowing how I should
design my next work so it is hooks up with systemd according to
systemd's preferred model. So first I'd like to see a document that lays
out the service state machine as seen by systemd (it can be somewhat
guessed from the sd_notify man page). Then I'd like to know if I should
implement the daemonizing boilerplate in my daemon or if systemd offers
that as a service to me.

Finally, I'd need to know if I need to integrate with some libraries to
interact with systemd or if I simply need to follow a protocol. I'd much
prefer the latter since sd_notify et al are not standard facilities in
most programming languages.

If I can't use the preferred model in my daemon, I'd then like to know
what legacy model is best supported by systemd and what the requirements
are there. Should I emit a pid file? When does systemd consider the
service up and running (status)? How does systemd perform start, stop,
restart and reload? Are there other operations to consider?

All of these things can be implemented, badly. For example, I have seen
many an init script that starts a service by backgrounding it with a
trailing ampersand (&), making it look like the service is up before it
has completed its initialization. That in turn often leads to
silly-looking heuristic sleeps in the dependent services.

So, I would still very much like a systemd daemon writer's cookbook.


Marko

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

#5514

Marko Rauhamaa <marko@pacujo.net> writes:

> Torsten Bronger <bronger@physik.rwth-aachen.de>:
>
>> I've little idea about systemd or daemon programming, but I recognise
>> good programming resources when I see them.
>
> Lack of good documentation doesn't automatically mean a technical
> approach is bad but it does make it difficult to jump on the bandwagon.

About 10 lines of .service file to make xautolock into a systemd
daemon.  That doesn't qualify as difficult.

Snipped rest of this discussion, it's become tedious.

-- 
Dan Espen

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

#5503

Dan Espen <despen@verizon.net>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>>> https://wiki.archlinux.org/index.php/Systemd/Services
>>
>> Thanks, but there's not a single line of daemon source code there.
>
> Are you looking at the links I post?
>
> At least one of those daemons is xautolock.
> Tell me you don't know how to find the source code for xautolock.

The page you link gives examples for how to integrate existing daemons
with systemd.

My question is, what is the recommended way to write a daemon that is
systemd-aware from the get-go?

For example, does such a daemon talk to systemd directly over D-Bus?


Marko

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

#5504

Marko Rauhamaa <marko@pacujo.net> writes:

> Dan Espen <despen@verizon.net>:
>
>> Marko Rauhamaa <marko@pacujo.net> writes:
>>>> https://wiki.archlinux.org/index.php/Systemd/Services
>>>
>>> Thanks, but there's not a single line of daemon source code there.
>>
>> Are you looking at the links I post?
>>
>> At least one of those daemons is xautolock.
>> Tell me you don't know how to find the source code for xautolock.
>
> The page you link gives examples for how to integrate existing daemons
> with systemd.
>
> My question is, what is the recommended way to write a daemon that is
> systemd-aware from the get-go?
>
> For example, does such a daemon talk to systemd directly over D-Bus?

Do you think xautolock uses d-bus?

(It doesn't.)

I don't think you are getting it.
xautolock existed since the dark ages.
There's nothing special in it and it wasn't changed
for systemd.

Simply write a .service file, and you are good to go.

If you _WANT_ your daemon to communicate with DBUS with
systemd, read the docs.

-- 
Dan Espen

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

#5506

Dan Espen <despen@verizon.net>:

> If you _WANT_ your daemon to communicate with DBUS with systemd, read
> the docs.

Finally we are approaching what I asked in the beginning: how does one
write a systemd-aware daemon?

I know systemd can deal with a number of schemes to interface with
legacy daemons with better or worse results. But are you saying systemd
doesn't have any native or preferred daemon interface or policy? If that
is indeed the systemd way, you could have said that right away (and
pointed to the documentation stating that fact).

In fact, it seems the opposite is the case. <URL:
http://0pointer.de/public/systemd-man/sd_notify.html> documents a C
library interface for the daemon to chat directly with systemd.

And finally, I can make progress with my "strong doubts." I laud systemd
for trying to bring clarity to the daemon lifecycle. However, I don't
like it depending on a shared library. Instead, it should be defined
like X11 and Wayland: through a protocol. Obviously, underlying
sd_notify() is some sort of protocol that could be reverse-engineered
with a moderate effort. I think it should be front-page material on
systemd documentation.


Marko

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

#5508

Marko Rauhamaa <marko@pacujo.net> writes:

> Dan Espen <despen@verizon.net>:
>
>> If you _WANT_ your daemon to communicate with DBUS with systemd, read
>> the docs.
>
> Finally we are approaching what I asked in the beginning: how does one
> write a systemd-aware daemon?
>
> I know systemd can deal with a number of schemes to interface with
> legacy daemons with better or worse results. But are you saying systemd
> doesn't have any native or preferred daemon interface or policy? If that
> is indeed the systemd way, you could have said that right away (and
> pointed to the documentation stating that fact).
>
> In fact, it seems the opposite is the case. <URL:
> http://0pointer.de/public/systemd-man/sd_notify.html> documents a C
> library interface for the daemon to chat directly with systemd.
>
> And finally, I can make progress with my "strong doubts." I laud systemd
> for trying to bring clarity to the daemon lifecycle. However, I don't
> like it depending on a shared library.

I really don't follow what you are getting at.
Usage of sd_notify is 100% optional.

Looking at what it can do, I'd guess most daemons wouldn't need
or want to use sd_notify.

You asked for developer information.
So, we're looking at API calls.
Exactly how do you intend to make API calls without a shared
library?  When did using shared libraries and providing APIs
become a bad thing?

> Instead, it should be defined
> like X11 and Wayland: through a protocol.
> Obviously, underlying
> sd_notify() is some sort of protocol that could be reverse-engineered
> with a moderate effort. I think it should be front-page material on
> systemd documentation.

As you say, obviously sd_notify uses a protocol.
Up until now you asked about developer information,
I pointed you to the APIs.

Now you are making the unsubstantiated claim that
the protocol is not documented.
I'm not going to Google search it, maybe you should.
I'm already certain that the protocol is documented. 

I don't understand why you think a developer would
need to know anything about the protocol.

-- 
Dan Espen

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

#5513

Dan Espen <despen@verizon.net>:

> You asked for developer information. So, we're looking at API calls.
> Exactly how do you intend to make API calls without a shared library?

Developer information does not necessarily involve shared libraries. For
example, you can define sockets and message formats. You can also define
policies such as this:

   A daemon's foreground process must not exit with a 0 exit code until
   it has completed its initialization successfully.

Or:

   A daemon must reload its configuration upon receiving a HUP signal.
   Reloading configuration should not disrupt existing service sessions.

Or:

   A daemon must write the PID of the servicing background process as a
   newline-terminated text file and flush it before the foreground
   process returns successfully.

> When did using shared libraries and providing APIs become a bad thing?

Providing useful libraries is great. Demanding their use is questionable
since you may not have the bindings available in all programming
languages (how do I call them from bash?) or on all systems (forcing a
conditional dlopen). Finally, libraries often induce awkward or
undocumented side effects on the application (other libraries,
threading, blocking calls etc).

So I prefer the primacy of protocols and policies with courtesy
libraries. I can then choose between the courtesy library and some other
compliant method to interface systemd.

> Now you are making the unsubstantiated claim that the protocol is not
> documented. I'm not going to Google search it, maybe you should. I'm
> already certain that the protocol is documented.

Deep down it is documented, and I have looked at it. But it is a bit of
a reverse-engineering exercise.


Marko

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

#5636

"D.D." <usenet.xyzzyx@spamgourmet.com> writes:

> My experience has been that how well any particular DE works on my
> computers is heavily influenced by the distro I'm running it on and
> (separately) whether it uses systemd.  If you haven't tried KDE under
> other unrelated distros with & without systemd, I'd recommend doing so
> ­— you might find that's a big part of the problem.

Well, it's been about two weeks now and I'm running Kubuntu 14.10
without systemd on my Thinkpad X201. None of the issues I had before in
Sabayon are present so I'm very happy.

While this is great for me I can't really know if the problem is systemd
or if Kubuntu is just a much better distro than Sabayon. Do you have
anything to support that systemd causes these issues? That would be a
real argument against systemd whereas what I've seen is pretty shaky.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.misc

csiph-web