On Tue, December 8, 2015 11:05, Matthew Miller wrote:
I have been bitten by things done in Fedora that only have any use on a laptop and that should never have been allowed into a server distribution. But I cannot see how I would have been aware of them until they manifested themselves on equipment under my care. By which
^ right, this.
time it is rather too late to influence the decision to include them.
Well, not if you get involved early. That's the point.
If you don't *want* to, that's fine, but there's only so much complainy cake that you can have and eat at the same time.
So, the implication of your suggestion, if I understand it aright, is that I should audit all of the communication forums in use by Fedora developers and then point out whenever any of the many dozens or hundreds of contributors introduces something that in my opinion may impact a server installation. To do this I am required to obtain such intimate personal knowledge of the internal workings of the distribution as to be able to identify these items as soon as they are introduced. naturally, I am also supposed to be able to immediately identify the negative impact of these things and prepare and present a cogent argument against their adoption or propose patches to correct the deficiencies that I believe that I have detected.
I am to do this whilst running a CentOS installation that will not allow Fedora onto the premises. SO, no doubt, the intent is that I should run Fedora on my home systems and work diligently in my off hours to protect any future version of CentOS from that vantage. And of course, if I miss something then it is my fault for not having paid enough attention to that item.
Am I correct?
On 12/09/2015 08:54 AM, James B. Byrne wrote:
So, the implication of your suggestion, if I understand it aright, is that I should audit all of the communication forums in use by Fedora developers and then point out whenever any of the many dozens or hundreds of contributors introduces something that in my opinion may impact a server installation. ....
Am I correct?
Yeah, pretty much. At least you have the ability to have some input upstream, unlike with Windows.
Once it is in RHEL, it is simply *going* to be in CentOS, full stop. If you don't want it in CentOS, then it needs to be yelled about when it appears in Fedora. Yes, this is work. But many are already doing this work; it is those people whose voices are being heard; it is also some of those people that are making dynamic networking happen (which is useful for more than just laptops).
If you want your voice to be heard, you have to use your voice in the venue where changes can happen. Once it is in a particular major version of CentOS, it is simply not going away (unless RHEL removes it).
On Wed, Dec 09, 2015 at 09:37:33AM -0500, Lamar Owen wrote:
On 12/09/2015 08:54 AM, James B. Byrne wrote:
So, the implication of your suggestion, if I understand it aright, is that I should audit all of the communication forums in use by Fedora developers and then point out whenever any of the many dozens or hundreds of contributors introduces something that in my opinion may impact a server installation. ....
If you want your voice to be heard, you have to use your voice in the venue where changes can happen. Once it is in a particular major version of CentOS, it is simply not going away (unless RHEL removes it).
The best place to keep track is probably the Fedora testing list. Adam Williamson, among others, does listen to reasonable disagreements and some decisions that would be bad for a server O/S do get turned down.
Lamar Owen wrote:
On 12/09/2015 08:54 AM, James B. Byrne wrote:
So, the implication of your suggestion, if I understand it aright, is that I should audit all of the communication forums in use by Fedora developers and then point out whenever any of the many dozens or hundreds of contributors introduces something that in my opinion may impact a server installation. ....
Am I correct?
Yeah, pretty much. At least you have the ability to have some input upstream, unlike with Windows.
<snip> Can't remember if I posted this here - I've posted this comment in a one or two other places - but one thing that's always aggravated me is when the development or architecture side simply DOES NOT TALK to end users, but Knows How It Needs To Be.
I'm sure it's *far* too much work for, say, the fedora development team to put out once a quarter a notice to upstream, and maybe CentOS, Scientific Linux, and whatever other main user groups to inform them of major changes, and see the feedback....
Nahhh, who cares whether end users are happy, they'll just do what is K3wl, never mind if it's appropriate, or overly complicated....
mark
On Wed, Dec 09, 2015 at 11:45:55AM -0500, m.roth@5-cent.us wrote:
I'm sure it's *far* too much work for, say, the fedora development team to put out once a quarter a notice to upstream, and maybe CentOS, Scientific Linux, and whatever other main user groups to inform them of major changes, and see the feedback....
I'm not sure what you mean by "to upstream".
But overall, why do you think I'm here suggesting that CentOS users follow Fedora development?
And, if following the actual development cycle is too hard, we actually do produce something else that's designed for exactly what you're asking: the actual Fedora OS releases.
On 12/09/2015 11:45 AM, m.roth@5-cent.us wrote:
I'm sure it's *far* too much work for, say, the fedora development team to put out once a quarter a notice to upstream, and maybe CentOS, Scientific Linux, and whatever other main user groups to inform them of major changes, and see the feedback....
Someone just needs to spend the time to do it. So who is that someone? The Fedora team already has their hands full; or is the Fedora team supposed to allocate already scarce volunteer resources to handle the needs of CentOS users? (Red Hat likely already has one or more liaisons of this sort with the needs of Red Hat's customers in mind).
No, it seems to me that a suitably motivated CentOS user needs to scratch this itch; and, no, I am not volunteering, as I've followed Fedora before......and just simply cannot give the time to it at this point in time in my life.
So I shouldn't really complain, either, when a feature I use was removed way back then or a feature I would never use was added way back then, when I am getting many thousands of man-hours worth of work for free. If I want the right to complain, I need to ante up, either with money (and I did purchase and do annually renew my RHEL subscription) or with time (and I have done that, too, both as a Red Hat beta tester (prior to the Enterprise Linux / Fedora Core 'split') and by maintaining the PostgreSQL RPMs as a volunteer for five years, which is a far costlier thing to do!). IMHO, of course.
So who wants to be the CentOS-Users to Fedora liaison, likely to be one of the most thankless jobs on the planet?
On 9 Dec 2015 9:07 p.m., "Lamar Owen" lowen@pari.edu wrote:
No, it seems to me that a suitably motivated CentOS user needs to scratch
this itch; and, no, I am not volunteering, as I've followed Fedora before......and just simply cannot give the time to it at this point in time in my life.
<snip>
So who wants to be the CentOS-Users to Fedora liaison, likely to be one
of the most thankless jobs on the planet?
I'm an active Fedora packager and yet I dare say Mark would hate me as liaison for I find the changes in EL7 most refreshing and look forward to bring able to make better use of them in due course ;)
But I really do question whether someone in this industry is really not able to spend 30 minutes or so every six months checking changes for anything interesting.
And frankly if one isn't willing to get either get a subscription and feedback as a paying customer or to get involved with the upstream sources then no one does not have say in direction and one shouldn't be surprised by that.
If it was a democracy with a vote on every possible choice then we'd never get anywhere given the time to carry out such a survey and the vast differences in opinions.
No, as the Debian folks say it is a meritocracy instead and those who get stuck in and actively discuss at the right time provide the influence on what happens next.
On 12/09/2015 09:37 AM, Lamar Owen wrote:
On 12/09/2015 08:54 AM, James B. Byrne wrote:
So, the implication of your suggestion, if I understand it aright, is that I should audit all of the communication forums in use by Fedora developers and then point out whenever any of the many dozens or hundreds of contributors introduces something that in my opinion may impact a server installation. ....
Am I correct?
Yeah, pretty much. At least you have the ability to have some input upstream, unlike with Windows.
Once it is in RHEL, it is simply *going* to be in CentOS, full stop. If you don't want it in CentOS, then it needs to be yelled about when it appears in Fedora. Yes, this is work. But many are already doing this work; it is those people whose voices are being heard; it is also some of those people that are making dynamic networking happen (which is useful for more than just laptops).
Hi,
I think saying that you can have some say as to what goes into Fedora is being a little naive, look at systemd, many people complained about its inclusion but the powers to be heard none of it, and the refrain I saw was if you don't like systemd then run something else.
Regards, Steve
If you want your voice to be heard, you have to use your voice in the venue where changes can happen. Once it is in a particular major version of CentOS, it is simply not going away (unless RHEL removes it).
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, Dec 09, 2015 at 01:15:56PM -0500, Steve Clark wrote:
I think saying that you can have some say as to what goes into Fedora is being a little naive, look at systemd, many people complained about its inclusion but the powers to be heard none of it, and the
That's not a historically accurate picture of the process. And, I know, because I was one of the people very skeptical of systemd's inclusion. "Powers to be" didn't really come into it.
I'm not going to argue about systemd in specific, because that horse is so dead that its zombie skeleton version is _also_ dead, but the general point is important enough that I'll say it again: anyone who puts in the effort to contribute can have a meaningful say in any and every part of Fedora.
On Wed, Dec 09, 2015 at 08:54:56AM -0500, James B. Byrne wrote:
So, the implication of your suggestion, if I understand it aright, is that I should audit all of the communication forums in use by Fedora developers and then point out whenever any of the many dozens or hundreds of contributors introduces something that in my opinion may impact a server installation. To do this I am required to obtain such intimate personal knowledge of the internal workings of the distribution as to be able to identify these items as soon as they are introduced. naturally, I am also supposed to be able to immediately identify the negative impact of these things and prepare and present a cogent argument against their adoption or propose patches to correct the deficiencies that I believe that I have detected.
Yes, that's basically how it works — but you don't actually have to go to that elaborate scale to make a difference. That's why I suggested getting involved with Fedora Server, not "auditing all of the communication forums". We (Fedora) also work hard on making sure that proposed and planned changes are communicated. Following the Devel Announce list
https://lists.fedoraproject.org/pipermail/devel-announce/
is a relatively low-traffic, low-effort way to stay informed of major things.
Focus on something you're interested in. When enough people do that, it adds up.
I am to do this whilst running a CentOS installation that will not allow Fedora onto the premises. SO, no doubt, the intent is that I should run Fedora on my home systems and work diligently in my off hours to protect any future version of CentOS from that vantage.
Working with your employer to fix the "will not allow Fedora into the premises" part seems like a good start.
Of course, if you don't like all of this — and from your tone, it sounds very much like you don't — there's another obvious path where you can have an impact. That's to pay for Red Hat Enterprise Linux, and to submit feedback and problems through the official channels that provides.
Andof course, if I miss something then it is my fault for not having paid enough attention to that item.
I don't think _fault_ comes into it. It's not about blame; it's just that when no one does something, that something doesn't happen.
Matthew Miller wrote:
On Wed, Dec 09, 2015 at 08:54:56AM -0500, James B. Byrne wrote:
<snip>
Working with your employer to fix the "will not allow Fedora into the premises" part seems like a good start.
<snip> Why? Fedora is a development, rapid change distro. I just bugged one of my users yesterday that I'm *GOING* to update and reboot his system, since it hasn't been rebooted in about a year and a third. And we've got cluster members that they won't *let* us update, because it might break the software that's running on them. Around 6.3, I think, one user found an issue with the results from an updated system, and reran a completed job, and the update did *not* give the correct results. We had to downgrade - I forget what packages.
And some of these users have jobs that on bare metal (forget VMs, we can't spare the cycles) run one to two *weeks*... and that's on clusters with 512 or over 1100 cores, or the boxes with *two* Tesla cards. Yes, we are talking very serious scientific computing.
Absolute stability is what matters. For production machines, I worked out a once a month maintenance window, to update and reboot.
In an environment like this, why would we want to do fedora, with its how-many-updates in the last two days? This is why we're on CentOS, which is *stable*.
mark
On Wed, Dec 09, 2015 at 11:54:57AM -0500, m.roth@5-cent.us wrote:
Matthew Miller wrote:
Working with your employer to fix the "will not allow Fedora into the premises" part seems like a good start.
<snip> Why? Fedora is a development, rapid change distro. I just bugged one of my
Because of the context of this conversation. We can't have user feedback and involvement without user feedback and involvement.
Matthew Miller wrote:
On Wed, Dec 09, 2015 at 11:54:57AM -0500, m.roth@5-cent.us wrote:
Matthew Miller wrote:
Working with your employer to fix the "will not allow Fedora into the premises" part seems like a good start.
<snip> Why? Fedora is a development, rapid change distro. I just bugged one of my
Because of the context of this conversation. We can't have user feedback and involvement without user feedback and involvement.
So, you're saying that end users need to go poke their noses into the development process, but that developers don't need to poke their noses out to the end users... or at least, that's how I read what you're saying.
mark
On Wed, Dec 09, 2015 at 01:05:15PM -0500, m.roth@5-cent.us wrote:
Why? Fedora is a development, rapid change distro. I just bugged one of
Because of the context of this conversation. We can't have user feedback and involvement without user feedback and involvement.
So, you're saying that end users need to go poke their noses into the development process, but that developers don't need to poke their noses out to the end users... or at least, that's how I read what you're saying.
If you want to go out of your way to read it that way, it's hard to stop you. However, it's not what I'm saying. The development process is conducted in the open for a reason.
Matthew Miller wrote:
On Wed, Dec 09, 2015 at 01:05:15PM -0500, m.roth@5-cent.us wrote:
Why? Fedora is a development, rapid change distro. I just bugged one
of
Because of the context of this conversation. We can't have user feedback and involvement without user feedback and involvement.
So, you're saying that end users need to go poke their noses into the development process, but that developers don't need to poke their noses out to the end users... or at least, that's how I read what you're saying.
If you want to go out of your way to read it that way, it's hard to stop you. However, it's not what I'm saying. The development process is conducted in the open for a reason.
I don't see that as going "out of my way". Let's put it this way: how many times have folks on the development side poked their nose in here - the general redhat list is pretty dead - and asked anything? I've been here since '09, and I *think* that maybe once, *maybe* twice, someone asked something here, who was on that side of the house.
Perhaps, if it's open, it should be a two way street, not one way, for us to take time from what we're being paid for, to hit that side.
Oh, and btw, we *do* have a few RH licenses... and for those who have to deal with smart card ID cards, you can thank my manager for pushing through native support in RHEL 7. So I guess you could say we do, sometimes, go to the development side.
mark
On Dec 9, 2015, at 11:55 AM, m.roth@5-cent.us wrote:
Matthew Miller wrote:
On Wed, Dec 09, 2015 at 01:05:15PM -0500, m.roth@5-cent.us wrote:
So, you're saying that end users need to go poke their noses into the development process
If you want to go out of your way to read it that way, it's hard to stop you. However, it's not what I'm saying. The development process is conducted in the open for a reason.
I don't see that as going "out of my way". Let's put it this way: how many times have folks on the development side poked their nose in here - the general redhat list is pretty dead - and asked anything?
So…you want veto power over Fedora? You want every proposed change to cross your desk for a yea/nay?
What if the Fedora project gatewayed the low-traffic development mailing list to this one, so that you don’t even have *that* barrier to participation? Now ask yourself: what user-visible changes do you expect in the world afterward?
Hint to the correct answer: F/OSS is a do-ocracy: those who do the work, rule.
People give Poettering a lot of static, but the fact is, he Gets. Stuff. Done. If you want different stuff done, you’re going to have to make that happen somehow. Shouted complaints from a soapbox don’t compile.
And don’t play the “underfunded government agency” card. LANL, LLBL, ORNL, NASA, USGS…all have given back lots of code to the open source world. As well they should, because they derive an awful lot of benefit from that world.
I’m not against your basic position, Mark. I, too, have shaken my head in dismay at several of the desktop-focused behaviors in recent versions of CentOS.[*] I think where we actually differ is that I realize that I have no right to complain all that loudly about them, because I have the means to change them, but do not.
Partly that’s because of differing priorities, partly it’s out of rational self-interest (i.e. I know how many OS forks fizzle) and yes, it’s partly just laziness. But there’s that difference: I know why I’m not out there trying to change it.
What are your reasons?
[*] My favorite fumble is the one where a 2-NIC box with one DHCP interface and one static will swap the configurations silently when you boot with only the DHCP cable plugged in. Because *obviously* you want the static IP to be available all the time, right? This is great for wifi + Ethernet laptops, where you want the static IP to move when you plug the wired LAN cable in, but it doesn’t work out so great for servers where the DHCP NIC is normally disconnected, and exists only so the boots on the ground can move the cable in an emergency to reestablish the Internet link after they roached the LAN config somehow. This behavior means the broken static IP moves to the secondary NIC, where it remains broken. Solution: Plug both network cables in so NetworkManager doesn’t get Clever.™
Warren Young wrote:
On Dec 9, 2015, at 11:55 AM, m.roth@5-cent.us wrote:
Matthew Miller wrote:
On Wed, Dec 09, 2015 at 01:05:15PM -0500, m.roth@5-cent.us wrote:
So, you're saying that end users need to go poke their noses into the development process
If you want to go out of your way to read it that way, it's hard to stop you. However, it's not what I'm saying. The development process is conducted in the open for a reason.
I don't see that as going "out of my way". Let's put it this way: how many times have folks on the development side poked their nose in here
- the general redhat list is pretty dead - and asked anything?
So…you want veto power over Fedora? You want every proposed change to cross your desk for a yea/nay?
Beg pardon? Why are you caricaturing what I said? I don't believe any of us who are complaining are talking about every small change; rather, the major ones.
As a lesser example, I just *adore* the new ethernet names - NOT. Breaks scripts, makes it all more difficult, not to mention *so* much easier to guess, when you've debugging a box and your organization has hardware from many OEMs. What was wrong with eth0, or even em1? Why go to Sun naming conventions? Maybe it helps EEs, but not sysadmins.
Please, though, that naming is *not* the point of the thread.
What if the Fedora project gatewayed the low-traffic development mailing list to this one, so that you don’t even have *that* barrier to participation? Now ask yourself: what user-visible changes do you expect in the world afterward?
Why not what was suggested, a summary every month or three? How about sending announcements? <snip>
People give Poettering a lot of static, but the fact is, he Gets. Stuff. Done. If you want different stuff done, you’re going to have to make that happen somehow. Shouted complaints from a soapbox don’t compile.
Which a vast number of us strongly opposed, but were not listened to. That stuff is fine for a desktop, but who *cares* How Fast a *server* Shuts Down? And coming up - hell, damn HP server take for-bloody-*ever* with their firmware, init V is faster than their firmware.
And don’t play the “underfunded government agency” card. LANL, LLBL, ORNL, NASA, USGS…all have given back lots of code to the open source world. As well they should, because they derive an awful lot of benefit from that world.
May be, but my federal agency is at *least* 5% under what we were getting in 2003, and my manager, who's working with another Institute about 2/3rds of his time, and I, and another admin have to manage over 170 servers, workstations, and clusters, some with special software, and ranging in age from just bought to 2007 (I think there may be a workstation or 3 older), and some of which we haven't managed to get the owners to allow us to get off CentOS 5....
I’m not against your basic position, Mark. I, too, have shaken my head in dismay at several of the desktop-focused behaviors in recent versions of CentOS.[*] I think where we actually differ is that I realize that I have no right to complain all that loudly about them, because I have the means to change them, but do not.
And I ask permission from my fed manager to put in a ticket with upstream (which reminds me, I need to ask about putting one in for those docs with links to google ads).
Partly that’s because of differing priorities, partly it’s out of rational self-interest (i.e. I know how many OS forks fizzle) and yes, it’s partly just laziness. But there’s that difference: I know why I’m not out there trying to change it.
What are your reasons?
Lack of time, as I've indicated.
[*] My favorite fumble is the one where a 2-NIC box with one DHCP interface and one static will swap the configurations silently when you boot with only the DHCP cable plugged in. Because *obviously* you want the static IP to be available all the time, right? This is great for wifi
- Ethernet laptops, where you want the static IP to move when you plug the
wired LAN cable in, but it doesn’t work out so great for servers where the DHCP NIC is normally disconnected, and exists only so the boots on the ground can move the cable in an emergency to reestablish the Internet link after they roached the LAN config somehow. This behavior means the broken static IP moves to the secondary NIC, where it remains broken. Solution: Plug both network cables in so NetworkManager doesn’t get Clever.™
Oh, I remember when you couldn't be sure, pre-NM, what would be eth0, until you put the MAC address in....
mark
On Thu, Dec 10, 2015 at 04:56:34PM -0500, m.roth@5-cent.us wrote:
Why not what was suggested, a summary every month or three? How about sending announcements?
Do people _want_ accepted Fedora change announcements posted to this list? That's pretty easy to arrange if it really helps. I don't see a big benefit over just following the annoucement list where they're posted (filtering out other topics if you want), but if people would really find that helpful, we could do it.
On 12/10/2015 2:32 PM, Matthew Miller wrote:
On Thu, Dec 10, 2015 at 04:56:34PM -0500,m.roth@5-cent.us wrote:
Why not what was suggested, a summary every month or three? How about sending announcements?
Do people_want_ accepted Fedora change announcements posted to this list? That's pretty easy to arrange if it really helps. I don't see a big benefit over just following the annoucement list where they're posted (filtering out other topics if you want), but if people would really find that helpful, we could do it.
I personally say 'NO' to this. I have zilch interest in Fedora.
On Thu, Dec 10, 2015 at 5:32 PM, Matthew Miller mattdm@mattdm.org wrote:
On Thu, Dec 10, 2015 at 04:56:34PM -0500, m.roth@5-cent.us wrote:
Why not what was suggested, a summary every month or three? How about sending announcements?
Do people _want_ accepted Fedora change announcements posted to this list? That's pretty easy to arrange if it really helps. I don't see a big benefit over just following the annoucement list where they're posted (filtering out other topics if you want), but if people would really find that helpful, we could do it.
No.
I'd recommend those who want those announcements subscribe to the proper Fedora list. (as you point out, we think alike!)
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 12/10/2015 1:56 PM, m.roth@5-cent.us wrote:
As a lesser example, I just*adore* the new ethernet names - NOT. Breaks scripts, makes it all more difficult, not to mention*so* much easier to guess, when you've debugging a box and your organization has hardware from many OEMs. What was wrong with eth0, or even em1?
when you have multiple adapters, perhaps different types (maybe 2 10gigE and 2 1gigE?) which one is eth0 supposed to be? BSD has always used driver type in the network device names, and having dealt with device confusions before, I understand why.
You think this is irritating, what about when you're trying to replicate the network configuration to failover hardware... There is a way around this, I haven't tried it on CentOS but on Ubuntu there are kernel command line parameters:
net.ifnames=1 biosdevname=0
which will override this behavior. Again, on Ubuntu these are added in /etc/default/grub as parameters to GRUB_CMDLINE_LINUX_DEFAULT. Finally, there's /udev/rules.d/70-persistent-net.rules which allows you to associate a MAC address with an eth? label. However, without the command line parameters it is ignored (contrary to other statements on the web ). Given this is CentOS you mileage will almost certainly vary but hopefully this gives you enough to go on to get to the final solution. There is a freedesktop.org web page about why they did this - it has to do with mobile devices and plug-and-play networking. Take that page's statement about setting net.ifnames=0 cautiously, I found it was the exact opposite. biosdevname is a program written by someone at Dell which is supposed to report on hardware configurations and make some sense out of the cesspool. It appears the source of the whole thing is hardware vendors doing whatever they want and in some cases not playing by the rules.
----- Original Message ----- From: "John R Pierce" pierce@hogranch.com To: centos@centos.org Sent: Thursday, December 10, 2015 4:33:24 PM Subject: Re: [CentOS] wifi on servers and fedora [was Re: 7.2 kernel panic on boot]
On 12/10/2015 1:56 PM, m.roth@5-cent.us wrote:
As a lesser example, I just*adore* the new ethernet names - NOT. Breaks scripts, makes it all more difficult, not to mention*so* much easier to guess, when you've debugging a box and your organization has hardware from many OEMs. What was wrong with eth0, or even em1?
when you have multiple adapters, perhaps different types (maybe 2 10gigE and 2 1gigE?) which one is eth0 supposed to be? BSD has always used driver type in the network device names, and having dealt with device confusions before, I understand why.
On 12/10/2015 3:05 PM, Leroy Tennison wrote:
You think this is irritating, what about when you're trying to replicate the network configuration to failover hardware...
IMHO, active/standby failover hardware should have exact identical configurations down to firmware revisions, so I'm not sure what the issue is.
Unfortunately, hardware isn't always purchased at the same time and, even if it is, how do you know that the vendor didn't make some "transparent" change in production that isn't noticeable until you get into the details. Vendors ***shouldn't*** do that but then there's reality.
----- Original Message ----- From: "John R Pierce" pierce@hogranch.com To: centos@centos.org Sent: Thursday, December 10, 2015 5:10:23 PM Subject: Re: [CentOS] wifi on servers and fedora [was Re: 7.2 kernel panic on boot]
On 12/10/2015 3:05 PM, Leroy Tennison wrote:
You think this is irritating, what about when you're trying to replicate the network configuration to failover hardware...
IMHO, active/standby failover hardware should have exact identical configurations down to firmware revisions, so I'm not sure what the issue is.
On Dec 10, 2015, at 6:05 PM, Leroy Tennison leroy@datavoiceint.com wrote:
There is a freedesktop.org web page about why they did this - it has to do with mobile devices and plug-and-play networking. Take that page's statement about setting net.ifnames=0 cautiously, I found it was the exact opposite.
To be honest, I found that this change better suited servers, which often have multiple interfaces on multiple vendor’s cards, rather than mobile devices, which tend to only have one ethernet device, if any. Being able to predictably define which interface would be named is much more important when you’ve got 4 network interfaces, rather than hoping that eth0 is the one you booted from.
-- Jonathan Billings billings@negate.org
The device I encountered it on had 10 NICS, at installation 6 of them got the new naming convention and four of them got the eth convention. I guess my question is "what's wrong with using the MAC address?" Yes, I know some things don't have MAC addresses, let the exceptional situation be the exception.
----- Original Message ----- From: "Jonathan Billings" billings@negate.org To: "CentOS mailing list" centos@centos.org Sent: Thursday, December 10, 2015 5:15:09 PM Subject: Re: [CentOS] wifi on servers and fedora [was Re: 7.2 kernel panic on boot]
On Dec 10, 2015, at 6:05 PM, Leroy Tennison leroy@datavoiceint.com wrote:
There is a freedesktop.org web page about why they did this - it has to do with mobile devices and plug-and-play networking. Take that page's statement about setting net.ifnames=0 cautiously, I found it was the exact opposite.
To be honest, I found that this change better suited servers, which often have multiple interfaces on multiple vendor’s cards, rather than mobile devices, which tend to only have one ethernet device, if any. Being able to predictably define which interface would be named is much more important when you’ve got 4 network interfaces, rather than hoping that eth0 is the one you booted from.
-- Jonathan Billings billings@negate.org
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Confidentiality Notice | This email and any included attachments may be privileged, confidential and/or otherwise protected from disclosure. Access to this email by anyone other than the intended recipient is unauthorized. If you believe you have received this email in error, please contact the sender immediately and delete all copies. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
On 10 Dec 2015 23:25, "Leroy Tennison" leroy@datavoiceint.com wrote:
The device I encountered it on had 10 NICS, at installation 6 of them got
the new naming convention and four of them got the eth convention. I guess my question is "what's wrong with using the MAC address?" Yes, I know some things don't have MAC addresses, let the exceptional situation be the exception.
Because when that PCI express card with the 4-8 ports on it fails and it's replaced under warranty having the server come back up right away with the correct configuration since the logical port names haven't changed despite the change of MAC is useful...
On 12/10/2015 05:33 PM, John R Pierce wrote:
On 12/10/2015 1:56 PM, m.roth@5-cent.us wrote:
As a lesser example, I just*adore* the new ethernet names - NOT. Breaks scripts, makes it all more difficult, not to mention*so* much easier to guess, when you've debugging a box and your organization has hardware from many OEMs. What was wrong with eth0, or even em1?
when you have multiple adapters, perhaps different types (maybe 2 10gigE and 2 1gigE?) which one is eth0 supposed to be? BSD has always used driver type in the network device names, and having dealt with device confusions before, I understand why.
ethtool can easily tell you the capabilities of the device - you don't need magic names.
On Dec 10, 2015, at 2:56 PM, m.roth@5-cent.us wrote:
Warren Young wrote:
So…you want veto power over Fedora?
Beg pardon? Why are you caricaturing what I said?
I didn’t think it was a caricature at all. You clearly don’t want people to “listen” to you, you want veto power.
If all you wanted was to be heard, you’d have stopped banging on this drum long ago. We got it. We heard you. You don’t like it.
How else would you characterize a desire for wishes to be changes, other than veto power?
As a lesser example, I just *adore* the new ethernet names - NOT. Breaks scripts
Hard-coded values are never a good idea. That’s been a principle of good software design and systems administration since the 1960s, at least.
The outputs of ip link and ifconfig -a are parseable for a reason. Or, you can iterate over the contents of /sys/class/net.
Mind, I didn’t come away from that change unscathed. I had to go back and make some changes to my code. I think it amounted to about an hour of work, done years ago, and amortized to all-but-zero since then.
The bigger problem is the day-to-day mystery of it all. “Gee, Brain, what interface shall we bounce tonight?” “The same interface we bounce every night: enp3s0!” “But Braaain, it’s been called enp4s0 ever since the mobo manufacturer switched to the rev 2 boards! Narf!” 15 minutes of comic violence later, followed by utter failure; then, “So, Brain, what shall we do tomorrow night?” “The same thing we do every night, Pinky: try to bounce the first Ethernet NIC!”
What if the Fedora project gatewayed the low-traffic development mailing list to this one, so that you don’t even have *that* barrier to participation? Now ask yourself: what user-visible changes do you expect in the world afterward?
Why not what was suggested, a summary every month or three? How about sending announcements?
Fine, I repeat my question: what user-visible change do you expect to find in the world after they do that, given that those receiving only those announcements (i.e. those not also watching the Fedora dev lists) will contribute precisely *squat* other than complaints?
Once again, soapbox soliloquies don’t compile.
<snip> > People give Poettering a lot of static, but the fact is, he Gets. Stuff. > Done. If you want different stuff done, you’re going to have to make that > happen somehow.
Which a vast number of us strongly opposed
Opposed what, exactly? Everything Poettering has ever done, or did you have something specific in mind?
but were not listened to.
I took a wild guess that your complaints are about systemd, rather than avahi, pulseaudio, or any of the other several dozen projects Lennart Poettering has worked on.
I got 210 results from Googling CentOS’s mailing list archive server for your email address and “systemd”. The first one appeared in 2014, *four years* after systemd was created, and over three years after it was released as the default init system for Fedora.
And that was the *only* post from you on that topic in 2014. The other 209 posts were all in 2015, when it was way, way too late to change the decision.
So, in what world do your 2015 wishes for systemd to go away become a change in that world?
who *cares* How Fast a *server* Shuts Down? And coming up - hell, damn HP server take for-bloody-*ever* with their firmware, init V is faster than their firmware.
We’ve covered this already: the cloud cares.
It’s right there on the front page of https://www.digitalocean.com/ They can bring a VM up for you in 55 seconds. How do you suppose they achieved that?
It isn’t just one company’s marketing slogan. Rackspace, Amazon, etc., all start from a few key premises, one of which is that you can spin a server up and down fast enough that you can rent dynamic instant-to-instant slices of the host hardware, as opposed to the old VPS or shared hosting models, where the finest rental time granularity was a month.
This is a multi-billion dollar business.[1] You can’t handwave it away as unimportant. Red Hat would have to be fools not to be running hard to grab a slice of that pie.
[1]: http://www.bbc.co.uk/news/business-32442268
And don’t play the “underfunded government agency” card. LANL, LLBL, ORNL, NASA, USGS…all have given back lots of code to the open source world. As well they should, because they derive an awful lot of benefit from that world.
May be, but my federal agency is at *least* 5% under what we were getting in 2003
Sigh…so you go and play the card anyway.
What, you think NASA’s doing great? Their operating budget was about 1/20 that spent on troops’ air conditioning in Iraq and Afghanistan in 2011.[2]
Maybe you think the national labs are flush with cash, here in the post cold war era?
Open source works on the stone soup principle: everyone goes hungry when they hang onto their gnarled carrots and wrinkled potatoes, but everyone has stew when they throw their scraps into the pot.[3]
[2]: https://goo.gl/WejcWK [3]: https://goo.gl/t2pSMw
Partly that’s because of differing priorities, partly it’s out of rational self-interest (i.e. I know how many OS forks fizzle) and yes, it’s partly just laziness. But there’s that difference: I know why I’m not out there trying to change it.
What are your reasons?
Lack of time, as I've indicated.
By demanding changes to the software without contributing patches to effect those changes, you are in effect imposing a burden on other peoples’ time.
We have a model for that: I pay you $X for Y hours of time, so that I do not have to spend the Y hours myself, or acquire the specialized knowledge it takes to apply those hours productively. You can do that in the form of an employment contract, or a support contract, or a donation.
If you will neither contribute your own hours nor pay for someone else’s hours, all you’ve got left is soapboxing.
Plug both network cables in so NetworkManager doesn’t get Clever.™
Oh, I remember when you couldn't be sure, pre-NM, what would be eth0, until you put the MAC address in….
I thought the MAC address binding solution was a perfectly reasonable way to solve the problem, and I want it back.
The problem now is that NM in EL7 treats the MAC address as a mere hint, rather than a command.
On 12/09/2015 05:54 AM, James B. Byrne wrote:
So, the implication of your suggestion, if I understand it aright, is that I should audit all of the communication forums in use by Fedora developers and then point out whenever any of the many dozens or hundreds of contributors introduces something that in my opinion may impact a server installation.
I would offer that you could visit the Fedora ChangeSet page once every six months and see what's coming. For the release of 24 (changes not yet final): https://fedoraproject.org/wiki/Releases/24/ChangeSet
But generally, Free Software is a participation culture, where "Free" refers to liberty, not commerce. You don't get to consume the goods for free, and also dictate your needs to the developers. If your employer needs features that the developers aren't currently working on, it needs to participate in development. Maybe that means paying a developer.
-
Gordon Messmer -
James B. Byrne -
James Hogarth -
John R Pierce -
Jonathan Billings -
Lamar Owen -
Leroy Tennison -
m.roth＠5-cent.us -
Matthew Miller -
Mike - st257 -
Scott Robbins -
Steve Clark -
Warren Young