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

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

Question to new network device names

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

Contents

  Question to new network device names Hans <hans.ullrich@loop.de> - 2017-08-24 13:20 +0200
    Re: Question to new network device names Dejan Jocic <jodejka@gmail.com> - 2017-08-24 13:40 +0200
    Re: Question to new network device names Jude DaShiell <jdashiel@panix.com> - 2017-08-24 13:50 +0200
    Re: Question to new network device names <tomas@tuxteam.de> - 2017-08-24 14:00 +0200
      Re: Question to new network device names The Wanderer <wanderer@fastmail.fm> - 2017-08-24 15:20 +0200
        Re: Question to new network device names <tomas@tuxteam.de> - 2017-08-24 15:30 +0200
        Re: Question to new network device names Dave Sherohman <dave@sherohman.org> - 2017-08-24 15:40 +0200
          Re: Question to new network device names The Wanderer <wanderer@fastmail.fm> - 2017-08-24 16:00 +0200
          Re: Question to new network device names Dan Ritter <dsr@randomstring.org> - 2017-08-24 16:30 +0200
            Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 17:50 +0200
              Re: Question to new network device names The Wanderer <wanderer@fastmail.fm> - 2017-08-24 18:10 +0200
                Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 18:50 +0200
                  Re: Question to new network device names Dan Ritter <dsr@randomstring.org> - 2017-08-24 19:10 +0200
                    Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 20:20 +0200
                  Re: Question to new network device names The Wanderer <wanderer@fastmail.fm> - 2017-08-25 05:10 +0200
                    Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-25 07:30 +0200
              Re: Question to new network device names Dan Ritter <dsr@randomstring.org> - 2017-08-24 18:40 +0200
                Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 21:30 +0200
                Re: Question to new network device names Gene Heskett <gheskett@shentel.net> - 2017-08-25 03:00 +0200
                  Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-25 04:30 +0200
                    Re: Question to new network device names Gene Heskett <gheskett@shentel.net> - 2017-08-25 07:00 +0200
                      Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-25 07:30 +0200
                        Re: Question to new network device names Gene Heskett <gheskett@shentel.net> - 2017-08-25 08:30 +0200
                          Re: Question to new network device names Dan Ritter <dsr@randomstring.org> - 2017-08-25 15:30 +0200
                            Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-25 17:10 +0200
          Re: Question to new network device names Darac Marjal <mailinglist@darac.org.uk> - 2017-08-24 17:50 +0200
            Re: Question to new network device names The Wanderer <wanderer@fastmail.fm> - 2017-08-24 18:00 +0200
              Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 19:00 +0200
                Re: Question to new network device names Greg Wooledge <wooledg@eeg.ccf.org> - 2017-08-24 19:40 +0200
                  Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 20:00 +0200
        Re: Question to new network device names David Wright <deblis@lionunicorn.co.uk> - 2017-08-24 18:20 +0200
    Re: Question to new network device names Hans <hans.ullrich@loop.de> - 2017-08-25 14:00 +0200

Page 1 of 2  [1] 2  Next page →

#185815 — Question to new network device names

Hi folks,

I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of 
course I know, that this is obviously the newe standard (please correct me, i 
I am wrong).

What I would like to know: Is this new naming scheme an international standard 
on all linux distributions, or is this just a debian thing? At the moment, I 
renamed all devices to the old names (wlan0, eth0 and so on), as I many tools 
are still want the old names (however, it might be, that these are also not 
renewed documentations).

So, what is the status today? How have people accepted the new names also for 
long running systems? 

I think, most people might rename their stuff, just as I did, because they are 
more comfortable with the old names.

I would be happy for a little bit background information and if I am a 
dinosaur with old names.

Best regards

Hans
 

[toc] | [next] | [standalone]

#185816

On 24-08-17, Hans wrote:
> Hi folks,
> 
> I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of 
> course I know, that this is obviously the newe standard (please correct me, i 
> I am wrong).
> 
> What I would like to know: Is this new naming scheme an international standard 
> on all linux distributions, or is this just a debian thing? At the moment, I 
> renamed all devices to the old names (wlan0, eth0 and so on), as I many tools 
> are still want the old names (however, it might be, that these are also not 
> renewed documentations).
> 
> So, what is the status today? How have people accepted the new names also for 
> long running systems? 
> 
> I think, most people might rename their stuff, just as I did, because they are 
> more comfortable with the old names.
> 
> I would be happy for a little bit background information and if I am a 
> dinosaur with old names.
> 
> Best regards
> 
> Hans
>  
> 

Long answer short:

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

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

#185817

No, this is not just debian, you'll find it on archlinux as well.

On Thu, 24 Aug 2017, Hans wrote:

> Date: Thu, 24 Aug 2017 07:11:27
> From: Hans <hans.ullrich@loop.de>
> To: debian-user@lists.debian.org
> Subject: Question to new network device names
> Resent-Date: Thu, 24 Aug 2017 11:14:06 +0000 (UTC)
> Resent-From: debian-user@lists.debian.org
> 
> Hi folks,
>
> I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of
> course I know, that this is obviously the newe standard (please correct me, i
> I am wrong).
>
> What I would like to know: Is this new naming scheme an international standard
> on all linux distributions, or is this just a debian thing? At the moment, I
> renamed all devices to the old names (wlan0, eth0 and so on), as I many tools
> are still want the old names (however, it might be, that these are also not
> renewed documentations).
>
> So, what is the status today? How have people accepted the new names also for
> long running systems?
>
> I think, most people might rename their stuff, just as I did, because they are
> more comfortable with the old names.
>
> I would be happy for a little bit background information and if I am a
> dinosaur with old names.
>
> Best regards
>
> Hans
>
>
>

-- 

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

#185818

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

On Thu, Aug 24, 2017 at 01:11:27PM +0200, Hans wrote:
> Hi folks,
> 
> I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of 
> course I know, that this is obviously the newe standard (please correct me, i 
> I am wrong).

Relax. You can just choose whatever fits you (if you mix and match, though,
you better know what you are doing :)

> What I would like to know: Is this new naming scheme an international standard 
> on all linux distributions, or is this just a debian thing? At the moment, I 
> renamed all devices to the old names (wlan0, eth0 and so on), as I many tools 
> are still want the old names (however, it might be, that these are also not 
> renewed documentations).

Freedesktop has a well-written rationale [1] for the new naming scheme. That
said, freedesktop is... freedesktop, and has a clear stance on this.

> So, what is the status today? How have people accepted the new names also for 
> long running systems? 

I'd say: if you have a box with a huge number of interfaces, or if your
interface's hardware is brought up dynamically (picture a bunch of USB
hubs with 16 eth interface adapters at its tips, to have something your
phantasy can attach to), where the loading order of the corresponding
kernel modules determine who is first and who is last, whoever is eth0
and whoever is eth15 may change from boot to boot.

You don't want that, especially when those are attached to different
networks (picture a firewall/router...)

A similar case is when the interfaces come and go (e.g. plugging in and
out said USB adapters. All this doesn't need to be USB -- in the more
expensive world you can plug in (and out!) RAM and CPUs, while the
system is running).

Predictable names (try to) bring up the "same" interface with the "same"
name each time (although "same" itself isn't well-defined; IMHO this
makes a 100% job impossible anyway).

> I think, most people might rename their stuff, just as I did, because they are 
> more comfortable with the old names.

That's what I do: my workhorse has two built-in interfaces, one wired
and one wireless. Their good-ol' names are thus very predictable indeed,
namely "eth0" and "wlan0". The whole kaboodle is thus useless in this
case.

> I would be happy for a little bit background information and if I am a 
> dinosaur with old names.

If it ain't broke...

Just understand what the new scheme is for. Digest it. Convinced you
want/need it? Go for it! Not convinced? Keep the old.

Change for change's sake is as ill-advised as blind aversion to change
is.

The nice thing about free software is that you have the choice. Once you
climb up the "stack" and pile complexity up, your choice is reduced (gotta
pay a price for that comfort, right?), but the cool thing is that you
yourself find your point of equilibrium (gotta pay a price for that, and
that too: keep yourself informed :-)

Cheers

[1] https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

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

iEYEARECAAYFAlmeveMACgkQBcgs9XrR2kYlrQCdGjMIngOGTuE19UYae8oV81K3
/B4AmwfG0cRdI0HnIy7VivcQKm7Tkt8e
=LX6o
-----END PGP SIGNATURE-----

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

#185821

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

On 2017-08-24 at 07:52, tomas@tuxteam.de wrote:

> On Thu, Aug 24, 2017 at 01:11:27PM +0200, Hans wrote:
>
>> Hi folks,
> 
>> I stumbled over the new network names (i.e. wl0p8 instead of wlan0), and of 
>> course I know, that this is obviously the newe standard (please correct me, i 
>> I am wrong).

>> So, what is the status today? How have people accepted the new names also for 
>> long running systems? 
> 
> I'd say: if you have a box with a huge number of interfaces, or if your
> interface's hardware is brought up dynamically (picture a bunch of USB
> hubs with 16 eth interface adapters at its tips, to have something your
> phantasy can attach to), where the loading order of the corresponding
> kernel modules determine who is first and who is last, whoever is eth0
> and whoever is eth15 may change from boot to boot.
> 
> You don't want that, especially when those are attached to different
> networks (picture a firewall/router...)
> 
> A similar case is when the interfaces come and go (e.g. plugging in and
> out said USB adapters. All this doesn't need to be USB -- in the more
> expensive world you can plug in (and out!) RAM and CPUs, while the
> system is running).
> 
> Predictable names (try to) bring up the "same" interface with the "same"
> name each time (although "same" itself isn't well-defined; IMHO this
> makes a 100% job impossible anyway).

However, I'll point out that machines with this many network interfaces
are *by far* the exception rather than the rule; indeed, even machines
with more than *one* interface each of wired and wireless are reasonably
rare. As such, the scenario in which this naming scheme makes interface
names more predictable is not one which most people will ever encounter.
(...which calls into question the appropriateness of making this scheme
the default.)

To the best of my awareness, the rationale for calling this "predictable
network interface names" is that, on a single computer which has
multiple network interfaces of a given type, this naming scheme makes
it possible to predict *from one boot to the next* what the name of each
one will be. On such a computer, this is extremely valuable.

By contrast, on a computer which has at most one interface of a given
type, this naming scheme provides - so far as I can tell - no advantage
at all.

What's more, when working on *multiple* computers of that latter type,
this naming scheme makes it impossible to predict *from one computer to
the next* what the name of the sole available interface will be.

As such, IMO this naming scheme makes network-interface names
significantly *less* predictable in the real-world scenario which is
most commonly encountered.

On that basis and from that perspective, the choice of "predictable
network interface names" as the label for this naming scheme seems
downright Orwellian.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#185822

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

On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> On 2017-08-24 at 07:52, tomas@tuxteam.de wrote:

[...]

> However, I'll point out that machines with this many network interfaces
> are *by far* the exception rather than the rule [...]

If you meant *me*, you're preaching to the choir :)

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlme1IoACgkQBcgs9XrR2kbmbQCfSJirmY8iieqLwjq7MHmRaDpC
s/oAnROGgCiPMwbMGFb3YjUYRRkyQTmb
=h3zq
-----END PGP SIGNATURE-----

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

#185825

On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> However, I'll point out that machines with this many network interfaces
> are *by far* the exception rather than the rule; indeed, even machines
> with more than *one* interface each of wired and wireless are reasonably
> rare.

In the home desktop space, perhaps.  When you deal with rackmount
servers, OTOH, four (wired) network ports is pretty standard these days.

Of course, they're all on the same bus and using identical hardware/
firmware, so the "order might change based on which drivers load first"
case still doesn't apply.

> To the best of my awareness, the rationale for calling this "predictable
> network interface names" is that, on a single computer which has
> multiple network interfaces of a given type, this naming scheme makes
> it possible to predict *from one boot to the next* what the name of each
> one will be. On such a computer, this is extremely valuable.
> 
> By contrast, on a computer which has at most one interface of a given
> type, this naming scheme provides - so far as I can tell - no advantage
> at all.
> 
> What's more, when working on *multiple* computers of that latter type,
> this naming scheme makes it impossible to predict *from one computer to
> the next* what the name of the sole available interface will be.
> 
> As such, IMO this naming scheme makes network-interface names
> significantly *less* predictable in the real-world scenario which is
> most commonly encountered.

This closely parallels the move from using /dev/sdXn to UUIDs for
referring to filesystems.  Probably superior in theory and doesn't cause
any issues as long as you're dealing with a single machine and
unchanging hardware configuration... but then you have a drive failure,
restore your backups onto new hardware, and you're hosed because the
system wants to boot from a UUID that no longer exists.  (Yes, you can
recover from that situation - I know because I've had to do it - but it
doesn't Just Work(TM) effortlessly.)

-- 
Dave Sherohman

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

#185829

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

On 2017-08-24 at 09:30, Dave Sherohman wrote:

> On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> 
>> However, I'll point out that machines with this many network
>> interfaces are *by far* the exception rather than the rule; indeed,
>> even machines with more than *one* interface each of wired and
>> wireless are reasonably rare.
> 
> In the home desktop space, perhaps.  When you deal with rackmount 
> servers, OTOH, four (wired) network ports is pretty standard these
> days.

The computers I'm considering as what Carroll called the "universe of
discourse" here are "all computers on which this naming scheme is being
used". Whether they are servers or home desktops or business desktops or
smartphones or wireless access points or televisions or coffeepots or
anything else is irrelevant.

(Although of course several of those are unlikely to have anyone looking
at the interface names directly in the first place, so they may also be
irrelevant to the discussion.)

> Of course, they're all on the same bus and using identical hardware/ 
> firmware, so the "order might change based on which drivers load
> first" case still doesn't apply.

That's a detail I don't think I knew about.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#185830

On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:
> On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> > However, I'll point out that machines with this many network interfaces
> > are *by far* the exception rather than the rule; indeed, even machines
> > with more than *one* interface each of wired and wireless are reasonably
> > rare.
> 
> In the home desktop space, perhaps.  When you deal with rackmount
> servers, OTOH, four (wired) network ports is pretty standard these days.
> 
> Of course, they're all on the same bus and using identical hardware/
> firmware, so the "order might change based on which drivers load first"
> case still doesn't apply.
> 
> > To the best of my awareness, the rationale for calling this "predictable
> > network interface names" is that, on a single computer which has
> > multiple network interfaces of a given type, this naming scheme makes
> > it possible to predict *from one boot to the next* what the name of each
> > one will be. On such a computer, this is extremely valuable.
> > 
> > By contrast, on a computer which has at most one interface of a given
> > type, this naming scheme provides - so far as I can tell - no advantage
> > at all.
> > 
> > What's more, when working on *multiple* computers of that latter type,
> > this naming scheme makes it impossible to predict *from one computer to
> > the next* what the name of the sole available interface will be.
> > 
> > As such, IMO this naming scheme makes network-interface names
> > significantly *less* predictable in the real-world scenario which is
> > most commonly encountered.
> 
> This closely parallels the move from using /dev/sdXn to UUIDs for
> referring to filesystems.  Probably superior in theory and doesn't cause
> any issues as long as you're dealing with a single machine and
> unchanging hardware configuration... but then you have a drive failure,
> restore your backups onto new hardware, and you're hosed because the
> system wants to boot from a UUID that no longer exists.  (Yes, you can
> recover from that situation - I know because I've had to do it - but it
> doesn't Just Work(TM) effortlessly.)

There are, of course, five different ways to do this (at a
minimum):

1. /dev/sda1 is based on discovery order. Changes in discovery order
may indicate a significant problem that you need to investigate -- or not.

2. /dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S251NXAH217600A is based
on drive type and serial number. This is great if you treat changing a
disk as a serious problem that requires human intervention, and terrible
if you want a replacement disk to be handled automatically.

3. /dev/disk/by-label/sheepdog is based on filesystem labels.  These are
very good for mounting but useless for identifying specific disks,
and they can have collision problems.

4. /dev/disk/by-path/pci-0000:00:1f.2-ata-1-part1 is based on disk
controller topology. If you are interested in what's in a particular
disk slot rather than the particular disk in it, this is your choice.

5. /dev/disk/by-uuid/428366118125845852 identifies filesystems just
like by-label, and while it is unlikely to have an accidental collision
problem, does have a deliberate collision problem when you have copies
of filesystems.

6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
have their own ideas about what to do and how to do it, which may include
any of the above methods as well as their own peculiarities.

That said, if you have a laptop or a desktop with 1-2 disks, you
are probably going to be perfectly happy with either /dev/sda1 or
LABEL=root-$HOSTNAME addressing.

Getting back to the original point, NIC names -- virtually every computer
has exactly one or two NICs, and is best served by eth0 and wlan0. The
computers with 3-5 NICs are usually best served that way. More complex
naming schemes are helpful when you have a router or switch, and it's
nice that Debian supports that, but hardly a good default.

-dsr-

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

#185835

On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:

> > This closely parallels the move from using /dev/sdXn to UUIDs for
> > referring to filesystems.  Probably superior in theory and doesn't cause
> > any issues as long as you're dealing with a single machine and
> > unchanging hardware configuration... but then you have a drive failure,
> > restore your backups onto new hardware, and you're hosed because the
> > system wants to boot from a UUID that no longer exists.  (Yes, you can
> > recover from that situation - I know because I've had to do it - but it
> > doesn't Just Work(TM) effortlessly.)
> 
> There are, of course, five different ways to do this (at a
> minimum):
> 
> 1. /dev/sda1 is based on discovery order. Changes in discovery order
> may indicate a significant problem that you need to investigate -- or not.

I'm having difficulty imagining a scenario where the identity
of sdaX, in particular, is unimportant (for most people).

> 2. /dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S251NXAH217600A is based
> on drive type and serial number. This is great if you treat changing a
> disk as a serious problem that requires human intervention, and terrible
> if you want a replacement disk to be handled automatically.

I find this useful for identifying bootable Debian USB sticks
whose 'soft' identities vary from one revision/architecture/whatever
to the next. It probably fails for multiple cheap generic USBs
that have no firmware serial number.

> 3. /dev/disk/by-label/sheepdog is based on filesystem labels.  These are
> very good for mounting but useless for identifying specific disks,
> and they can have collision problems.

I find this ideal for most disks. It's amazingly easy to write the
human-friendly LABEL on the device with a marker pen, and I do use
stable partitioning numbering. All my hard drives are labelled thus,
and the USB sticks and SD cards that aren't already identifiable.

But I understand that I'm working within my own defined universe
of devices, and don't expect this to work for all others.
(Now think NICs.)

> 4. /dev/disk/by-path/pci-0000:00:1f.2-ata-1-part1 is based on disk
> controller topology. If you are interested in what's in a particular
> disk slot rather than the particular disk in it, this is your choice.
> 
> 5. /dev/disk/by-uuid/428366118125845852 identifies filesystems just
> like by-label, and while it is unlikely to have an accidental collision
> problem, does have a deliberate collision problem when you have copies
> of filesystems.

If genuine GUIDs, they're great for machines but no so much for
humans. If they're not genuine, they have to be checked, if it
matters, and that can be tedious.

But in connection with the original NIC discussion, the absence
of disk/by-uuid would be sorely missed if it weren't there, which
is why some improvement on eth0, eth1 assignment was needed,
and the result was a very flexible system IMO.

> 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
> have their own ideas about what to do and how to do it, which may include
> any of the above methods as well as their own peculiarities.
> 
> That said, if you have a laptop or a desktop with 1-2 disks, you
> are probably going to be perfectly happy with either /dev/sda1 or
> LABEL=root-$HOSTNAME addressing.

With two disks on a BIOS computer, you have an immediate problem,
don't you? That what disk-swapping was all about. And that was when
everything was on ATA.

But now look at the debates here on, for example, how an SD card
is going to appear to the system. The schematic diagram of any laptop
looks like a forest of USBs (and other types) so which is going to win
the race to become sda?

> Getting back to the original point, NIC names -- virtually every computer
> has exactly one or two NICs, and is best served by eth0 and wlan0. The
> computers with 3-5 NICs are usually best served that way. More complex
> naming schemes are helpful when you have a router or switch, and it's
> nice that Debian supports that, but hardly a good default.

There are plenty of ways that you, or Debian, can set a default.
But it surprises me that so many people grumble about this change.
The history of computing is littered with statements like
"virtually every computer has exactly one or two NICs".
This list is full of postings about the complex DNS system. But
how long did /etc/hosts last? Some complexity is unavoidable,
but if you try to avoid it, you pay for it later. Look at timezones.
Ever allowing computers' internal clocks to run on local time
was, with hindsight, a big mistake. Leap seconds might also
be seen the same way (still under debate).

Cheers,
David.

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

#185838

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

On 2017-08-24 at 11:43, David Wright wrote:

> On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:

>> Getting back to the original point, NIC names -- virtually every
>> computer has exactly one or two NICs, and is best served by eth0
>> and wlan0. The computers with 3-5 NICs are usually best served that
>> way. More complex naming schemes are helpful when you have a router
>> or switch, and it's nice that Debian supports that, but hardly a
>> good default.
> 
> There are plenty of ways that you, or Debian, can set a default. But
> it surprises me that so many people grumble about this change. The
> history of computing is littered with statements like "virtually
> every computer has exactly one or two NICs".

The thing is, currently that statement[1] *is* correct, so *currently*
the default should be suited for that configuration.

If things ever do reach a point where that is no longer the common case,
it would then become appropriate to propose changing the default to one
suited for that more-complex configuration.

But we are not yet there, or indeed anywhere close to there, so that
should not yet be the default.

> This list is full of postings about the complex DNS system. But how
> long did /etc/hosts last?

It's still there and still in use, albeit not as a primary source, last
I checked...


[1] Actually, the more precise statement involving "at most one NIC of
each type, wired and wireless" would be more accurate, because a machine
with two NICs of the same type would still benefit from the "predictable
network interface names" scheme.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#185844

On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> On 2017-08-24 at 11:43, David Wright wrote:
> 
> > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> 
> >> Getting back to the original point, NIC names -- virtually every
> >> computer has exactly one or two NICs, and is best served by eth0
> >> and wlan0. The computers with 3-5 NICs are usually best served that
> >> way. More complex naming schemes are helpful when you have a router
> >> or switch, and it's nice that Debian supports that, but hardly a
> >> good default.
> > 
> > There are plenty of ways that you, or Debian, can set a default. But
> > it surprises me that so many people grumble about this change. The
> > history of computing is littered with statements like "virtually
> > every computer has exactly one or two NICs".
> 
> The thing is, currently that statement[1] *is* correct, so *currently*
> the default should be suited for that configuration.
> 
> If things ever do reach a point where that is no longer the common case,
> it would then become appropriate to propose changing the default to one
> suited for that more-complex configuration.
> 
> But we are not yet there, or indeed anywhere close to there, so that
> should not yet be the default.

By that argument, you wait until lots of people have problems before
you change the default to accomodate them, instead of thinking ahead.
If you want a simpler default, can you not follow the instructions
and give yourself one. For people upgrading, Debian ensured that
there would not be an unexpected change; the older methods prevail¹.

> > This list is full of postings about the complex DNS system. But how
> > long did /etc/hosts last?
> 
> It's still there and still in use, albeit not as a primary source, last
> I checked...

It's the *only* source here for such as 192.168.1.13	wasp
but I was assuming you'd understand I was talking about non-local
hosts on the Internet.

> [1] Actually, the more precise statement involving "at most one NIC of
> each type, wired and wireless" would be more accurate, because a machine
> with two NICs of the same type would still benefit from the "predictable
> network interface names" scheme.

Yes, and I remember the problems I had when all my NICs were
3c509s from the free shop (Academic Computing Services) and
I put two in the same box. These (problems) would be unacceptable
nowadays.

You can't please everyone. You can find threads here complaining
loud and long about udev's persistent-net rules¹, one of the
preceding methods "foisted" on us by Debian.

Cheers,
David.

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

#185846

On Thu, Aug 24, 2017 at 11:40:28AM -0500, David Wright wrote:
> On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> > On 2017-08-24 at 11:43, David Wright wrote:
> > 
> > > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > If things ever do reach a point where that is no longer the common case,
> > it would then become appropriate to propose changing the default to one
> > suited for that more-complex configuration.
> > 
> > But we are not yet there, or indeed anywhere close to there, so that
> > should not yet be the default.
> 
> By that argument, you wait until lots of people have problems before
> you change the default to accomodate them, instead of thinking ahead.
> If you want a simpler default, can you not follow the instructions
> and give yourself one. For people upgrading, Debian ensured that
> there would not be an unexpected change; the older methods prevail¹.

This is the biggest systemic problem I have with Debian today.

You just made an assumption that does not match my reality, and
you didn't even realize that you made it. 

I'm in charge of a lot of Debian-running machines. One of the major
reasons that we chose Debian is because of the promise that we would be
able to upgrade in place, rather than wiping the old OS and reinstalling.

As a result, we buy machines when we need them, not necessarily all at
once. And we expect a new install of Stretch to behave the same way as
an upgraded Wheezy-to-Jessie-to-Stretch. 

It does not.

That makes Debian worth less than it used to be.

-dsr-

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

#185850

On Thu 24 Aug 2017 at 12:59:46 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 11:40:28AM -0500, David Wright wrote:
> > On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> > > On 2017-08-24 at 11:43, David Wright wrote:
> > > 
> > > > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > > If things ever do reach a point where that is no longer the common case,
> > > it would then become appropriate to propose changing the default to one
> > > suited for that more-complex configuration.
> > > 
> > > But we are not yet there, or indeed anywhere close to there, so that
> > > should not yet be the default.
> > 
> > By that argument, you wait until lots of people have problems before
> > you change the default to accomodate them, instead of thinking ahead.
> > If you want a simpler default, can you not follow the instructions
> > and give yourself one. For people upgrading, Debian ensured that
> > there would not be an unexpected change; the older methods prevail¹.
> 
> This is the biggest systemic problem I have with Debian today.
> 
> You just made an assumption that does not match my reality, and
> you didn't even realize that you made it. 

That's rather patronising.

> I'm in charge of a lot of Debian-running machines. One of the major
> reasons that we chose Debian is because of the promise that we would be
> able to upgrade in place, rather than wiping the old OS and reinstalling.
> 
> As a result, we buy machines when we need them, not necessarily all at
> once. And we expect a new install of Stretch to behave the same way as
> an upgraded Wheezy-to-Jessie-to-Stretch. 
> 
> It does not.
> 
> That makes Debian worth less than it used to be.

Are you saying that you can get a Wheezy-to-Jessie-to-Stretch machine
to be identical to a new Stretch one without any configuration
adjustments? All you have to do is remove the constraints on the
upgraded machines to make them behave like the new ones. The place
to look is /etc/udev/rules.d/70-persistent-net.rules AIUI.

Cheers,
David.

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

#185875

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

On 2017-08-24 at 12:40, David Wright wrote:

> On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:

>> On 2017-08-24 at 11:43, David Wright wrote:

>>> There are plenty of ways that you, or Debian, can set a default.
>>> But it surprises me that so many people grumble about this
>>> change. The history of computing is littered with statements like
>>> "virtually every computer has exactly one or two NICs".
>> 
>> The thing is, currently that statement[1] *is* correct, so
>> *currently* the default should be suited for that configuration.
>> 
>> If things ever do reach a point where that is no longer the common
>> case, it would then become appropriate to propose changing the
>> default to one suited for that more-complex configuration.
>> 
>> But we are not yet there, or indeed anywhere close to there, so
>> that should not yet be the default.
> 
> By that argument, you wait until lots of people have problems before 
> you change the default to accomodate them, instead of thinking
> ahead.

Well, yes - or at least until lots of people are *about to* have
problems pretty soon, unless the default is changed first. That is at
least preferable to *causing* lots of people to have problems (or at
least experience additional inconvenience) by changing the default too
far in advance.

> If you want a simpler default, can you not follow the instructions 
> and give yourself one.

Er... what?

A default is "what you get if you don't take steps to get something else".

If you have to take steps to achieve a given configuration, by
definition that configuration is not the default.

Thus, since the "old" naming scheme here no longer comes as the default
(for new installs, et cetera), I cannot make it the default.

I can certainly make local changes to get a non-default configuration,
but that does not make that configuration the default.

> For people upgrading, Debian ensured that there would not be an
> unexpected change; the older methods prevail¹.

Missing footnote?

>>> This list is full of postings about the complex DNS system. But
>>> how long did /etc/hosts last?
>> 
>> It's still there and still in use, albeit not as a primary source,
>> last I checked...
> 
> It's the *only* source here for such as 192.168.1.13	wasp but I was
> assuming you'd understand I was talking about non-local hosts on the
> Internet.

Just offhand, I don't think I even remember a time when that file was
used (outside of special one-off cases) for such hosts. I also don't
remember encountering such a special one-off case in the past several
years to a decade, at least, although I wouldn't be at all surprised to
learn they still crop up.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#185884

On Thu 24 Aug 2017 at 23:00:19 (-0400), The Wanderer wrote:
> On 2017-08-24 at 12:40, David Wright wrote:
> 
> > On Thu 24 Aug 2017 at 12:02:11 (-0400), The Wanderer wrote:
> 
> >> On 2017-08-24 at 11:43, David Wright wrote:
> 
> >>> There are plenty of ways that you, or Debian, can set a default.
> >>> But it surprises me that so many people grumble about this
> >>> change. The history of computing is littered with statements like
> >>> "virtually every computer has exactly one or two NICs".
> >> 
> >> The thing is, currently that statement[1] *is* correct, so
> >> *currently* the default should be suited for that configuration.
> >> 
> >> If things ever do reach a point where that is no longer the common
> >> case, it would then become appropriate to propose changing the
> >> default to one suited for that more-complex configuration.
> >> 
> >> But we are not yet there, or indeed anywhere close to there, so
> >> that should not yet be the default.
> > 
> > By that argument, you wait until lots of people have problems before 
> > you change the default to accomodate them, instead of thinking
> > ahead.
> 
> Well, yes - or at least until lots of people are *about to* have
> problems pretty soon, unless the default is changed first. That is at
> least preferable to *causing* lots of people to have problems (or at
> least experience additional inconvenience) by changing the default too
> far in advance.

I see. So you never consider the vanguard's problems or expectations?
If it's a question of timing, then waiting would usually suit me; as
I said, I'm usually at the trailing rather than the cutting edge.

> > If you want a simpler default, can you not follow the instructions 
> > and give yourself one.
> 
> Er... what?
> 
> A default is "what you get if you don't take steps to get something else".
> 
> If you have to take steps to achieve a given configuration, by
> definition that configuration is not the default.
> 
> Thus, since the "old" naming scheme here no longer comes as the default
> (for new installs, et cetera), I cannot make it the default.
> 
> I can certainly make local changes to get a non-default configuration,
> but that does not make that configuration the default.

Fair enough. Pick a word you prefer and override my choice of default.
Perhaps "prefer" or "override" will do. Meanwhile, I shall have words
with whoever chose the directory name /etc/default/. At the back of
my mind was adding net.ifnames=0 to GRUB_CMDLINE_LINUX in
/etc/default/grub.

> > For people upgrading, Debian ensured that there would not be an
> > unexpected change; the older methods prevail¹.
> 
> Missing footnote?

No, I put the matching ¹ at the words "udev's persistent-net rules"
in the footnote (which was more of an aside) as this is an older
method that prevails. I guess the visibility of the ¹ is something
I have no control over.

> >>> This list is full of postings about the complex DNS system. But
> >>> how long did /etc/hosts last?
> >> 
> >> It's still there and still in use, albeit not as a primary source,
> >> last I checked...
> > 
> > It's the *only* source here for such as 192.168.1.13	wasp but I was
> > assuming you'd understand I was talking about non-local hosts on the
> > Internet.
> 
> Just offhand, I don't think I even remember a time when that file was
> used (outside of special one-off cases) for such hosts. I also don't
> remember encountering such a special one-off case in the past several
> years to a decade, at least, although I wouldn't be at all surprised to
> learn they still crop up.

That can't be right. You don't mean to say that people use
dotted quads to communicate with their local hosts. That's
a lot to commit to memory. I wouldn't say we have an abundance
of devices, but I am using over half the area I reserved for
static addresses, 16 out of 31. I might have been using more
but for the fact that IPv6 is available for direct links.

Cheers,
David.

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

#185841

On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > There are, of course, five different ways to do this (at a
> > minimum):
> > 
> > 1. /dev/sda1 is based on discovery order. Changes in discovery order
> > may indicate a significant problem that you need to investigate -- or not.
> 
> I'm having difficulty imagining a scenario where the identity
> of sdaX, in particular, is unimportant (for most people).

Say you boot from /dev/nvme0n1p1 (a high speed NVMe SSD) and 
have /dev/sda, b, c and d in an mdadm RAID10. 

mdadm will scan all disks looking for its signature, and will
assemble them into /dev/md/0 regardless of physical disk
location. So it really won't matter to you whether you have the
same disks in /dev/sdX from boot to boot as long as they are
all there.

But for most people, most of the time, swapping /dev/sda and
/dev/sdc would be a problem.

> But in connection with the original NIC discussion, the absence
> of disk/by-uuid would be sorely missed if it weren't there, which
> is why some improvement on eth0, eth1 assignment was needed,
> and the result was a very flexible system IMO.
> 
> > 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
> > have their own ideas about what to do and how to do it, which may include
> > any of the above methods as well as their own peculiarities.
> > 
> > That said, if you have a laptop or a desktop with 1-2 disks, you
> > are probably going to be perfectly happy with either /dev/sda1 or
> > LABEL=root-$HOSTNAME addressing.
> 
> With two disks on a BIOS computer, you have an immediate problem,
> don't you? That what disk-swapping was all about. And that was when
> everything was on ATA.

On a well-working computer, device discovery order is constant without
physical changes. sda will always be sda, until it breaks or
something else (bad) happens.

> But now look at the debates here on, for example, how an SD card
> is going to appear to the system. The schematic diagram of any laptop
> looks like a forest of USBs (and other types) so which is going to win
> the race to become sda?

They don't. The SATA, SATA-DOM or NVMe disk selected by the UEFI or BIOS
will become sda. Or if you've got an internal USB port with a
stick in it, that might be a selected candidate. In no case
should it change without hardware failure or physical
rearrangement.

The question is, how will your newly plugged in SD card become
sdk rather than sdj, and the answer is that mass storage devices
that are expected to be rearranged should be treated differently 
from those which are expected to always be available from
boot-time onwards.


> > Getting back to the original point, NIC names -- virtually every computer
> > has exactly one or two NICs, and is best served by eth0 and wlan0. The
> > computers with 3-5 NICs are usually best served that way. More complex
> > naming schemes are helpful when you have a router or switch, and it's
> > nice that Debian supports that, but hardly a good default.
> 
> There are plenty of ways that you, or Debian, can set a default.
> But it surprises me that so many people grumble about this change.

People grumble about changes for several nonexclusive reasons:

1. The change broke what they were doing.
2. The change broke their mental model of what they were doing.
3. The change did not bring them perceived benefits.
4. The change appears arbitrary.
5. The change fixed a problem but they perceive better ways to
   solve the problem.
6. The change creates new problems.


> The history of computing is littered with statements like
> "virtually every computer has exactly one or two NICs".

It used to be zero.

We are currently in the phase of history where this statement is
true. NICs are both ubiquitous and cheap, yet devices tend to
come with one (only an ethernet port or only a wifi radio) or
two (one of each of those, or a wifi radio and a cell radio).

Devices can add more, but they are always special cases: my 
Debian-running firewall has 5 ethernet ports. I occasionally
add a USB ethernet frob in order to isolate a device that I want
to talk to directly. Special cases deserve special treatment.

I expect the statement to remain true for the next ten years.

Do you expect differently? If so, why?


> This list is full of postings about the complex DNS system. But
> how long did /etc/hosts last? Some complexity is unavoidable,
> but if you try to avoid it, you pay for it later. Look at timezones.
> Ever allowing computers' internal clocks to run on local time
> was, with hindsight, a big mistake. Leap seconds might also
> be seen the same way (still under debate).

/etc/hosts still acts the way it always did -- put in an entry,
it overrides DNS.

Timezones are a human legal-social problem, and the ability of
technology to deal with those is known to be problematic.

-dsr-

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

#185853

On Thu 24 Aug 2017 at 12:30:37 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > > There are, of course, five different ways to do this (at a
> > > minimum):
> > > 
> > > 1. /dev/sda1 is based on discovery order. Changes in discovery order
> > > may indicate a significant problem that you need to investigate -- or not.
> > 
> > I'm having difficulty imagining a scenario where the identity
> > of sdaX, in particular, is unimportant (for most people).
                                                ↑↑↑↑↑↑↑↑↑↑↑

> Say you boot from /dev/nvme0n1p1 (a high speed NVMe SSD) and 
> have /dev/sda, b, c and d in an mdadm RAID10. 
> 
> mdadm will scan all disks looking for its signature, and will
> assemble them into /dev/md/0 regardless of physical disk
> location. So it really won't matter to you whether you have the
> same disks in /dev/sdX from boot to boot as long as they are
> all there.
> 
> But for most people, most of the time, swapping /dev/sda and
> /dev/sdc would be a problem.

Yes, I assumed that *most* people boot from sda.

> > But in connection with the original NIC discussion, the absence
> > of disk/by-uuid would be sorely missed if it weren't there, which
> > is why some improvement on eth0, eth1 assignment was needed,
> > and the result was a very flexible system IMO.
> > 
> > > 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
> > > have their own ideas about what to do and how to do it, which may include
> > > any of the above methods as well as their own peculiarities.
> > > 
> > > That said, if you have a laptop or a desktop with 1-2 disks, you
> > > are probably going to be perfectly happy with either /dev/sda1 or
> > > LABEL=root-$HOSTNAME addressing.
> > 
> > With two disks on a BIOS computer, you have an immediate problem,
> > don't you? That what disk-swapping was all about. And that was when
> > everything was on ATA.
> 
> On a well-working computer, device discovery order is constant without
> physical changes. sda will always be sda, until it breaks or
> something else (bad) happens.

Passing comment: our memories are short. I remember the time when the
sole disk in a machine would vacillate between hda and sda if one was
running (as I always do) two consecutive versions of Debian. A
different cause, however.

I haven't looked back to see the number of screams. I'd left
debian-user by then on the grounds of traffic volume.

> > But now look at the debates here on, for example, how an SD card
> > is going to appear to the system. The schematic diagram of any laptop
> > looks like a forest of USBs (and other types) so which is going to win
> > the race to become sda?
> 
> They don't. The SATA, SATA-DOM or NVMe disk selected by the UEFI or BIOS
> will become sda. Or if you've got an internal USB port with a
> stick in it, that might be a selected candidate. In no case
> should it change without hardware failure or physical
> rearrangement.
> 
> The question is, how will your newly plugged in SD card become
> sdk rather than sdj, and the answer is that mass storage devices
> that are expected to be rearranged should be treated differently 
> from those which are expected to always be available from
> boot-time onwards.

You just made an assumption that does not match my reality, and
you didn't even realize that you made it. :) The SD card may
already be plugged in and contain the OS itself.

But seriously, the only point I'm trying to make here is that even the
single disk computer user should not rely on /dev/sdX names. When they
buy a new disk with perhaps a new technology, or have a failing drive
and want to copy at device-level (ie dd-style), that's precisely not
the time to be distracted by coping with hardware races and shifting
device names.

> > > Getting back to the original point, NIC names -- virtually every computer
> > > has exactly one or two NICs, and is best served by eth0 and wlan0. The
> > > computers with 3-5 NICs are usually best served that way. More complex
> > > naming schemes are helpful when you have a router or switch, and it's
> > > nice that Debian supports that, but hardly a good default.
> > 
> > There are plenty of ways that you, or Debian, can set a default.
> > But it surprises me that so many people grumble about this change.
> 
> People grumble about changes for several nonexclusive reasons:
> 
> 1. The change broke what they were doing.
> 2. The change broke their mental model of what they were doing.
> 3. The change did not bring them perceived benefits.
> 4. The change appears arbitrary.
> 5. The change fixed a problem but they perceive better ways to
>    solve the problem.
> 6. The change creates new problems.

Summarising, people will grumble.

> > The history of computing is littered with statements like
> > "virtually every computer has exactly one or two NICs".
> 
> It used to be zero.
> 
> We are currently in the phase of history where this statement is
> true. NICs are both ubiquitous and cheap, yet devices tend to
> come with one (only an ethernet port or only a wifi radio) or
> two (one of each of those, or a wifi radio and a cell radio).
> 
> Devices can add more, but they are always special cases: my 
> Debian-running firewall has 5 ethernet ports. I occasionally
> add a USB ethernet frob in order to isolate a device that I want
> to talk to directly. Special cases deserve special treatment.
> 
> I expect the statement to remain true for the next ten years.
> 
> Do you expect differently? If so, why?

I didn't expect to have to deal with this problem when I ran a PC
with two identical NICs; it's highly unusual for me to be ahead of
the curve. But I know that the future will always confound our
expectations. So why not build in flexibility. The tools are
there on the web page for hiding any complexity.

> > This list is full of postings about the complex DNS system. But
> > how long did /etc/hosts last? Some complexity is unavoidable,
> > but if you try to avoid it, you pay for it later. Look at timezones.
> > Ever allowing computers' internal clocks to run on local time
> > was, with hindsight, a big mistake. Leap seconds might also
> > be seen the same way (still under debate).
> 
> /etc/hosts still acts the way it always did -- put in an entry,
> it overrides DNS.
> 
> Timezones are a human legal-social problem, and the ability of
> technology to deal with those is known to be problematic.

I see it differently. Technologists didn't plan for a time when
electronic devices would know the time, care about it, and be
capable of movement around the globe. What surprises me is that
many/most of those technologists live in a country with four
timezones and a multiplicity of civil times, so you might have
expected them to deal with the problem from the start.

Cheers,
David.

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

#185872

On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:

> On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > > There are, of course, five different ways to do this (at a
> > > minimum):
> > >
> > > 1. /dev/sda1 is based on discovery order. Changes in discovery
> > > order may indicate a significant problem that you need to
> > > investigate -- or not.
> >
> > I'm having difficulty imagining a scenario where the identity
> > of sdaX, in particular, is unimportant (for most people).
>
> Say you boot from /dev/nvme0n1p1 (a high speed NVMe SSD) and
> have /dev/sda, b, c and d in an mdadm RAID10.
>
> mdadm will scan all disks looking for its signature, and will
> assemble them into /dev/md/0 regardless of physical disk
> location. So it really won't matter to you whether you have the
> same disks in /dev/sdX from boot to boot as long as they are
> all there.
>
> But for most people, most of the time, swapping /dev/sda and
> /dev/sdc would be a problem.
>
> > But in connection with the original NIC discussion, the absence
> > of disk/by-uuid would be sorely missed if it weren't there, which
> > is why some improvement on eth0, eth1 assignment was needed,
> > and the result was a very flexible system IMO.
> >
> > > 6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware
> > > RAID -- have their own ideas about what to do and how to do it,
> > > which may include any of the above methods as well as their own
> > > peculiarities.
> > >
> > > That said, if you have a laptop or a desktop with 1-2 disks, you
> > > are probably going to be perfectly happy with either /dev/sda1 or
> > > LABEL=root-$HOSTNAME addressing.
> >
> > With two disks on a BIOS computer, you have an immediate problem,
> > don't you? That what disk-swapping was all about. And that was when
> > everything was on ATA.
>
> On a well-working computer, device discovery order is constant without
> physical changes. sda will always be sda, until it breaks or
> something else (bad) happens.
>
> > But now look at the debates here on, for example, how an SD card
> > is going to appear to the system. The schematic diagram of any
> > laptop looks like a forest of USBs (and other types) so which is
> > going to win the race to become sda?
>
> They don't. The SATA, SATA-DOM or NVMe disk selected by the UEFI or
> BIOS will become sda. Or if you've got an internal USB port with a
> stick in it, that might be a selected candidate. In no case
> should it change without hardware failure or physical
> rearrangement.
>
> The question is, how will your newly plugged in SD card become
> sdk rather than sdj, and the answer is that mass storage devices
> that are expected to be rearranged should be treated differently
> from those which are expected to always be available from
> boot-time onwards.
>
> > > Getting back to the original point, NIC names -- virtually every
> > > computer has exactly one or two NICs, and is best served by eth0
> > > and wlan0. The computers with 3-5 NICs are usually best served
> > > that way. More complex naming schemes are helpful when you have a
> > > router or switch, and it's nice that Debian supports that, but
> > > hardly a good default.
> >
> > There are plenty of ways that you, or Debian, can set a default.
> > But it surprises me that so many people grumble about this change.
>
> People grumble about changes for several nonexclusive reasons:
>
> 1. The change broke what they were doing.
> 2. The change broke their mental model of what they were doing.
> 3. The change did not bring them perceived benefits.
> 4. The change appears arbitrary.
> 5. The change fixed a problem but they perceive better ways to
>    solve the problem.
> 6. The change creates new problems.
>
> > The history of computing is littered with statements like
> > "virtually every computer has exactly one or two NICs".
>
> It used to be zero.
>
> We are currently in the phase of history where this statement is
> true. NICs are both ubiquitous and cheap, yet devices tend to
> come with one (only an ethernet port or only a wifi radio) or
> two (one of each of those, or a wifi radio and a cell radio).
>
> Devices can add more, but they are always special cases: my
> Debian-running firewall has 5 ethernet ports. I occasionally
> add a USB ethernet frob in order to isolate a device that I want
> to talk to directly. Special cases deserve special treatment.
>
> I expect the statement to remain true for the next ten years.
>
> Do you expect differently? If so, why?
>
> > This list is full of postings about the complex DNS system. But
> > how long did /etc/hosts last? Some complexity is unavoidable,
> > but if you try to avoid it, you pay for it later. Look at timezones.
> > Ever allowing computers' internal clocks to run on local time
> > was, with hindsight, a big mistake. Leap seconds might also
> > be seen the same way (still under debate).
>
> /etc/hosts still acts the way it always did -- put in an entry,
> it overrides DNS.
>
That depends entirely on who wrote your /etc/resolv.conf and whether or 
not your did a sudo chattr +i /etc/resolv.conf, immediately after 
verifying that it works. (and of course that implies it is a real file, 
not a softlink to something else.  With N-M in the mix and active that 
is the only way to keep it from tearing down your network configuration 
and leaving you empty files, and no network, if it cannot find a dhcpd 
server)

> Timezones are a human legal-social problem, and the ability of
> technology to deal with those is known to be problematic.

Just as humans are known to be a problem...
> -dsr-


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

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

#185874

On Thu 24 Aug 2017 at 20:58:18 (-0400), Gene Heskett wrote:
> On Thursday 24 August 2017 12:30:37 Dan Ritter wrote:
> > On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:

> > > The history of computing is littered with statements like
> > > "virtually every computer has exactly one or two NICs".
> >
> > It used to be zero.
> >
> > We are currently in the phase of history where this statement is
> > true. NICs are both ubiquitous and cheap, yet devices tend to
> > come with one (only an ethernet port or only a wifi radio) or
> > two (one of each of those, or a wifi radio and a cell radio).
> >
> > Devices can add more, but they are always special cases: my
> > Debian-running firewall has 5 ethernet ports. I occasionally
> > add a USB ethernet frob in order to isolate a device that I want
> > to talk to directly. Special cases deserve special treatment.
> >
> > I expect the statement to remain true for the next ten years.
> >
> > Do you expect differently? If so, why?
> >
> > > This list is full of postings about the complex DNS system. But
> > > how long did /etc/hosts last? Some complexity is unavoidable,
> > > but if you try to avoid it, you pay for it later. Look at timezones.
> > > Ever allowing computers' internal clocks to run on local time
> > > was, with hindsight, a big mistake. Leap seconds might also
> > > be seen the same way (still under debate).
> >
> > /etc/hosts still acts the way it always did -- put in an entry,
> > it overrides DNS.
> >
> That depends entirely on who wrote your /etc/resolv.conf and whether or 
> not your did a sudo chattr +i /etc/resolv.conf, immediately after 
> verifying that it works. (and of course that implies it is a real file, 
> not a softlink to something else.  With N-M in the mix and active that 
> is the only way to keep it from tearing down your network configuration 
> and leaving you empty files, and no network, if it cannot find a dhcpd 
> server)

(We've heard about your problems concerning /etc/resolv.conf
several times now.)

I think the file that affects the priority of /etc/hosts is
/etc/nsswitch.conf which typically contains a line like:

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

But that misses the point I was making, which requires one to know
a fragment of Internet history. /etc/hosts started life as a file
containing the address of every host on the network (then ARPANET).
Simple, sufficient at the time, but obviously not going to stay
the course.

Similarly, /dev/sdX just about works well enough for simple, static
systems but not for more complex, dynamic ones; eth0 likewise is
showing its age for scaling and flexibility, particularly as the
newer scheme adds functionality without removing the legacy.

Cheers,
David.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web