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

Groups > linux.debian.user > #161396 > unrolled thread

A stop job is running for...

Back to article view | Back to linux.debian.user

Contents

  A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-01 03:20 +0100
    Re: A stop job is running for... Sven Arvidsson <sa@whiz.se> - 2015-12-01 15:50 +0100
      Re: A stop job is running for... "James P. Wallen" <jpwallen@comcast.net> - 2015-12-02 04:40 +0100
        Re: A stop job is running for... Martin Read <zen75502@zen.co.uk> - 2015-12-02 12:10 +0100
          Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-02 16:20 +0100
          Re: A stop job is running for... "James P. Wallen" <jpwallen@comcast.net> - 2015-12-02 16:20 +0100
            Re: A stop job is running for... Himanshu Shekhar <irm2015006@iiita.ac.in> - 2015-12-03 11:30 +0100
              Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-03 18:20 +0100
                Re: A stop job is running for... Michael Biebl <biebl@debian.org> - 2015-12-03 19:10 +0100
                  Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-03 21:30 +0100
                    Re: A stop job is running for... Michael Biebl <biebl@debian.org> - 2015-12-03 22:10 +0100
                      Systemd debugging (was ... Re: A stop job is running for...) Chris Bannister <cbannister@slingshot.co.nz> - 2015-12-04 10:20 +0100
                Re: A stop job is running for... Rick Thomas <rbthomas@pobox.com> - 2015-12-03 19:30 +0100
                  Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-03 22:20 +0100
          Re: A stop job is running for... David Wright <deblis@lionunicorn.co.uk> - 2015-12-02 17:00 +0100
            Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-02 18:10 +0100
              Re: A stop job is running for... Michael Biebl <biebl@debian.org> - 2015-12-02 18:20 +0100
                Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-02 19:00 +0100
                  Re: A stop job is running for... Michael Biebl <biebl@debian.org> - 2015-12-02 20:10 +0100
                    Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-02 20:30 +0100
                Re: A stop job is running for... David Wright <deblis@lionunicorn.co.uk> - 2015-12-06 03:30 +0100
          Re: A stop job is running for... Gene Heskett <gheskett@shentel.net> - 2015-12-02 19:30 +0100
            Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-02 20:10 +0100
              Re: A stop job is running for... Don Armstrong <don@debian.org> - 2015-12-03 00:00 +0100
                Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-03 00:40 +0100
                Re: A stop job is running for... David Wright <deblis@lionunicorn.co.uk> - 2015-12-03 20:20 +0100
                  Re: A stop job is running for... Don Armstrong <don@debian.org> - 2015-12-04 19:50 +0100
                    Re: A stop job is running for... Himanshu Shekhar <irm2015006@iiita.ac.in> - 2015-12-05 07:30 +0100
                      Re: A stop job is running for... Jape Person <japers@comcast.net> - 2015-12-05 17:10 +0100
              Re: A stop job is running for... Gene Heskett <gheskett@shentel.net> - 2015-12-03 02:20 +0100
                Re: A stop job is running for... Chris Bannister <cbannister@slingshot.co.nz> - 2015-12-03 03:50 +0100
                  Re: A stop job is running for... "Neal P. Murphy" <neal.p.murphy@alum.wpi.edu> - 2015-12-03 04:10 +0100
                    Re: A stop job is running for... Gene Heskett <gheskett@shentel.net> - 2015-12-03 04:30 +0100
                  Re: A stop job is running for... Gene Heskett <gheskett@shentel.net> - 2015-12-03 04:30 +0100
                Re: A stop job is running for... Nicolas George <george@nsup.org> - 2015-12-03 08:50 +0100
                  Re: A stop job is running for... Gene Heskett <gheskett@shentel.net> - 2015-12-03 12:00 +0100
                    Re: A stop job is running for... <tomas@tuxteam.de> - 2015-12-03 13:10 +0100

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

#161595

On Wed 02 Dec 2015 at 18:17:18 (+0100), Michael Biebl wrote:
> Am 02.12.2015 um 18:05 schrieb Jape Person:
> > On 12/02/2015 10:49 AM, David Wright wrote:
> >> I have observed behaviour where, when the time limit of 90 seconds is
> >> reached, the limit increases by another 90 seconds and nothing else
> >> happens (for hours). eg
> >>
> >> [ <*> ] A stop job is running for Manage, Install and Generate Color
> >> Profiles (34min 54s / 36min)_
> >>
> >> Fortunately, that hasn't happened for a few months. It's very
> >> embarrassing when my laptop takes longer to close down than my
> >> wife's W10.
> 
> Sounds like it could be hard to reproduce indeed.
> 
> > Now *that* would be annoying.
> 
> In case you run into such a situation again, where a service is blocking
> the shutdown you can of course just use force and pull the plug or use
> sysrq b.
> But there is a nicer alternative: just hit ctrl+alt+del quickly 7 times.
> systemd then will initiate a forced shutdown. See [1].

[...]

> http://www.freedesktop.org/software/systemd/man/systemd.html#SIGINT

I presume that this facility was added between versions 215 (jessie)
and 228 (this web page) so I'm hoping not to need it. Thanks anyway.

Cheers,
David.

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

#161467

On Wednesday 02 December 2015 06:06:09 Martin Read wrote:

> On 02/12/15 03:07, James P. Wallen wrote:
> > Thanks for your response, Sven. It's nice to know that someone else
> > has seen this type of problem. I was thinking that this could be
> > self-inflicted. Perhaps that's a little less likely now.
> >
> > So, is this behavior controlled by systemd?
> >
> > I'm not trying to start a fracas. I'm really interested. What I'm
> > asking is, do I need to start poring over systemd documentation to
> > see if there might be a way to control this behavior?
>
> If a stop job is taking two minutes, that suggests that the service
> has one or more ExecStop lines defined in its service unit and that
> one of those commands is taking an unduly long time to complete for
> some reason.
>
> The default and per-service timeout values for stopping a service
> (after which systemd gives up and sends fatal signals to all of the
> service's processes) are configurable; see the systemd-system.conf(5)
> and systemd.service(5) man pages for details.

'scuse me, but shouldn't the errant process be fixed so it can stop and 
clean up after itself?  Thats the real bug here.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#161468

On 12/02/2015 01:21 PM, Gene Heskett wrote:
> On Wednesday 02 December 2015 06:06:09 Martin Read wrote:
>
>> On 02/12/15 03:07, James P. Wallen wrote:
>>> Thanks for your response, Sven. It's nice to know that someone else
>>> has seen this type of problem. I was thinking that this could be
>>> self-inflicted. Perhaps that's a little less likely now.
>>>
>>> So, is this behavior controlled by systemd?
>>>
>>> I'm not trying to start a fracas. I'm really interested. What I'm
>>> asking is, do I need to start poring over systemd documentation to
>>> see if there might be a way to control this behavior?
>>
>> If a stop job is taking two minutes, that suggests that the service
>> has one or more ExecStop lines defined in its service unit and that
>> one of those commands is taking an unduly long time to complete for
>> some reason.
>>
>> The default and per-service timeout values for stopping a service
>> (after which systemd gives up and sends fatal signals to all of the
>> service's processes) are configurable; see the systemd-system.conf(5)
>> and systemd.service(5) man pages for details.
>
> 'scuse me, but shouldn't the errant process be fixed so it can stop and
> clean up after itself?  Thats the real bug here.
>
>
> Cheers, Gene Heskett
>

It's occurred to me that, though I have occasionally seen service 
shutown issues with sysv-init, they were never as pervasive or repetitve 
as it has been since switching to systemd as the init system. And the 
issue seems to be happening with several different types of services. 
That at least begs the question as to whether the problem is really with 
the services themselves or with the way they are controlled by systemd.

I'm guessing that this is just a sort of shakedown cruise problem, where 
it may be that those who develop and maintain some packages will have to 
customize those packages' service units to work properly with systemd OR 
that there are problems with systemd itself OR both.

Or maybe end users like me just need to learn to deal with systemd. 
However, the idea of having end users edit service units hardly seems 
like an ideal routine.

Regards,
JP

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

#161483

On Wed, 02 Dec 2015, Jape Person wrote:
> It's occurred to me that, though I have occasionally seen service
> shutown issues with sysv-init, they were never as pervasive or
> repetitve as it has been since switching to systemd as the init
> system.

This is generally because sysv-init tends to not pay attention to
whether a particular service has actually stopped. Many init scripts
just send an appropriate signal, hope for the best, and return control.
 
If your goal is just to shutdown the system regardless of what is
actually going on, that's great... but if you value your data, that's
not really a workable solution.

That said, most of these cases are bugs, not really cases where the
daemon is actually doing something; reporting the bugs when you run into
them will help them get fixed.

-- 
Don Armstrong                      http://www.donarmstrong.com

"You know," said Arthur, "it's at times like this, when I'm trapped in
a Vogon airlock with a man from Betelgeuse, and about to die from
asphyxiation in deep space that I really wish I'd listened to what my
mother told me when I was young."
"Why, what did she tell you?"
"I don't know, I didn't listen."
 –- Douglas Adams _The Hitchhikers Guide To The Galaxy_

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

#161485

On 12/02/2015 05:59 PM, Don Armstrong wrote:
> On Wed, 02 Dec 2015, Jape Person wrote:
>> It's occurred to me that, though I have occasionally seen service
>> shutown issues with sysv-init, they were never as pervasive or
>> repetitve as it has been since switching to systemd as the init
>> system.
>
> This is generally because sysv-init tends to not pay attention to
> whether a particular service has actually stopped. Many init scripts
> just send an appropriate signal, hope for the best, and return control.
>

Yes, that was my understanding. Sysv-init worked just fine for my my use 
cases, but I can easily see that the arrangement might not work so well 
for something like, say, a print server.

> If your goal is just to shutdown the system regardless of what is
> actually going on, that's great... but if you value your data, that's
> not really a workable solution.
>
> That said, most of these cases are bugs, not really cases where the
> daemon is actually doing something; reporting the bugs when you run into
> them will help them get fixed.
>

I finally found this older thread(1) which gave me some ideas as to how 
to proceed in trying to find the cause of the issue.

I want to be useful, but it takes a bit of time for those of us who 
fumble about in darkness to find the walls. We have to find one of those 
before we stand a chance of getting to the cave entrance. I may return 
if I don't first impale myself on a stalagmite.

;-)

JP

(1) https://bugzilla.redhat.com/show_bug.cgi?id=1044602

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

#161529

On Wed 02 Dec 2015 at 16:59:23 (-0600), Don Armstrong wrote:
> On Wed, 02 Dec 2015, Jape Person wrote:
> > It's occurred to me that, though I have occasionally seen service
> > shutown issues with sysv-init, they were never as pervasive or
> > repetitve as it has been since switching to systemd as the init
> > system.
> 
> This is generally because sysv-init tends to not pay attention to
> whether a particular service has actually stopped. Many init scripts
> just send an appropriate signal, hope for the best, and return control.
>  
> If your goal is just to shutdown the system regardless of what is
> actually going on, that's great... but if you value your data, that's
> not really a workable solution.

Which data do you mean? By the time I instigate a shutdown, I've saved
my data and, if at home, copied to my server. So I'm hoping that's safe.

By the time these Stop jobs start running, there are just system
processes running. I don't really care about them as long as the
filesystems get unmounted. Almost anything is better than a forced
poweroff followed by fscking saying things at the next boot.

> That said, most of these cases are bugs, not really cases where the
> daemon is actually doing something; reporting the bugs when you run into
> them will help them get fixed.

At the time I had the timeout-increasing problem, I was still focussed
on getting Start jobs to succeed, particularly when the kernel
"forgot" to load binfmt_misc (for help on which, I thank you again).

Cheers,
David.

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

#161559

On Thu, 03 Dec 2015, David Wright wrote:
> Which data do you mean?

For example, a database server[1] which has a transaction outstanding or
needs a long time to write to disk for an orderly shutdown.

> By the time these Stop jobs start running, there are just system
> processes running. I don't really care about them as long as the
> filesystems get unmounted.

The issue here are the system processes, which in some cases need more
time to shut down.


1: To the best of my knowledge, the sysv init scripts for postgresql and
mysql actually handle this properly, so this is more of a theoretical
example.
-- 
Don Armstrong                      http://www.donarmstrong.com

I leave the show floor, but not before a pack of caffeinated Jolt gum
is thrust at me by a hyperactive girl screaming, "Chew more! Do more!"
The American will to consume more and produce more personified in a
stick of gum. I grab it.
 -- Chad Dickerson

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

#161567

[Multipart message — attachments visible in raw view] — view raw

Well, Google shall help! The two articles seem much technical for a kid
like me. Still, the content made me feel that there shall be something
convincing, which is why I posted it on this mail.

1. https://lists.fedoraproject.org/pipermail/users/2014-February/446722.html
           # for NTP
2. https://bugzilla.redhat.com/show_bug.cgi?id=1044602
                  # for CUPS

The message may be irrelevant due to lack of knowledge. So you may ignore
it if it is so.

Regards
Himanshu Shekhar

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

#161573

On 12/05/2015 01:21 AM, Himanshu Shekhar wrote:
> Well, Google shall help! The two articles seem much technical for a kid
> like me. Still, the content made me feel that there shall be something
> convincing, which is why I posted it on this mail.
>
> 1.
> https://lists.fedoraproject.org/pipermail/users/2014-February/446722.html
>           # for NTP

This post supplies two "fixes" for the NTP problem, but only by not 
allowing the service to start in the first place, or by doing what has 
been suggested earlier in the thread -- forcing the system to shut down 
without waiting. I do want my systems to benefit from syncrhonization 
with time sources. And the purpose of all of the discussion is to 
actually find out what's wrong with what component(s) of the system 
that's causing the problem in the first place.

> 2. https://bugzilla.redhat.com/show_bug.cgi?id=1044602
>                      # for CUPS
>

I actually posted that link earlier in the thread in my reply of 12/02 
to Don Armstrong. The indication is that CUPS was interacting with the 
avahi daemon both directly and indirectly (via systemd configuration). 
Especially if the problem is caused by the direct interaction, there's 
not much of anything that an end user could do to fix the problem -- 
except report it. And that would require a lot of work to figure out 
what really is the culprit. That's something that's well beyond my skill 
level, but Michael Biebl had been pursuing the matter offline by 
providing the monkey (me) with step-by-step instructions to help him 
suss out the issues.

Unfortunately, I have discovered a separate interfering issue on my 
systems which may have muddied the waters. I'm not sure whether or not 
Michael will be continuing to work on my particular problem since 
eliminating the interfering issue has essentially fixed both the CUPS 
and NTP problems for me.

> The message may be irrelevant due to lack of knowledge. So you may
> ignore it if it is so.
>
> Regards
> Himanshu Shekhar

Not at all. I appreciate your interest, and I would certainly not ignore 
you. I intend to report back with the findings in my particular case 
when I know a little more.

In the meantime, we should remember that others have reported the same 
issue with CUPS and NTP. I suspect that those others are unlikely (IMO) 
to be running systems with the same configuration as mine. So the 
problem with CUPS and NTP vs. systemd is probably real -- even if it 
might only be a corner case.

Regards,
JP

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

#161489

On Wednesday 02 December 2015 14:02:50 Jape Person wrote:

> On 12/02/2015 01:21 PM, Gene Heskett wrote:
> > On Wednesday 02 December 2015 06:06:09 Martin Read wrote:
> >> On 02/12/15 03:07, James P. Wallen wrote:
> >>> Thanks for your response, Sven. It's nice to know that someone
> >>> else has seen this type of problem. I was thinking that this could
> >>> be self-inflicted. Perhaps that's a little less likely now.
> >>>
> >>> So, is this behavior controlled by systemd?
> >>>
> >>> I'm not trying to start a fracas. I'm really interested. What I'm
> >>> asking is, do I need to start poring over systemd documentation to
> >>> see if there might be a way to control this behavior?
> >>
> >> If a stop job is taking two minutes, that suggests that the service
> >> has one or more ExecStop lines defined in its service unit and that
> >> one of those commands is taking an unduly long time to complete for
> >> some reason.
> >>
> >> The default and per-service timeout values for stopping a service
> >> (after which systemd gives up and sends fatal signals to all of the
> >> service's processes) are configurable; see the
> >> systemd-system.conf(5) and systemd.service(5) man pages for
> >> details.
> >
> > 'scuse me, but shouldn't the errant process be fixed so it can stop
> > and clean up after itself?  Thats the real bug here.
> >
> >
> > Cheers, Gene Heskett
>
> It's occurred to me that, though I have occasionally seen service
> shutown issues with sysv-init, they were never as pervasive or
> repetitve as it has been since switching to systemd as the init
> system. And the issue seems to be happening with several different
> types of services. That at least begs the question as to whether the
> problem is really with the services themselves or with the way they
> are controlled by systemd.
>
> I'm guessing that this is just a sort of shakedown cruise problem,
> where it may be that those who develop and maintain some packages will
> have to customize those packages' service units to work properly with
> systemd OR that there are problems with systemd itself OR both.
>
> Or maybe end users like me just need to learn to deal with systemd.
> However, the idea of having end users edit service units hardly seems
> like an ideal routine.
>
> Regards,
> JP

I can agree with that. I can hack up a bash script now & then, but 
wholesale patching really is the sources problem once he/she is aware 
there is a problem.  But it bugs the heck out of me that the guy/gal 
doing the codeing doesn't watch the user lists, so it all has to wait on 
someone qualified enough to wade thru the bug reporter forms and 
actually file the bug.  Thats quite often a week or more additional 
delay before they are aware that there really is a problem.

In the meantime, its hit another 200 users, discouraging them from ever 
touching linux again.  In that regard, we are our own worst enemy at 
times.  Unfortunately, the oar I steer this ship with could be swapped 
for a toothpick and have exactly the same result.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#161490

On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> 
> In the meantime, its hit another 200 users, discouraging them from ever 
> touching linux again.  In that regard, we are our own worst enemy at 
> times.  Unfortunately, the oar I steer this ship with could be swapped 
> for a toothpick and have exactly the same result.

Or you could be in the Windoze world ' stuck up *cough* *cough* 
*whistle* *whistle* ... with no paddle.' :)

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

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

#161492

On Thu, 3 Dec 2015 15:48:07 +1300
Chris Bannister <cbannister@slingshot.co.nz> wrote:

> On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > 
> > In the meantime, its hit another 200 users, discouraging them from ever 
> > touching linux again.  In that regard, we are our own worst enemy at 
> > times.  Unfortunately, the oar I steer this ship with could be swapped 
> > for a toothpick and have exactly the same result.
> 
> Or you could be in the Windoze world ' stuck up *cough* *cough* 
> *whistle* *whistle* ... with no paddle.' :)
> 

And half a gnu.

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

#161494

On Wednesday 02 December 2015 22:05:10 Neal P. Murphy wrote:

> On Thu, 3 Dec 2015 15:48:07 +1300
>
> Chris Bannister <cbannister@slingshot.co.nz> wrote:
> > On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > > In the meantime, its hit another 200 users, discouraging them from
> > > ever touching linux again.  In that regard, we are our own worst
> > > enemy at times.  Unfortunately, the oar I steer this ship with
> > > could be swapped for a toothpick and have exactly the same result.
> >
> > Or you could be in the Windoze world ' stuck up *cough* *cough*
> > *whistle* *whistle* ... with no paddle.' :)
>
> And half a gnu.

And how is that best done on the barbie?

Sorry, couldn't resist, must do better.  Or do I get the Senior Citizen 
discount on this stuff?  As probably the oldest subscriber to this list 
at 81, does that count?  Or is there someone older yet?  ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#161493

On Wednesday 02 December 2015 21:48:07 Chris Bannister wrote:

> On Wed, Dec 02, 2015 at 08:12:24PM -0500, Gene Heskett wrote:
> > In the meantime, its hit another 200 users, discouraging them from
> > ever touching linux again.  In that regard, we are our own worst
> > enemy at times.  Unfortunately, the oar I steer this ship with could
> > be swapped for a toothpick and have exactly the same result.
>
> Or you could be in the Windoze world ' stuck up *cough* *cough*
> *whistle* *whistle* ... with no paddle.' :)

Why the heck to do think I'm here Chris?  I don't allow winderz on the 
property unless I get suckered into trying to fix a box full of viri and 
keyloggers they picked up while trolling for good porn or the next get 
rich quick scheme?  I've already been there, done that, skipped the 
T-shirt, and swore I'd never do that again.  I have come to the 
conclusion that winderz lusers deserve what they get.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#161501

[Multipart message — attachments visible in raw view] — view raw

Le duodi 12 frimaire, an CCXXIV, Gene Heskett a écrit :
>		       But it bugs the heck out of me that the guy/gal 
> doing the codeing doesn't watch the user lists, so it all has to wait on 
> someone qualified enough to wade thru the bug reporter forms and 
> actually file the bug.

Developer time is valuable.

>			  Thats quite often a week or more additional 
> delay before they are aware that there really is a problem.

Regarding support with guaranteed reaction time, you get exactly your
money's worth: 0.

> In the meantime, its hit another 200 users, discouraging them from ever 
> touching linux again.

If these people are so easily discouraged, and especially definitively
discouraged, they probably belong to the kind of people who only ever
complain and never contribute back. Maybe the community is better without
them.

>	  Unfortunately, the oar I steer this ship with could be swapped 
> for a toothpick and have exactly the same result.

Libre Software development is a meritocracy, not a democracy. Your oar is
exactly how large you make it. That means Linus' is larger than yours, of
course, and that is only right. I am still writing about steering oar.

Regards,

-- 
  Nicolas George

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

#161510

On Thursday 03 December 2015 02:41:57 Nicolas George wrote:

> Le duodi 12 frimaire, an CCXXIV, Gene Heskett a écrit :
> >		       But it bugs the heck out of me that the guy/gal
> > doing the codeing doesn't watch the user lists, so it all has to
> > wait on someone qualified enough to wade thru the bug reporter forms
> > and actually file the bug.
>
> Developer time is valuable.
>
> >			  Thats quite often a week or more additional
> > delay before they are aware that there really is a problem.
>
> Regarding support with guaranteed reaction time, you get exactly your
> money's worth: 0.
>
> > In the meantime, its hit another 200 users, discouraging them from
> > ever touching linux again.
>
> If these people are so easily discouraged, and especially definitively
> discouraged, they probably belong to the kind of people who only ever
> complain and never contribute back. Maybe the community is better
> without them.
>
> >	  Unfortunately, the oar I steer this ship with could be swapped
> > for a toothpick and have exactly the same result.
>
> Libre Software development is a meritocracy, not a democracy. Your oar
> is exactly how large you make it. That means Linus' is larger than
> yours, of course, and that is only right. I am still writing about
> steering oar.
>
> Regards,

Well, for me that coding oar is quite large, but I write the huge 
majority of the code I write these days in RS274c, aka g-code to run cnc 
machines.  I have a lathe and 2 milling machines, all run by LinuxCNC.

You would be amazed at what can be done in 200 lines of g-code.  The good 
stuff I'll put up on my web site from time to time, but generally, I'll 
never see a 100 count in the total downloads column in the logs.

But I am quite cognizant of the difference in importance to the linux 
community.  To you, we are at best fringe users.  And thats ok. But we 
are here, and we appreciate the stability of linux.

Amazingly, because I do share the experience on that mailing list, 
frustrations and all, I am apparently well read there, picking up an 
occasional order of flowers from some of the rest because I'm 
so "colorfull".  Makes this old fart think he is appreciated.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#161514

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Dec 03, 2015 at 05:50:09AM -0500, Gene Heskett wrote:
> On Thursday 03 December 2015 02:41:57 Nicolas George wrote:

[...]

> > Libre Software development is a meritocracy, not a democracy [...]

Hm. Somehow I feel that while true, this is just part of the truth.

> Well, for me that coding oar is quite large, but I write the huge 
> majority of the code I write these days in RS274c, aka g-code to run cnc 
> machines.  I have a lathe and 2 milling machines, all run by LinuxCNC.

[...]

> But I am quite cognizant of the difference in importance to the linux 
> community [...]

This. There are many philosophies in all that spectrum Free Software,
Libre, Open Source. It can be "all about the user", it can be "all
about the developer" (and many other things not fitting in this simple
dipole I just sketched). Developers are users all the time. And so
on.

But one of the things that make us greater than the sum of our parts
is definitely the "caring for the user" part. Oftentimes it's what
get people on board, but also what makes new things possible (those
"new things" start often as "just consumers" and are contributing
to totally different areas. Do not trample on the young saplings :-)

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZgJtwACgkQBcgs9XrR2kY7rQCcC+DrM96JhOrNgNeM/SK3Gzv6
C2YAn2/5HzeICjo5KPQX6njsk7yyRN+o
=nLf3
-----END PGP SIGNATURE-----

[toc] | [prev] | [standalone]

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

Back to top | Article view | linux.debian.user

csiph-web