[CentOS] wifi on servers and fedora [was Re: 7.2 kernel panic on boot]

Fri Dec 11 00:11:21 UTC 2015
Warren Young <wyml at etr-usa.com>

On Dec 10, 2015, at 2:56 PM, m.roth at 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.