[DNG] ctwm docs

[Steve Litt]

Hi all,

I forgot to mention it, but about a month ago I finished my ctwm
documentation tree:

http://troubleshooters.com/linux/ctwm/

I think it's the best single source of ctwm documentation, although it
certainly could use improvement. 

Ctwm isn't for everybody. It's a no-panel lightweight window manager,
in the same class as Openbox. Not sure, but I think ctwm uses less RAM
than Openbox. Ctwm is much more configurable than Openbox. But
Openbox's behavior is much less surprising, and much handier for most
workflows.

I've been using ctwm for a month now. It's pretty cool. Will I go back
to Openbox? I don't know.

Anyway, feel free to ask me questions about ctwm. I've gotten it
running on Devuan VM guests, and it works well there.
 
SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] systemd-udevd: renamed network interface eth0 to eth1

[golinux]

On 2017-10-20 20:24, Steve Litt wrote:

On Wed, 18 Oct 2017 12:33:33 -0400
John Franklin  wrote:


You owe him an apology.


Perhaps you're right. Here it is. Tobias, instead of railing against
this list's primary priority, why don't you go join the systemd project
and make it the init of your dreams. Lead, follow, or get the hell out
of the way.

SteveT



He already has done just that Steve ;)

https://github.com/hunger/systemd

golinux

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

Re: [DNG] systemd-udevd: renamed network interface eth0 to eth1

[John Franklin]

> On Oct 20, 2017, at 9:24 PM, Steve Litt  wrote:
> 
>> You owe him an apology.
> 
> Perhaps you're right. Here it is. Tobias, instead of railing against
> this list's primary priority, why don't you go join the systemd project
> and make it the init of your dreams. Lead, follow, or get the hell out
> of the way.

That’s not an apology.  Would you like to try again?

jf
-- 
John Franklin
frank...@tux.org



smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] ID Quantique "Quantum" PCI-e RNG's - does anyone have more info?

[taii...@gmx.com]

I found this seemingly cool product, a pci-e hardware RNG that produces 
a large stream of "truly random" "quantum" random numbers.


https://www.idquantique.com/

It is made in Switzerland, which is cool as it isn't outsourced and it 
endeavors way more trust than chinese hardware.



I am curious what the deal with this is, does it really work? what is 
the use case for this? does anyone here have one?


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

Re: [DNG] systemd-udevd: renamed network interface eth0 to eth1

[Steve Litt]

On Wed, 18 Oct 2017 12:33:33 -0400
John Franklin  wrote:

> > On Oct 16, 2017, at 1:51 PM, Steve Litt 
> > wrote:
> > 
> > On Mon, 16 Oct 2017 17:18:43 +0200
> > "Dr. Nikolaus Klepp"  wrote:
> >   
> >> Am Samstag, 7. Oktober 2017 schrieb Tobias Hunger:  
> >>> On Sat, Oct 7, 2017 at 3:46 PM, Didier Kryn 
> >>> wrote:
> Then maybe I misunderstood the reason for EFI.
> >>> 
> >>> UEFI is a huge step forward in pretty much all areas and makes
> >>> booting both simpler and more powerful.  
> > 

[snip]


> > 
> > Tobias Hunger is a systemd apologist and perpetual troll. Instead of
> > contributing to the systemd project, he comes to Devuan discussion
> > venues and says "systemd's not so bad.”  
> 
> Where, exactly, did Tobias mention systemd?

Throughout the "The show goes on: “su” command replacement merged into
systemd on Fedora Rawhide" thread starting 8/28/2015, and the "does
systemd set runlevel 0 in utmp on shutdown?" thread starting 8/28/2015.
Currently the web-based Dng archives are unavailable.


> 
> >>> 
> >>> With UEFI the firmware just loads a efi binary with everything:-)
> >>> MUCH simpler.  
> > 
> > There's absolutely nothing simpler about the preceding sentence:
> > Hunger simply fails to break out a vast tree of subcomponents and
> > dependencies of the "efi binary.”  
> 
> Please enlighten us.

Not my job. I enlighten about good software and features, not
monolithic complexifications. But it's obvious merely mentioning an
executable while comparing it to a complete tree analysis of an
alternative is deliberate propaganda.


> 
> >>> * UEFI allows for more security with secure boot. E.g. my thinkpad
> >>> *only* boots things that I have signed with my key.  
> > 
> > Does Devuan have a key? If not, I guess that's all we need to know
> > about what distro Tobias Hunger REALLY uses. I'm guessing he doesn't
> > have the brainpower to actually implement the distro-independent
> > shim, which sounds like an utter nightmare.  
> 
> Yes, it is clear he’s using a MOK to sign things.  It’s also clear
> you don’t understand what that means, 

You always have been fond of the ad-hominem, haven't you?

Given that you seem to imply this misunderstanding is a deficit on my
part, perhaps you can walk us all through installing a MOK on Devuan
such that we can easily boot UEFI plus Secure Boot with Devuan.

> and instead take another shot
> at insulting him.
> 
> >>> * UEFI allows for different OSes living next to each other
> >>> peacefully, without the constant fight over who writes the MBR and
> >>> with that defines the boot loader.  
> > 
> > Characterization. "Peacefully?" "Constantly fighting?" The fights
> > only occur when changing the boot system. And by the way, if you
> > use MBR boot, you can use the old and superior Grub1 or LILO.  
> 
> Stage 1.5 bootloaders were written to unused parts of the disk.
> Other OSes and tools commonly wrote their intermediate bootloaders or
> RAID configuration or whatnot to unused parts of the disk.  Often, a
> second program would write to the same unused part of the disk,
> overwriting or corrupting the first.  Tobias is spot-on here.

And, as I said above, this "constantly fighting" occurs only when
changing boot systems. Yeah, you have to either use Grub all the time
or use Windows' system all the time. But, having done that, boot
procedes based on the first 512,  without need or interference with
bunches of firmware based memory that can be modified to brick a
system. With the first 512 guiding the whole boot, you can slowly
pull yourself up by the bootstraps to ANY software situation you
want. I'd rather endure the inconvenience of having to use Grub all the
time rather than having a complex and poorly implemented systems such
that you can't install the system you want.


> 
> >> You forgot to mention that UEFI is the best code in the world
> >> written by the the best of the best and therefore absolutely
> >> secure.  
> > 
> > Nik, that should be intuitively obvious to the most casual
> > observer :-)
> > 
> > Tobias Hunger, why don't you go support the project you DO like
> > instead of trolling the one you don't?   
> 
> This is grossly inappropriate.  Toabias’ post was entirely technical
> in nature and accurate.  At no point does his denigrate, insult or
> bully anyone on the list, or advocate the inclusion of packages
> incompatible with the Devuan mission, such as systemd.

My records tell me you've been on this list since August 12 of this
year: A couple months and change. Long ago, when the VUAs were
evangelizing a systemd-free distro, the world said they would fail, and
everyone on the list was working toward removing systemd from Debian,
Tobias Hunger regularly came on this list saying, in effect, "systemd
isn't that bad." He doesn't belong here.
 
> You owe him an apology.

Perhaps you're right. Here it is. Tobias, instead of railing against
this 

Re: [DNG] Debian testing drop redis non systemd

[Steve Litt]

On Thu, 19 Oct 2017 23:46:28 +0200
Adam Borowski  wrote:

> On Thu, Oct 19, 2017 at 10:22:33AM +0200, Jaromil wrote:
> > On Wed, 18 Oct 2017, Arnt Gulbrandsen wrote:
> >   
> > > Steve Litt writes:  
> > > > Does anyone here actually use redis? I looked it up, and to me
> > > > it looks like dbus on steroids. An in-memory data store
> > > > accessible by lots of different applications. What could
> > > > POSSIBLY go wrong?  
> > > 
> > > I've used in several contexts, it's great at its job and a joy to
> > > use.  
> > 
> > Same here, its a core part of many software projects, not only web
> > based but also on embedded systems and micro-service related.
> > 
> > One of its authors, antirez, is an old friend and coding made of
> > some of us here. Redis is heavily inspired by minimalism,
> > simplicity and UNIX principles since its inception. We will contact
> > upstream so they notice the fact the Debian maintainers are
> > removing a support which is provided upstream, since redis does
> > pack scripts for sysvinit that should be left in place.  
> 
> In that case, could you have someone from the upstream file a bug?
> If that support is provided, such a regression is not warranted --
> and a bug report from upstream carries a lot more weight than from a
> mere user.
> 
> > This episode is again of great shame on Debian maintainers, but it
> > should be addressed by upstream.  
> 
> Note that, while it might be tempting to "just fix it in Devuan",
> this would be a great duplication of effort.  A fix in Debian proper
> affects all derivatives, and thus applies to orders of magnitude more
> users than Devuan currently has.  It would also avoid forcing admins
> to use an inferior init/rc system.

Last I heard (which was about 2 years ago), Devuan's plan was to apply
changes to Debian distros for some time, but slowly migrate to a
completely different distro. If I remember correctly, one reason for
becomig independent was to avoid Debian sabotage like we're appearing
to see now on redis.

Devuan has no responsibility to Debian users. If Devuan and Debian can
cooperate, that's cool. But if Debian puts landmines in Devuan's path,
 em!

 
SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Patrick Meade]

On 10/20/2017 10:22 AM, John Hughes wrote:

On 20/10/17 16:37, Antony Stone wrote:
However, Bardot Jérôme's original posting in this thread, quoting 
Chris Lamb

 Wed, 11 Oct 2017 22:55:00 -0400 said:

"This version drops the Debian-specific support for the
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories in
favour of using systemd's ExecStartPre, ExecStartPost, ExecStopPre,
ExecStopPost commands."

So, yes, what's been dropped is Debian-specific, but shouldn't we 
still be

concerned about the "in favour of systemd's ... commands"?


That's not what the Debian changelog says:


That text is not from the Debian changelog, but rather from debian/NEWS.
The GitHub commit is here:

https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-e2b5949461a30128734d213f0ead1565


In the buster/sid version (4:4.0.2-3) there is no code that I can find 
to run the {pre,post}-{up,down} scripts in sysvinit *or* systemd.


As version 4:4.0.2-3 is the version that "drops the Debian-specific 
support for the 
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories", 
it would be rather surprising if you did find those scripts.


I must admit that I'm still learning the ropes with respect to Debian 
packaging. Could you explain this diff of debian/redis-server.init to me?


https://github.com/lamby/pkg-redis/commit/6a9e4d0142b45195a0d55945bbc558df4c48707b#diff-9e388da7cd119765989cc22d2bc07e5c

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

Re: [DNG] Amprolla3 is out for testing

[aitor_czr]

On 10/20/2017 11:47 PM, goli...@dyne.org wrote:

Dear dev1rs,

We are happy to announce that 'amprolla3', the rewrite of nextime's
amprolla by parazyd and Wizzup, is finally up and running and ready
to be tested. 


Hurray!!

The DevJuanBoy


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

[DNG] Amprolla3 is out for testing

[golinux]

Dear dev1rs,

We are happy to announce that 'amprolla3', the rewrite of nextime's
amprolla by parazyd and Wizzup, is finally up and running and ready
to be tested.

The code can be found at:

https://git.devuan.org/devuan-infrastructure/amprolla3

The rewrite increases the frequency of merges (now performed
every few minutes, rather than once a day), meaning that new packages,
updates, and upgrades will be available almost immediately to Devuan
users.

We have set up a second host which will serve Devuan packages as
merged by the new amprolla3. It is now available at
pkgmaster.devuan.org and currently serves Devuan Jessie, Devuan Ascii,
and Devuan Ceres, including all the *-security and *-updates sections.
The host, pkgmaster.devuan.org, also supports https.

If you want to help testing the new amprolla3, you just need to:

- replace "auto.mirror.devuan.org" with "pkgmaster.devuan.org" in
  your /etc/apt/sources.list
- # apt-get update
- # apt-get install devuan-keyring

Then just use it as you did with auto.mirror.devuan.org. Please
report any bugs on https://bugs.devuan.org, as usual.

The current auto.mirror.devuan.org host remains up and running and
perfectly usable. Once the testing of amprolla3 is complete, the
transition to the new system should be seamless and transparent to
all users.

The new amprolla3 also provides support for the currently missing
Contents*.gz files (solving the apt-file bug). The feature will be
made available in the coming couple of days.

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

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 20/10/17 16:37, Antony Stone wrote:

However, Bardot Jérôme's original posting in this thread, quoting Chris Lamb
 Wed, 11 Oct 2017 22:55:00 -0400 said:

"This version drops the Debian-specific support for the
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories in
favour of using systemd's ExecStartPre, ExecStartPost, ExecStopPre,
ExecStopPost commands."

So, yes, what's been dropped is Debian-specific, but shouldn't we still be
concerned about the "in favour of systemd's ... commands"?


That's not what the Debian changelog says:


redis (4:4.0.2-3) unstable; urgency=medium

   * Drop Debian-specific support for
 /etc/redis/redis-{server,sentinel}.{pre,post}-{up,down}.d and remove them
 if unchanged.
   * Include systemd redis-server@.service and redis-sentinel@.service template
 files to easily run multiple instances. (Closes: #877702)
   * Patch redis.conf and sentinel.conf with quilt instead of maintaining our
 own versions under debian/.
   * Refresh all patches.
   * Bump Standards-Version to 4.1.1.

  -- Chris Lamb   Thu, 12 Oct 2017 14:54:27 -0400


In the buster/sid version (4:4.0.2-3) there is no code that I can find 
to run the {pre,post}-{up,down} scripts in sysvinit *or* systemd.


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

Re: [DNG] Debian testing drop redis non systemd

[John Hughes]

On 20/10/17 16:48, goli...@dyne.org wrote:

On 2017-10-20 09:27, John Hughes wrote:


My appologies for posting to a list from which I have been banned . . .



If you were 'banned' you would would not have been able to post. I 
just checked and your account has no restrictions on it.



Yup, I misrembered.  Sorry.

Also, appologies to golinux for replying off-list, cause by my lack of 
attention and Thunderbirds stupid defaults.


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

Re: [DNG] Debian testing drop redis non systemd

[golinux]

On 2017-10-20 09:27, John Hughes wrote:


My appologies for posting to a list from which I have been banned . . .



If you were 'banned' you would would not have been able to post. I just 
checked and your account has no restrictions on it.


Wouldn't it be more to the point to find out *if* you were banned before 
declaring you were?


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

Re: [DNG] systemd-udevd: renamed network interface eth0 to eth1

[Tobias Hunger]

@Nikolaus: UEFI is closed source software (just as BIOS), so of course
the usual problems with closed source also apply here. I trust my
notebook vendor just enough to not fuck this up badly enough so that
random thieves will be able to get around secure boot though:-)

I am pretty sure though that a state actor will not be stopped by
UEFI. And of course UEFI has bugs, just like BIOS.


I am skipping the paranoia ramblings

On Mon, Oct 16, 2017 at 7:51 PM, Steve Litt  wrote:
>> > Grub on BIOS basically works like this: the one MBR is read by BIOS
>> > and executed (512 bytes!). That contains code to chain load some
>> > more code (usually from a fixed set of sectors on disk!). That is
>> > phase 1 of the boot loader. That has enough smarts to find a
>> > hard-coded partition and read phase 2 from there. Phase 2 will then
>> > load a ton of modules and some configuration files and do the
>> > actual work.
>
> The preceding is reasonably accurate.

So is the following:-)

>> >
>> > With UEFI the firmware just loads a efi binary with everything:-)
>> > MUCH simpler.
>
> There's absolutely nothing simpler about the preceding sentence: Hunger
> simply fails to break out a vast tree of subcomponents and dependencies
> of the "efi binary."

UEFI can only access the EFI partition. In that partition I have
exactly two files: The bootloader and the kernel it loads. The
bootloader is actually optional: The kernel is a efi binary and can be
booted directly, but updating kernels requires messing with EFI vars
then.

Where is the vast tree of subcomponents and dependencies are you
referring to hiding?

>> > UEFI has a couple more features:
>> >
>> > * UEFI allows for better hardware support (graphical login at full
>> > resolution, mouse support, RAID drivers, etc.)
>
> OF COURSE we all desparately need graphical login at full resolution.

I like it.

> And I guess we never had RAID and CLI mouse support before UEFI, right?

Not before the OS was up with all its drivers.

With UEFI I can boot straight from the RAIDs in my machines. I used to
need a separate HDD on a non-RAID controller for that.

>> > * UEFI allows for more security with secure boot. E.g. my thinkpad
>> > *only* boots things that I have signed with my key.
>
> Does Devuan have a key?

Why would devuan even *need* a key?

> If not, I guess that's all we need to know
> about what distro Tobias Hunger REALLY uses.

You are right: I do not use devuan, I still follow it with interest,
pretty much like you do. Are you still using void Linux?

> I'm guessing he doesn't
> have the brainpower to actually implement the distro-independent shim,
> which sounds like an utter nightmare.

A bootloader signed by Microsoft is only needed if you need the same
binary to boot on any computer out there in the world -- they all come
with a Microsoft key pre-installed. But you can install your own keys
though -- and remove the one from Microsoft.

My systems only know my own key, the Microsoft key is gone. So my
machines boot everything *I* sign and nothing else. No Windows, no
rescue CD, no secure-boot enabled Linux distribution, nothing. Even
meddling with the kernel command line or the initrd. of my signed
kernel will cause the boot to fail (and yes, I did test that:-).

>> > * UEFI allows for different OSes living next to each other
>> > peacefully, without the constant fight over who writes the MBR and
>> > with that defines the boot loader.
>
> Characterization. "Peacefully?" "Constantly fighting?" The fights only
> occur when changing the boot system.

On BIOS you have only one bootloader (per drive:-), and all but the
last one installed will be broken.

On UEFI you can register several bootloaders that will all function at
the same time.

Installing windows after Linux is finally safe:-)

> And by the way, if you use MBR
> boot, you can use the old and superior Grub1 or LILO.

To each what he likes best.

> Tobias Hunger, why don't you go support the project you DO like

I do. Hanging out here does not keep me busy, no worry:-)

> instead of trolling the one you don't?

I posted information that is to the best of my knowledge correct on a
topic that I have actual experience with. I did not spot anything rude
in my mail and did not see anybody complain about that. Your
definition of trolling is very different from mine:-)

Even Steve only disagrees on the parts he has obviously never used --
and admits that the parts he has experience with are "reasonably
accurate".

Best Regards,
Tobias

PS:  Feel free to contact me if you want to lock down your Devuan
installation in a similar way I locked down my machines. It is all
very generic and in no way tied to systemd -- how could it be
considering that all this happens before even the kernel is loaded!
You obviously need UEFI though.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Antony Stone]

On Friday 20 October 2017 at 16:33:09, Adam Borowski wrote:

> On Fri, Oct 20, 2017 at 04:27:44PM +0200, John Hughes wrote:
> > Jaromil wrote:
> > > I would like to know here if anyone knows in detail the "reasons"
> > > Debian is removing the support for sysvinit scripts in the redis
> > > package.
> > 
> > Wouldn't it be more to the point to find out *if* Debian is removing the
> > support for sysvinit scripts in the redis package before trying to find
> > out why?
> > 
> > Because they aren't.
> 
> [...]
> 
> > The Debian supplied init scripts (debian/redis-server.init and
> > debian/redis-sentinel.init) still exist, they just no longer include the
> > (Debian specific) calls to "Run_parts".
> > 
> > These init scripts do not exist in the upstream redis distribution.  They
> > were added by Debian.
> > 
> > My apologies for posting to a list from which I have been banned, but I
> > thought it might be wise to have a little more light and a little less
> > heat.
> 
> Thanks for the correction -- that's always appreciated.

However, Bardot Jérôme's original posting in this thread, quoting Chris Lamb 
 Wed, 11 Oct 2017 22:55:00 -0400 said:

"This version drops the Debian-specific support for the 
/etc/redis/redis-{server}.sentinel.{pre,post}-{up,down}.d directories in 
favour of using systemd's ExecStartPre, ExecStartPost, ExecStopPre, 
ExecStopPost commands."

So, yes, what's been dropped is Debian-specific, but shouldn't we still be 
concerned about the "in favour of systemd's ... commands"?


Antony.

-- 
This email was created using 100% recycled electrons.

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Debian testing drop redis non systemd

[Adam Borowski]

On Fri, Oct 20, 2017 at 04:27:44PM +0200, John Hughes wrote:
> Jaromil wrote:
> > I would like to know here if anyone knows in detail the "reasons"
> > Debian is removing the support for sysvinit scripts in the redis
> > package.
> 
> Wouldn't it be more to the point to find out *if* Debian is removing the
> support for sysvinit scripts in the redis package before trying to find out
> why?
> 
> Because they aren't.
[...]
> The Debian supplied init scripts (debian/redis-server.init and
> debian/redis-sentinel.init) still exist, they just no longer include the
> (Debian specific) calls to "Run_parts".
> 
> These init scripts do not exist in the upstream redis distribution.  They
> were added by Debian.
> 
> My appologies for posting to a list from which I have been banned, but I
> thought it might be wise to have a little more light and a little less heat.

Thanks for the correction -- that's always appreciated.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. 
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Debian testing drop redis non systemd

[John Hughes]

Jaromil wrote:


I would like to know here if anyone knows in detail the "reasons"
Debian is removing the support for sysvinit scripts in the redis
package.


Wouldn't it be more to the point to find out *if* Debian is removing the 
support for sysvinit scripts in the redis package before trying to find 
out why?


Because they aren't.

What they have done is what the changelog says:


   * Drop*Debian-specific*  support for
 /etc/redis/redis-{server,sentinel}.{pre,post}-{up,down}.d and remove them
 if unchanged.


The Debian supplied init scripts (debian/redis-server.init and 
debian/redis-sentinel.init) still exist, they just no longer include the 
(Debian specific) calls to "Run_parts".


These init scripts do not exist in the upstream redis distribution.  
They were added by Debian.


My appologies for posting to a list from which I have been banned, but I 
thought it might be wise to have a little more light and a little less heat.






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

Re: [DNG] systemd-udevd: renamed network interface eth0 to eth1

[Narcis Garcia]

Perhaps this helps you for a more static configuration:
https://git.actiu.net/libre/mactoname/


El 06/10/17 a les 18:12, J. Fahrner ha escrit:
> Hello,
> I found the message
> "systemd-udevd[415]: renamed network interface eth0 to eth1"
> in my dmesg log.
> 1. why is there a systemd daemon?
> 2. why is my ethernet device renamed?
> 
> I would like it as eth0 and wlan0, not eth1 and wlan1.
> 
> Jochen
> 
> 
> ___
> 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