Rainer Weikusat wrote:
> But leaving these two general remarks aside, I don't quite understand
> what you wanted to express.
That "freedom of choice" is very important - as demonstrated by two posts
setting out the reason why (for the poster's situation) the correct option is
both one way and
Le 04/05/2016 15:44, Rob Owens a écrit :
- Original Message -
From: "Didier Kryn"
Le 03/05/2016 19:10, Rob Owens a écrit :
Yes, but then when an openrc user wants to start/stop a service, he
cannot do '/etc/init.d/myservice start' like he could do on any other
OS using openrc. He'd ha
Hendrik Boom writes:
> On Wed, May 04, 2016 at 09:45:24PM +0100, Rainer Weikusat wrote:
>> Stephanie Daugherty writes:
>> > Process supervision is something I'm very opinionated about. In a number of
>> > high availability production environments, its a necessary evil.
>> >
>> > However, it shoul
On Wed, May 04, 2016 at 09:45:24PM +0100, Rainer Weikusat wrote:
> Stephanie Daugherty writes:
> > Process supervision is something I'm very opinionated about. In a number of
> > high availability production environments, its a necessary evil.
> >
> > However, it should *never* be an out of the bo
Stephanie Daugherty writes:
> Process supervision is something I'm very opinionated about. In a number of
> high availability production environments, its a necessary evil.
>
> However, it should *never* be an out of the box default for any
> network-exposed service, Service failures should be ext
Stephanie Daugherty writes:
Service failures should be extraordinary events, and we should
strive to keep treating them as such, so that we continue to
pursue stability. Restarting a service automatically doesn't
improve stability of that software, it works around an
instability rather than ad
On Wed, 04 May 2016 18:18:02 +
Stephanie Daugherty wrote:
> Process supervision is something I'm very opinionated about. In a
> number of high availability production environments, its a necessary
> evil.
>
> However, it should *never* be an out of the box default for any
> network-exposed s
On Wed, May 04, 2016 at 01:55:15PM -0400, Steven W. Scott wrote:
> It sort of reminded me of Ubuntu, where networking issn't activated until
> desktop login time. Once I added the adapters to interfaces and set up the
> wpa_supplicant definitions the fstab mount was successful. Most bothersome
>
Process supervision is something I'm very opinionated about. In a number of
high availability production environments, its a necessary evil.
However, it should *never* be an out of the box default for any
network-exposed service, Service failures should be extraordinary events,
and we should striv
FYI,
If anybody is having trouble getting nfs mounts in fstab to work, have
a look at /etc/network/interfaces and make sure your interface is defined
there - I've been trying to figure out why mine wasn't working for the past
few days and found the only thing in interfaces was lo.
Could have b
upstart is init subsystem which is using same names for binaries; commands
as sysvinit probably to be a drop in replacement, not ment to coexist with
sysvinit.
sysv-rc,openrc , file-rc all depend on init binary daemon and are
replacements for init.d/rc(S) files which init binary executes. so they
On Wed, 4 May 2016 09:54:37 -0400 (EDT)
Rob Owens wrote:
> - Original Message -
> > From: "Steve Litt"
>
> > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > Rob Owens wrote:
> >
> >> I agree with putting each init in its own directory, but sysvinit
> >> should not own /etc/init.d. sy
On Tue, 3 May 2016 22:41:48 -1000
Joel Roth wrote:
> We're not the first people to think about supporting
> alternative init systems. There are collections of the
> init scripts already available.
>
> https://bitbucket.org/avery_payne/supervision-scripts
> https://github.com/tokiclover/supervisi
On Wed, 5/4/16, fsmithred wrote:
Subject: Re: [DNG] Default purpy desktop theme
To: dng@lists.dyne.org
Date: Wednesday, May 4, 2016, 11:13 AM
On 05/04/2016 11:20 AM, Go Linux wrote:
> Evidently the default purpy desktop graphics didn't make it into the beta.
> :( You can find the purpy w
On 05/04/2016 11:20 AM, Go Linux wrote:
> Evidently the default purpy desktop graphics didn't make it into the beta.
> :( You can find the purpy wallpaper here (among all the others):
>
> https://git.devuan.org/devuan-packages/desktop-base/tree/master/backgrounds
>
> And it looks like the purp
Evidently the default purpy desktop graphics didn't make it into the beta. :(
You can find the purpy wallpaper here (among all the others):
https://git.devuan.org/devuan-packages/desktop-base/tree/master/backgrounds
And it looks like the purpy window manager theme is here:
https://git.devuan.
If I had to be and admin of mixture of linux distributions I would
probably use 'service', instead of remembering all commands suited for
different init flavours and checking on which box I'm about to run a
command.
But in such a case I probably would not care what kind of init
subsystem is runnin
Someone said they wanted a non-gui way to mount removable devices by
label. Here it is. Let me know if it works for you or not. (It's working
well here.)
I'll add support for labels in the gui pmounter, too.
https://gist.github.com/fsmithred/81a4e1585175c377c32ed2f670ab9ef3
-fsr
___
On Wed, May 04, 2016 at 09:44:30AM -0400, Rob Owens wrote:
Normally *this* admin never uses the service command because:
You should because the service command cleans the environment. If you do
„/etc/init.d/ start” you can have strange results.
1) it is not available on all distros or may n
- Original Message -
> From: "Steve Litt"
> On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> Rob Owens wrote:
>
>> I agree with putting each init in its own directory, but sysvinit
>> should not own /etc/init.d. sysvinit stuff should go in /etc/sysvinit
>> and by default /etc/init.d should be
Robert Storey writes:
> For whatever it's worth, I'm fully supportive of the idea of defaulting to
> a simpler init system such as S6, Epoch, Runit, you-name-it. I can't speak
> for anyone else, of course, but I tend to think the sort of people who are
> attracted to Devuan see the virtue of simpl
- Original Message -
> From: "Didier Kryn"
> Le 03/05/2016 19:10, Rob Owens a écrit :
>> Yes, but then when an openrc user wants to start/stop a service, he
>> cannot do '/etc/init.d/myservice start' like he could do on any other
>> OS using openrc. He'd have to do '/etc/openrc/myservice
Le 04/05/2016 10:30, Joel Roth a écrit :
How do you like ceni? There isn't much detail in the man
page. How does it deal with suspend? (With wicd-gtk I have
to reconnect after wake-up.)
I see there is a debian package available here:
I have ceni installed on my Debian-wheezy. I just gave i
Hendrik Boom escribió:
On Wed, May 04, 2016 at 11:23:05AM +, hellekin wrote:
On 05/03/2016 06:05 PM, Steve Litt wrote:
> On Tue, 3 May 2016 10:44:29 +
> hellekin wrote:
>
>
>> I want to call it "rabbit" or "Shub-Niggurath"
>
> I fear the latter name would not be well received in the
Am Wed, 04 May 2016 10:07:01 +
schrieb dng-requ...@lists.dyne.org:
> How do you like ceni? There isn't much detail in the man
> page. How does it deal with suspend? (With wicd-gtk I have
> to reconnect after wake-up.)
>
> I see there is a debian package available here:
>
> http://aptosid.com
On Wed, May 04, 2016 at 08:10:40AM +0100, Simon Hobson wrote:
> Steve Litt wrote:
>
> > There's a special place in hell for people using ambiguous
> > abbreviations, acronyms, and nicknames.
>
> You mean, like the whole IT industry - and in fact pretty well any industry ?
> Such terms are routi
On Wed, May 04, 2016 at 11:23:05AM +, hellekin wrote:
> On 05/03/2016 06:05 PM, Steve Litt wrote:
> > On Tue, 3 May 2016 10:44:29 +
> > hellekin wrote:
> >
> >
> >> I want to call it "rabbit" or "Shub-Niggurath"
> >
> > I fear the latter name would not be well received in the United Sta
On 05/03/2016 06:05 PM, Steve Litt wrote:
> On Tue, 3 May 2016 10:44:29 +
> hellekin wrote:
>
>
>> I want to call it "rabbit" or "Shub-Niggurath"
>
> I fear the latter name would not be well received in the United States.
>
Would replacing "Shub-Niggurath" with "Henry Ford" make it any be
On 05/04/2016 05:58 AM, Boruch Baum wrote:
> On 2016-05-02 08:12, fsmithred wrote:
>> No support for file system labels at this time. If someone can tell me a
>> reliable way for unprivileged user to get the labels, I'll add it. Feel
>> free to use these scripts as they are or as motivation to crea
Steve Litt escribió:
[...]
I think the only daemons you really need in an installer are the
gettys, sshd, wpa_supplicant and dhcpcd. And you'll probably want
the display manager too. Those obviously must be included in packages.
The more obscure stuff can exist first on the Wiki, and gradually b
Le 04/05/2016 11:58, Boruch Baum a écrit :
On 2016-05-02 08:12, fsmithred wrote:
No support for file system labels at this time. If someone can tell me a
reliable way for unprivileged user to get the labels, I'll add it. Feel
free to use these scripts as they are or as motivation to create somet
On 2016-05-02 08:12, fsmithred wrote:
> No support for file system labels at this time. If someone can tell me a
> reliable way for unprivileged user to get the labels, I'll add it. Feel
> free to use these scripts as they are or as motivation to create something
> better.
Are you looking for?:
Le 04/05/2016 05:43, Joel Roth a écrit :
nteresting, I thought /sbin was historically for statically
linked executables needed at boot time, or for system
recovery.
I think the 's' stands for "System-critical", not "Statically-linked".
Didier
___
Le 03/05/2016 20:03, Steve Litt a écrit :
On Tue, 3 May 2016 11:53:33 +0200
Didier Kryn wrote:
Yes, I know. All these front-ends use wpa_supplicant in their
kitchen. I just wonder why they find it more clever to re-do on their
own what wpa_supplicant can do alone.
I think I can answer
We're not the first people to think about supporting
alternative init systems. There are collections of the
init scripts already available.
https://bitbucket.org/avery_payne/supervision-scripts
https://github.com/tokiclover/supervision
--
Joel Roth
__
emnin...@riseup.net wrote:
> Also: Ceni is an excellent ncurses based tool to administrate network
> connections (it's based on dhcpd and wpa_supplicant), more basic then
> networkmanager and wicd ((who both, it think, there are not just
> overlays but they use their own way to deal with the hardwa
Le 03/05/2016 19:12, fsmithred a écrit :
@Didier - try pulling out the usb stick and replacing it with a different
one. When I do that, the cache does not get updated.
didn't try that. will do tonight :-)
___
Dng mailing list
Dng@lists.dyne.org
ht
Le 03/05/2016 19:10, Rob Owens a écrit :
Yes, but then when an openrc user wants to start/stop a service, he
cannot do '/etc/init.d/myservice start' like he could do on any other
OS using openrc. He'd have to do '/etc/openrc/myservice start'. Not a
really big deal, but I think it's undesirable
Le 03/05/2016 17:27, fsmithred a écrit :
On 05/03/2016 09:34 AM, Didier Kryn wrote:
Le 03/05/2016 14:48, hellekin a écrit :
On 05/03/2016 12:16 PM, Jim Murphy wrote:
Problem, blkid uses a cache that is only updated when root runs blkid.
Any changes are not automatically updated. A user only s
On Wed, 04 May 2016 06:47:06 +
Noel Torres wrote:
> Steve Litt escribió:
>
> > On Mon, 2 May 2016 22:15:44 -1000
> > Joel Roth wrote:
> >
> >
> >> The problem with supporting multiple init systems is that
> >> there is an init script for each service that has to be
> >> ported or rewritt
On Wed, May 04, 2016 at 01:03:08PM +0800, Robert Storey wrote:
> For whatever it's worth, I'm fully supportive of the idea of defaulting to
> a simpler init system such as S6, Epoch, Runit, you-name-it.
Many people agree that sysvinit with its symlinks and run
levels is overly complex for the com
Steve Litt wrote:
> There's a special place in hell for people using ambiguous
> abbreviations, acronyms, and nicknames.
You mean, like the whole IT industry - and in fact pretty well any industry ?
Such terms are routinely used because they make speech and writing less
verbose. I did my appre
42 matches
Mail list logo
