Re: [Dng] printing (was Re: Readiness notification)

[Nate Bargmann]

* On 2015 13 Jun 18:23 -0500, Jonathan Wilkes wrote:

> What part of systemd are these various (non-systemd) programs
> leveraging?  Is it the sd-notify thingy?  If it is that would imply a
> different course of action than if they are using many different
> features.

I know that CUPS can be run under systemd in demand start and stop mode
which for a desktop is a nice feature since it isn't running all the
time.  If it can do that with another daemon manager, so much the
better, but on my desktop I am back to having CUPS running all the time
since I exorcised systemd from it.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] printing (was Re: Readiness notification)

[Jonathan Wilkes]

On 06/13/2015 01:31 PM, Clarke Sideroad wrote:

On 06/13/2015 11:03 AM, Hendrik Boom wrote:

On Sat, Jun 13, 2015 at 10:22:29AM -0500, Nate Bargmann wrote:

* On 2015 13 Jun 08:08 -0500, LM wrote:

Laurent Bercot wrote:
It would be great if Devuan became the Linux distribution that offered
its users alternatives to more commonly used, often bloated software.
It would certainly make a great base distribution for other
derivatives if it did.  Most Linux distributions I've run across so
far try to limit ones choices and make you follow their philosophy and
way of doing things.  Personally, the systems that work the best for
me are the ones that don't try to lock you into doing things a
specific way and let you do what you want.

This, exactly this.  Thank you, Laura, you have penned in your last
sentence exactly what my philosophy has been ever since Windows 95 was
dumped on the scene and I went to Slackware to maintain the freedom I
had known with MS-DOS.  I think I have gotten lax in the intervening
years (something about aging and wanting to divert my energies into
other areas) and accepted these new monoliths/monocultures for the ease
they provided.  Over the past year I have had a rude awakening and am
generally striving toward minimalism these days.

I would dearly love to dump CUPS in favor of something comprehensible
that would feed my HL-5240 compatible PS or PCL.
What's convenient about Cups is that it knows what printer driver to 
use.


What used to be convenient before Cups is that I could just write a
program that created a postscript file and send it to my printer using
a command like lpr, which knew that the printer was attached through
the parallel port.

I liked it back then.  I could write actual postsript programs that
computed diagrams.

I have no idea what to do now.  As far as I know, everything is
intercepted and rerouted.  I'm not even sure if my laptop is talking to
the printer or to my wife's Apple laptop, which also runs CUPS.

CUPS used to e usable.  But now?

I tried to print a jpeg image a while ago.  I used a browser.  I had a
choice between one mode thta I think was one screen pixel per printer
pixel -- useless, and 'fit to page', which seemed to think my
standard 8.5 x 11 page was twice as big, so I oonly got a quarter of
the image.

I think that Brother is one of the companies that advertises actual
Unix support, and that my printer an HL-3170CDW, at least, accepts a
variety of networked protocols, including some that originated in Unix.
But I don't know how to access them without CUPS.

There must be a way.



CUPS definitely is a monster, but it does add to the convenience of 
setup "out of the box" for many printers even ones that have reached 
"end of life" as far as the manufacturer is concerned.
I use a LaserJet 1200 and there are a multitude of drivers and then 
the HP CUPS add-ons to add to the confusion.


I would think that since CUPS can be used in the various BSD flavours, 
Apple included, systemd is just used in the latest Linux versions as a 
common convenience.  I am no programmer, but it would seem to me that 
dumping systemd from the source would be doable.


What part of systemd are these various (non-systemd) programs 
leveraging?  Is it the sd-notify thingy?  If it is
that would imply a different course of action than if they are using 
many different features.


-Jonathan



Clarke



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Readiness notification

[Jonathan Wilkes]

On 06/13/2015 09:34 AM, Klaus Hartnegg wrote:

Am 13.06.2015 um 13:33 schrieb Laurent Bercot:

30 seconds is a lot. What if you could get your desktop ready in
5 seconds or less ?


This would mean less than what most people think. Because everything 
longer than half a second is perceived as being forced to wait. As 
long as an improvement stays above this threshold, it just replaces 
one forced wait with another forced wait.


I had some problem awhile back that required making changes in the Grub 
menu to see the result after bootup.


10 reboots * 5 seconds = 50 seconds
10 reboots * 30 seconds = 5 minutes
5 minutes / 5-second-reboots = 60 reboots
5 minutes / 30-second-reboots = 10 reboots

It's not just a matter of speed, but also granularity.  Yes, the faster 
boot time would give 6 reboots in the time of 1 on the slow machine.  
But it also lets me bail on a particular course of action sooner.  Where 
I'd be sitting at the slow machine twiddling my thumbs for another 25 
seconds, on the fast machine I'm analysing the feedback and choosing a 
new course of action.  Given the average human attention span is only 
about 20 minutes, this is a qualitative difference.


I mentioned Grub because it's the first that popped into my head. But 
given another 50 seconds I'd also mention the following:
having the (practical) option to restart on a system freeze if you're in 
a hurry

testing out the rt kernel vs stock kernel
having the option to restart in a presentation if you get stuck somehow 
(or if the projector somehow only gets triggered at bootup)

dev'ing rt kernel, init system, and lots of other stuff that requires reboot

-Jonathan
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[Dng] epoch feature request

[Hendrik Boom]

The maintainer of epoch has just asked for feature requests.

http://linux.slashdot.org/story/15/06/13/198222/ask-slashdot-feature-requests-for-epoch-init-system-130

-- hendrik

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Readiness notification

[Laurent Bercot]

On 13/06/2015 08:40, Didier Kryn wrote:

Yes, daemon writers are good-willing developpers; they want their
software to serve as many users as possible; and users install
distros. This gives power to the distros. But if someone provides
them with a KISS readyness-signaling method, along with a systemd
wrapper, then they can satisfy RedHat's requests at no cost.


 And there you go:
 http://skarnet.org/software/sdnotify-wrapper.c

 Untested with a real systemd, because I'm not going to install a
real systemd anywhere - but I've listened to a socket on the other
end of NOTIFY_SOCKET and it appears to work. Bug-reports welcome.



The question now is who will develop, maintain and package this
wrapper? Will Devuan be the official developper of
"Systemd-Readyness-Wrapper", or can anyone convince Openssh or who
else to take the job? Or are the daemon's developper powerfull enough
to tell RH "do it yourself."?


 I'm willing to maintain this for the time being; as long as systemd
does not gratuitously break compatibility with itself, it should not
be too hard. The goal is to encourage daemon developers to stop using
the sd_notify() interface and just write a newline somewhere; the
wrapper is just there to make this simple behaviour work with systemd,
nothing more.

 I firmly believe it should *not* be packaged by Devuan. The wrapper is
meant to only be used on systemd installations, which is exactly what
Devuan is not. Devuan can advertise such a wrapper, advocate its use,
but I don't think it makes sense for it to be a part of the Devuan
distribution.

 I'm providing a single C file for now. I can turn it into a complete
package tarball with configure/make/make install if there's interest.
I'm not going to make distribution-specific packages, though; that's
the job of distribution maintainers.

 Enjoy!

--
 Laurent
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] printing (was Re: Readiness notification)

[Clarke Sideroad]

On 06/13/2015 11:03 AM, Hendrik Boom wrote:

On Sat, Jun 13, 2015 at 10:22:29AM -0500, Nate Bargmann wrote:

* On 2015 13 Jun 08:08 -0500, LM wrote:

Laurent Bercot wrote:
It would be great if Devuan became the Linux distribution that offered
its users alternatives to more commonly used, often bloated software.
It would certainly make a great base distribution for other
derivatives if it did.  Most Linux distributions I've run across so
far try to limit ones choices and make you follow their philosophy and
way of doing things.  Personally, the systems that work the best for
me are the ones that don't try to lock you into doing things a
specific way and let you do what you want.

This, exactly this.  Thank you, Laura, you have penned in your last
sentence exactly what my philosophy has been ever since Windows 95 was
dumped on the scene and I went to Slackware to maintain the freedom I
had known with MS-DOS.  I think I have gotten lax in the intervening
years (something about aging and wanting to divert my energies into
other areas) and accepted these new monoliths/monocultures for the ease
they provided.  Over the past year I have had a rude awakening and am
generally striving toward minimalism these days.

I would dearly love to dump CUPS in favor of something comprehensible
that would feed my HL-5240 compatible PS or PCL.

What's convenient about Cups is that it knows what printer driver to use.

What used to be convenient before Cups is that I could just write a
program that created a postscript file and send it to my printer using
a command like lpr, which knew that the printer was attached through
the parallel port.

I liked it back then.  I could write actual postsript programs that
computed diagrams.

I have no idea what to do now.  As far as I know, everything is
intercepted and rerouted.  I'm not even sure if my laptop is talking to
the printer or to my wife's Apple laptop, which also runs CUPS.

CUPS used to e usable.  But now?

I tried to print a jpeg image a while ago.  I used a browser.  I had a
choice between one mode thta I think was one screen pixel per printer
pixel -- useless, and 'fit to page', which seemed to think my
standard 8.5 x 11 page was twice as big, so I oonly got a quarter of
the image.

I think that Brother is one of the companies that advertises actual
Unix support, and that my printer an HL-3170CDW, at least, accepts a
variety of networked protocols, including some that originated in Unix.
But I don't know how to access them without CUPS.

There must be a way.



CUPS definitely is a monster, but it does add to the convenience of 
setup "out of the box" for many printers even ones that have reached 
"end of life" as far as the manufacturer is concerned.
I use a LaserJet 1200 and there are a multitude of drivers and then the 
HP CUPS add-ons to add to the confusion.


I would think that since CUPS can be used in the various BSD flavours, 
Apple included, systemd is just used in the latest Linux versions as a 
common convenience.  I am no programmer, but it would seem to me that 
dumping systemd from the source would be doable.


Clarke



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] A nice candidate substitute to network-manager

[Marlon Nunes]

On 2015-06-12 17:48, Anto wrote:

On 12/06/15 22:15, Anto wrote:


On 12/06/15 18:34, Marlon Nunes wrote:

On 2015-06-12 10:03, Steve Litt wrote:

On Fri, 12 Jun 2015 07:50:25 -0300
Marlon Nunes  wrote:

Hi, i've been testing connman for a while and found it to handle 
very

well my network connections.

https://01.org/connman


The following sentence from the preceding link made me sweat a 
little

bit:

=
ConnMan is optimized through open source for embedded and client
focused Intel® Quark technology, Intel® Atom™ processors and Intel®
Core™ processors.
=

I'm an AMD guy.


I found it ok just for the fact that its completely independent of 
systemd.



https://wiki.archlinux.org/index.php/Connman


Those Arch guys are the biggest bunch of systemd jingoists on the
planet but you've got to admit, they write far and away the best
documentation on the planet.


Their wiki help pages are almost complete.



In my view, we can forget about network-manager completely for
desktop usage.


Whether we stay with Wicd, which Devuan Alpha 2 does such a great 
job
with, or switch to ConnMan, either way, you're right: 
network-manager

is too entangled in dbus and systemd to be useful on Devuan, and it
also requires you be in X, and that's not always true.

I think that whether Wicd or ConnMan is our default network "make it
easier machine", it should be easy to switch between the two, and 
part

of that ease could be good documentation.

By the way, I was going to answer Bardot Jérôme's query about Devuan
Network-Manager similarly: Better to be rid of Network-Manager than 
to
wonder if it's going to drag in systemd on an update. 
Network-Manager's

wonderful for the one use case Debian envisions, but turns into a
stumbling block when you go offroad.


That's why a wrote about it. =)




I doubt that connman is free of systemd. I was just in the middle of 
preparing to compile connman 1.29, and I saw 2 files which are 
definitely meant for systemd. And they are in http://git.kernel.org.


http://git.kernel.org/cgit/network/connman/connman.git/tree/src/connman.service.in 
[Unit]

Description=Connection service
Requires=dbus.socket
After=dbus.socket
Before=remote-fs-pre.target
Wants=remote-fs-pre.target

[Service]
Type=dbus
BusName=net.connman
Restart=on-failure
ExecStart=@sbindir@/connmand -n
StandardOutput=null

[Install]
WantedBy=multi-user.target


http://git.kernel.org/cgit/network/connman/connman.git/plain/vpn/connman-vpn.service.in 
[Unit]

Description=ConnMan VPN service
Requires=dbus.socket
After=dbus.socket

[Service]
Type=dbus
BusName=net.connman.vpn
ExecStart=@sbindir@/connman-vpnd -n
StandardOutput=null

[Install]
WantedBy=multi-user.target


I know that they are harmless. But that tells me the intention to 
allow it to be locked-in into systemd. So I always want to remove 
everything related to systemd including the unit, service and socket 
files. I got the impression that a lot of people find my attempt to do 
that ridiculous. But I really don't care :)




I just purged all connman files that I downloaded tonight. I think t
is not worth trying to compile and install it. The title of the commit
below clearly says that connman is definitely being locked-in to
systemd.

machine: Integrate ConnMan with systemd-hostnamed

http://git.kernel.org/cgit/network/connman/connman.git/commit/?id=d5acb39e80b40d2b21eed37506523e73fcd8956f

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


root@core >> eix-installed -a | wc -l
906

root@core >> eix-installed -a | grep systemd
root@core >>

As you saw, no single systemd here.


--
Stop slacking you lazy bum!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] printing (was Re: Readiness notification)

[Hendrik Boom]

On Sat, Jun 13, 2015 at 10:22:29AM -0500, Nate Bargmann wrote:
> * On 2015 13 Jun 08:08 -0500, LM wrote:
> > Laurent Bercot wrote:

> > It would be great if Devuan became the Linux distribution that offered
> > its users alternatives to more commonly used, often bloated software.
> > It would certainly make a great base distribution for other
> > derivatives if it did.  Most Linux distributions I've run across so
> > far try to limit ones choices and make you follow their philosophy and
> > way of doing things.  Personally, the systems that work the best for
> > me are the ones that don't try to lock you into doing things a
> > specific way and let you do what you want.
> 
> This, exactly this.  Thank you, Laura, you have penned in your last
> sentence exactly what my philosophy has been ever since Windows 95 was
> dumped on the scene and I went to Slackware to maintain the freedom I
> had known with MS-DOS.  I think I have gotten lax in the intervening
> years (something about aging and wanting to divert my energies into
> other areas) and accepted these new monoliths/monocultures for the ease
> they provided.  Over the past year I have had a rude awakening and am
> generally striving toward minimalism these days.
> 
> I would dearly love to dump CUPS in favor of something comprehensible
> that would feed my HL-5240 compatible PS or PCL.

What's convenient about Cups is that it knows what printer driver to use.

What used to be convenient before Cups is that I could just write a 
program that created a postscript file and send it to my printer using 
a command like lpr, which knew that the printer was attached through 
the parallel port.  

I liked it back then.  I could write actual postsript programs that 
computed diagrams.

I have no idea what to do now.  As far as I know, everything is 
intercepted and rerouted.  I'm not even sure if my laptop is talking to  
the printer or to my wife's Apple laptop, which also runs CUPS.

CUPS used to e usable.  But now?

I tried to print a jpeg image a while ago.  I used a browser.  I had a 
choice between one mode thta I think was one screen pixel per printer 
pixel -- useless, and 'fit to page', which seemed to think my 
standard 8.5 x 11 page was twice as big, so I oonly got a quarter of 
the image.

I think that Brother is one of the companies that advertises actual 
Unix support, and that my printer an HL-3170CDW, at least, accepts a 
variety of networked protocols, including some that originated in Unix.  
But I don't know how to access them without CUPS.

There must be a way.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] printing (was Re: Readiness notification)

[Nate Bargmann]

* On 2015 13 Jun 08:08 -0500, LM wrote:
> Laurent Bercot wrote:
> >As for printing servers, I don't know, but I'd be surprised
> >if cupsd was the only possibility.
> >
> >   And if it actually is the only possibility, then we have a bigger
> > problem than just sd_notify: it means that monopolies exist in free
> > software - real, existing monopolies, albeit more inconspicuous than
> > systemd's obvious attempts at a monopoly - and it is taking away from
> > users' freedom. And that is what needs to be fought first and foremost.
> 
> Unfortunately, it seems like this is becoming the case.  Was looking
> for less complex substitutes to cups that I could easily modify myself
> if I needed to.  Didn't find a lot in that area.  When I search for
> multimedia viewers that don't use ffmpeg, they're also difficult to
> find.  There are several areas where I've looked for alternatives to a
> library or ways around using them and found few or no other options.

As if on cue, IgnorantGuru posts up a very timely and salient post:

https://igurublog.wordpress.com/2015/06/13/openwashing-and-other-deceptions-in-linux/

Sadly, CUPS is long one of these technologies ensnared by Apple and now
we're beholden to them.  At first CUPS was a very good idea and an
independent project which was then somehow "bought" by Apple and for a
time things improved.  Then a couple of years ago Linux support was more
or less dropped by Apple and CUPS, which worked flawlessly, almost
completely stopped working with my Brother HL-5240 save for
Open|LibreOffice.  Last night Firefox actually printed to that printer
again so perhaps something has turned toward the better.

CUPS seems next to impossible to understand, much less troubleshoot.

> There's a list of printer/spooler options at:
> http://www.tldp.org/HOWTO/Printing-HOWTO/spoolers.html
> Main alternatives typically mentioned are from BSD (lpd and lprng).
> Someone mentioned pdq as a simpler alternative to cups.  I was even
> going so far as to looking into doing a copy command to send
> postscript files to a printer.  That got me looking into ghostscript
> and ghostpcl.  That's another area where there seems to be a monopoly.
> There are practically no alternatives to ghostscript (that perform
> adequately when converting files to postscript) and I could not find a
> decent alternative to ghostpcl to create PCL formatted information.
> Ghostpcl is designed so that it uses its own versions of third party
> libraries (which can be annoying) rather than system libraries.  One
> would need to create one's own build scripts or get an alternative to
> work around this.  I should mention, my search for alternatives was
> limited to compiled languages such as C or C++ (for
> speed/responsiveness reasons) and I did not choose to consider many of
> the possibilities written in interpreted languages at the time.

It's the layers upon layers of libraries and the morass of filters and
drivers that makes printing a near incomprehensible mess.  I am naive
enough to think that if a printer supports PS or PCL that it should be
trivial to print to it.  The reality seems to be another matter
completely.

> >   I firmly believe that in 20ish years, we have lost most of the awareness
> > of what free software is and what it means. If we cannot actually dive
> > into the code and take out what we don't want, then it's de facto not
> > free software anymore, no matter the reason.
> 
> That is one of the goals I have.  I want to be able to go into the
> code on my system and be able to make changes when needed.  Most
> people I discuss the subject with who run Linux have no interest in
> how the code underneath works and don't understand why someone might
> find it important to do this.  Where I work, they're terrified of
> changing source code and don't want anyone but a qualified distributor
> doing that.  It's very difficult to find the building blocks to a
> system that are well designed, easy to modify and can be maintained by
> one individual if needed.  I really think you've hit on something
> important with your statement.

I find myself looking in that direction as well, so you're not alone.
In fact, I get the sense that most posting to this list have similar
goals.

> It would be great if Devuan became the Linux distribution that offered
> its users alternatives to more commonly used, often bloated software.
> It would certainly make a great base distribution for other
> derivatives if it did.  Most Linux distributions I've run across so
> far try to limit ones choices and make you follow their philosophy and
> way of doing things.  Personally, the systems that work the best for
> me are the ones that don't try to lock you into doing things a
> specific way and let you do what you want.

This, exactly this.  Thank you, Laura, you have penned in your last
sentence exactly what my philosophy has been ever since Windows 95 was
dumped on the scene and I went to Slackware to maintain the freedom I
had kn

Re: [Dng] A nice candidate substitute to network-manager

[Anto]

On 13/06/15 14:15, Hendrik Boom wrote:

On Sat, Jun 13, 2015 at 12:54:41PM +0200, Anto wrote:

However, after I found that there is a commit with the title
"machine: Integrate ConnMan with systemd-hostnamed" on connman
source code which I posted on this thread yesterday, I decided to
stay away from connman. I am quite sure that along the time, there
will be more integration to systemd.

I'm trying to remain optimistic here, however unreasonable that may be.
Could the 'integration' be run-time or compile-time conditional on
systemd being around?

-- hendrik


Hello Hendrik,

As I always mention, I am not a programmer. But I guess the integration 
is run-time conditional depending on whether systemd-hostnamed is 
running or not. So it could be safe to use without systemd. I still 
prefer to stay away on anything that is intentionally being locked-in to 
systemd, unless that there is no other options.


Cheers,

Anto

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[Dng] Unofficial wiki

[David Harrison]

Hi everyone,

I have set up http://wiki.friendsofdevuan.org as a holding place for 
useful information, at least until there's an official wiki in place.


It's empty right now but for a few category suggestions. Not even a 
nifty logo. One may follow :)


Please register if you like, and feel free to add any useful advice, 
tutorials, walk-throughs, links, scripts etc that you create or 
encounter while testing Devuan. There have been many useful gems about 
related software recently on this ML too -- vdev, alternatives to 
Network Manager, and all the rest. It would be great to see some posts 
on these topics.


Markup is Dokuwiki flavoured for now. There's a Markdown-ish plugin 
available for those that would prefer one -- let me know.


For now the content license is GPL. If the majority of posters would 
prefer something else, such as CC-attribution-whathaveyou, I'll change it.


I stress that this is not in any way an official Devuan project. However 
any posts may find their way onto an official public Devuan wiki later 
on. Let me know if you'd rather that didn't happen for any reason.


All the best,

Dave Harrison
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Readiness notification

[Steve Litt]

On Sat, 13 Jun 2015 10:43:52 +0200
marc  wrote:

> On a personal note: You have been making a number of pronouncements
> which suggest incomplete understanding of unix: Here unaware of
> dup2(), but in previous posts you were unclear on when a shell needs
> to do a stat() (5542b2d4.5030...@skarnet.org), misunderstood security
> through obscurity (55449253@skarnet.org), do not realise that a
> setgid exectuable which isn't world executable is almost useless
> (5545e741.5000...@skarnet.org)

Do you even know who you're talking to? You might want to find out who
Laurent is and what software he's written before you declare his Unix
understanding "incomplete".

When Laurent speaks, I listen, and he's never steered me wrong.

SteveT

Steve Litt 
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Museum of mediaeval programming

[Steve Litt]

On Sat, 13 Jun 2015 08:04:12 -0400
Hendrik Boom  wrote:

> On Sat, Jun 13, 2015 at 01:53:44AM +0200, Laurent Bercot wrote:
> 
> > it comes from ancient Unix times when we
> > did not know better, and the daemon() function should either
> > disappear into oblivion, or have a place in the museum of medieval
> > programming as an example of how not to write Unix software.
> 
> That museum could actually be useful.  Especially if it were to
> explain why these once-advocated techniques were used, why they
> should not be, and what to do instead.
> 
> Maybe this should be a curated wiki?

I'll write an article on how flowcharts produced spaghetti.

SteveT

Steve Litt 
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] A nice candidate substitute to network-manager

[Steve Litt]

On Sat, 13 Jun 2015 12:29:17 +0200
Jaromil  wrote:


> I'd prefer something simplier and mostly bound to shell scripts and a
> light gui layer for the tray, which is handy.

As an Openbox guy, I'm always looking to make sure the tray stuff is
optional, and that whatever's in the tray can be opened as a
full-window app.

SteveT

Steve Litt 
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Readiness notification

[Steve Litt]

On Sat, 13 Jun 2015 10:37:19 +0100
KatolaZ  wrote:

> On Sat, Jun 13, 2015 at 08:40:27AM +0200, Didier Kryn wrote:
> 
> [cut]
> 
> > 
> > The question now is who will develop, maintain and package this
> > wrapper? Will Devuan be the official developper of
> > "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who
> > else to take the job? Or are the daemon's developper powerfull
> > enough to tell RH "do it yourself."?
> > 
> 
> I think there is another, more fundamental question: do we really need
> to know in *real time* when a service/daemon is ready for its job or
> has done what it is supposed to do?  AFAIK all this fuss with
> "daemon-readiness" began with the first attempts to have parallel boot
> sequences, which is something that is still *useless* in 95% of the
> use cases: servers don't get restarted evey other minute and "normal"
> users who don't use suspend can wait 30 seconds to have their desktop
> ready, what else? Embedded systems? Well, they usually have just a few
> services running, if any
> 
> What are we really talking about? Isn't this just another
> feature-for-the-feature's-sake-thing? Why should I bother to allow
> cups signalling immediately that it is ready to put my printouts on a
> queue that will anyway need minutes to be processed?
> 
> My2Cents
> 
> KatolaZ
> 

Good questions, all.

In my opinion, this is a legitimate issue, not an attempt to match
another systemd marketing feature (magnesium paddle shifter).

KatolaZ, I just got done converting Plop Linux to init with a
combination of Suckless Init (for the
PID1/interrupt_listening/shutdown_instantiation) and daemontools-encore
for the process management. I have a daemontools service running
dhclient in the foreground (like all daemontools managed daemons). As
you know, dhclient takes between what, 3 and 20 seconds to get an IP
address, so in my LittKit ordered startup script, I have a loop to
detect when there's an IP address, and stall til one appears.

If dhclient had seen fit to inform us of a DHCP lease aquisition in a
way other than backgrounding itself (a feature I don't use because
within daemontools I run the program in the foreground), I could have
detected that. Or possibly written LittKit to afirmatively kick off a
process when all its dependencies are met (and you would be right: that
would be more than is necessary).

I'd hate to have a boot where an outlier dhclient took 50 seconds to
acquire a lease, and all sorts of network-dependent daemons got spawned
in the meantime.

SteveT

Steve Litt 
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] A nice candidate substitute to network-manager

[Hendrik Boom]

On Sat, Jun 13, 2015 at 12:54:41PM +0200, Anto wrote:
> 
> However, after I found that there is a commit with the title
> "machine: Integrate ConnMan with systemd-hostnamed" on connman
> source code which I posted on this thread yesterday, I decided to
> stay away from connman. I am quite sure that along the time, there
> will be more integration to systemd.

I'm trying to remain optimistic here, however unreasonable that may be. 
Could the 'integration' be run-time or compile-time conditional on 
systemd being around?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Readiness notification

[Klaus Hartnegg]

Am 13.06.2015 um 13:33 schrieb Laurent Bercot:

30 seconds is a lot. What if you could get your desktop ready in
5 seconds or less ?


This would mean less than what most people think. Because everything 
longer than half a second is perceived as being forced to wait. As long 
as an improvement stays above this threshold, it just replaces one 
forced wait with another forced wait.


In contrast an iPad is immediately ready to get work done. No perceived 
wait. This feels like a different world! Good luck getting a PC from 
sleep to online in half a second. As long as it is slower, the precise 
number of seconds does not matter much.


If you want to make Linux go from sleep to ready faster, there is an 
easier way: eliminate the waits in dhclient. The IP stack in a firmware 
which I wrote initializes itself in a few milliseconds. The replies from 
DHCP servers are lightning fast. Getting confirmation for the last used 
IP address does not take significantly longer than a ping time. The only 
slow parts are the waits in the recommended checks whether another PC is 
errorneously using the same IP address. This is a very rare case, and 
these cases can usually be detected within 10 milliseconds, because the 
offending machine must be very nearby. Do just this quick check, then 
report ready, and then do a more thorough check afterwards, just to be 
closer to be RFC-compliant. Please make this as systemd-incompatible as 
possible ;-) And then compare the whole sleep to useable time, not just 
the time to show the desktop.


Btw. boot times tend to get less relevant in the future, because user 
devices just never go completely offline, and servers are mostly 
clusters. The whole upgrade downtime for the largest of my servers is 
over 5 minutes (but only once a month). How much effort would I spend to 
reduce this by 30 seconds? None! If the users want to get rid of this 
downtime, they must order a cluster. And then the downtime of the single 
machines would be completely irrelevant. There is no good reason to 
completely rewrite Linux just to save a few seconds boot time.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[Dng] Museum of mediaeval programming

[Hendrik Boom]

On Sat, Jun 13, 2015 at 01:53:44AM +0200, Laurent Bercot wrote:

> it comes from ancient Unix times when we
> did not know better, and the daemon() function should either
> disappear into oblivion, or have a place in the museum of medieval
> programming as an example of how not to write Unix software.

That museum could actually be useful.  Especially if it were to explain 
why these once-advocated techniques were used, why they should not be, 
and what to do instead.

Maybe this should be a curated wiki?

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[Dng] printing (was Re: Readiness notification)

[LM]

Laurent Bercot wrote:
>As for printing servers, I don't know, but I'd be surprised
>if cupsd was the only possibility.
>
>   And if it actually is the only possibility, then we have a bigger
> problem than just sd_notify: it means that monopolies exist in free
> software - real, existing monopolies, albeit more inconspicuous than
> systemd's obvious attempts at a monopoly - and it is taking away from
> users' freedom. And that is what needs to be fought first and foremost.

Unfortunately, it seems like this is becoming the case.  Was looking
for less complex substitutes to cups that I could easily modify myself
if I needed to.  Didn't find a lot in that area.  When I search for
multimedia viewers that don't use ffmpeg, they're also difficult to
find.  There are several areas where I've looked for alternatives to a
library or ways around using them and found few or no other options.

There's a list of printer/spooler options at:
http://www.tldp.org/HOWTO/Printing-HOWTO/spoolers.html
Main alternatives typically mentioned are from BSD (lpd and lprng).
Someone mentioned pdq as a simpler alternative to cups.  I was even
going so far as to looking into doing a copy command to send
postscript files to a printer.  That got me looking into ghostscript
and ghostpcl.  That's another area where there seems to be a monopoly.
There are practically no alternatives to ghostscript (that perform
adequately when converting files to postscript) and I could not find a
decent alternative to ghostpcl to create PCL formatted information.
Ghostpcl is designed so that it uses its own versions of third party
libraries (which can be annoying) rather than system libraries.  One
would need to create one's own build scripts or get an alternative to
work around this.  I should mention, my search for alternatives was
limited to compiled languages such as C or C++ (for
speed/responsiveness reasons) and I did not choose to consider many of
the possibilities written in interpreted languages at the time.

>   I firmly believe that in 20ish years, we have lost most of the awareness
> of what free software is and what it means. If we cannot actually dive
> into the code and take out what we don't want, then it's de facto not
> free software anymore, no matter the reason.

That is one of the goals I have.  I want to be able to go into the
code on my system and be able to make changes when needed.  Most
people I discuss the subject with who run Linux have no interest in
how the code underneath works and don't understand why someone might
find it important to do this.  Where I work, they're terrified of
changing source code and don't want anyone but a qualified distributor
doing that.  It's very difficult to find the building blocks to a
system that are well designed, easy to modify and can be maintained by
one individual if needed.  I really think you've hit on something
important with your statement.

It would be great if Devuan became the Linux distribution that offered
its users alternatives to more commonly used, often bloated software.
It would certainly make a great base distribution for other
derivatives if it did.  Most Linux distributions I've run across so
far try to limit ones choices and make you follow their philosophy and
way of doing things.  Personally, the systems that work the best for
me are the ones that don't try to lock you into doing things a
specific way and let you do what you want.

Sincerely,
Laura
http://www.distasis.com/cpp
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Readiness notification

[Klaus Hartnegg]

Am 13.06.2015 um 08:40 schrieb Didier Kryn:

 Yes, daemon writers are good-willing developpers; they want their
software to serve as many users as possible; and users install distros.
This gives power to the distros. But if someone provides them with a
KISS readyness-signaling method, along with a systemd wrapper, then they
can satisfy RedHat's requests at no cost.


This is great, because usually the way to win is to provide something 
which is immediately better, not discussing that other ideologies might 
cause issues in the future.


Developers want an easier way to send this signal, which automatically 
works in all distributions. If there is a library which provides this, 
they will look at it. And while they are, there they might look at other 
offers there as well. Redhat will probably not provide such a thing, 
thus this is an example where Devuan can be better, and gain attention.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Readiness notification

[Laurent Bercot]

On 13/06/2015 11:37, KatolaZ wrote:

 AFAIK all this fuss with
"daemon-readiness" began with the first attempts to have parallel boot
sequences, which is something that is still *useless* in 95% of the
use cases: servers don't get restarted evey other minute and "normal"
users who don't use suspend can wait 30 seconds to have their desktop
ready, what else? Embedded systems? Well, they usually have just a few
services running, if any


 30 seconds is a lot. What if you could get your desktop ready in
5 seconds or less ?
 About embedded systems, things are changing quite fast. The amount of
services running on an Android phone, for instance, is mind-boggling,
and it can take several minutes to boot a phone. Most of this waiting
time is unnecessary.



What are we really talking about? Isn't this just another
feature-for-the-feature's-sake-thing? Why should I bother to allow
cups signalling immediately that it is ready to put my printouts on a
queue that will anyway need minutes to be processed?


 A printing service may not be the best example, but when you're late
for a broadcast and turn your TV on, you don't want to wait any more
than is necessary to get image and sound. If your TV took extra seconds
to boot up, you'd curse at it.
(This has happened to me, I watch broadcast streams on my PC and have
wished for faster booting times on more than one occasion.)

 More generally, the main reason why computing is so slow is that
everyone reasons the same way "why bother?" Somebody has to start,
and there's no better place than the low level.

 If nothing else, there's the public relations argument. As long as
systemd is able to say "we do parallel service startup and boot your
machine in 5 seconds, nobody else does it", then systemd has a real,
valid, technical advantage over other systems, and it makes it harder
to advocate against it.

--
 Laurent

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Readiness notification

[Laurent Bercot]

On 13/06/2015 10:43, marc wrote:

It is only bad design if you have your heart set on a supervision
framework like daemontools.


 No, it is bad design because
 - it lengthens the code path before the service is operational
 - it requires software authors to write more code into their
daemon instead of less, code that could otherwise be factored
 - it prevents system administrators from running the service as
they choose, supervised or not. Even systemd gives administrators
this choice.



Such frameworks have been around
for decades too, and have not caught on (also for several reasons ;)


 Lots of good ideas have not caught on. Plan 9 has not caught on.
Itanium has not caught on. Popularity has never been a suitable
measure for technical quality, and if we were after popularity, we
would be using Microsoft Windows.



The biggest reason is that in a number of applications it is unclear
if and when things should turn in to a daemon. Consider something
like screen - things only background when you press . In
general terms having a supervision framework means that a daemon is
something an administrator decides to create, not something which the
user asks his application to become.


 Um, yes. Supervision frameworks were made to help administrators, and
usually run noninteractive programs. The way you manage a system requires
planning, as any management task.
 The thing is, they don't prevent users from doing whatever they want.
If a user wants to daemonize a screen process previously running
interactively, then fine - it's possible to do so. It won't be supervised,
but who cares? It wasn't supervised in the first place and does not need to.

 Also, I honestly wouldn't use GNU screen as an example of good software
design, but that's not the point.



  * It becomes harder for end users to run their own daemons. Harder,
less convenient, whatever. Not impossible - with enough contortions
anything is possible. But it disempowers non-admin users.


 Huh? Non-admin users have exactly the *same* ways to run their
own daemons with or without a supervision framework. And that is the
point: it's always possible to make a program run in the background,
whereas it's much harder to make an auto-backgrounding program run
in the foreground. Supervision does not take away anything from anyone,
it *opens up* possibilities.



  * Daemon programmers get to become lazy - where previously a crash
was something horrible, a crash now means that the supervision
framework restarts it, so no biggie. Welcome to windows, where
software is expected to crash


 This is a complete straw man, akin to blaming antiretroviral treatment
for people having unsafe sex and catching AIDS saying it's not that
big of a deal anymore.



  * People are lulled into the false sense of security: "My supervision
framework thinks the process is still up, so things are ok". But
your process has has been running in an infinite loop for the
last couple of days.  If you want to have monitoring, monitor
your task at the service it provides (retrieve a web page from
a web server, finger the finger daemon).


 Supervision frameworks do not replace competent system administration,
complete with logging, in-service monitoring and alerts if your SLA
requires it. They only make it easier. This is another strawman.



Inevitably that requires domain knowledge, which supervision framework
advocates struggle to realise.


 Nothing replaces domain knowledge. Wanting to make administration easier
is not the same as wanting to dumb it down. Progress and convenience is
not decadence, unless you miss the time where washing machines did not
exist, and men were men and did all their laundry by hand - wait, they
didn't, they enslaved women instead.



Or if you are Lennart, you end up absorbing all domains
into your supervision framework, at which point we have to
fork a distribution


 The fact that I'm following this list should make it clear that I'm not
Lennart, and about anything I've written here or anywhere else should
make it clear that my goal is quite opposite to absorbing all domains.



  * Supervison frameworks are marketed as "So easy to use, any idiot
can write a daemon".


 No, this is not what they are marketed as, and you are severely
misinterpreting.



Closing stderr to the parent does not prevent logging to stderr, you can
quite happily close a file descriptor with dup2().


 The child is run with stderr pointing to a pipe to the parent. You
have to close that descriptor for the parent to exit. The original
stderr, the one the parent was run with, is overwritten with your
dup2() in fork_parent() and the child has no access to it; and it is
irremediably lost when the parent exits.
 You can dup2() all you want in the child, you will never get the
original stderr back, which is of course the point of logging to
stderr - you want to log to the stderr the daemon has when it is
started!



Or you could use
some other

Re: [Dng] A nice candidate substitute to network-manager

[Anto]

On 13/06/15 12:29, Jaromil wrote:

dear Anto

On 12 June 2015 18:01:07 CEST, Anto  wrote:


I should have written my previous sentence properly like "there was no
connman GUI interface for XFCE in Debian wheezy when I tried it". :)

I just double checked. There is actually connman gui on Devuan/Debian
jessie as shown below. But I have not tried that yet. Does anybody try
that on XFCE?


I use connman regularly on my desktop also via the gui component

it is not perfect, but works well for basic operations

I'd prefer something simplier and mostly bound to shell scripts and a light gui 
layer for the tray, which is handy.

ciao



Hello Jaromil,

Thanks a lot for your feedback.

However, after I found that there is a commit with the title "machine: 
Integrate ConnMan with systemd-hostnamed" on connman source code which I 
posted on this thread yesterday, I decided to stay away from connman. I 
am quite sure that along the time, there will be more integration to 
systemd.


Cheers,

Anto

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] task-xfce-desktop, task-mate-desktop task-lxde-desktop proposed changes.

[Anto]

On 13/06/15 08:38, Daniel Reurich wrote:

Hi,

I'm currently looking at patching the desktop tasks in taskselect to 
use slim instead of lightdm (atleast until lightdm has been cleaned up 
to not depend on systemd).


Also I'm planning to replace gnome-network-manager in those tasks with 
wicd.


These changes bring us closer to our goal of not needing to install 
any systemd dependencies.  (There still are packages like cups and 
lxsession that need to have the tie-ins to systemd excised.


Also, these changes only effect from scratch installation of Devuan, 
where tasksel is used.  Installing the removed packages manually will 
work just fine.


Regards,
Daniel.


Hello Daniel,

That is possibly the best option that we could have. Thanks for the idea.

I have never used slim before and I have been using lightdm for years. 
But after looking at slim source code, it is cleaner than lightdm as 
there is only 1 file that is related to systemd, i.e. slim.service. So I 
decided to re-compile slim, of course after removing everything related 
to systemd including adding the following patch.


anto@d945gclf:~/packages/development/slim/mine/slim-1.3.6/debian/patches$ cat 
do-not-install-unused-file.patch

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -251,9 +251,5 @@ if(BUILD_SLIMLOCK)
 endif(BUILD_SLIMLOCK)
 # configure
 install(FILES slim.conf DESTINATION ${SYSCONFDIR})
-# systemd service file
-if (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
-install(FILES slim.service DESTINATION ${LIBDIR}/systemd/system)
-endif (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
 # themes directory
 subdirs(themes)
anto@d945gclf:~/packages/development/slim/mine/slim-1.3.6/debian/patches$

I installed it on my test PC, purged lightdm and it looks to be running 
fine. I need to play around a bit with its setting before I install it 
on my main PC.


About wicd, I have been looking for alternative of that because I 
occasionally experience WiFi disconnection. It looks that it tries to 
move to another access point even the signal strength and quality is not 
good. I have 3 access points (two at 2.4 GHz and one at 5 GHz) in my 
apartment with the same SSID to minimise the severe interference.


Do you or anybody else have any suggestion to solve this occasional drop 
of WiFi connection on wicd?


Cheers,

Anto

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] A nice candidate substitute to network-manager

[Jaromil]

dear Anto

On 12 June 2015 18:01:07 CEST, Anto  wrote:

>I should have written my previous sentence properly like "there was no 
>connman GUI interface for XFCE in Debian wheezy when I tried it". :)
>
>I just double checked. There is actually connman gui on Devuan/Debian 
>jessie as shown below. But I have not tried that yet. Does anybody try 
>that on XFCE?
>

I use connman regularly on my desktop also via the gui component

it is not perfect, but works well for basic operations

I'd prefer something simplier and mostly bound to shell scripts and a light gui 
layer for the tray, which is handy.

ciao
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Readiness notification

[KatolaZ]

On Sat, Jun 13, 2015 at 08:40:27AM +0200, Didier Kryn wrote:

[cut]

> 
> The question now is who will develop, maintain and package this
> wrapper? Will Devuan be the official developper of
> "Systemd-Readyness-Wrapper", or can anyone convince Openssh or who
> else to take the job? Or are the daemon's developper powerfull
> enough to tell RH "do it yourself."?
> 

I think there is another, more fundamental question: do we really need
to know in *real time* when a service/daemon is ready for its job or
has done what it is supposed to do?  AFAIK all this fuss with
"daemon-readiness" began with the first attempts to have parallel boot
sequences, which is something that is still *useless* in 95% of the
use cases: servers don't get restarted evey other minute and "normal"
users who don't use suspend can wait 30 seconds to have their desktop
ready, what else? Embedded systems? Well, they usually have just a few
services running, if any

What are we really talking about? Isn't this just another
feature-for-the-feature's-sake-thing? Why should I bother to allow
cups signalling immediately that it is ready to put my printouts on a
queue that will anyway need minutes to be processed?

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Readiness notification

[marc]

> On 12/06/2015 22:21, marc...@welz.org.za wrote:
> >The trick is for the daemon process to only background when
> >it is ready to service requests (ie its parent process exits
> >when the child is ready).
> 
>  You already mentioned it in a reply to me, indeed. I intentionally
> did not follow up, and here is why.
> 
>  This is bad design, for several reasons. It's actually worse design
> than sd_notify(), and I'd rather have every daemon use sd_notify()
> and write a sd_notify server myself than recommend your solution.
> 
>  The reasons why it's bad are mostly described here:
>  
> http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/unix-daemon-design-mistakes-to-avoid.html

It is only bad design if you have your heart set on a supervision
framework like daemontools. Such frameworks have been around
for decades too, and have not caught on (also for several reasons ;)
The above link even lists all these attempts, and so presumably
has the agenda of trying to make these frameworks happen

The biggest reason is that in a number of applications it is unclear
if and when things should turn in to a daemon. Consider something
like screen - things only background when you press . In 
general terms having a supervision framework means that a daemon is 
something an administrator decides to create, not something which the 
user asks his application to become.

This has at least four undesirable side-effects:

 * It becomes harder for end users to run their own daemons. Harder,
   less convenient, whatever. Not impossible - with enough contortions
   anything is possible. But it disempowers non-admin users. 

 * Daemon programmers get to become lazy - where previously a crash
   was something horrible, a crash now means that the supervision
   framework restarts it, so no biggie. Welcome to windows, where
   software is expected to crash

 * People are lulled into the false sense of security: "My supervision
   framework thinks the process is still up, so things are ok". But
   your process has has been running in an infinite loop for the
   last couple of days. If you want to have monitoring, monitor
   your task at the service it provides (retrieve a web page from
   a web server, finger the finger daemon). Inevitably that requires
   domain knowledge, which supervision framework advocates struggle
   to realise. Or if you are Lennart, you end up absorbing all domains
   into your supervision framework, at which point we have to
   fork a distribution

 * Supervison frameworks are marketed as "So easy to use, any idiot
   can write a daemon". And assume it to be true and every idiot writes a
   daemon. People who don't know what an attack surface is, how a
   protection domain gets synthesised, etc. And typically in languages
   which assume infinite RAM and CPU time, cause if they run out, they
   just hit the wall...

> Your solution enforces forking, i.e. auto-backgrounding, and
> prevents logging to stderr; in doing so, it prevents daemons from
> ever being used with a supervision framework. 

Closing stderr to the parent does not prevent logging to stderr, you can
quite happily close a file descriptor with dup2(). Or you could use
some other logging framework, but that would then conflict with the 
supervision framework. Framework collisions

On a personal note: You have been making a number of pronouncements
which suggest incomplete understanding of unix: Here unaware of dup2(),
but in previous posts you were unclear on when a shell needs to do a
stat() (5542b2d4.5030...@skarnet.org), misunderstood security through
obscurity (55449253@skarnet.org), do not realise that a setgid
exectuable which isn't world executable is almost useless
(5545e741.5000...@skarnet.org)

So in general this ok, everybody starts off new, nobody is perfect, etc.
But surely it is worth understanding something before wanting to
redesign it wholesale (5542603e.8000...@skarnet.org, and now here
with daemon startup). Especially in a forum (devuan) which appears
to have been forked in response to such a poorly conceived redesign.
Consider your closing statement here:

>  But auto-backgrounding is not good
>  design in the first place; it comes from ancient Unix times when we
>  did not know better, and the daemon() function should either
>  disappear into oblivion, or have a place in the museum of medieval
>  programming as an example of how not to write Unix software.

This paragraph does not convey anything useful, and the tone
comes across as arrogant - consider carefully whom label as not
knowing how to write Unix software, cause you might fit that 
description rather well, like all of us

regards

marc
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] task-xfce-desktop, task-mate-desktop task-lxde-desktop proposed changes.

[Irrwahn]

On Sat, 13 Jun 2015 18:38:29 +1200, Daniel Reurich wrote:
> I'm currently looking at patching the desktop tasks in taskselect to use 
> slim instead of lightdm (atleast until lightdm has been cleaned up to 
> not depend on systemd).

Slim should work fine as the default display manager. Although I personally 
ever so slightly prefer lightdm (only for the script hooks actually), I 
would be content with slim as well. It's KISS, and it works. I can switch 
without trouble between the two, noticing only differences in visual 
appearance. 

> Also I'm planning to replace gnome-network-manager in those tasks with wicd.

As for wicd I guess it too should easily meet the requirements. Plus, (aside 
from the systemd aspect) it does not pull in a whole host of packages in its 
wake like network-manager[-gnome] does; packages which are not necessarily 
desirable on e.g. lean DE installations.

> These changes bring us closer to our goal of not needing to install any 
> systemd dependencies.  (There still are packages like cups and lxsession 
> that need to have the tie-ins to systemd excised.
> 
> Also, these changes only effect from scratch installation of Devuan, 
> where tasksel is used.  Installing the removed packages manually will 
> work just fine.

So +1 for both proposals from me. Especially since, as you say, it's only 
about the tasksel, and it would presumably shorten the time till stable 
release.

Cheers
Urban
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng