[CentOS] Design changes are done in Fedora

[Warren Young]

On Dec 31, 2014, at 4:41 PM, Les Mikesell <lesmikesell at gmail.com> wrote:

> On Wed, Dec 31, 2014 at 11:03 AM, Warren Young <wyml at etr-usa.com> wrote:
>> You keep talking about the cost of coping with change, but apparently you believe maintaining legacy interfaces is cost-free.
>> 
>> Take it from a software developer: it isn’t.
> 
> OK, but should one developer make an extra effort or the bazillion
> people affected by it?

That developer is either being paid by a company with their own motivations or is scratching his own itch.  You have no claim on his time.

Open source is a do-ocracy: those who do the work, rule.

People throw all kinds of hate at Poettering, but he is *doing things* and getting those things into consequential Linux distributions.  The haters are just crying about it, not out there trying to do things differently, not trying to win an audience.

I don’t just mean an audience standing around your soapbox.  Crazies on the street corner can manage that.  I mean an audience of people who are willing to roll your new Linux distro out over their infrastructure.

I repeat my call to action: If you think EL6 was better, fork it.  If enough people agree with you that sitting still is better than what Red Hat is doing, you *will* get Red Hat’s attention.  Even if the end the result is an EGCS-like divergence and re-merging, you will cause something to happen.

>> Result?  We cannot afford to maintain every interface created during the quarter century of Linux’s existence.  Every now and then, we have to throw some ballast overboard.
> 
> And the user base that depended on them.

Nonsense.  This is open source.  EL6 is still there, if that’s what you want.  You’re free to maintain it as long as you like.

>>> Are you offering to do it for free?
>> 
>> This is one of the things my employer pays me to do.  This is what I’m telling you: the job description is, “Cope with change.”
> 
> So either it "isn't hard",  or "you need a trained, experienced,
> professional staff to do it".   Big difference.  Which is it?

You’re trying to shove a crowbar in where there is no gap: It isn’t hard for an experienced staff.  It is one of the reasons our various organizations employ us.

Why do you believe this is a stringent requirement?  I thought CentOS was the distro targeted at organizations staffed by competent technical professionals.  That’s me.  Isn’t that you, too?

>>> I'm asking if computer science has advanced to the point where adding
>>> up a total needs new functionality, or if you would like the same
>>> total for the same numbers that you would have gotten last year.
>> 
>> Mathematics doesn’t change.  The business and technology worlds do.  Your example is a non sequitur.
> 
> If you are embedding business logic in your library interfaces,
> something is wrong.

Once again you’re making non sequiturs.

Your example was that arithmetic doesn’t change, then you go off and try to use that to explain why EL7 is wrong.  So, where is the part of EL7 that doesn’t add columns of numbers correctly?

When the rest of the technology world changes, Red Hat has two options: they can react to it, or they can keep churning out the same thing they always have done.  The latter is a path toward irrelevance.

OS/2 is a fine OS for solving 1993’s problems.

Given a choice between disruptive change and a future where RHEL/CentOS is the next OS/2, I’ll take the change.

> Take something simple like the dhcp server in the disto.    It allows
> for redundant servers - but the versions are not compatible.   How do
> you manage that by individual node upgrades when they won't fail over
> to each other?

Is that hypothetical, or do you actually know of a pair of dhcpd versions where the new one would fail to take over from the older one when run as its backup?  Especially a pair actually shipped by Red Hat?

I’m not interested in the reverse case, where an old server could not take over from a newer one, because there’s no good reason to manage the upgrade that way.  You drop the new one in as a backup, take the old one offline, upgrade it, and start it back up, whereupon it can take over as primary again.

>> Okay, so that’s embedded Linux, it doesn’t seem remarkable that such systems never change, once deployed.
> 
> Which sort of points out that the wild and crazy changes in the
> mainstream distributions weren't all that necessary either…

No.  The nature of embedded systems is that you design them for a specific task, with a fixed scope.  You deploy them, and that’s what they do from that point forward.  (Routers, print servers, media streamers…)

New general purpose OSes do more things than their predecessor did.  Their scope is always changing.  (Widening, usually, but occasionally old functionality does get chopped off.)

If all you need is a print server, go buy a Lantronix box and be done with it.

If you need the power of CentOS, you’re probably not actually doing the same thing with it year after year.

Just to keep with the print server example, I know there’s been a lot of change in *my* world with printing in the past 10-20 years.

The change from parallel to USB wasn’t trivial.  Plug & play device support is one of those things the hated systemd does for us.

In the past 5 years or so, I’ve pretty much retired all my Samba print servers, because every printer I’ve bought during that time has a competent print server built in.

It’s no surprise then that CentOS 7 isn’t anything like Red Hat Linux 7.

>>> You'd probably be better off in java if you aren't already.
>> 
>> If you actually had a basis for making such a sweeping prescription like that, 90% of software written would be written in Java.
> 
> I do.  ...The java stuff has been much less problematic in porting across
> systems - or running the same code concurrently under different
> OS's/versions at once.

And yet, 90% of new software continues to *not* be developed in Java.

Could be there are more downsides to that plan than upsides.

> I don't think the C++ guys have even figured
> out a sane way to use a standard boost version on 2 different Linux's,
> even doing separate builds for them.

This method works for me: 

  # scp -r stableserver:/usr/local/boost-1.x.y /usr/local
  # cd /usr/local
  # ln -s boost-1.x.y boost

Then build with CXXFLAGS=-I/usr/local/boost/include.

>>>> I’ve never done much with Windows Server, but my sense is that they have plenty of churn over in their world, too.
>>> 
>>> Yes, there are changes - and sometimes mysterious breakage.  But an
>>> outright abandonment of an existing interface that breaks previously
>>> working code s pretty rare
>> 
>> Yes, well, that’s one of the things you can do when you’ve got a near-monopoly on PC OSes, which allows you to employ 128,000 people. [1]
> 
> And you only get that with code that keeps users instead of driving them away.

Seriously?  I mean, you actually believe that if RHEL sat still, right where it is now, never changing any ABIs, that it would finally usher in the Glorious Year of Linux?  That’s all we have to do?