On Thu, Jun 13, 2024 at 06:59:49AM +0200, Kamil Jońca wrote:
> to...@tuxteam.de writes:
[...]
> > and of course, if you are using a desktop environment and NetworkManager
> > or systemd-networkd, it's probably better to go with the flow and let
> > them do.
>
> About year ago none of them was ab
to...@tuxteam.de writes:
> On Thu, Jun 13, 2024 at 06:30:27AM +0200, to...@tuxteam.de wrote:
>
> [following up on myself, bad style, I know]
>
>> For my laptop, I very much prefer to say "sudo ifup eth0" than to
>> say "sudo ifup en0ps&&@*#!☠" thankyouverymuch :)
>
> and of course, if you are usin
On Thu, Jun 13, 2024 at 06:30:27AM +0200, to...@tuxteam.de wrote:
[following up on myself, bad style, I know]
> For my laptop, I very much prefer to say "sudo ifup eth0" than to
> say "sudo ifup en0ps&&@*#!☠" thankyouverymuch :)
and of course, if you are using a desktop environment and NetworkMa
I tested it
>> with mc from Ubuntu 18 and from the current Mint). File and directory
>> names on the remote Debian Testing computer containing UTF-8 Non-ASCII
>> characters are displayed incorrectly and the files and directories
>> cannot be read.
>> For example, inste
in mc. SSH in the terminal works fine. FTP Link in mc also
> works properly.
> The bug appeared today and is visible on all computers connecting to
> remote Debian Testing systems regardless of MC version (I tested it
> with mc from Ubuntu 18 and from the current Mint). File and directo
l Link in mc. SSH in the
> terminal works fine. FTP Link in mc also works properly.
> The bug appeared today and is visible on all computers connecting to remote
> Debian Testing systems regardless of MC version (I tested it with mc from
> Ubuntu 18 and from the current Mint). Fi
operly.
The bug appeared today and is visible on all computers connecting to remote
Debian Testing systems regardless of MC version (I tested it with mc from
Ubuntu 18 and from the current Mint). File and directory names on the remote
Debian Testing computer containing UTF-8 Non-ASCII character
On 15/10/2023 15:49, Erwan David wrote:
Le 15/10/2023 à 10:32, Max Nikulin a écrit :
I am curious if debian installer uses volume names in /etc/fstab when
LVM is involved (either guided or manual partitioning).
In guided partitionning, it uses the /dev/mapper name
Thank you, Erwan and
On Sun, Oct 15, 2023 at 10:32 AM Max Nikulin wrote:
>
> I am curious if debian installer uses volume names in /etc/fstab when
> LVM is involved (either guided or manual partitioning).
I'm pretty sure it does, I checked a few of my machines that I'm
reasonably sure I haven&
Le 15/10/2023 à 10:32, Max Nikulin a écrit :
I am curious if debian installer uses volume names in /etc/fstab when
LVM is involved (either guided or manual partitioning).
In guided partitionning, it uses the /dev/mapper name : here is what the
installer put in the fstab of my laptop (/boot
ng UUID or file system labels have
warnings concerning LVM.
I am curious if debian installer uses volume names in /etc/fstab when
LVM is involved (either guided or manual partitioning).
, A5, A6 and many
> others, plus the M1, M4, M5, M6.
>
> > The objects that are by their number are the exception, not the rule.
>
> There are roads whose 'numbers' I don't know but I don't know the
> 'names' of any of them except for rare exceptions s
numbers. Numbers so well known that songs are written
> about the number: historic US 66 [1], and in France the historic N7 [2],
> a vacation highway.
You asked me to justify that names are more memorable than numbers,
(and Stefan had stated that numbers can be easier to remember than
na
On Tue, 04 Jul 2023 11:33:20 +0100
"mick.crane" wrote:
> On 2023-07-03 23:34, Emanuel Berg wrote:
> > tomas wrote:
> >
> >> Or is "metric" one of these things spared by the
> >> Brexit Bonfire?
> >
> > It depends which gear your camp is since the metric system is
> > partly implemented and
jeremy ardley wrote:
> Or is "metric" one of these things spared by the
> Brexit Bonfire?
It depends which gear your camp is since the metric
system is partly implemented and partly co-exists
>>>
>>> British Standard Pipe still in use for plumbing and 1/4",
>>> 3/8" of speci
On 4/7/23 19:22, Emanuel Berg wrote:
mick.crane wrote:
Or is "metric" one of these things spared by the
Brexit Bonfire?
It depends which gear your camp is since the metric system
is partly implemented and partly co-exists
British Standard Pipe still in use for plumbing and 1/4",
3/8" of spe
mick.crane wrote:
>>> Or is "metric" one of these things spared by the
>>> Brexit Bonfire?
>>
>> It depends which gear your camp is since the metric system
>> is partly implemented and partly co-exists
>
> British Standard Pipe still in use for plumbing and 1/4",
> 3/8" of specification I forget f
On 2023-07-03 23:34, Emanuel Berg wrote:
tomas wrote:
Or is "metric" one of these things spared by the
Brexit Bonfire?
It depends which gear your camp is since the metric system is
partly implemented and partly co-exists
British Standard Pipe still in use for plumbing and 1/4", 3/8" of
spe
On Mon, 03 Jul 2023 23:34:50 +0200
Emanuel Berg wrote:
Hello Emanuel,
>Maybe the UK roads also follow a system.
They certainly did. The remnants can be seen still. Maybe wikipedia
has an article about it - I've not checked. A DDG (or other search
engine) lookup would find something.
--
Re
On Mon, 03 Jul 2023 23:33:23 +0200
Emanuel Berg wrote:
Hello Emanuel,
>days, they want their product or project to come up first if
>anyone Googles them.
What comes up first is the company with biggest wallet. Name, or
number, matters not one iota.
--
Regards _ "Valid sig separator
e, Made in China anyway ...
Here is an example of a product that have not 2 but 3 systems
(English, French and ISO). Maybe you are familiar with it,
https://dataswamp.org/~incal/bike/TIRE
But it is still not comparable since those digits say what
size the tire is, it isn't the tire vers
Brad Rogers wrote:
>> But M5 can be a bolt size and a lot of other things as well,
>
> Context! When the conversation is about roads in the UK, why
> would *anyone* think bolt size?
I agree, but that's why people have a hangup with names these
days, they want their product o
tomas wrote:
>>> But M5 can be a bolt size and a lot of other things as well,
>>
>> Context! When the conversation is about roads in the UK,
>> why would *anyone* think bolt size?
>
> Especially metric ones =:-o
Maybe the UK roads also follow a system. They were the first
guys having one, after
debian-user wrote:
>>>> No but I live in the UK and I know the A1, A2, A4, A5, A6
>>>> and many others, plus the M1, M4, M5, M6.
>>
>> But M5 can be a bolt size and a lot of other things as
>> well, while creative names may stay "more" un
On Mon, Jul 03, 2023 at 05:53:10PM +0100, Brad Rogers wrote:
> On Mon, 03 Jul 2023 18:28:49 +0200
> Emanuel Berg wrote:
>
> Hello Emanuel,
>
> >But M5 can be a bolt size and a lot of other things as well,
>
> Context! When the conversation is about roads in the UK, why would
> *anyone* think b
On Mon, 03 Jul 2023 18:28:49 +0200
Emanuel Berg wrote:
Hello Emanuel,
>But M5 can be a bolt size and a lot of other things as well,
Context! When the conversation is about roads in the UK, why would
*anyone* think bolt size?
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
On 2023-07-01 15:15, David Wright wrote:
You don't have to memorize all of Debian's codenames in order, do you?
There are about three or four in current use at any one time. (And the
release numbers might be monotonic, but they're not sequential, so
memorizing them would be just as tricky.)
Th
Emanuel Berg wrote:
> Curt wrote:
>
> >> No but I live in the UK and I know the A1, A2, A4, A5, A6
> >> and many others, plus the M1, M4, M5, M6.
>
> But M5 can be a bolt size and a lot of other things as well,
> while creative names may stay "more"
Curt wrote:
>> No but I live in the UK and I know the A1, A2, A4, A5, A6
>> and many others, plus the M1, M4, M5, M6.
But M5 can be a bolt size and a lot of other things as well,
while creative names may stay "more" unique.
But on the other hand there are many Emmas an
M1, M4, M5, M6.
>
>> The objects that are by their number are the exception, not the rule.
>
> There are roads whose 'numbers' I don't know but I don't know the
> 'names' of any of them except for rare exceptions such as 'the Great
> Nort
re are roads whose 'numbers' I don't know but I don't know the
'names' of any of them except for rare exceptions such as 'the Great
North Road'. But road numbers are mostly just labels, although there is
a kind of system for allocating them.
On Mon, Jul 3, 2023 at 4:42 AM Roger Price wrote:
>
> On Sun, 2 Jul 2023, David Wright wrote:
>
> > Perhaps more people remember the A5 is the Holyhead Road, rather than
>
> Exactly my point that inanimate objects of which there are many examples are
> best known by numbers. Numbers so well known
Roger Price (12023-07-03):
> Exactly my point that inanimate objects of which there are many examples are
> best known by numbers. Numbers so well known that songs are written about
> the number: historic US 66 [1], and in France the historic N7 [2], a
> vacation highway.
And you know which one i
On Sun, 2 Jul 2023, David Wright wrote:
Perhaps more people remember the A5 is the Holyhead Road, rather than
Exactly my point that inanimate objects of which there are many examples are
best known by numbers. Numbers so well known that songs are written about the
number: historic US 66 [1]
ng the machines.
> > > > > >
> > > > > > "It's 2023 and we're running Debian 2021. It's time to upgrade."
> > > > >
> > > > > ++
> > > >
> > > > I don't see how that works. Wh
On Sun 02 Jul 2023 at 12:08:27 (-0400), Stefan Monnier wrote:
> >> > Unlike numbers, names are memorable and unambiguous (when well-chosen).
> >> This claim is far from evident and needs justification. The only
> [...]
> > Leaving aside that Titanic is the r
is
>> concerned with allowing people to converse with memorable
>> names rather than anonymous numbers.
>
> Anecdotal evidence cuts both ways: how many years have names
> rather than numbers?
There are pieces of military equipment that have a code
designation as well as a flashy name
>> > Unlike numbers, names are memorable and unambiguous (when well-chosen).
>> This claim is far from evident and needs justification. The only
[...]
> Leaving aside that Titanic is the real name of the ship and not a
> codename, the evidence is all around you. Look no furt
gt; ++
> > >
> > > I don't see how that works. What would your codename be, instead of
> > > trixie? How do you know?
> >
> > I wouldn't care, because "2023" would be a synonym for
> > "bookworm" in all the appropriate files
It's time to upgrade."
> > >
> > > ++
> >
> > I don't see how that works. What would your codename be, instead of
> > trixie? How do you know?
>
> I wouldn't care, because "2023" would be a synonym for
> "bookworm&quo
On Sat 01 Jul 2023 at 18:00:01 (+0200), Roger Price wrote:
> On Sat, 1 Jul 2023, David Wright wrote:
>
> > Unlike numbers, names are memorable and unambiguous (when well-chosen).
>
> This claim is far from evident and needs justification. The only
> example I can think of
s what they're
> > talking about. Unlike numbers, names are memorable and unambiguous
> > (when well-chosen).
>
> AFAICT codenames are common before a project is released. They're
> much less common afterwards.
>
> > You don't have to memorize all of D
On Sat, 1 Jul 2023, David Wright wrote:
Unlike numbers, names are memorable and unambiguous (when well-chosen).
This claim is far from evident and needs justification. The only example I can
think of is project number 401 which later became the product "Titanic". However
the n
why we're upgrading the machines.
> > >
> > > "It's 2023 and we're running Debian 2021. It's time to upgrade."
> >
> > ++
>
> I don't see how that works. What would your codename be, instead of
> trixie? How do you know?
I wo
> But I can't see what's wrong with codenames. It's not just a "tradition",
> it's standard practice in most fields of endeavour. You slap a name on
> a project, and everyone knows what they're talking about. Unlike numbers,
> names are memora
++
I don't see how that works. What would your codename be, instead of
trixie? How do you know?
But I can't see what's wrong with codenames. It's not just a "tradition",
it's standard practice in most fields of endeavour. You slap a name on
a project, and everyon
>> > DO NOT USE "stable" IN YOUR sources.list FILE!
>> And this is because... ?
> Because a full release upgrade is a process that requires planning and
> execution with intent. There are many steps to follow, in order to
> maximize the chances of it actually working, and not breaking your
> syste
On Mon, 26 Jun 2023 23:06:41 -0400
Greg Wooledge wrote:
> On Mon, Jun 26, 2023 at 10:51:36PM -0400, pa...@quillandmouse.com
> wrote:
> > On Mon, 26 Jun 2023 22:10:38 -0400
> > Greg Wooledge wrote:
> >
> > > DO NOT USE "stable" IN YOUR sources.list FILE!
> > >
> > And this is because... ?
>
[
On Tue, Jun 27, 2023 at 08:51:07AM +0200, Erwan David wrote:
> Le 27/06/2023 à 05:06, Greg Wooledge a écrit :
> >
> > A lot of people who run stable releases use automatic upgrades. This
> > is a thing that will attempt to run "apt update" and "apt upgrade"
> > automatically for you in the backgr
Le 27/06/2023 à 05:06, Greg Wooledge a écrit :
A lot of people who run stable releases use automatic upgrades. This
is a thing that will attempt to run "apt update" and "apt upgrade"
automatically for you in the background.
If you use the "stable" label in your source.list file, and if you als
table to refer to the current and
> > > > previous releases
> > >
> > > This sounds good in theory, but in the sources.list file, Debian
> > > defaults to the code names, not "stable"/"testing"/"unstable".
> > > Fixing this req
On Mon, Jun 26, 2023 at 10:51:36PM -0400, pa...@quillandmouse.com wrote:
> On Mon, 26 Jun 2023 22:10:38 -0400
> Greg Wooledge wrote:
>
> > DO NOT USE "stable" IN YOUR sources.list FILE!
> >
> And this is because... ?
Because a full release upgrade is a process that requires planning and
executi
but in the sources.list file, Debian
> > defaults to the code names, not "stable"/"testing"/"unstable".
> > Fixing this requires a manual edit.
>
> DO NOT USE "stable" IN YOUR sources.list FILE!
>
> EVER!!
>
> G!!!
>
On Mon, Jun 26, 2023 at 09:53:33PM -0400, pa...@quillandmouse.com wrote:
> > * Stable/OldStable/OldOldStable to refer to the current and previous
> > releases
>
> This sounds good in theory, but in the sources.list file, Debian
> defaults to the code names, not "s
On Mon, 26 Jun 2023 21:01:17 +0200
Nicolas George wrote:
[snip]
> Twenty five years ago I started naming my computers after the
> characters in an obscure French sci-fi duology. The names are still
> pretty much unique, but I have had trouble finding names for new
> boxes, especia
On Mon, 26 Jun 2023 17:04:57 +0100
Darac Marjal wrote:
>
> On 26/06/2023 09:18, Roger Price wrote:
> > I have difficulty remembering the Debian code names for releases
> > Buzz Rex Bo Hamm Slink Potato Woody Sarge Etch Lenny Squeeze Wheezy
> > Jessie Stretch Buster Bull
On Mon, Jun 26, 2023 at 4:45 PM Dan Ritter wrote:
>
> riveravaldez wrote:
> > It would be possible, as an alternative, to populate sources.list with
> > '2021',
> > for instance, instead of 'bullseye', 'bookworm', etc.?
> >
> > We could have something like, 'Debian 2023 - Bookworm', so, preservin
riveravaldez wrote:
> It would be possible, as an alternative, to populate sources.list with '2021',
> for instance, instead of 'bullseye', 'bookworm', etc.?
>
> We could have something like, 'Debian 2023 - Bookworm', so, preserving
> tradition, but allowing '2023' to be used as an alternative re
On 6/26/23, Nicolas George wrote:
> ghe2001 (12023-06-26):
> (...)
> What works for Ubuntu is that their version numbers are really the year.
> We know what year we are in, usually.
It would be possible, as an alternative, to populate sources.list with '2021',
for instance, instead of 'bullseye',
On 27/06/2023 03:40, Kent West wrote:
Code-names are awesome. I prefer them to be something like "First" or
"Secundo" or "Twelve"
The wallpaper for Ubuntu Hardy Heron was exquisite.
--
Ash Joubert (they/them)
Director / Game Developer
Transient Software
On Mon, Jun 26, 2023 at 06:33:37PM +0200, Roger Price wrote:
> On Mon, 26 Jun 2023, Darac Marjal wrote:
>
The reason for Debian using code names - and it was one of the first Linux
distributions to use code names routinely - was very simple.
Debian 1.0 never happened. InfoMagic took a c
ghe2001 (12023-06-26):
> I've been using Debian for some 20 years, and I've had the impression
> that Ian started with the major characters in Toy Story and the names
> have moved toward the minor ones (no proof, just an impression).
That is the problem with major characters,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I've been using Debian for some 20 years, and I've had the impression that Ian
started with the major characters in Toy Story and the names have moved toward
the minor ones (no proof, just an impression). I'm sure it seemed to be
On Mon, 26 Jun 2023, Darac Marjal wrote:
As you can see, the intention of code names is so that developers
(of Debian) have a way to refer to an as-yet-unreleased collection of
packages. Once those set of packages are released (literally, put out there
in the wild), then they become a
On Mon, Jun 26, 2023 at 12:21 PM Charles Curley
wrote:
>
> On Mon, 26 Jun 2023 17:04:57 +0100
> Darac Marjal wrote:
>
> > OK, a question back at you, then: Why do you feel the need to
> > remember Debian codenames?
>
> Imprimis: Because you use the code names as
On Mon, 26 Jun 2023 17:04:57 +0100
Darac Marjal wrote:
> OK, a question back at you, then: Why do you feel the need to
> remember Debian codenames?
Imprimis: Because you use the code names as part of configuring
systems, e.g. in /etc/apt/sources.list
Secundus: Because some utiliti
On 26/06/2023 09:18, Roger Price wrote:
I have difficulty remembering the Debian code names for releases Buzz
Rex Bo Hamm Slink Potato Woody Sarge Etch Lenny Squeeze Wheezy Jessie
Stretch Buster Bullseye Bookworm Trixie and Forky.
It's much easier to remember that release numbers are
On 2023-06-26 at 11:40, Kent West wrote:
> On Mon, Jun 26, 2023 at 10:29 AM Arno Lehmann wrote:
>
>>
>> Also, I struggle with the names, always need to go to the project web
>> page or wikipedia if I need to look up which version has which name, and
>> it
> Also, I struggle with the names, always need to go to the project web page
> or wikipedia if I need to look up which version has which name, and it's
> always a nuisance.
>
> A small one, though. Also, I really like the Debian project, its resulting
> software collectio
On Mon, Jun 26, 2023 at 10:29 AM Arno Lehmann wrote:
>
> Also, I struggle with the names, always need to go to the project web
> page or wikipedia if I need to look up which version has which name, and
> it's always a nuisance.
>
>
>
Code-names are awesome. I prefer
Hi all,
I have read a few replies here.
I am in no way affiliated with those people who originally introduced
the names or assign them now.
The only real answer to the actual question that I can see is "It's a
tradition".
Also, I struggle with the names, always need to go
On Monday, June 26, 2023, Charles Curley
wrote:
> On Mon, 26 Jun 2023 10:18:30 +0200 (CEST)
> Roger Price wrote:
>
>> Is there some reason why Debian still continues to invent and use
>> code names?
>
> At least use some sequence of code names with an order to them.
&
On Mon, 26 Jun 2023 10:18:30 +0200 (CEST)
Roger Price wrote:
> Is there some reason why Debian still continues to invent and use
> code names?
At least use some sequence of code names with an order to them.
Ubuntu's code names are in alphabetical order. Maybe the names of
t
On Mon, Jun 26, 2023 at 10:18:30AM +0200, Roger Price wrote:
> I have difficulty remembering the Debian code names for releases Buzz Rex Bo
> Hamm Slink Potato Woody Sarge Etch Lenny Squeeze Wheezy Jessie Stretch
> Buster Bullseye Bookworm Trixie and Forky.
>
> It's much eas
On Mon, Jun 26, 2023 at 4:18 AM Roger Price wrote:
>
> I have difficulty remembering the Debian code names for releases Buzz Rex Bo
> Hamm Slink Potato Woody Sarge Etch Lenny Squeeze Wheezy Jessie Stretch Buster
> Bullseye Bookworm Trixie and Forky.
>
> It's much easier t
I have difficulty remembering the Debian code names for releases Buzz Rex Bo
Hamm Slink Potato Woody Sarge Etch Lenny Squeeze Wheezy Jessie Stretch Buster
Bullseye Bookworm Trixie and Forky.
It's much easier to remember that release numbers are in a sequence 1.1 ... 14.
Quoting from Goo
20.06.23, 08:36 +0200, Rick Thomas:
I've been upgrading my machines Bullseye => Bookworm recently. In a few of these
upgrades, the name of the ethernet device changed. (E.g. enP2p32s15f0 =>
enP2p0s15f0) This required changes to /etc/network/interfaces in order to start up
the interface.
T
I've been upgrading my machines Bullseye => Bookworm recently. In a few of
these upgrades, the name of the ethernet device changed. (E.g. enP2p32s15f0 =>
enP2p0s15f0) This required changes to /etc/network/interfaces in order to
start up the interface.
This is only a minor inconvenience (thou
king Raspberry Pis.
Not so sure what to do with other systems that have multiple
interfaces. My file server has three, router has four or four and a half
since there's an LTE module which presents as "kinda" ethernet. On the
router especially my firewall rules depend on interface names.
gt; Some NICs can have their MAC addresses changed permanently.
>
> There were at least a few terrible NICs in history where an
> entire production run got the same MAC address assigned.
>
> Most NICs can have their MAC addresses reassigned after boot,
> which will almost always
On Thu, Mar 31, 2022 at 08:04:13AM -0400, Michael Stone wrote:
> On Thu, Mar 31, 2022 at 07:10:33AM +0200, to...@tuxteam.de wrote:
> > Somewhat self-referential. I'm not the one getting worked up here ;-)
>
> And I'm not the one accusing people of lying.
I hope my clarification --uh-- clears thin
On Thu, Mar 31, 2022 at 12:39:37PM +0100, Brian wrote:
> On Thu 31 Mar 2022 at 07:28:47 +0200, to...@tuxteam.de wrote:
>
> [...]]
>
> > Since then, I learnt that I like to relax call my interfaces
> > "eth0" and "wlan0".
> >
> > Can we still be friends?
>
> Of course! After all, we are both pla
On Thu, Mar 31, 2022 at 07:10:33AM +0200, to...@tuxteam.de wrote:
Somewhat self-referential. I'm not the one getting worked up here ;-)
And I'm not the one accusing people of lying.
On 2022-03-31 at 01:28, to...@tuxteam.de wrote:
> This is one weakness I see with freedesktop often. They try to
> fight complexity with ever more complexity, with the end result
> of a more user-unfriendly (because less understandable) system.
Very well expressed. I've added that to the "complet
On Wed, Mar 30, 2022 at 05:56:47PM -0500, Nicholas Geovanis wrote:
Because some of us work in corporate data centers. And everything you claim
that helps us here really does the opposite. Because it was introduced in large
part to support mobile computing. Which does not and will never be valuabl
On Thu 31 Mar 2022 at 07:28:47 +0200, to...@tuxteam.de wrote:
[...]]
> Since then, I learnt that I like to relax call my interfaces
> "eth0" and "wlan0".
>
> Can we still be friends?
Of course! After all, we are both playing in the same game.
--
Brian.
31.03.22, 13:01 +0200, Sven Hartge:
Greg Wooledge wrote:
unicorn:~$ cat /etc/systemd/network/10-lan0.link
[Match]
MACAddress=18:60:24:77:5c:ec
[Link]
Name=lan0
Careful with that one. If you use VLANs then you suddenly get multiple
interface with the same MAC and strange things will happe
Greg Wooledge wrote:
> unicorn:~$ cat /etc/systemd/network/10-lan0.link
> [Match]
> MACAddress=18:60:24:77:5c:ec
> [Link]
> Name=lan0
Careful with that one. If you use VLANs then you suddenly get multiple
interface with the same MAC and strange things will happen, because it
matches for all of
t; > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > > > as I can read here [1] network names should be stable.
> > > > > (Stable interface names even when hardware is added or removed)
> > > >
> > > > > [1]
> > > &g
sively worked up over things like interface names and
> like to throw around strong words for dramatic effect. Just ignore the
> noise.
Somewhat self-referential. I'm not the one getting worked up here ;-)
Let's not quarrel over it. You like your predictable names. I like
mine. Let&#
On Wednesday, 30 March 2022 18:31:36 EDT Michael Stone wrote:
> On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:
> >It's like you haven't even read this thread.
>
> of course I have
>
> >Predictable interface names *do* sometimes change. And when
> Some people get excessively worked up over things like interface names
> and like to throw around strong words for dramatic effect. Just ignore
> the noise.
I've just come to accept that the actual interface name is going to be some
bizarre name. So I look it up, and then prom
On Wed, Mar 30, 2022, 5:32 PM Michael Stone wrote:
> On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:
> >It's like you haven't even read this thread.
>
> of course I have
>
> >Predictable interface names *do* sometimes change. And when that hap
On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:
It's like you haven't even read this thread.
of course I have
Predictable interface names *do* sometimes change. And when that happens,
it's a huge deal, because all of the configuration files are set up f
ke you haven't even read this thread.
Predictable interface names *do* sometimes change. And when that happens,
it's a huge deal, because all of the configuration files are set up for
the old name. Things break, in an extremely visible way.
This is not some theoretical issue. This is real.
On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote:
Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?
Some people get excessively worked up over things like interface names
and like to throw around strong words for
On Wed 30 Mar 2022 at 21:50:53 +0200, to...@tuxteam.de wrote:
> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> >
> > > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > >
ed "rl0", regardless
of whether it's detected before or after an Intel PRO/100, which is
claimed by the fxp driver and named "fxp0".
As long as there's only one interface claimed by each driver, there will
never be any unpredictability in the names.
I'm not su
; > <https://utcc.utoronto.ca/~cks/space/blog/linux/PCINamesNotStable> which
> > goes into some detail.
>
> Thanks. Very informative. As the second link says:
>
> The resulting reality is that your PCI based names are only
> stable if you change no hardware in t
On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
>
> > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > as I can read here [1] network names should be stable.
> > > (Stable interface nam
1 - 100 of 1366 matches
Mail list logo
