On Dec 10, 2015, at 2:56 PM, m.r...@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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Reply via email to