Wifi On Servers And Fedora [was 7.2 Kernel Panic On Boot]

Home » General » Wifi On Servers And Fedora [was 7.2 Kernel Panic On Boot]
General 37 Comments

I subscribe to the Fedora Server list digest. Which form also is how I
get this list’s messages. Thus the delay in my responses.

However, to describe the Server List as an active forum for discussion would be somewhat overstating things. I have not received anything from it as yet in December and the total volume of traffic on that list in November was very light. I am not sure in what way you envisage additional involvement is to take place.

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 time it is rather too late to influence the decision to include them. Automatically powering down NICs comes to my mind; due the rather nasty consequences that resulted.

The difficulty is that with Free and Open Source Software you are only going to see features that are of some immediate use to the writers;
or whose value has already been entrenched such that it is difficult if not impossible to dispense with. Clearly, power saving features are of some interest to people that run their systems on batteries.

However, there are batteries, and then there are batteries. We occasionally run run on batteries too. It is just that ours are measured in kilovolt-amp hours. Having a server distro configured by default to turn off a NIC because it has not had traffic for fifteen minutes is not going to save us enough power from now to the end of eternity to warrant the disruption that little ‘feature’ cost us when it was first encountered.

The move to Systemd, and all the controversy that decision has generated, also provides ‘features’ whose benefits appear to me be be aimed principally at users who shut their systems off every day. These benefits are of far less value to people who measure uptime in months or years, while the discomfort, and expense, of this change must be borne regardless.

Systemd will eventually be accepted or rejected on its own merits. I
am not interested in debating them here since I have nothing upon which to base an opinion one way or the other. But it can hardly be denied that forcing highly qualified people to expend time, a very limited resource in my experience, to learn yet another way to start a computer system, without providing any readily discernible benefit to them, is not likely to engender much in the way of sympathy.

We went to RedHat and ended up on CentOS because of its server orientation. Which to us implied something more than simple compatibility of the software components. If RedHats’s intent is to end up as a laptop distro then we will probably part ways at some point. We have a laptop distro that works well for us. It is called OSX. And the hardware is pretty good too.

37 thoughts on - Wifi On Servers And Fedora [was 7.2 Kernel Panic On Boot]

  • I didn’t describe in that way. In fact, it *isn’t* that. It’s a mailing list for working on the Fedora Server edition.

    I’m sure it will pick up as we get further into the Fedora 24 cycle.

    It’s an open source project. There are a lot of ways to be involved. From your concerns, doing early testing and providing feedback on system-wide features from a server perspective is one way. Or simply doing QA in general. You could also help develop server roles matching needs in your environment — that’s a particular feature I’m hoping will come from Fedora through RHEL to CentOS.

    ^ right, this.

    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.


    Matthew Miller mattdm@mattdm.org < http://mattdm.org/>
    Fedora Project Leader
    mattdm@fedoraproject.org < http://fedoraproject.org/>

  • 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?

  • 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).

  • 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.

  • 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.

    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.

    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

    Fedora Project Leader

  • Lamar Owen wrote:

    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

  • Matthew Miller wrote:


    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

  • 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.

  • Because of the context of this conversation. We can’t have user feedback and involvement without user feedback and involvement.

  • 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

  • Matthew Miller wrote:

    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

  • 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.

  • 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.

  • Matthew Miller wrote:

    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

  • 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.

  • Without any references, it’s hard to know what you’re referring to specifically. However, I *think* you’re talking about the Intel e1000
    ASPM bugs. Those bugs were in the Intel NICs, and had nothing to do with decision making in the Fedora project. If you’re convinced that those features have no business in server class products, then you should provide that feedback to the hardware vendor who enabled ASPM in their BIOS (had they not done so, you would not have been affected by the bug). I think you’re upset at the wrong people, though I understand your frustration. I was affected by that bug, too.

    If you’re referring to something else, I’d be curious to know what it was.

    Well, considerable effort was made to provide discernible benefit. If you find time to look at it later:
    http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/the-biggest-myths.html

    I doubt you mean to imply that you’d use OS X as a server. No one does that. Even Apple uses Linux for its servers.

  • 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?

  • 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.

    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.

  • Since the import of what I was trying to convey has been lost, no doubt due to my poor choice of words, I will restate the obvious: If the bulk of the developers working on Fedora use laptops as their platform then, inevitably, Fedora will become in essence a laptop distribution and RHEL will follow. Talking about the server community monitoring the Fedora development channel once every six months, or every day for that matter, is simply not going to change this.

    A handful of voices representing server installations, who by definition are not development types, has no hope of dealing with the incremental changes introduced every day by hundreds of people that use laptops as their primary development platform and all of whom have their own ‘itch’ to scratch. That is just the way it is in open source. The choice to go to Fedora for RHEL development was a commitment to the laptop environment, whether consciously made or not. And it is not in the control of RH to dictate this. If the Fedora developers take up tablets en masse then guess what?: We will end up with a tablet distribution.

    The OS distro we get is the consequence of the culture and environment predominant in the development community. This is neither good nor bad. It just is. Our firm has specific requirements which to date have been more than adequately met by RHEL and CentOS. But that seems to us to be changing in ways that no longer meet our expectations from a server based distro.

    A server based distro to us has certain characteristics that are orientated to long running processes and system uptimes measured in months if not years. I have given up counting how many times I have to reboot all of our CentOS servers in the past year because of updates.

    On the other hand I have this task running on a different server with a different OS:

    Priority = DS; Inpri = 8; Time = UNLIMITED seconds.
    Job number = #j3719.
    TUE, NOV 4, 2014, 2:04 PM.

    We do not need plug-and-play; or usb hot-swapping; or hibernation; or screen savers; or audio-video players; or power optimisation. All of which are worthy things in their own right and certainly have their place in computing. While these occasionally have proved convenient for me none are really necessary for a server host and their presence undoubtedly significantly increases the complexity and maintenance burden of the distribution.

    What we need is simplicity, stability, reliability, and consistency. What seems to be happening instead is feature-creep, software-bloat and increased coupling.

    And lest I be accused of ‘wingeing’ from the sideline I have been contributing to Open Source in a modest way since 1995, starting with Sendmail-8.7 on HP-UX. I just have limited time to give over to these things. The selection of RHEL for our primary platform was, in large part, to reduce the resources given over to managing the software. It would be ironic in the extreme were the reverse prove the case.

  • But this isn’t the case, so it’s not really a very productive line of speculation. We _have_ a server community around Fedora, both developers and users.

    This does not match history nor the current situation.

  • As Matthew said, there is a Fedora _server_ community already. Not all Fedora devs are running laptops; but a laptop is one target, just as a server is another. I’ve said it before and I’ll say it again:
    Enterprise != Server. I need an Enterprise distribution for my workstation needs, on a laptop. Dell has been supporting RHEL on their Precision Mobile Workstations (aka ‘high end laptops’) for years; and there is a definite market segment for that use.

    There is no single ‘server-oriented’ way of doing things; different servers have different requirements, and CentOS already gets poked on by those who think version number is a good indicator of how up to date a piece of software is for security and/or bugfix purposes. Owncloud, for instance, is server software, but it needs a far more up-to-date PHP
    than the default in CentOS 6 (Software Collections to the rescue).

    And I have a Cisco 7401 running a different OS (IOS, of course) with the following uptime (and other details…..):
    …………………………………………………………………………………. colo-7400-2 uptime is 6 years, 43 weeks, 3 days, 14 hours, 13 minutes System returned to ROM by reload at 00:40:17 UTC Tue Feb 10 2009
    System restarted at 00:43:11 UTC Tue Feb 10 2009
    … Cisco 7401ASR (NSE) processor (revision A) with 491520K/32768K bytes of memory. Processor board ID 74993065
    R7000 CPU at 375MHz, Implementation 39, Rev 3.3, 256KB L2 Cache
    1 slot ASR midplane, Version 2.0

    Last reset from power-on PXF processor tmc ‘system:pxf/ucode0’ is running ( v1.1 ).
    2 Gigabit Ethernet interfaces
    509K bytes of NVRAM.
    ………………………………………………………………………………….

    But uptime isn’t everything. That router would not have been up that long if there was a more updated IOS available for it (I am running the last security update available from Cisco’s TAC for that box, and it is way out of support, but it’s in a ‘sheltered’ position and works fine for what it is doing).

    Certain updates require a reboot; without ksplice or similar technology it will always be that way for the kernel. Certain glibc updates are similar.

    Many share your needs; at this point in time, CentOS 6 is in that form of maintenance mode. CentOS 7 is still in a ‘can get new features’ mode
    (this due entirely to upstream’s model). If you need something in a stable mode today, use C6. C7 will get there in a few releases.

    The footprint of the needs met by a general-purpose Enterprise Linux distribution is getting larger, not smaller, and the software needed to meet all of these needs is necessarily not as simple as it once was.
    Now, niche distributions can be a bit more simple, but they will not have as broad of a footprint as the general-purpose ones. CentOS, and its upstream, is a general-purpose Enterprise (and Enterprise != Server)
    OS where one of the many use cases is as a traditional server.

    Other use cases exist, and are targeted by upstream as being valuable market segments. That includes the Dell Precision Mobile Workstation line of high-end laptops (like my 2010-vintage M6500), as well as the Precision Workstation desktops and the PowerEdge servers, all of which can be ordered from Dell with a fully-supported RHEL factory-installed.
    But there is also the virtualization market and the lightweight containers (‘cloud’) market. And now there is the IoT market, and those are almost entirely ARM-based systems. Perhaps a ‘tablet’ market for Enterprise Linux will come into play; at the moment the Linux penetration here is mostly Android, with some niche traditional Linux distributions filling certain needs (like Kali Linux for things like the Pwnie Express Pwn Pad).

  • 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:

    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.

    Why not what was suggested, a summary every month or three? How about sending announcements?

    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.

    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….

    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).

    Oh, I remember when you couldn’t be sure, pre-NM, what would be eth0, until you put the MAC address in….

    mark

  • 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 b y the rules.

    —– Original Message —

  • IMHO, active/standby failover hardware should have exact identical configurations down to firmware revisions, so I’m not sure what the issue is.

  • 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

  • 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 —

  • 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”
    To: “CentOS mailing list”
    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]

    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

  • 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…

  • Surely you’re not suggesting that the code a developer writes is dependent on the form factor of the computer on which they write it?
    I’m sure that idea would shock nearly all of the developers of software for both rack mounted servers and embedded devices.

    I think it’s likely that, instead, you believe that you are representative of all of the people who do your job, and that features which you do not need are therefore not needed by others. That logic is quite normal, but completely wrong.

    Take for instance your opinion of power management for NICs. While power management is important to mobile, battery-operated devices, it is also desirable in large data centers. Cooling and power use are big issues for data centers, and that feature was intended for that environment. You dismiss it as laptop-oriented technology, but not all system administrators do.

    “By definition?” Have you heard of DevOps? Whatever your opinion of that idea, there are definitely server admins who take part in development at all levels of the stack.

    I share that frustration, but it has nothing to do with whether or not Fedora developers use laptops. The truth is simply that software becomes more complex over time, that there is a growing value in attacking computer systems, and that the world is increasingly connected. These things act together to create a situation where bugs are more likely in the core components, where it’s harder to update a system without fully rebooting it.

    But there’s hope. There are a number of efforts to produce a system to update the kernel without reboots (ksplice, kgraft, kpatch, and KernelCare). More developers are writing unit tests. Code analysis tools are improving. Both the number of bugs produced and the cost of fixing them are getting better over time, too.

    That’s great for you, but some of those things are really valuable for system admins, especially those who run *really large* numbers of systems. Power and cooling cost money, so optimization has a lot of value. A lot of those plug-and-play and hot-swapping technologies that you deride are essential for high availability systems (such as SAS/SATA
    hot swapping).

  • 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?

    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!”

    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.

    Opposed what, exactly? Everything Poettering has ever done, or did you have something specific in mind?

    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?

    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

    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

    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.

    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.

  • Gordon Messmer wrote:

    On the other hand, it would be relatively easy to determine the number of CentOS users, or CentOS machines, in various categories. For some reason both CentOS and Fedora seem to shy away from gathering this kind of information, or indeed any information from users.

  • I’m interested in any suggestions for how to do this in a “relatively easy” way. Traditionally, Fedora users have been very wary of any opt-out metrics-gathering. So, that leaves either reach-out information seeking (which is valuable but expensive, hard, and time-consuming) or else self-selected feedback, which when not done carefully can be
    _worse_ than nothing.

    And when I say I’m interested in suggestions, that’s not a rhetorical flourish. I mean it. :)

  • Users’ privacy, perhaps? Maybe some users don’t want people to know that they use CentOS, for whatever reason. Fedora/Red Hat tried doing this sort of gathering of data, years ago, and it didn’t work out well
    (I’m trying to remember the name of the program that did the data collection, which was an opt-in thing, but I’m coming up blank).

LEAVE A COMMENT