Re: [DNG] ASCII - clearlooks-Phenix-Purpy style issues

[Ozi Traveller]

Adwaita and Clearlooks seems to be ok in ascii. I'm running openbox, tint2,
thunar, geany, and I think xfce4-terminal.

ozi

On Tue, Aug 22, 2017 at 12:38 PM, Tom Cassidy 
wrote:

> I had filed bug #107 against xfce4-terminal in ascii for this issue but I
> guess I can close that now if it's caused by the theme.
>
> I have also solved my issue by switching to another theme.
>
> --Tomas
>
> > I never expected Clearlooks Phenix Purpy to work in ascii.   Both Xfce
> and (I'm pretty sure) Mate have jumped the GTK3 shark.  Sorry to hear pluma
> has gone down that road.   When I finally get around to playing with ascii,
> I'll start looking for a theme that doesn't break GTK3 apps.  Still waiting
> for an ascii 32 bit iso to test . . . hint, hint.
> ___
> 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] ASCII - clearlooks-Phenix-Purpy style issues

[Tom Cassidy]

I had filed bug #107 against xfce4-terminal in ascii for this issue but I guess 
I can close that now if it's caused by the theme.

I have also solved my issue by switching to another theme.

--Tomas

> I never expected Clearlooks Phenix Purpy to work in ascii.   Both Xfce and 
> (I'm pretty sure) Mate have jumped the GTK3 shark.  Sorry to hear pluma has 
> gone down that road.   When I finally get around to playing with ascii, I'll 
> start looking for a theme that doesn't break GTK3 apps.  Still waiting for an 
> ascii 32 bit iso to test . . . hint, hint.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ASCII - clearlooks-Phenix-Purpy style issues

[golinux]

On 2017-08-21 21:02, Gary Olzeke wrote:

*There was a (closed) bug #50 that may be relevant.*

Hadn't been using ascii for a week or so - did the update & upgrade
it loaded 49 packages -- will append at the end.

with the  Settings/Appearance/Style set to  *clearlooks-phenix-purpy*
(this reverted back to this after the upgrade/reboot)
'
the icons and lettering are all scrunched together, button outlines
are not visible in these three packages -
* Pluma, PulseAudio Vol Cntrl, Galculator*
'
I changed it to Green Submarine & Xfce Flat and all looks normal.
I switch back to 'purpy' and messed up ,
'
it says I am on Xfce 4.12 ( I think it is just the Devuan DE, not the
full 'task-xfce-desktop' package

**upgraded packages this time around
olzeke51@dev-ascii:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  eom eom-common libmate-slab0 libmate-window-settings1 
mate-control-center

  mate-polkit mate-polkit-common pluma pluma-common
The following packages will be upgraded:
  adwaita-icon-theme apt apt-utils bind9-host dnsutils exim4 exim4-base
  exim4-config exim4-daemon-light host libapt-inst2.0 libapt-pkg5.0
  libbind9-140 libc-bin libc-l10n libc6 libdns-export162 libdns162
libgcrypt20
  libgnutls-openssl27 libgnutls30 libisc-export160 libisc160 
libisccc140

  libisccfg140 liblwres141 libopenmpt-modplug1 libopenmpt0 libperl5.24
  libpulse-mainloop-glib0 libpulse0 libpulsedsp libsystemd0 libtiff5
libudev1
  linux-image-4.9.0-3-amd64 linux-image-amd64 locales multiarch-support
  os-prober perl perl-base perl-modules-5.24 pulseaudio 
pulseaudio-utils

udev
  xserver-common xserver-xorg-core xserver-xorg-legacy
49 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.
Need to get 87.7 MB of archives.
After this operation, 153 kB of additional disk space will be used.


---

I never expected Clearlooks Phenix Purpy to work in ascii.   Both Xfce 
and (I'm pretty sure) Mate have jumped the GTK3 shark.  Sorry to hear 
pluma has gone down that road.   When I finally get around to playing 
with ascii, I'll start looking for a theme that doesn't break GTK3 apps. 
 Still waiting for an ascii 32 bit iso to test . . . hint, hint.


golinux



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

[DNG] FWIW fixed :: network down after ASCII upgrades

[Gary Olzeke]

Haven't been on my ascii setup for a week or so.
so I did the 'update & 'upgrade routine
installed these upgrades::  [see below]

'
did a reboot and lost my network connection.
ifconfig isn't available anymore (am I getting old?!)
ip was too confusing to me
'
ended up doing this:
 sudo bash /etc/network/if-up.d/upstart .(ethtool script didn't help??)
'
noted in my 'Linux guide'

*second reboot  - works now!*
some dmesg info and console notetaking::

this is a part of the dmesg log, copied it from the console
right after logon

[1.505647] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22,
2004)
[1.505656] 8139cp :02:05.0: This (id 10ec:8139 rev 10) is not an
8139C+ compatible chip, use 8139too
[1.506495] 8139too: 8139too Fast Ethernet driver 0.9.28
[1.507804] 8139too :02:05.0 eth0: RealTek RTL8139 at
0xb0de40661c00, 00:19:21:c9:14:f6, IRQ 20
***time stamps jumped about 30 seconds with no messages

[   44.473509] 8139too :02:05.0 eth0: link up, 10Mbps, half-duplex, lpa
0x
[   44.512059] floppy0: no floppy controllers found
[   48.850748] EXT4-fs (sdb7): re-mounted. Opts: errors=remount-ro
[  171.515112] RPC: Registered named UNIX socket transport module.
[  171.515116] RPC: Registered udp transport module.
[  171.515117] RPC: Registered tcp transport module.
[  171.515119] RPC: Registered tcp NFSv4.1 backchannel transport module.
*

My screen showed (almost verbatim)
"Configure network. ifup: waiting for lock on /run/network/ifstate.eth0"
[waited for a time period - I think in the 30+ second gap] then reported ::
"if eth0 already configured"
[then it went on to boot up to the console
'
' ***
installed these upgrades::
The following packages have been kept back:
  eom eom-common libmate-slab0 libmate-window-settings1 mate-control-center
  mate-polkit mate-polkit-common pluma pluma-common
The following packages will be upgraded:
  adwaita-icon-theme apt apt-utils bind9-host dnsutils exim4 exim4-base
  exim4-config exim4-daemon-light host libapt-inst2.0 libapt-pkg5.0
  libbind9-140 libc-bin libc-l10n libc6 libdns-export162 libdns162
libgcrypt20
  libgnutls-openssl27 libgnutls30 libisc-export160 libisc160 libisccc140
  libisccfg140 liblwres141 libopenmpt-modplug1 libopenmpt0 libperl5.24
  libpulse-mainloop-glib0 libpulse0 libpulsedsp libsystemd0 libtiff5
libudev1
  linux-image-4.9.0-3-amd64 linux-image-amd64 locales multiarch-support
  os-prober perl perl-base perl-modules-5.24 pulseaudio pulseaudio-utils
udev
  xserver-common xserver-xorg-core xserver-xorg-legacy
49 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] ASCII - clearlooks-Phenix-Purpy style issues

[Gary Olzeke]

*There was a (closed) bug #50 that may be relevant.*

Hadn't been using ascii for a week or so - did the update & upgrade
it loaded 49 packages -- will append at the end.

with the  Settings/Appearance/Style set to  *clearlooks-phenix-purpy*
(this reverted back to this after the upgrade/reboot)
'
the icons and lettering are all scrunched together, button outlines
are not visible in these three packages -
* Pluma, PulseAudio Vol Cntrl, Galculator*
'
I changed it to Green Submarine & Xfce Flat and all looks normal.
I switch back to 'purpy' and messed up ,
'
it says I am on Xfce 4.12 ( I think it is just the Devuan DE, not the
full 'task-xfce-desktop' package

**upgraded packages this time around
olzeke51@dev-ascii:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  eom eom-common libmate-slab0 libmate-window-settings1 mate-control-center
  mate-polkit mate-polkit-common pluma pluma-common
The following packages will be upgraded:
  adwaita-icon-theme apt apt-utils bind9-host dnsutils exim4 exim4-base
  exim4-config exim4-daemon-light host libapt-inst2.0 libapt-pkg5.0
  libbind9-140 libc-bin libc-l10n libc6 libdns-export162 libdns162
libgcrypt20
  libgnutls-openssl27 libgnutls30 libisc-export160 libisc160 libisccc140
  libisccfg140 liblwres141 libopenmpt-modplug1 libopenmpt0 libperl5.24
  libpulse-mainloop-glib0 libpulse0 libpulsedsp libsystemd0 libtiff5
libudev1
  linux-image-4.9.0-3-amd64 linux-image-amd64 locales multiarch-support
  os-prober perl perl-base perl-modules-5.24 pulseaudio pulseaudio-utils
udev
  xserver-common xserver-xorg-core xserver-xorg-legacy
49 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.
Need to get 87.7 MB of archives.
After this operation, 153 kB of additional disk space will be used.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]

[Adam Borowski]

On Mon, Aug 21, 2017 at 05:01:13PM -0700, Rick Moen wrote:
> Quoting Adam Borowski (kilob...@angband.pl):
> 
> > Manually creating the configuration -- or even manually triggering its
> > creation -- is a pretty bad idea.  It just guarantees you won't have
> > working X when you make any change to your hardware -- and sometimes
> > software as well.
> 
> Gosh, what you call a bad idea was utterly routine and what everyone was
> used to for decades.  You simply knew that, if you changed your video chipset
> or changed to a radically different pointing device, or if you wanted to
> do something very different like Xinerama, you'd need to generate a new
> one.

There are cases when the old way had its merit -- but here, we have an
equivalent of a car that needs to be started with a hand-crank.

> Also, having an /etc/X11/Xorg.conf file means _you_, rather than Xorg
> autoprobing, were in charge of what X would do and what it would be
> willing to try.  Like, maybe you have a monitor for which the built-in
> EDID information is slightly wrong and you know what it should be, so
> you tweak Xorg.conf to use the correct information.

Then write just your desired resolution (or what else is wrong in your
EDID).  Or, better, set it at runtime.

> Moreover, 'won't have working X' is a melodramatic exaggeration of the 
> situation where, if you changed to a new video chipset, or a new
> monitor, or a very different mouse

Now this is getting ridiculous.  I borrow one of the monitors for a quick
task elsewhere quite often.  Why would I need to shut down X, configure
things manually, then start it again, if it can -- and does -- handle
monitor hotplug correctly?  Worst case, I'd need to use xrandr (or a
clicky-clicky equivalent) to turn off that blasted mirrored mode some smelly
laptop-lover invented (although this particular bug seems to be gone).

Same with input devices.  If I change the keyboard or the mouse, why would I
need to drop all my state, rewrite the config, then restart X?  Input
devices are handled by the kernel in an unified way for a decade.

(BTW, you'd want to purge gpm and replace it with consolation -- it's a
clean rewrite without the 90's baggage, with less than 10% code size.)

> you could always re-run 'Xorg
> -configure', test the output, put it in place, and have a tested new
> configuration in about 60 seconds.  Or, if you no longer wanted that,
> just mv /etc/X11/Xorg.conf /etc/X11/Xorg.conf.save , and you're right
> back to the automagical thing.

I prefer 0 seconds to 60 seconds.  And it's never 60 seconds in practice --
in the bad old days it was a matter of hours digging through the
documentation.  Assuming the user knew where to find the documentation in
the first place.

> I personally think a udev dependency is far too big a price to pay for
> Xorg autoconfiguration when generating what you want is so simple.
> However, as usual, I'm deciding that only for myself.

It's neither simple nor necessary.  If mdev fails to provide X with required
information, that's a defect of mdev.  But really, it's not the duty of
userland to do such things these days -- unless you happen to have a decade
old graphics card no one bothered to write a KMS and DRM driver for, there's
no configuration to be done.

Per the other thread, the only thing you need udev/mdev for anymore is
setting permissions and calling hooks.  Don't tell me that udev is a "big
price" on any machine bigger than a microcontroller these days.

> > Save for good-for-nothing Nvidia proprietary drivers, I haven't seen a case
> > where mucking with this file was needed to get working X for over a decade.
> 
> You might have missed the context.  We were talking about how to ensure
> that Xorg works with mdev, rather than udev.

But why?  mdev is not meant to be used beyond an initramfs, it can't do
hotplug, and on modern Linux coldplug is almost entirely done via hotplug --
with shit happening if your software can't take a device which took a while
to start.

Could you please tell me what's your use case for micromanaging a machine
that has an X-capable display attached?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀-- Genghis Ht'rok'din
⠈⠳⣄ 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Alessandro Selli]

On Sun, 20 Aug 2017 at 22:24:58 -0400
Steve Litt  wrote:

> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot.

  What about the numerous cases when you cannot chose what ethernet cards are
going to be fitted inside a computer?  Maybe a specific model was chosen to
comply with warranty terms, or because a specific piece of hardware is
certified in a given scenario, or because what you have is a PCIe card with
multiple NICs built-in, or because the interfaces are embedded in the
motherboard, or because it's not you how buys the hardware...?


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

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Alessandro Selli]

On Mon, 21 Aug 2017 at 12:56:24 +0200
Didier Kryn  wrote:

>  In any case the admin must either hack /etc/network/interfaces or 
> the udev rules. But I think this little inconveniency is better than the 
> meaningless device names promoted by Systemd people.

  And the other network cards can stay assured they are not going to be
renamed because of this.


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

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Alessandro Selli]

On Mon, 21 Aug 2017 at 10:32:43 +0200
Narcis Garcia  wrote:

[...]

> This logic does not guarantee 100% predictable naming (think about
> removable NICs), but gives enough confort to a sysadmin deals any with
> situation.

  If it's not 100% predictable and configurable by the sysadmin then it does
*not* provide "enough confort", as in an Enterprise environment this means
100% certainty that the system comes up with each networking card having
a definite, assigned name and that everything that depends on networking is
always going to work fine short of a hardware failure.
  Randomness is very unwelcome in critical systems and in data centers, where
even a tiny percentage of random malfunction has to be multiplied by the
numer of racks and devices that are present to be deemed acceptable.


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

Re: [DNG] auto.mirror.devuan.org or us.mirror.devuan.org

[Gregory Nowak]

On Mon, Aug 21, 2017 at 09:17:58AM +0200, Evilham wrote:
> IIRC, when the package mirror network is setup (plans are for it to
> start soon), auto.mirror would send you to the closest mirror, so if you
> move around, that'd be best for you; if you'd rather use a specific
> country mirror, you should use that instead.

How would the closest mirror be determined when using auto.mirror? By IP
address I'm coming from, by running ping/traceroute in the background
to a devuan.org server, or some other means?

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Alessandro Selli]

On Mon, 21 Aug 2017 at 09:22:22 +0100
Simon Hobson  wrote:

[...]

> I suppose that one REALLY good way to fix the problem (at least in the
> server & desktop areas) is actually to undo a lot of "progress" and make
> all driver and service initiation strictly linear. Ie, do away with all
> this parallelism and make all drivers be loaded strictly in sequence, one
> after the other, in a defined order. I strongly suspect that it wouldn't
> hugely impact boot times either. Put another way, part of the "problem"
> being "solved" is actually a side effect of "improvements" made elsewhere.

  I see some potential problems with serialization as a panacea for
interface naming.

1) How is a driver supposed to know what "queue number" it has at boot time?
   "The kernel assigns it, maybe dinamically", all right,  how could the
   sysadmin then set his own ethernet-card-driver load order? (Suppose a
   network booted system must configure it's eth0 via DHCP and then load the
   NFS root filesystem out of eth1?)
2) You've got to set timeouts on ethernet drivers loading and initialization
   to avoid network card B sitting indefinitely because network card A got
   stuck; this could increase boot time considerably, expecially if
   networking is required to boot the OS.  And what eth number is B going to
   get if A got stuck?  The same as if A did not get stuck?  Or maybe it's
   going to get A's?
3) If a network card driver fails to load, how are the other ethernet
   interfaces names affected?  Are the following ones named just like it
   loaded fine or does the naming procedure skip the failed interface?
4) What about a hardware card swap, substitution or removal, how can one know
   what effect this will have on the module load sequence and interface
   naming?
5) Network initialization and configuration can in some cases take a long
   time (DHCP, RPC/NFS, Kerberos/NIS/LDAP/SMB and iSCSI are not
   lightning-fast and might be required by other start-up steps, WiFi makes
   things a lot worse of course), so serialization of multiple networking
   interfaces can have a huge impact on start-up time indeed, depending on
   the specific setup.

  In short, networking device naming does not have to depend on load time and
sequence, and it should not.  It must be predictable and configurable, but it
ought to be independend from driver load time and order.  The card's MAC
address should be all that matters and dynamical interface naming should
apply only to unknown hardware that just popped up now or on this boot (and
of course it should assign only names that are not already reserved to
configured network cards, that they are present or not).


Alessandro

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

Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]

[Rick Moen]

Quoting Adam Borowski (kilob...@angband.pl):

> Manually creating the configuration -- or even manually triggering its
> creation -- is a pretty bad idea.  It just guarantees you won't have
> working X when you make any change to your hardware -- and sometimes
> software as well.

Gosh, what you call a bad idea was utterly routine and what everyone was
used to for decades.  You simply knew that, if you changed your video chipset
or changed to a radically different pointing device, or if you wanted to
do something very different like Xinerama, you'd need to generate a new
one.

Also, having an /etc/X11/Xorg.conf file means _you_, rather than Xorg
autoprobing, were in charge of what X would do and what it would be
willing to try.  Like, maybe you have a monitor for which the built-in
EDID information is slightly wrong and you know what it should be, so
you tweak Xorg.conf to use the correct information.

Moreover, 'won't have working X' is a melodramatic exaggeration of the 
situation where, if you changed to a new video chipset, or a new
monitor, or a very different mouse, you could always re-run 'Xorg
-configure', test the output, put it in place, and have a tested new
configuration in about 60 seconds.  Or, if you no longer wanted that,
just mv /etc/X11/Xorg.conf /etc/X11/Xorg.conf.save , and you're right
back to the automagical thing.

I personally think a udev dependency is far too big a price to pay for
Xorg autoconfiguration when generating what you want is so simple.
However, as usual, I'm deciding that only for myself.

> Save for good-for-nothing Nvidia proprietary drivers, I haven't seen a case
> where mucking with this file was needed to get working X for over a decade.

You might have missed the context.  We were talking about how to ensure
that Xorg works with mdev, rather than udev.

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

[DNG] new behaviour of /dev

[Adam Borowski]

Hi!
Do you remember when for decades we had to populate /dev using mknod
(using makedev or something) -- both on Linux and on Unices that predated
it?  Then when udev came to make device creation dynamic.

I just installed a new server, not using d-i but manual debootstrap.  Not
even regular debootstrap but with --variant=minbase as --exclude is still
buggy and fails to exclude THE THING THAT SHOULDN'T BE NAMED.  Everything
worked fine, except for one detail: somehow /dev/ttyUSB* were mode 600
root:root instead of 660 root:dialout.

Turns out, udev was not installed.  Nor mdev, nothing.  No initrd either. 
Yet it boots and works correctly.  fstab has no entries except for / -- and
even this is pointless if you mount rootfs rw on cmdline (the ro + remount
dance does nothing good on any modern fs other than ext4).  If there was any
userland configuration, it is done by openrc by default.

Hotplugging USB devices seems to work fine, new nodes get created without
udev's involvement.

Obviously, I guess running without udev is a bad idea in the long run -- you
want correct permissions to get applied, hotplug hooks to be run, etc.  But
this suggests 90% of udev/mdev/vdev code can be thrown out.

That the kernel can now do most of this work by itself is news to me.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀-- Genghis Ht'rok'din
⠈⠳⣄ 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]

[Adam Borowski]

On Mon, Aug 21, 2017 at 02:30:00PM -0700, Rick Moen wrote:
> My guess is that the udev developers thought 'It'd be excellent to 
> automatically supply to the starting Xorg binary the output of "Xorg
> -configure" when /etc/X11/Xorg.conf doesn't exist, thereby making Xorg
> automagically able to reconfigure itself every time it starts without
> ever bothering to create Xorg.conf' -- and somehow made the library
> call to libudev perform that shim operation.  All I really know is that
> I was suddenly being told that creating Xorg.conf was no longer
> necessary if you were adequately happy with the autoconfiguration
> occuring in its absence.

Manually creating the configuration -- or even manually triggering its
creation -- is a pretty bad idea.  It just guarantees you won't have working
X when you make any change to your hardware -- and sometimes software as
well.

If you have a need to adjust the configuration, you put into Xorg.conf just
the settings you want to alter.  This will let X do the right thing.

Save for good-for-nothing Nvidia proprietary drivers, I haven't seen a case
where mucking with this file was needed to get working X for over a decade.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀-- Genghis Ht'rok'din
⠈⠳⣄ 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]

[Rick Moen]

Quoting Didier Kryn (k...@in2p3.fr):

> Sorry, Rick, but I don't understand how it is possible that, on
> one hand, it needs libudev to configure itself, and, on the other
> hand, it is able to generate its config file without it. Can you
> explain this paradox?

Not really, no.

My guess is that the udev developers thought 'It'd be excellent to 
automatically supply to the starting Xorg binary the output of "Xorg
-configure" when /etc/X11/Xorg.conf doesn't exist, thereby making Xorg
automagically able to reconfigure itself every time it starts without
ever bothering to create Xorg.conf' -- and somehow made the library
call to libudev perform that shim operation.  All I really know is that
I was suddenly being told that creating Xorg.conf was no longer
necessary if you were adequately happy with the autoconfiguration
occuring in its absence.

The fine point you might have missed is, in the absence of the libudev
support, Xorg doesn't _automatically_ create an Xorg.conf nor default in
its absence to using what would have been created by 'Xorg -configure >
/etc/X11/Xorg.conf' if you had do that.

In fact, the old-school method was/is so cautious that its default
output (./Xorg.conf.new) is specifically crafted so you would _not_ 
accidetnally overwrite a production Xorg.conf .

Anyway, I can testify that 'Xorg -configure' does indeed output a
conffile that's usually really good.  I did that for long years, and the
same with XFree86 before that.

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

Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]

[Didier Kryn]

Le 21/08/2017 à 16:48, Rick Moen a écrit :

Quoting Didier Kryn (k...@in2p3.fr):

[mdev:]


Sure it would be helpful :-) AFAIK X11 is able to configure
itself automatically without a config file when libudev provides it
with an interface to query device properties, and without this
library it is necessary to provide a config file.

At the risk of committing heresy, there's nothing all _that_ bad about,
on new Linux systems or ones where you suddenly switched in a whole new
video hardware system, having to generate an /etc/X11/Xorg.conf file
using 'Xorg -configure' (which by default outputs ./xorg.conf.new).

Sorry, Rick, but I don't understand how it is possible that, on one 
hand, it needs libudev to configure itself, and, on the other hand, it 
is able to generate its config file without it. Can you explain this 
paradox?


Didier

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

Re: [DNG] openbox-themes in ASCII?

[fsmithred]

On 08/21/2017 08:59 AM, Michael Siegel wrote:
> Am 18.08.2017 um 16:04 schrieb fsmithred:
> 
>> Some themes work, some don't, and they seem to work better if I use
>> lxappearance-obconf instead of just obconf.
> 
> What exactly do you mean by "some themes don't work"? I use obconf for
> setting the wm theme and gtk-theme-switch2 for setting the GTK theme. I
> just installed the openbox-themes package again and went through all the
> themes as well as the corresponding GTK themes where available. I
> couldn't make out any problem.
> 

The colors that I got did not match the colors in the samples. Lots of
gray, especially the hightlight. Some of those corrected when I used
lxappearance-obconf.


>> Separating the themes into several packages shouldn't be hard,
>> either.
> 
> Good. I think that would make a lot of sense, from a user perspective as
> well as for maintenance purposes. So, if I gave you the theme files,
> could you package them? That would be great. As soon as I'm able to do
> the packaging myself, I could take over all the maintenance.
> 

If you edit the existing theme files, I should be able to replace them and
rebuild. Let's start with one or two and make sure it works.


>> Getting them to work with gtk3 might require a large non-gmo care
>> package in the form of a bribe to a certain theme guru.
> 
> Well, I don't know if it's a reasonable aim to make anything work with
> GTK3. From what I've read, theming for GTK3 seems like a tedious waste
> of time. I mean, if someone volunteers to do it, great. But I don't
> really mind if that doesn't happen.
> 

Good point. I was not thinking.

fsr


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

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Hendrik Boom]

On Sun, Aug 20, 2017 at 09:30:00PM -0700, Rick Moen wrote:
> Let me try to draw a distinction with some nuance, here:  To the best of
> my knowledge -- and my knowledge might be incomplete or unaware of some
> new developments -- 'spontaneous' network device renaming, just like
> spontaneous mass storage device renaming, happens _only_ following
> admin-initiated hardware reshuffles.

The only time I had a problem with this it was upon an Debian upgrade 
from one release to another.  The easy way to fix the problem was to 
swap the cables at the back of the box.

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

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[info at smallinnovations dot nl]

On 21-08-17 06:30, Rick Moen wrote:

Quoting Steve Litt (sl...@troubleshooters.com):


As a wee lad, my mentors told me never to put two of the same model
NICs in a computer, because which one became eth0 and which became eth1
would be indeterminate from boot to boot.

It's funny you'll say that, and not just because we're both old enough
that advice we got as 'wee lads' would probably have to involve
sliderules.  I'll get back to that, later.


That's horrible, and that *is* solved by the systemd naming scheme.

I find myself in the position of being a little unconvinced about the
extent and seriousness of the problem, even though I don't have
exhaustive data, only a few decades of *ix experience to draw on.
Let me try to draw a distinction with some nuance, here:  To the best of
my knowledge -- and my knowledge might be incomplete or unaware of some
new developments -- 'spontaneous' network device renaming, just like
spontaneous mass storage device renaming, happens _only_ following
admin-initiated hardware reshuffles.

---snip

I do remember this switching of network cards happened spurious on 
SME-Server 8 (a RHEL based SMB distribution for e-mail, fileserver and 
firewall with a webinterface). With other distro's like Suse, Debian, 
Ubuntu and Mandrake i never have seen this happen.


Grtz.

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

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Ron]

On Mon, 21 Aug 2017 07:26:04 -0700
Rick Moen  wrote:

> > On Sun, 20 Aug 2017 21:30:00 -0700 Rick Moen 
> > wrote:
> > 
> > > However_, even given that, in my experience any reshuffle USB would
> > > add to the _existing_ devices' node assignments would occur only at
> > > reboot time _if_ you left the USB device plugged in. 
> > 
> > Personal experience: I run an IPCop box as a firewall for my LAN,
> > using three USBtoRJ45 interfaces in an attempt to reduce the
> > motherboard damage from thunderstorms (I live in Darkest Paraguay).
> > 
> > The local electricity system is not all that reliable, and even with a
> > UPS the box gets rebooted several times a week.
> > 
> > In around ten years of use I have never had the problem of USB/NIC
> > assignment changing at reboot, except when I had to replace a
> > burnt-out USBtoRJ45  ;-3(
> 
> Interesting and thank you.  At first, I thought you were going to post
> Yet Another USB Flakiness Story, but it turns out that your NICs have
> _not_ self-reassigned.  Good to know.
> 
> FWIW, when I wrote the above, I actually had in mind mass storage, e.g., 
> a system has /dev/sda on one HBA and /dev/sdb on another, mounts a USB
> mass storage device as /dev/sdc, and then reboots with the USB mass
> storage device plugged in and now finds that the USB device is /dev/sdb
> in-between the two persistent devices with the result that /etc/fstab is
> wrong.  (Probably, the admin curses a blue streak and switches to UUID
> referencing or disk labels.)
> 
> One thing that people definitely _do_ bitch about is USB casual storage
> being (say) /dev/sdc upon one insertion and then later /dev/sdd at the
> next insertin (without a reboot between).  From my perspective, I never
> saw this as a problem.  You just observe the inserted device's node by
> looking at dmesg | tail, su to root, mount device, done.  But the
> new-user people don't like that, and want the process to be automagic.
> Greg Kroah-Hartman justified the whole udev thing to me, claiming it
> needed to be on all Linux systems, on grounds that he wanted his
> daughter to be able to use USB devices without needing to be root.  I
> replied that happily he could do anything for his daughter he wished on
> his _own_ systems, but that his daughter wouldn't be plugging USB
> devices into my servers, so I wasn't especially interested in helping
> her there.

I forgot to precise that the three USBtoRJ45 are the same model, TrendNet 
TU2-ET100.
 
Cheers,
 
Ron.
-- 
Like some infernal monster, still venomous in death, 
 a war can go on killing people for a long time after it’s all over.
 -- Nevil 
Shute Norway

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]

[Rick Moen]

Quoting Didier Kryn (k...@in2p3.fr):

[mdev:]

> Sure it would be helpful :-) AFAIK X11 is able to configure
> itself automatically without a config file when libudev provides it
> with an interface to query device properties, and without this
> library it is necessary to provide a config file.

At the risk of committing heresy, there's nothing all _that_ bad about,
on new Linux systems or ones where you suddenly switched in a whole new
video hardware system, having to generate an /etc/X11/Xorg.conf file
using 'Xorg -configure' (which by default outputs ./xorg.conf.new).

(/me raps the virtual podium with his figurative cane.  ;->  )

-- 
Cheers,   « Certainement qui est en droit de vous rendre absurde est
Rick Moen endroit de vous rendre injuste. »  ("Certainly, any one 
r...@linuxmafia.com   who has the power to make you believe absurdities has the 
McQ! (4x80)   power to make you commit injustices.")   -- Voltaire 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Rick Moen]

Quoting Renaud OLGIATI (ren...@olgiati-in-paraguay.org):

> On Sun, 20 Aug 2017 21:30:00 -0700 Rick Moen 
> wrote:
> 
> > However_, even given that, in my experience any reshuffle USB would
> > add to the _existing_ devices' node assignments would occur only at
> > reboot time _if_ you left the USB device plugged in. 
> 
> Personal experience: I run an IPCop box as a firewall for my LAN,
> using three USBtoRJ45 interfaces in an attempt to reduce the
> motherboard damage from thunderstorms (I live in Darkest Paraguay).
> 
> The local electricity system is not all that reliable, and even with a
> UPS the box gets rebooted several times a week.
> 
> In around ten years of use I have never had the problem of USB/NIC
> assignment changing at reboot, except when I had to replace a
> burnt-out USBtoRJ45  ;-3(

Interesting and thank you.  At first, I thought you were going to post
Yet Another USB Flakiness Story, but it turns out that your NICs have
_not_ self-reassigned.  Good to know.

FWIW, when I wrote the above, I actually had in mind mass storage, e.g., 
a system has /dev/sda on one HBA and /dev/sdb on another, mounts a USB
mass storage device as /dev/sdc, and then reboots with the USB mass
storage device plugged in and now finds that the USB device is /dev/sdb
in-between the two persistent devices with the result that /etc/fstab is
wrong.  (Probably, the admin curses a blue streak and switches to UUID
referencing or disk labels.)

One thing that people definitely _do_ bitch about is USB casual storage
being (say) /dev/sdc upon one insertion and then later /dev/sdd at the
next insertin (without a reboot between).  From my perspective, I never
saw this as a problem.  You just observe the inserted device's node by
looking at dmesg | tail, su to root, mount device, done.  But the
new-user people don't like that, and want the process to be automagic.
Greg Kroah-Hartman justified the whole udev thing to me, claiming it
needed to be on all Linux systems, on grounds that he wanted his
daughter to be able to use USB devices without needing to be root.  I
replied that happily he could do anything for his daughter he wished on
his _own_ systems, but that his daughter wouldn't be plugging USB
devices into my servers, so I wasn't especially interested in helping
her there.

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

Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]

[Narcis Garcia]

El 21/08/17 a les 15:52, Didier Kryn ha escrit:
> Note that a similar problem with disks has been solved elegantly by
> referencing disks by their uuid or label in /etc/fstab. Maybe
> /etc/network/interface could specify the MAC address as a hook. This
> would only suppose that the hotplugger creates a symlink to the
> interface in some /dev/net/by-address/ subdirectory. With this solution,
> it is up to the admin to decide if  s?he wants a simple configuration
> based on interface name (eth0) or a secured one alla
> "Address=a0:d3:c1:9d:a5:86".
> 

+1

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

Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]

[Didier Kryn]

Le 21/08/2017 à 16:04, k...@aspodata.se a écrit :

Didier Kryn:

Le 21/08/2017 à 14:41, Arnt Karlsen a écrit :

..we need to sell either vdev or eudev or some such non-systemd
udev upstream to Linus and the kernel guys and get them happy
about kicking out systemd-udev from the kernel code base.

[OT]I would prefer Mdev if the issue with X11 could be solved :-)
Mdev is so simpler than Udev, Eudev and Vdev.

...

What is the issue with X11, you know that you can run X without udev ?
Perhaps it would be helpful if I provided udev-less versions of it.

Sure it would be helpful :-) AFAIK X11 is able to configure itself 
automatically without a config file when libudev provides it with an 
interface to query device properties, and without this library it is 
necessary to provide a config file.


There are instructions at 
https://github.com/slashbeast/mdev-like-a-boss but I didn't experiment 
them yet.


Didier

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

Re: [DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]

[karl]

Didier Kryn:
> Le 21/08/2017 à 14:41, Arnt Karlsen a écrit :
> > ..we need to sell either vdev or eudev or some such non-systemd
> > udev upstream to Linus and the kernel guys and get them happy
> > about kicking out systemd-udev from the kernel code base.
> 
> [OT]I would prefer Mdev if the issue with X11 could be solved :-) 
> Mdev is so simpler than Udev, Eudev and Vdev.
...

What is the issue with X11, you know that you can run X without udev ?
Perhaps it would be helpful if I provided udev-less versions of it.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


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

[DNG] An alternative to renaming [was Re: Proposed change in behaviour for ascii: eudev net.ifnames]

[Didier Kryn]

Le 21/08/2017 à 14:41, Arnt Karlsen a écrit :

..we need to sell either vdev or eudev or some such non-systemd
udev upstream to Linus and the kernel guys and get them happy
about kicking out systemd-udev from the kernel code base.


[OT]I would prefer Mdev if the issue with X11 could be solved :-) 
Mdev is so simpler than Udev, Eudev and Vdev.


Let's forget Systemd and their "solutions". Interface renaming was 
introduced by the original Udev. According to Adam, it races with 
kernel's device discovery and the only solution is apparently to use a 
namespace different of the one of the kernel.


Note that a similar problem with disks has been solved elegantly by 
referencing disks by their uuid or label in /etc/fstab. Maybe 
/etc/network/interface could specify the MAC address as a hook. This 
would only suppose that the hotplugger creates a symlink to the 
interface in some /dev/net/by-address/ subdirectory. With this solution, 
it is up to the admin to decide if  s?he wants a simple configuration 
based on interface name (eth0) or a secured one alla 
"Address=a0:d3:c1:9d:a5:86".


Didier


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

Re: [DNG] openbox-themes in ASCII?

[Michael Siegel]

Am 18.08.2017 um 16:04 schrieb fsmithred:

> I downloaded the wheezy source and built a package on ascii pretty 
> easily last night. Didn't change anything.

Nice. But the package meta data would have to be revised for an official
Devuan package, I guess.

> Some themes work, some don't, and they seem to work better if I use
> lxappearance-obconf instead of just obconf.

What exactly do you mean by "some themes don't work"? I use obconf for
setting the wm theme and gtk-theme-switch2 for setting the GTK theme. I
just installed the openbox-themes package again and went through all the
themes as well as the corresponding GTK themes where available. I
couldn't make out any problem.

> Separating the themes into several packages shouldn't be hard,
> either.

Good. I think that would make a lot of sense, from a user perspective as
well as for maintenance purposes. So, if I gave you the theme files,
could you package them? That would be great. As soon as I'm able to do
the packaging myself, I could take over all the maintenance.

> Getting them to work with gtk3 might require a large non-gmo care
> package in the form of a bribe to a certain theme guru.

Well, I don't know if it's a reasonable aim to make anything work with
GTK3. From what I've read, theming for GTK3 seems like a tedious waste
of time. I mean, if someone volunteers to do it, great. But I don't
really mind if that doesn't happen.


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

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Didier Kryn]

Le 21/08/2017 à 12:56, Didier Kryn a écrit :

Le 20/08/2017 à 18:57, Renaud (Ron) OLGIATI a écrit :

On Sun, 20 Aug 2017 16:38:18 +0100
Rowland Penny  wrote:


As far as I am aware, each network device should have a different MAC,
couldn't this be used to identify which device is which ?
Could, but whenever you have to change a NIC after a thunderstorm you 
are buggered...

  Cheers,
  Ron.
That's exactly the most frequent case. There's also the following 
case: you break your computer but not the disk. Instead of making a 
new install on another computer, you just exchange the disks. Your 
network was configured for eth0 but there's no more eth0, udev has 
renamed it eth1, because eth0 is the NIC of the broken computer.


In any case the admin must either hack /etc/network/interfaces or 
the udev rules. But I think this little inconveniency is better than 
the meaningless device names promoted by Systemd people.


Remains the problem of the namespace. Why not use nic0, nic1, etc 
as a namespace for ethernet?


Didier


Sorry, thunderbird messed with citation. The paragraph after the 
signature of Ron is from me.


Didier

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

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Didier Kryn]

Le 20/08/2017 à 18:57, Renaud (Ron) OLGIATI a écrit :

On Sun, 20 Aug 2017 16:38:18 +0100
Rowland Penny  wrote:


As far as I am aware, each network device should have a different MAC,
couldn't this be used to identify which device is which ?

Could, but whenever you have to change a NIC after a thunderstorm you are 
buggered...
  
Cheers,
  
Ron.
That's exactly the most frequent case. There's also the following 
case: you break your computer but not the disk. Instead of making a 
new install on another computer, you just exchange the disks. Your 
network was configured for eth0 but there's no more eth0, udev has 
renamed it eth1, because eth0 is the NIC of the broken computer.


In any case the admin must either hack /etc/network/interfaces or 
the udev rules. But I think this little inconveniency is better than the 
meaningless device names promoted by Systemd people.


Remains the problem of the namespace. Why not use nic0, nic1, etc 
as a namespace for ethernet?


Didier


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

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Ron]

On Sun, 20 Aug 2017 21:30:00 -0700
Rick Moen  wrote:

> However_, even given that, in my experience any reshuffle
> USB would add to the _existing_ devices' node assignments would occur
> only at reboot time _if_ you left the USB device plugged in. 

Personal experience: I run an IPCop box as a firewall for my LAN, using three 
USBtoRJ45 interfaces in an attempt to reduce the motherboard damage from 
thunderstorms (I live in Darkest Paraguay).

The local electricity system is not all that reliable, and even with a UPS the 
box gets rebooted several times a week.

In around ten years of use I have never had the problem of USB/NIC assignment 
changing at reboot, except when I had to replace a burnt-out USBtoRJ45  ;-3(
 
Cheers,
 
Ron.
-- 
 To succeed, planning alone is insufficient.
 One must improvise as well.
-- Salvor Hardin

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Rick Moen]

Quoting marc (marc...@welz.org.za):

> Like Rick I haven't encountered a spontaneous device name 
> re-order in the wild.

Just to be skeptical for a moment of my own wording, I probably 
_slightly_ overstated (at least by implication) what I've observed over
the decades, here:

   I understood that, if you had a motherboard with dual e1000 NICs and
   suddenly added (or removed) a third ethernet port on a PCI-E card,
   whether it was also an e1000 NIC or not, you might expect to get a
   ^^^
  device assignment reshuffle.

On reflection, I'm not sure I've ever seen, say, a server with a pair of
e1000 NICs on the motherboard supplemented by an ethernet card with a
Tigon tg3 chipset.  In my own systems, and the ones I've used at work, 
we've always stuck with a single NIC chipset by preference, just on
instinct.  If you needed a third NIC on a dual-e1000 host, you plugged
in an e1000 card.  

But honestly, I think this whole situation almost never arises in my own
experience.  In business, if you have a situation where dual-NIC
motherboards don't suffice, you typically need a dedicated router, not a
regular Linux host.

I stand by my observation that a machine with multiple copies of the
same NIC, especially (as we find for the last decade or so) they're
integrated into the motherboard, you do _not_ see spontaneous
device-assignment reshuffles.  If it happens, I've never seen it,
anyway.

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

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Simon Hobson]

Edward Bartolo  wrote:

> Therefore, if I were in a position to take decisions I would
> not expect a computer to know what I need. However, a computer should
> have no difficulty processing data. A decent OS should save a map of
> how hardware is connected, somewhat like a hardware tree with all
> points fully defined. That way, if on a future boot, nodeX is not
> found or is replaced with some other hardware, nodeZ, that we assume
> existed before, will continue to be assigned with the same device
> name.

Dunno, there's lots of "what if ?" opportunities there.

What if ... a NIC is seen to appear in a different position in the bus/device 
tree ?
Should it be assumed to be the same device (eg USB NIC plugged into different 
port) and given the same name ? Should it be given a different name as a 
different device ?

What if that device moves (and you think the answer above should be, "it's 
obviously the same device - give it the same name") and a different (new) 
device appears in the old location ? Has the user just upgraded their primary 
NIC (eg got a gigabit dongle instead of a 100M dongle) and wants to use the old 
slower one as a secondary NIC - or have they moved an existing device 
(expecting it to keep the same settings) in order to install* an additional 
device for something new ?

Absent the mind reading module which we haven't invented yet - there is no way 
of knowing and so whichever way we decide to code it will be wrong for some 
instances.

However, for a lot of cases - the existing udev persistent rules method "does 
just what people want".

* Sometimes, I've had to move a USB device in order to be able to install 
another device - some devices are oversize and block adjacent ports so physical 
location matters.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Narcis Garcia]

El 20/08/17 a les 21:53, fsmithred ha escrit:
> On 08/20/2017 10:27 AM, Adam Borowski wrote:
>>
>> * systemd-udev's promise of providing _stable_ names didn't deliver.  They
>>   still change on major kernel upgrades, and sometimes on every boot. 
>>   And their chosen naming is utterly insane (wlxf81a671bcfae, WTF?).
>>   Only systemd proponents still say it's a good idea.
>>
> 
> They change? I thought they were based on which hardware slot they were
> in. I've been ranting about how you have to open the box and look inside
> to predict the names. Have I been wrong all this time?
> 
> Yeah, the name on a usb dongle is insane. I didn't stick with it long
> enough to figure out if that number comes from somewhere or is random.
> 
> fsmithred
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 

I suggest:
ethX/wlanX naming BUT:
Based on last MAC byte;
- When MAC ends with :00 -> eth0
- When MAC ends with :01 -> eth1
- When MAC ends with :0A -> eth10
- When MAC ends with :10 -> eth16
* When 2 NICs have same MAC byte (01) -> eth1 & eth1a & ... eth1b
* Anyway, maintain full support of
/etc/udev/rules.d/70-persistent-net.rules

This logic does not guarantee 100% predictable naming (think about
removable NICs), but gives enough confort to a sysadmin deals any with
situation.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Simon Hobson]

Steve Litt  wrote:

> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot. That's horrible, and that *is*
> solved by the systemd naming scheme.

Except when it isn't !
In fact, two card of the same type (or rather, using the same driver), is not a 
problem - they use the same driver, and enumeration of devices follows (or is 
supposed) to follow a set order.
When they use different drivers, then there is parallelism in initialisation 
which means it's not determinate which driver gets loaded first and hence which 
device is eth0 and which is eth1.



Adam Borowski  wrote:

>> Why not use a similar mechanism for interface names?  remember which 
>> names were recently used and use them again?
>> 
>> This sounds a lot like the fstab-like proposal, except it 
>> autoconfigures.
> 
> You mean, /etc/udev/rules.d/70-persistent-net.rules which has been removed
> in favour of completely-un-"predictable" names, right?
> 
> It has a very user unfriendly syntax, but it did just what you suggest.

Exactly, THAT problem was solved (in the server and probably desktop spaces) 
many many years ago. SOLVED, nothing to see here, move along please.
It has it's issues, but these are mostly down to hardware being changed and 
installations being cloned - ie situation that involve administrator 
involvement and so an opportunity to fix it at the same time.

I accept that there ARE issues in some cases - especially things like laptops 
with plug in (USB) NICs - but fixing that doesn't need to break everyone else. 
Put another way, yes I can see that there is a problem to be solved, but no, I 
don't think that imposing massive problems on the majority of users is the 
right way to do it.



Rick Moen  wrote:

> I find myself in the position of being a little unconvinced about the
> extent and seriousness of the problem, even though I don't have
> exhaustive data, only a few decades of *ix experience to draw on.
> Let me try to draw a distinction with some nuance, here:  To the best of
> my knowledge -- and my knowledge might be incomplete or unaware of some
> new developments -- 'spontaneous' network device renaming, just like
> spontaneous mass storage device renaming, happens _only_ following
> admin-initiated hardware reshuffles.

Not so.
I recall working on a system a while ago with two different SCSI interfaces - 
basically trying to make a working and usable system from scavenged parts, 
pretty well everything I did in the last 12 years (linux wise) has been using 
"hand me down" hardware that the Windoze server guys had discarded. This was 
around the time that similar discussions were being had about "what's wrong 
with sda, sdb, etc ?". Due to the parallel driver loading issue, it was random 
which interface got it's devices installed first, and so I did have devices 
that would be in random order at boot time - ie some boots would result in my 
"first" drive being sda, other boots it would be sdb.
This was easily fixed (for me) using filesystem labels instead of device names 
- others just accepted the opaque filesystem IDs with those very long and hard 
to type strings (great fun when trying to boot manually in Grub !)

I don't recall exactly that problem with network interfaces, as by the time I 
was working with systems susceptible to it, udev had already fixed it. What I 
do recall was the pain of a two-NIC system where the "active" NIC (only one 
cable plugged in) would be different when booted from an installer disk or live 
distro than when booted from the installed OS.
But that isn't the same thing really

I suppose that one REALLY good way to fix the problem (at least in the server & 
desktop areas) is actually to undo a lot of "progress" and make all driver and 
service initiation strictly linear. Ie, do away with all this parallelism and 
make all drivers be loaded strictly in sequence, one after the other, in a 
defined order. I strongly suspect that it wouldn't hugely impact boot times 
either.
Put another way, part of the "problem" being "solved" is actually a side effect 
of "improvements" made elsewhere.

marc  wrote:

> However, some time ago the authors of the reverse engineered
> nvidia ethernet driver (was it forcedeth?) noticed they had
> decoded the mac address incorrectly and fixed it in a point
> release. For me that meant a headless machine many thousands
> of kilometers away became unreachable as what was eth0 at the
> last reboot now was stuck at eth1_renamed or ens9faefas#*$? or
> whatever it was.
> 
> Point is: In many cases eth0 means "the only network device
> on the system, the one we use to go online" and tieing it
> to a piece of hardware can be problematic too, as on occasion
> it gets replaced - or as per anecdode above, changes
> spontaneously, even though its 

[DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[Edward Bartolo]

If Devuan decides to use a different device name naming scheme apart
from the one discussed several months ago (a year ago?), it will
result in breaking simple-netaid-backend and simple-netaid-gui. I used
the naming scheme en* for ethN and wl* for wlanN.

Regarding this discussion what I have to say is what a Captain Obvious
would tell: 'Computers do not read minds, not even minds read other
minds'. Therefore, if I were in a position to take decisions I would
not expect a computer to know what I need. However, a computer should
have no difficulty processing data. A decent OS should save a map of
how hardware is connected, somewhat like a hardware tree with all
points fully defined. That way, if on a future boot, nodeX is not
found or is replaced with some other hardware, nodeZ, that we assume
existed before, will continue to be assigned with the same device
name.

The above should be unaffected by the worst of race conditions
provided these do not result in a complete OS freeze.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] auto.mirror.devuan.org or us.mirror.devuan.org

[Evilham]

Am 20/08/2017 um 12:50 schrieb tirveni yadav:
> Currently, Both the hostnames us.mirror.devuan.org and
> auto.mirror.devuan.org are pointing to packages.devuan.org.
> 
> And packages.devuan.org is pointing to an IP in pool of ovh, France.
> 
> So, there's no difference.

Pretty sure that's accurate, XY.mirror.devuan.org, where XY is a country
code should all be resolving to the same IP address.

IIRC, when the package mirror network is setup (plans are for it to
start soon), auto.mirror would send you to the closest mirror, so if you
move around, that'd be best for you; if you'd rather use a specific
country mirror, you should use that instead.
Keeping in mind, that while the package mirror network is deployed, they
all resolve to the same IP in France.
-- 
Evilham
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Proposed change in behaviour for ascii: eudev net.ifnames logic reversing proposal

[marc]

So another vote for keeping the eth0/wlan0 scheme and
not renaming devices in userspace.

Like Rick I haven't encountered a spontaneous device name 
re-order in the wild.

However, some time ago the authors of the reverse engineered
nvidia ethernet driver (was it forcedeth?) noticed they had
decoded the mac address incorrectly and fixed it in a point
release. For me that meant a headless machine many thousands
of kilometers away became unreachable as what was eth0 at the
last reboot now was stuck at eth1_renamed or ens9faefas#*$? or
whatever it was.

Point is: In many cases eth0 means "the only network device
on the system, the one we use to go online" and tieing it
to a piece of hardware can be problematic too, as on occasion
it gets replaced - or as per anecdode above, changes
spontaneously, even though its function does not.

regards

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