Distribution quotes of the week

[Posted December 3, 2014 by ris]

In other words, the way I choose to look at this GR is that the project as a whole just voted to take away the sticks that we were using to beat each other with.

-- Russ Allbery (Thanks to Paul Wise)

This has long been the case. However, if it explains _why_, I forget, for the same reason that this never works. (Yeah yeah whatever, I just want to install my system now and keep using "godmode" as my root password just like I always have so I don't forget it.)

-- Matthew Miller

tl;dr it's a mess, sorry about that. Stable output naming isn't something that any of our desktop environments care about, afaik, so it's not something I'd ever see as a regression. In a sense, noticing this level of implementation detail is the price you pay for choosing not to run something that gets it right for you. [2]

[2] - And Linux, as we know, is all about choice.

-- Adam Jackson

On 2 December 2014 at 09:15, <jfm512-at-free.fr> wrote:

> 2) It has an uninspiring installer.

Ok I need more information on what this means in comparison to what? I have installed pretty much every major Linux distribution and I have never found any one of them 'inspiring'. Even the Ubuntu one is more of "well at least its not the base Debian installer" versus "OMG I am alive and free because of this installer."

-- Stephen John Smoogen

Distribution quotes of the week

Posted Dec 4, 2014 11:59 UTC (Thu) by xz (guest, #86176) [Link] (56 responses)

Note that Adam Jackson is the author of the famous post http://islinuxaboutchoice.com/ (obviously he meant no).

The naming issue quoted here is far from being a mess (VGA0 -> VGA-0), but something similar has been going on with systemd's naming of network interface where usb0 becomes something like enp0s29u1u1u5. And from day to day there is a greater urge in making everything's name a UUID. Note the pattern and these seem to be based on the rationale that the user should no longer interact with certain interface that has been decided to be an implementation detail in exchange for some other advantages.

On a higher level, this is consistent with the unifying approaches from freedesktop people towards an integrated, tightly coupled, "modern" operating system by reducing the user's control over the system (starting with less readable names, then binary logs, then binary configurations) and ability of total customization and flexibility (hidden interfaces, strong interdependencies, deep abstraction), with the users being reduced to consumers. All in the name of creating a "product" that "works well" for "users".

The argument about whether Linux is about choice is not really interesting beyond being an argument of might makes right (we are going to do this, accept it or do your own). Historically Linux has not been meant to be one single thing that works in a single purpose. It is a bunch of extremely high quality building blocks which evolve from years of harsh natural selection. This might seems a disorganized anarchical pile of mess. But it is the strength of Linux to have more than one True Way in every aspects. And this is why Linux has attracted people in technical fields. Linux is a construction site with lots of scaffolding with lots of things being built really quickly and easily. Once you tear away the scaffolding, not much can be done anymore.

If creating a "product" that "works well" for "users" is the end, Linux desktop will still never be able to compete with products by say, Apple, because things that matter a whole lot more are UI/UX design, marketing, and customer services instead of discipline and rigor in software engineering. It still has to compete, but let us not forget where the competence comes from and what it is leveraging upon.

Distribution quotes of the week

Posted Dec 4, 2014 12:31 UTC (Thu) by peter-b (guest, #66996) [Link] (51 responses)

> The naming issue quoted here is far from being a mess (VGA0 -> VGA-0), but something similar has been going on with systemd's naming of network interface where usb0 becomes something like enp0s29u1u1u5.

First of all, this is udev, not systemd.

Second of all, this actually solves a real problem that I have had on one of my systems at home with two network cards. Approximately 75% of the time card A would get eth0; approximately 25% card B would get eth0. Given that A was the system's DMZ interface and B was its internal interface, this was a pretty big damn problem and one that was solved permanently by the enhancement to udev.

I feel like the prevalence of "it's not a problem for me therefore it's not a problem" attitudes in the community are an increasingly serious problem, and I can't help but wonder whether it's related to other similar trends in Western society (more conservative politics, decreasing enthusiasm for socialised welfare and humanitarian programmes, NIMBYism and BANANAism, etc.)

Distribution quotes of the week

Posted Dec 4, 2014 13:15 UTC (Thu) by mikapfl (subscriber, #84646) [Link] (24 responses)

I completely see your point and do think that stable or otherwise more useful naming is important and a good thing(TM), even if it leads to longer/less readable names. However, I think the "mostly-working shorthands" could and should be preserved. A perfect example of things working correctly for all usecases I know is storage device naming in linux:

* /dev/{s,h,v}d{a,b,c,d…} are shorthands and even mostly stable (for sata or IDE devices connected at boot, I have almost always ended up with the same names). This makes people happy who do not want to type much, will not learn anything new (they were shocked by the sda->hda switch (-; ) and have sufficiently stable configurations that these names just work.

* /dev/disk/by-{id,uuid,path,name,…}/* are useful, stable names which I prefer for almost all purposes, because I can connect the same sata disk internally or with a usb-sata-adaptor externally or whatever (or even just insert two usb storage devices at the same time) and get a stable name, and do not "dd if=/dev/null of=/dev/sdb" nuke the wrong device.

Note how you can have both - stable, descriptive, (long) names and traditional names, which might even be preferable for the "I have one disk and never more and I want to mount it!" use case (which might well be the majority of linux systems).

Cheers,

Mika

Distribution quotes of the week

Posted Dec 4, 2014 13:24 UTC (Thu) by mchapman (subscriber, #66589) [Link]

> However, I think the "mostly-working shorthands" could and should be preserved.

Luckily for you, you're just one small symlink away from achieving that. Either:

ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

or:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

depending on your Udev version.

Distribution quotes of the week

Posted Dec 4, 2014 13:27 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (17 responses)

Please speak for yourself. Yes, as long as there is one disk, one Ethernet port, and so on, everything works just fine with the legacy setup. Throw in two of each, and things break horribly at the worst possible times. I.e., my "server" machine (stuffed away somewhere not readily accessible) one fine boot (remote, kernel and assorted userland updates had accumulated) decided to switch its two disks around, ditto with the network interfaces. Required a trip (and much headscratching) one fine sunny Saturday afternoon to find out what was wrong and fix it. Not funny.

Persistent device names

Posted Dec 4, 2014 15:45 UTC (Thu) by itvirta (guest, #49997) [Link] (11 responses)

Debian has /etc/udev/rules.d/70-persistent-net.rules which basically locks the ethX numbers in
place using the MAC address every time it sees new interfaces. I thought something like that would have been universal by now?

I don't know about disks, since the everyday consumer SATA-stuff I've had seem to always detect
the drives in the same order the physical ports are.

Persistent device names

Posted Dec 4, 2014 17:08 UTC (Thu) by raven667 (subscriber, #5198) [Link] (9 responses)

That is pretty universal but one of the problems the persistent udev rule creates is that if you replace an interface, even though it is in the same physical port, it has a new MAC address and so you might lose connectivity to the host while you get on the console and rename the interface and clear out the old MAC to device name mapping. This happens a lot when cloning virtual systems. This is also not the only place interface names can be defined, there is another biosdevname tool which can read the firmware, if there is a canonical name encoded there then the device can get a consistent name even if it is replaced and the MAC changes, systems with 4-port LAN-on-Motherboard interfaces tend to get stable em1-4 names which correspond to the labels on the back.

There is a whole hierarchy of rules which are used to create stable names, only the last fallback is to encode the bus and slot number. For some reason I want to say that the bus and slot convention was taken from some other UNIX but I'm not sure which one.

Persistent device names

Posted Dec 4, 2014 19:01 UTC (Thu) by itvirta (guest, #49997) [Link]

I was going to say that if you change the NIC, it's not going to be the same physical port anymore
and the system is correct not to make any assumptions about which NIC replaces which.
If the MAC addresses are all it has, that is.
A pedant might argue that a VM NIC doesn't have a physical port to begin with. ;)

But yeah, that's a valid case, though it can probably be fixed with a quick run through the virtual
console, and/or automated with a script. (brute force solution: nuke the saved MACs and reboot)

Persistent device names

Posted Dec 4, 2014 19:16 UTC (Thu) by dlang (guest, #313) [Link] (7 responses)

> That is pretty universal but one of the problems the persistent udev rule creates is that if you replace an interface, even though it is in the same physical port, it has a new MAC address and so you might lose connectivity to the host while you get on the console and rename the interface and clear out the old MAC to device name mapping.

it gives it a new ethX number, it doesn't re-use an existing one.

This is annoying, but how in the world is the system (any system, including systemd) supposed to know how a new interfact that shows up is wired?

If you have a system with predictable boot ordering, you just disable the persistent udev rules (which is what I did on my servers, for exactly this problem), but if you have a system that doesn't have predictable boot ordering (like one with multiple USB NICs), you are going to have to lock the names down based on a characteristic of the interfaces, and when you add a new interface, it's not going to match whatever rules you have defined.

Wrong kind of port?

Posted Dec 4, 2014 20:34 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (5 responses)

Perhaps I'm being too obvious, or perhaps you're thinking about the "same port" in the wrong way. I don't think the idea is that Linux should detect which Ethernet port on a switch it is plugged into ‡

Surely if I unplug a USB WiFi stick from the hub on top of my mother's PC and then plug in a different USB WiFi stick in the same port of the same hub, the kernel knows that, right? It can certainly tell it's not a PCI device plugged into the motherboard, and so far as I can see it can also see that it's plugged into that particular hub based on how USB works.

So we certainly can in principle write a rule that says "The WiFi stick plugged into the USB hub that's plugged into a USB socket we'll arbitrarily label '#3' is in the DMZ, no matter if I replace that USB stick (they drop dead sometimes, I guess because they're cheaply made)

And I don't see any reason (though I don't have a POC in front of me) why we can't do the same for PCI, or perhaps most relevantly for virtio. Surely there's a way to tell one virtio network device apart from the next, so we should be able to use that to say "Ignore the MAC address, we want _that_ virtio device" in the same way you can certainly say "Ignore the disk serial number, we want _that_ virtio storage device".

‡ If we did want this, and all the switches involved are smart, I think it's actually possible but maybe only with some network cards. Smart switches have a MAC per port, and are willing to talk to other switches about the topology of the network using MACs to uniquely identify each port in the system. I suspect Linux could choose to listen in to this chatter passively and detect which port it's on (although not whether a dumb switch was intermediary between it and the nearest smart switch) and perhaps it could actively interrogate the network.

Wrong kind of port?

Posted Dec 4, 2014 20:47 UTC (Thu) by dlang (guest, #313) [Link] (4 responses)

I've seen people claim that you can do this, but I've also seen people on the kernel list talking about how you can't predictably a USB device if you have multiple devices that don't have a serial number, MAC address or other unique identifier.

Wrong kind of port?

Posted Dec 4, 2014 21:02 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (2 responses)

That's the _opposite_ problem though, surely? The kernel devs are saying that if I unplug my cheap no-name no-serial keyboard, and then plug in a _different_ (say, maybe it's bright red) cheap no-name no-serial keyboard the kernel can't tell it isn't just the same keyboard as before.

And that is painfully obvious once you know USB serial numbers are optional and cost somebody an extra penny on a product they're selling at the factory gate for a dollar yet probably not one customer in a million cares if they're present. In fact the kind of factories producing the cheapest USB devices don't even put real MACs in their network devices. They pick a random number, hopefully one belonging to their parent company but it could just as well belong to some hapless iMac or Cisco router, and they burn that into every single device to save money. Most customers will never know, until they love the product so much they buy another one and their switch loses its mind...

Wrong kind of port?

Posted Dec 4, 2014 21:08 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

replace keyboards with serial dongles and you have a real problem. Which serial cable is connected to which device?

As I understand it, some USB NICs don't have any MAC address on the NIC, it's set by the driver.

Wrong kind of port?

Posted Dec 5, 2014 9:47 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Which part of what I wrote didn't you understand? Although Linux can't tell one dongle from another (as you wrote) it can tell which dongle is plugged into which port (as I wrote).

To a human this means Linux can't necessarily do "The red dongle is the DMZ" (because the "red" dongle may have no unique characteristics that Linux can determine from inside the box) but it can do "the dongle plugged into the right-most port is the DMZ" because that's just a matter of topology.

Wrong kind of port?

Posted Dec 4, 2014 21:11 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

I'm sure I've corrected you on this before. USB provides stable topology. But if you swap two arbitrary shitty USB devices, the kernel has no way of knowing that they've been swapped - you can only bind policy to the port, not to the device.

Persistent device names

Posted Dec 4, 2014 21:12 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> it gives it a new ethX number, it doesn't re-use an existing one.

If you are falling back to the physical topology based name then a new interface in the same slot would get the same name, PCI slot 1 port 1 would be p1p1 even after swapping adapters, if you swapped a dual port NIC in for a single port, you'd have p1p1 and p1p2 but that wouldn't affect an interface in another slot like p2p1.

Persistent device names

Posted Dec 11, 2014 18:20 UTC (Thu) by farnz (subscriber, #17727) [Link]

It tries to. Unfortunately, on one of my systems, it mostly brought up the two devices as "eth0" and "eth1", except when it hit an awkward race, and renamed them to "eth0_rename" and "eth0". As "eth0_rename" was the device my scripts thought of as "eth0" and "eth0" was the device they saw as "eth1", hilarity ensued.

Now, you could blame the kernel for this, because the trigger was an upgrade to a kernel that probed the two devices in parallel, but the kernel change was for good reasons.

Distribution quotes of the week

Posted Dec 4, 2014 17:48 UTC (Thu) by zev (subscriber, #88455) [Link] (4 responses)

LVM solves this problem nicely for disks, using UUIDs (that the user/administrator rarely if ever has to deal with) to automatically assemble volume groups and logical volumes with human-friendly names. Using a human-unfriendly bus/slot/port-based scheme for user-facing names seems decidedly inferior to me.

Distribution quotes of the week

Posted Dec 4, 2014 18:38 UTC (Thu) by cortana (subscriber, #24596) [Link]

Unfortunately, network device names are limited to 15 characters, and don't have a feature to allow aliases to be created, in a way that would be analagous to how /dev/disk/by-*/* symlinks may be created pointing to the real /dev/sd* device files.

And if you knew anything about udev's Predictable Network Interface Names <http://www.freedesktop.org/wiki/Software/systemd/Predicta...> scheme then you would know that user-friendly names provided by firmware (e.g., "eno1" which is even printed on my chassis above the ethernet port" take precedence to the topology-based names such as "enp1s2" (which I really don't find any less user-friendly than a label "eth0" which refers to a different physical network interface every time I reboot my machine).

Distribution quotes of the week

Posted Dec 4, 2014 19:19 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

and UUIDs have a similar problem. You can't just clone a drive any longer or the system gets confused. If you replace one drive with another, the UUIDs aren't going to match and the system won't know what to do with it.

The great thing here is that this is useful for some people, and others are still free to ignore it and mount by path when that works better for them.

Distribution quotes of the week

Posted Dec 5, 2014 9:43 UTC (Fri) by Seegras (guest, #20463) [Link] (1 responses)

> and UUIDs have a similar problem.

Yes, ever had a split-raid1-problem? Two disks with filesystems on them, with all the UUIDs the same. Fun...

Distribution quotes of the week

Posted Dec 12, 2014 0:01 UTC (Fri) by Wol (subscriber, #4433) [Link]

:-)

That bug has been fixed now, but yes, I've had it ... three drives, two arrays, 1 UUID ...

Cheers,
Wol

Distribution quotes of the week

Posted Dec 4, 2014 18:31 UTC (Thu) by cortana (subscriber, #24596) [Link] (2 responses)

> Note how you can have both - stable, descriptive, (long) names and traditional names, which might even be preferable for the "I have one disk and never more and I want to mount it!" use case (which might well be the majority of linux systems).

But you're talking about disks. The stable names are provided with symlinks. Network interfaces don't live in the filesystem, and you can't create a symlink to point to them.

Now, personally I'd love to see a /dev/eth0 with an (in my case) /dev/eno1 pointing to it. Are you volunteering to step up and unify network devices with traditional block/character devices?

Distribution quotes of the week

Posted Dec 5, 2014 2:11 UTC (Fri) by mikapfl (subscriber, #84646) [Link] (1 responses)

Hi,

yeah, I suspected that network interfaces can't have symlinks, which is a pity but there is probably a good reason for that.
And I fear I don't have the resources to (learn to) unify network devices with traditional block/character devices.

If we can't have old-style ethX and stable names at the same time due to this, I'll of course always side with stable, predictable, useful names instead of some ethX scheme just because of tradition.

Cheers,

Mika

Distribution quotes of the week

Posted Dec 5, 2014 4:30 UTC (Fri) by raven667 (subscriber, #5198) [Link]

> yeah, I suspected that network interfaces can't have symlinks, which is a pity but there is probably a good reason for that.

Hahaha, what an optimist. A lot of things in Unix were designed they way they were for all sorts of reasons but not all of them were good, many were just day to day challenges fixed in the quickest way that ended up as infrastructure. Network interfaces clearly don't follow any Unix paradigm.

Distribution quotes of the week

Posted Dec 4, 2014 18:33 UTC (Thu) by cortana (subscriber, #24596) [Link] (1 responses)

(Sorry, meant to add this to my previous message.)

> /dev/{s,h,v}d{a,b,c,d…} are shorthands and even mostly stable (for sata or IDE devices connected at boot, I have almost always ended up with the same names)

I wonder if anyone has ever been screwed over by an /etc/crypttab entry; "swap0 /dev/sda2 /dev/urandom swap,cipher=...,hash=...,size=..." will happily blindly overwrite whatever already exists on that partition; so if you boot up one day with sda and sdb transposed, you can kiss your vital data goodbye...

Distribution quotes of the week

Posted Dec 4, 2014 19:45 UTC (Thu) by alankila (guest, #47141) [Link]

I've not experienced this myself, but I remember that I saw crypttab do this and disabled it with an almost audible scream. This is a very dangerous way to handle swap device. Why can't the kernel do encryption but keep the swap accessible by a fixed uuid? Just generate a random key and then encrypt and decrypt pages as they go in and out of swap without involving some damn whole-device encryption layer.

Distribution quotes of the week

Posted Dec 4, 2014 19:12 UTC (Thu) by dlang (guest, #313) [Link] (25 responses)

> First of all, this is udev, not systemd.

since udev is part of systemd, what's the difference?

> Second of all, this actually solves a real problem that I have had on one of my systems at home with two network cards. Approximately 75% of the time card A would get eth0; approximately 25% card B would get eth0

you've been able to configure eth0/eth1 based on the MAC address in udev for years (prior to it being merged into systemd)

Distribution quotes of the week

Posted Dec 4, 2014 20:09 UTC (Thu) by peter-b (guest, #66996) [Link] (4 responses)

>> Second of all, this actually solves a real problem that I have had on one of my systems at home with two network cards. Approximately 75% of the time card A would get eth0; approximately 25% card B would get eth0

> you've been able to configure eth0/eth1 based on the MAC address in udev for years (prior to it being merged into systemd)

No shit. And that's exactly how I fixed it once I figured out what the problem was.

When I last upgraded it I didn't need to manually tinker with the udev configuration any more -- it Just Works Out Of The Box, which is great and I'm very happy about it.

Distribution quotes of the week

Posted Dec 4, 2014 20:44 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

with debian, this was 'fixed' (worked out of the box with no manual effort needed) back in the 3.x days without needing systemd or funny named interfaces.

Distribution quotes of the week

Posted Dec 4, 2014 21:06 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (2 responses)

A subset of the problem was fixed - an installed system wouldn't usually change interface names, but:

a) two identical pieces of hardware weren't guaranteed to have eth0 be the same port
b) replacing a system motherboard would change all your interfaces names

Distribution quotes of the week

Posted Dec 4, 2014 21:10 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

but in this case, the system is never going to reliably know what to do. systemd isn't going to be any more reliable in picking which one to name what when the devices in question have never been seen before (such as when you replace all the NICs in a system)

Distribution quotes of the week

Posted Dec 4, 2014 21:13 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

That's… the entire point of this feature. The interface name is defined by bus topology, and as such it'll be the same even across motherboard swaps.

Distribution quotes of the week

Posted Dec 4, 2014 23:03 UTC (Thu) by barryascott (subscriber, #80640) [Link] (19 responses)

We support mother boards with two ethernet interfaces and only the interface on the left is used.

Without the unique names p1p1 etc it is not possible to know which nic is on the left.

We do not want to edit the mac address in a udev rule on every install manually. That would be a tedius and error prone waste of time.

Distribution quotes of the week

Posted Dec 5, 2014 0:38 UTC (Fri) by dlang (guest, #313) [Link] (18 responses)

If the system always enumerates the interfaces in a predictable way, eth0/eth1 are valid names

If the system doesn't, then p1p1 isn't going to be any more reliable than eth0

Distribution quotes of the week

Posted Dec 5, 2014 0:51 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (17 responses)

PCI bus topology doesn't change. Order of driver binding does. One of these naming schemes is based on something that doesn't change and the other is based on something that does change. Which do you think is going to be more reliable?

Distribution quotes of the week

Posted Dec 5, 2014 1:21 UTC (Fri) by dlang (guest, #313) [Link] (16 responses)

I actually ran into that problem at one point. It only happens if your motherboard has different chipsets on it, which is a pretty unusual case.

When I ran into it, there were a pair of Gig-E ports and a 100M port intended for management. Given the decreased cost of gig-e parts, this is something that you are unlikely to run into.

And if it's an add-on card, the PCI topology can change (the card gets installed in different ports)

Distribution quotes of the week

Posted Dec 5, 2014 1:40 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (15 responses)

> I actually ran into that problem at one point. It only happens if your motherboard has different chipsets on it, which is a pretty unusual case.

Cool. So you admit that it wasn't fixed back in Debian 3.x?

(I disagree about this being an unusual case, given how many people are deploying 10G ethernet)

Distribution quotes of the week

Posted Dec 5, 2014 4:22 UTC (Fri) by dlang (guest, #313) [Link] (14 responses)

I ran into back in the debian 3.x days (if not earlier, I don't remember exactly)

But having different chipsets on the motherboard (as opposed to having some 10G add-in cards with gig-e on the motherboard) is fairly rare. And even if you have this situation, a kernel upgrade that changed the driver load ordering would not change the interface names on a debian box.

I opted to disable the persistant naming in udev because my hardware had stable ordering (except for the one kernel upgrade) and so it was far more likely that I would have a NIC failure and have to swap out a card than to have the names show up in the wrong order.

So I will still say thatthis problem is solved in all but the very odd corner cases, so you shouldn't force everyone to deal with new, location based names just because it makes sense for a few cases.

didn't we learn from the hard drive situation that it makes far more sense for drives to be /dev/sdX instead of having different names depending on what type of card they are attached to and similar nonsense? (I'm not just talking sda vs hda, but all the strange names that would show up when connected to higher end RAID cards)

having topology based names helps experts in a few cases, but it hurts everyone most of the time, and really wrecks phone support for inexperienced people (imagine trying to talk someone through figuring out what nic is called what over the phone)

Distribution quotes of the week

Posted Dec 5, 2014 6:00 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (13 responses)

> But having different chipsets on the motherboard (as opposed to having some 10G add-in cards with gig-e on the motherboard) is fairly rare.

What does that have to do with anything? If I order 100 machines with 10G cards from a vendor, they'll all come in the same slot.

> And even if you have this situation, a kernel upgrade that changed the driver load ordering would not change the interface names on a debian box.

But will do nothing to ensure that the ordering is stable between different machines, even if the hardware is identical. Reinstalling on the same machine may trigger a change. And swapping the motherboard but using the same image is guaranteed to change the names.

> I opted to disable the persistant naming in udev because my hardware had stable ordering (except for the one kernel upgrade)

Other than this one time that you saw this exact problem, nobody ever sees this problem?

> didn't we learn from the hard drive situation that it makes far more sense for drives to be /dev/sdX instead of having different names depending on what type of card they are attached to and similar nonsense?

No? More drivers have started using the scsi layer and so have ended up with sd* naming, but the common pattern in drivers that don't is still to use custom names.

> having topology based names helps experts in a few cases

Probably more cases than people adversely affected by journald's effect on syslog performance.

You continue to rail against changes solve problems you don't care about, but you make zero effort to actually educate yourself about these problems. You repeatedly make factually incorrect statements to justify your position. You do this even when you've been corrected in the past. The change in interface naming solves real problems that affected real people in the real world, which is why distributions adopted it.

Distribution quotes of the week

Posted Dec 5, 2014 6:38 UTC (Fri) by dlang (guest, #313) [Link] (12 responses)

> What does that have to do with anything? If I order 100 machines with 10G cards from a vendor, they'll all come in the same slot.

that doesn't match my experience.

> More drivers have started using the scsi layer and so have ended up with sd* naming, but the common pattern in drivers that don't is still to use custom names.

many other drivers that aren't the generic ones use the sdX naming as well now. There are far fewer odd names than there used to be.

> The change in interface naming solves real problems that affected real people in the real world

It also breaks things for real people in the real world. The question is if the benefits are larger than the drawbacks.

remember devfs? one of it's bit things was the topology naming, and that was one of the things that people actively hated about it (although there was a vocal minority who loved it, giving the same reasons that you are giving)

One of the things that we should have learned by now is that breaking some people to fix others isn't just a matter of "it broke X people and fixed Y people, if Y > X it's an improvement", it's more like "Y needs to be > 10 * X to have a chance of breaking even" because breaking existing things is FAR more damaging to trust and reliability.

Distribution quotes of the week

Posted Dec 9, 2014 22:54 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (11 responses)

> that doesn't match my experience.

I don't really know what to say to that. When we spec a build with a vendor, any further orders we make with the same reference come with the same layout. As such, topology-based interface naming helps us a great deal.

> many other drivers that aren't the generic ones use the sdX naming as well now. There are far fewer odd names than there used to be.

I can't find anything in the kernel that uses the sd namespace other than the SCSI layer. So yeah, any driver that decides to make use of the SCSI layer will end up in the sd namespace, but the motivation there is using the SCSI layer rather than simplifying naming.

> It also breaks things for real people in the real world.

Who? It won't on Debian - upgrades will maintain the old names, because of the MAC-based policy you described earlier.

Distribution quotes of the week

Posted Dec 9, 2014 23:20 UTC (Tue) by dlang (guest, #313) [Link] (10 responses)

>> that doesn't match my experience.

> I don't really know what to say to that. When we spec a build with a vendor, any further orders we make with the same reference come with the same layout. As such, topology-based interface naming helps us a great deal.

There are tier 1 vendors who you order a system from and you get a pile of boxes, one for the base system, another for the second processor, another for the ram, another for the second power supply, a bunch for any drives past the first one, others for any cards you ordered, etc.

As I say, this isn't buying from a whitebox vendor, but instead something I've seen from multiple top-tier vendors over the years (some of whom have merged now)

This last week $work had a machine in a datacenter that was giving them problems, they are paying for the expensive 4-hour support contract. After 3 days and multiple replacement motherboards and other parts, they got a replacement system shipped. The main system arrived at the datacenter and was installed (with cards transplanted from the old system), the next day the cards for the new system arrived, at corporate HQ three timezones away.

Distribution quotes of the week

Posted Dec 11, 2014 11:47 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (9 responses)

> As I say, this isn't buying from a whitebox vendor, but instead something I've seen from multiple top-tier vendors over the years (some of whom have merged now)

Maybe this is down to how you order things? If you're configuring devices online and ordering directly for each individual order, I can imagine this happening - if you have an account manager and defined configurations tied to your customer account, I'd expect the configuration to be identical. But that's kind of beside the point: you can accept that people who *do* receive machines with add-in cards in well-defined locations benefit from having a topology-based naming scheme?

Distribution quotes of the week

Posted Dec 11, 2014 19:09 UTC (Thu) by dlang (guest, #313) [Link] (6 responses)

Having a topology based naming scheme as an option is useful, making it the default isn't

Distribution quotes of the week

Posted Dec 11, 2014 21:27 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (5 responses)

I think there's plenty of room to disagree there, but this discussion started with your assertion that this was a problem that was adequately fixed by binding interface names to MAC address. I hope we've established that that isn't the case?

Distribution quotes of the week

Posted Dec 12, 2014 0:36 UTC (Fri) by dlang (guest, #313) [Link] (4 responses)

I still say that under the vast majority of conditions, binding interface names to MAC addresses does solve the problem.

I am not one of those people who oppose the creation of other options. I do start opposing things when the new options become the default, complicating things for people for who the prior setup 'just worked'. and I _really_ want the option of disabling the new option if I like the old one.

Distribution quotes of the week

Posted Dec 12, 2014 1:00 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (3 responses)

> I still say that under the vast majority of conditions, binding interface names to MAC addresses does solve the problem.

But there are circumstances where it doesn't, right?

Distribution quotes of the week

Posted Dec 12, 2014 1:42 UTC (Fri) by dlang (guest, #313) [Link]

"vast majority" acknowledges that there are circumstances where it doesn't

Distribution quotes of the week

Posted Dec 12, 2014 1:57 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (1 responses)

Most setups have one network interface (for each type, e.g., one WiFi, one Ethernet). There whatever is used is completely irrelevant. If there are several interfaces of the same type, binding a MAC to a name solves the problems as long as the MAC doesn't change (that might happen if a broken card is replaced, or the MAC is reconfigured, or in course of maintenance cards get shuffled around). So name fixed by MAC does solve the problem most of the time, except when it doesn't. And then you are up a remote creek with no paddle.

Distribution quotes of the week

Posted Dec 12, 2014 2:10 UTC (Fri) by dlang (guest, #313) [Link]

> So name fixed by MAC does solve the problem most of the time, except when it doesn't. And then you are up a remote creek with no paddle.

Yep, same for topology based names. Plus switching to topology based names will confuse people and invalidate a huge amount of existing documentation for all the people who don't need them.

Distribution quotes of the week

Posted Dec 13, 2014 13:54 UTC (Sat) by HelloWorld (guest, #56129) [Link] (1 responses)

Why are you wasting your time with this jackass?

PLEASE

Posted Dec 13, 2014 14:09 UTC (Sat) by corbet (editor, #1) [Link]

This is the last time I'll ask you to can it with the personal attacks. Seriously. If you're not mesmerized by the discussion, ignore it please. But I really don't want to see more of this kind of stuff, and I'm not the only one; there is a reason why you are one of the most heavily filtered commenters on the site. Please stop.

Distribution quotes of the week

Posted Dec 4, 2014 13:07 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Do I miss my first Linux machine, an i486dx4/100 with 16MiB RAM, a 510MiB disk, 3.5" diskette drive, a no-name 10baseT Ethernet card, connected to the net via SLIP a few minutes a day, getting updates via MS-DOS formatted diskettes or a Zip drive connected by parallel port instead of the printer? You bet I do.

But that kind of configuration is long a thing of the past. Currently I wander about, connecting this machine to a variety of WiFi and 100baseT networks depending on where I'm currently, sometimes even using my Android phone via tethering for network. Printing is either a local USB printer or a remote network printer. When available, it gets connected via USB to an external keyboard and a much larger monitor. This little beast has 4 cores, 8GiB RAM, 500GiB disk (with a 512MiB SSD). Mouse is Bluetooth, and I connect USB disks, pendrives, and sometimes CD/DVDs to it. And I expect all that to just work, with no manual intervention (no futzing around with network configuration, no reconfiguring X, ever).

Current machines are much larger than what they used to be. Demands on them have grown perhaps even faster than the machines themselves. All this translates into much more complexity, which has to be tamed somehow. Yes, I could very well do all the reconfiguring required by hand. I could perhaps also cobble something together to handle much of it via "traditional" mechanisms (sysvinit-style scripts, assorted scripts to set up the various network configurations, and so on). But I very much prefer an integrated set of solutions to all this, done by people who care much more than I ever will about this whole mess. I have other work to do.

Distribution quotes of the week

Posted Dec 5, 2014 0:22 UTC (Fri) by ebassi (subscriber, #54855) [Link] (2 responses)

Note that Adam Jackson is the author of the famous post http://islinuxaboutchoice.com/ (obviously he meant no).

very minor nitpick: ajax wrote the email in 2008, but I set up the website — on the stairs of the Humbolt University, during the Desktop Summit in Berlin, 2011.

we do split the revenue of the website (50% of 0 to each of us), but he justifiably gets all the fame.

Distribution quotes of the week

Posted Dec 5, 2014 3:16 UTC (Fri) by jschrod (subscriber, #1646) [Link] (1 responses)

Please add a `d'.

http://en.wikipedia.org/wiki/Wilhelm_von_Humboldt
One of the guys who's visions still have not been realized.

Then we'll consider to allocate more part of the fame for you. (Promise is easy to make, I didn't know about that site or about that `famous' post -- which obviously misses the wood for the trees -- before I read that LWN thread.)

Here's to you, :-)
Joachim

Distribution quotes of the week

Posted Dec 22, 2014 15:37 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

“whose” ;-)

SCNR.