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


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

network setup

Started byJude DaShiell <jdashiel@panix.com>
First post2016-12-11 19:20 +0100
Last post2016-12-16 01:20 +0100
Articles 9 on this page of 29 — 11 participants

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


Contents

  network setup Jude DaShiell <jdashiel@panix.com> - 2016-12-11 19:20 +0100
    Re: network setup Henning Follmann <hfollmann@itcfollmann.com> - 2016-12-11 20:00 +0100
    Re: network setup Charlie Kravetz <cjk@teamcharliesangels.com> - 2016-12-11 20:40 +0100
      Re: network setup Brian <ad44@cityscape.co.uk> - 2016-12-11 20:50 +0100
      Re: network setup Jude DaShiell <jdashiel@panix.com> - 2016-12-12 01:50 +0100
        Re: network setup Brian <ad44@cityscape.co.uk> - 2016-12-12 13:50 +0100
          Re: network setup Jude DaShiell <jdashiel@panix.com> - 2016-12-13 12:20 +0100
            Re: network setup Brian <ad44@cityscape.co.uk> - 2016-12-13 14:00 +0100
              Re: network setup Jude DaShiell <jdashiel@panix.com> - 2016-12-14 19:40 +0100
        Re: network setup Jude DaShiell <jdashiel@panix.com> - 2016-12-13 12:10 +0100
          Re: network setup Charlie Kravetz <cjk@teamcharliesangels.com> - 2016-12-13 15:50 +0100
        Re: network setup <tomas@tuxteam.de> - 2016-12-13 14:20 +0100
          Re: network setup Darac Marjal <mailinglist@darac.org.uk> - 2016-12-13 14:40 +0100
            Re: network setup <tomas@tuxteam.de> - 2016-12-13 14:50 +0100
              Re: network setup Brian <ad44@cityscape.co.uk> - 2016-12-13 20:50 +0100
                Re: network setup Erwan David <erwan@rail.eu.org> - 2016-12-13 21:00 +0100
                  Re: network setup Greg Wooledge <wooledg@eeg.ccf.org> - 2016-12-13 22:10 +0100
                    Re: network setup Erwan David <erwan@rail.eu.org> - 2016-12-14 08:50 +0100
                      Re: network setup Jude DaShiell <jdashiel@panix.com> - 2016-12-14 19:50 +0100
                  Re: network setup Brian <ad44@cityscape.co.uk> - 2016-12-13 22:10 +0100
                Re: network setup <tomas@tuxteam.de> - 2016-12-13 22:00 +0100
                  Re: network setup David Wright <deblis@lionunicorn.co.uk> - 2016-12-14 04:00 +0100
                    Re: network setup <tomas@tuxteam.de> - 2016-12-14 10:20 +0100
                      Re: network setup Lisi Reisz <lisi.reisz@gmail.com> - 2016-12-14 12:20 +0100
                        Re: network setup <tomas@tuxteam.de> - 2016-12-14 12:40 +0100
                          Re: network setup Lisi Reisz <lisi.reisz@gmail.com> - 2016-12-14 13:50 +0100
                    Re: network setup David Jardine <david@jardine.de> - 2016-12-14 14:10 +0100
                      Re: network setup Brian <ad44@cityscape.co.uk> - 2016-12-14 15:20 +0100
                        Re: network setup David Jardine <david@jardine.de> - 2016-12-16 01:20 +0100

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


#175686

From<tomas@tuxteam.de>
Date2016-12-13 22:00 +0100
Message-ID<sO2l4-5Po-33@gated-at.bofh.it>
In reply to#175683
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Dec 13, 2016 at 07:44:39PM +0000, Brian wrote:

[...]

> For someone who has been using Debian for many years the position you
> expound is understandable and viable to support [...]

> But remember new users; does it really matter to them? They have no
> personal history to point to. As you point out, the engineering
> advantages are unarguable [...]

I'm not going to argue too much, since "de gustibus non est disputandum",
as they say. But I'm a little concerned to see the innards of the
system to get less accessible, bit by bit, in the name of some
engineering advantages which only matter in an uncommon context
(pluggable Ethernet devices being such a case here).

In my eyes, the main asset of Free Software is that the end user
*can* study and hack it. Baroque engineering is a heavy debt piling
up against hackability, and should be considered in the cost analysis.

I understand that it is a trade-off, and that different folks will
see the sweet spot at different points.

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

iEYEARECAAYFAlhQX38ACgkQBcgs9XrR2kZs4gCfZ8E6ciEmd6QtRKHTcoK5BYJF
KMQAn1oLKwsO/EWPbEXfC5vvwLgLhlwf
=NiGY
-----END PGP SIGNATURE-----

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


#175697

FromDavid Wright <deblis@lionunicorn.co.uk>
Date2016-12-14 04:00 +0100
Message-ID<sO7Xr-Mm-7@gated-at.bofh.it>
In reply to#175686
On Tue 13 Dec 2016 at 21:52:15 (+0100), tomas@tuxteam.de wrote:
> On Tue, Dec 13, 2016 at 07:44:39PM +0000, Brian wrote:
> 
> [...]
> 
> > For someone who has been using Debian for many years the position you
> > expound is understandable and viable to support [...]
> 
> > But remember new users; does it really matter to them? They have no
> > personal history to point to. As you point out, the engineering
> > advantages are unarguable [...]
> 
> I'm not going to argue too much, since "de gustibus non est disputandum",
> as they say. But I'm a little concerned to see the innards of the
> system to get less accessible, bit by bit,

Eh? How does calling something by the string "wlx00c0ca364bd2" instead
of "wlan0" make it less accessible? At least it's not telling a lie,
which the old naming scheme sometimes does.

> in the name of some
> engineering advantages which only matter in an uncommon context
> (pluggable Ethernet devices being such a case here).

When I ran machines containing two identical ethernet cards, it
was lucky dip as to which card got which name. That alone would
have made the new method far preferable, had it been available at
the time.

> In my eyes, the main asset of Free Software is that the end user
> *can* study and hack it. Baroque engineering is a heavy debt piling
> up against hackability, and should be considered in the cost analysis.
> 
> I understand that it is a trade-off, and that different folks will
> see the sweet spot at different points.

I think you understand something different by "trade-off". You gain
several new methods of naming interfaces and lose nothing. The only
people who can be said to lose are those upgrading (which preserves
the existing names) who might remain unaware of the new options
available to them.

Cheers,
David.

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


#175702

From<tomas@tuxteam.de>
Date2016-12-14 10:20 +0100
Message-ID<sOdTc-4EN-17@gated-at.bofh.it>
In reply to#175697
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Dec 13, 2016 at 08:54:07PM -0600, David Wright wrote:

[...]

> Eh? How does calling something by the string "wlx00c0ca364bd2" instead
> of "wlan0" make it less accessible?

Thank you! You just highlighted why I'm not staying for long in that
discussion. I'm out.

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

iEYEARECAAYFAlhRDU0ACgkQBcgs9XrR2kYAUwCaAo1RZumnlFtHNynQ8c7c17ZF
N/oAnRPeZ0iEWr1vxx+JFlWJ050g+Xp/
=/Ayf
-----END PGP SIGNATURE-----

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


#175704

FromLisi Reisz <lisi.reisz@gmail.com>
Date2016-12-14 12:20 +0100
Message-ID<sOfLk-5M6-25@gated-at.bofh.it>
In reply to#175702
On Wednesday 14 December 2016 09:13:49 tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, Dec 13, 2016 at 08:54:07PM -0600, David Wright wrote:
>
> [...]
>
> > Eh? How does calling something by the string "wlx00c0ca364bd2" instead
> > of "wlan0" make it less accessible?
>
> Thank you! You just highlighted why I'm not staying for long in that
> discussion. I'm out.


This is a) incomprehensible and b) unnecessary.  If you want out, just drop 
out.  There is no need to imply that you are in some way forced out by 
someone else's reprehensible behaviour.  Though the question to which you 
object seems fine to me.  

The answer to your question, David, is that for some of us that string is a) 
unreadable and b) totally unmemorable (since it is unreadable in the first 
place).  A non-changing name is obviously (well, it is obvious to me) a good 
idea - but I would want one that I had some hope of both reading and 
remembering.  This thread has told me how to achieve that!!  Great!

Lisi

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


#175705

From<tomas@tuxteam.de>
Date2016-12-14 12:40 +0100
Message-ID<sOg4F-5SB-9@gated-at.bofh.it>
In reply to#175704
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Dec 14, 2016 at 11:14:30AM +0000, Lisi Reisz wrote:
> On Wednesday 14 December 2016 09:13:49 tomas@tuxteam.de wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Tue, Dec 13, 2016 at 08:54:07PM -0600, David Wright wrote:
> >
> > [...]
> >
> > > Eh? How does calling something by the string "wlx00c0ca364bd2" instead
> > > of "wlan0" make it less accessible?
> >
> > Thank you! You just highlighted why I'm not staying for long in that
> > discussion. I'm out.
> 
> 
> This is a) incomprehensible and b) unnecessary.  If you want out, just drop 
> out.  There is no need to imply that you are in some way forced out by 
> someone else's reprehensible behaviour.

?

I really can't fathom how it's possible for you to interpret my words
as me "feeling forced to" whatever or as seeing any behaviour as
"reprehensible". So if I made that impression to anyone else, here's
my statement: no, I don't feel forced to anything (and leave this
thread in free will), and no, I don't think it's reprehensible for
anyone to have different tastes, opinions or whatever than I have.

I just stated that I dindn't want to extend this discussion forever,
because I consider it a matter of judgement/taste on which there
are many possible positions, but feelings are typically strong.

David's answer illustrated my point so beautifully that i had to
say thanks. It's up there for reference :-)

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

iEYEARECAAYFAlhRLgEACgkQBcgs9XrR2kYREgCeNn2YFcVaod+XxgLHmkZr8uYO
kg8An0coCKQEoHnWI9GVtoLNPHWZiXQ5
=U9Hk
-----END PGP SIGNATURE-----

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


#175708

FromLisi Reisz <lisi.reisz@gmail.com>
Date2016-12-14 13:50 +0100
Message-ID<sOhap-6vv-1@gated-at.bofh.it>
In reply to#175705
On Wednesday 14 December 2016 11:33:21 tomas@tuxteam.de wrote:
> David's answer illustrated my point so beautifully that i had to
> say thanks.

What point???

Lisi

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


#175709

FromDavid Jardine <david@jardine.de>
Date2016-12-14 14:10 +0100
Message-ID<sOhtM-6Rb-33@gated-at.bofh.it>
In reply to#175697
On Tue, Dec 13, 2016 at 08:54:07PM -0600, David Wright wrote:
[...]
> 
> When I ran machines containing two identical ethernet cards, it
> was lucky dip as to which card got which name. That alone would
> have made the new method far preferable, had it been available at
> the time.

But don't entries in 
  /etc/udev/rules.d/70-persistent-net.rules
solve this problem?

> 
[...]

Cheers,
David

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


#175710

FromBrian <ad44@cityscape.co.uk>
Date2016-12-14 15:20 +0100
Message-ID<sOizw-7tt-5@gated-at.bofh.it>
In reply to#175709
On Wed 14 Dec 2016 at 14:03:09 +0100, David Jardine wrote:

> On Tue, Dec 13, 2016 at 08:54:07PM -0600, David Wright wrote:
> [...]
> > 
> > When I ran machines containing two identical ethernet cards, it
> > was lucky dip as to which card got which name. That alone would
> > have made the new method far preferable, had it been available at
> > the time.
> 
> But don't entries in 
>   /etc/udev/rules.d/70-persistent-net.rules
> solve this problem?

Apparently not. From

 https://lists.debian.org/debian-user/2015/08/msg01083.html

  * The mechanism for providing stable network interface names changed.
    Previously they were kept in /etc/udev/rules.d/70-persistent-net.rules
    which mapped device MAC addresses to the (arbitrary) name they got when
    they first appeared (i. e. mostly at the time of installation). As this
    had several problems and is not supported any more, this is deprecated in
    favor of the "net.ifnames" mechanism.

And in

 https://lists.debian.org/debian-devel/2015/06/msg00018.html

  some 4 weeks ago I sent a first proposal to change persistent network
  interface naming away from our current
  /lib/udev/rules.d/75-persistent-net-generator.rules (which is
  inherently racy and doesn't apply to all virtualized environments) to
  udev's "net.ifnames":

-- 
Brian.

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


#175734

FromDavid Jardine <david@jardine.de>
Date2016-12-16 01:20 +0100
Message-ID<sOOpH-4ik-7@gated-at.bofh.it>
In reply to#175710
On Wed, Dec 14, 2016 at 02:14:57PM +0000, Brian wrote:
> On Wed 14 Dec 2016 at 14:03:09 +0100, David Jardine wrote:
> 
> > On Tue, Dec 13, 2016 at 08:54:07PM -0600, David Wright wrote:
> > [...]
> > > 
> > > When I ran machines containing two identical ethernet cards, it
> > > was lucky dip as to which card got which name. That alone would
> > > have made the new method far preferable, had it been available at
> > > the time.
> > 
> > But don't entries in 
> >   /etc/udev/rules.d/70-persistent-net.rules
> > solve this problem?
> 
> Apparently not. From
> 
>  https://lists.debian.org/debian-user/2015/08/msg01083.html
> 
>   * The mechanism for providing stable network interface names changed.
>     Previously they were kept in /etc/udev/rules.d/70-persistent-net.rules
>     which mapped device MAC addresses to the (arbitrary) name they got when
>     they first appeared (i. e. mostly at the time of installation). As this
>     had several problems and is not supported any more, this is deprecated in
>     favor of the "net.ifnames" mechanism.
> 
> And in
> 
>  https://lists.debian.org/debian-devel/2015/06/msg00018.html
> 
>   some 4 weeks ago I sent a first proposal to change persistent network
>   interface naming away from our current
>   /lib/udev/rules.d/75-persistent-net-generator.rules (which is
>   inherently racy and doesn't apply to all virtualized environments) to
>   udev's "net.ifnames":
> 

Many thanks for taking the trouble to enlighten this poor benighted
creature.  It is much appreciated.

Cheers,
David

[toc] | [prev] | [standalone]


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

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


csiph-web