CentOS - Jan 2015 - Design changes are done in Fedora

On Mon, Jan 5, 2015 at 9:22 PM, Warren Young <wyml at etr-usa.com>
wrote:
>
> Docker will eat away at this problem going forward.  You naturally will not
already have Dockerized versions of apps built 10 years ago, and it may not be
practical to create them now, but you can start insisting on getting them today
so that your future OS changes don?t break things for you again.
>
Yes, it is just sad that it is necessary to isolate your work from the
disruptive nature of the OS distribution. But it is becoming clearly
necessary.
>> I built a
>> CentOS7 to match my old CentOS5 pair.   It can do the same thing, but
>> there is no way to make them actively cluster together so the new one
>> is aware of the outstanding leases at cutover or to have the ability
>> to revert if the new one introduces problems.
>
> I believe that was ISC?s fault, not Red Hat?s.
Agreed - and some of the value of Red Hat shows in the fact that the
breakage is not packaged into a mid-rev update.
> Perhaps your point is that Red Hat should have either a) continued to
distribute an 8-year-old version of dhcpd with EL7 [1], or b) somehow given you
the new features of ISC dhcpd 4.2.5 without breaking anything?  If so, I take
this point back up at the end.
>
Maybe document how you were supposed to deal with the situation,
keeping your lease history intact and the ability to fail over during
the transition.   My point here is that there are people using RHEL
that care about this sort of thing, but the system design is done in
Fedora where I'm convinced that no one actually manages any machines
doing jobs that matter or cares what the change might break.   That
is, the RHEL/Fedora split divided the community that originally built
RH into people who need to maintain working systems and people who
just want change.  And they let the ones who want change design the
next release.
>> And those things
>> span much longer that 10 years.  If you are very young you might not
>> understand that.
>
> My first look at the Internet was on a VT102.  I refer not to a terminal
emulator, but to something that crushes metatarsals if you drop it on your foot.
>
> I think I?ve got enough gray in my beard to hold my own in this
conversation.
So, after you've spent at least 10 years rolling out machines to do
things as fast as you can, and teaching the others in your
organization to spell 'chkconfig' and use 'system ...' commands,
wouldn't you rather continue to be productive and do more instead of
having to start over and re-do the same set of things over again just
to keep the old stuff working?
>> But if
>> numbers impress you, if you count android/Dalvik which is close enough
>> to be the stuff of lawsuits, there's probably more instances of
>> running programs than anything else.
>
> There are more JavaScript interpreters in the world than Dalvik, ART,[2]
and Java ? VMs combined.  Perhaps we should rewrite everything in JavaScript
instead?
>
I'm counting the running/useful instances of actual program code, not
the interpreters that might be able to run something.  But JavaScript
is on the rise mostly because the interpreters upgrade transparently
and the hassle is somewhat hidden.
> If we consider only the *ix world, there are more Bourne-compatible shell
script interpreters than Perl, Python, or Ruby interpreters.  Why did anyone
bother to create these other languages, and why do we spend time maintaining
these environments and writing programs for them?
We spend time 'maintaining' because the OS underneath churns.
Otherwise we would pretty quickly have all of the programs anyone
needs completed.   I thought CPAN was approaching that long ago, or at
least getting to the point where the new code you have to write to do
about anything would take about half a page of calls to existing
modules.
> Why even bother with ksh or Bash extensions, for that matter?  The original
Bourne shell achieved Turing-completeness in 1977.  There is literally nothing
we can ask a computer to do that we cannot cause to happen via a shell script. 
(Except run fast.)
Well, Bourne didn't deal with sockets.  My opinion is that you'd be
better off switching to perl at the first hint of needing
arrays/sockets or any library modules that already exist in CPAN
instead of extending a shell beyond the basic shell-ish stuff.  But
nobody asked me about that.
> If you think I?m wrong about that, you probably didn?t ever use sharchives.
Of course I used sharchives - and I value the fact that (unlike most
other languages) things written in Bourne-compatible shell syntax at
any time in the past will still run, and fairly portably - except
perhaps for the plethora of external commands that were normally
needed.   Perl doesn't have quite as long a history but is just about
as good at backwards compatibility.   With the exception of
interpolating @ in double-quoted strings starting around version 5,
pretty much anything you ever wrote in perl will still work.   I'm
holding off on python and ruby until they have a similar history of
not breaking your existing work with incompatible updates.
>
> If I *did* have to distribute libboost*.so, I?d just ship them in the same
RPM that contains the binaries that reference those libraries.
>
> This is no different than what you often see on Windows or Mac: third-party
DLLs in c:\Program Files that were installed alongside the .exe, or third-party
.dylib files buried in foo.app/Contents/Frameworks or similar.
>
Yes, on windows, you can just pick a boost version out of several
available and jenkins and the compiler and tools seem to do the right
thing.   On linux it may be possible to do that, but you have to fight
with everything that knows where the stock shared libraries and
include files are supposed to be.    While every developer almost
certainly has his own way of maintaining multiple versions of things
through development and testing, the distribution pretends that only
one version of things should ever be installed.  Or if multiples are
installed there must be a system-wide default for which thing executes
set by symlinks to obscure real locations. Never mind that Linux is
multi-user and different users might want different versions.  Or at
least it was that way before 'software collections'.
> Or were you planning on demanding that EL5 be supported forever, with no
changes, except for magical cost-free features?
No, what I wish is that every change would be vetted by people
actively managing  large sets of systems, with some documentation
about how to handle the necessary conversions to keep things running.
I don't believe anyone involved in Fedora and their wild and crazy
changes actually has anything  running that they care about
maintaining or a staff of people to retrain as procedures change.
There's no evidence that anyone has weighed the cost of
backwards-incompatible changes against the potential benefits - or
even knows what those costs are or how best to deal with them.

-- 
   Les Mikesell
     lesmikesell at gmail.com

On Jan 6, 2015, at 11:43 AM, Les Mikesell <lesmikesell at gmail.com>
wrote:
> On Mon, Jan 5, 2015 at 9:22 PM, Warren Young <wyml at etr-usa.com>
wrote:
> 
> So, after you've spent at least 10 years rolling out machines to do
> things as fast as you can, and teaching the others in your
> organization to spell 'chkconfig' and use 'system ...'
commands,
> wouldn't you rather continue to be productive and do more instead of
> having to start over and re-do the same set of things over again just
> to keep the old stuff working?
Having been through a bunch of these transitions already (SysV -> Linux bingo
-> BSD -> OS X?) it doesn?t greatly bother me.

Given that I?ve spent more time on Red Hattish Linuxes than any other *ix, I
suppose I?m more surprised it?s lasted as long as it has than I am upset that
it?s changing again.
>> There are more JavaScript interpreters in the world than Dalvik,
ART,[2] and Java ? VMs combined.  Perhaps we should rewrite everything in
JavaScript instead?
> 
> I'm counting the running/useful instances of actual program code,
I rather doubt you?ve done anything like actual research on this.

If you?re just buying Oracle?s bogus ?3 billion? number uncritically, there are
a bunch of problems with that, but I?d have to drag us off topic to discuss
them.  In any case, *ix falls into the noise floor if this is the scale you?re
using to gauge the success of Java.

If you?re trying to say that there?s more CPU-hours of JVM use on *ix than JS in
browsers, that sort of elitist argument has been repeatedly defeated.  Big Iron
vs minicomputers, Unix workstations vs the PC, ?real? Unix vs Linux, the PC vs
the smartphone?

Time and time again, the forces driving the end-user market end up taking over
the hrumph hrumph serious computing market.  This has already happened with JS
vs Java in the ?3 billion? space Oracle wants to claim, and I see no reason why
it can?t eventually steamroll the *ix world, too, via node.js.

Even if you wave a magic wand and get the JVM onto every *ix box ? which is
currently very much *not* the case ? you?re ignoring the Tiobe numbers I posted
in the previous reply.  There?s plenty to argue about when it comes to Tiobe?s
methodology, but not so much that you can scrape together anything like a
majority for any single language.

I think the real difference we have on this point is that I?m not actually
serious when I propose that the whole world rewrite all software in My Favorite
Language just to make my job easier.
> JavaScript
> is on the rise mostly because the interpreters upgrade transparently
> and the hassle is somewhat hidden.
No, JavaScript is on the rise because the web is on the rise, and it managed to
secure the spot as the web?s scripting language through an accident of history. 
That is all.
> Otherwise we would pretty quickly have all of the programs anyone
> needs completed.
    "There is nothing new to be discovered in physics now. All that
     remains is more and more precise measurement.?

         ? William Thomson, Lord Kelvin, 1900

Yes, *that* Kelvin.
> I thought CPAN was approaching that long ago, or at
> least getting to the point where the new code you have to write to do
> about anything would take about half a page of calls to existing
> modules.
Ah yes, the ever-near future where everyone will plug a few Lego-like software
blocks together and thereby construct any useful program they wish, while
lacking any clue about what?s going on.  That future?s been 5 years away for the
past 5 decades.

It?s as likely today as ever ? which is to say, ?not? ? and it isn?t the Fedora
development community?s fault that we have not yet achieved this nirvana.

Even in electronics, where you have physics to constrain the set of possible
realizations, we haven?t even approached this level of nirvana.  For every
Arduino success story, you have ten stories of cluebies who burned up their H
bridge motor driver because they didn?t understand that P=I?R, and that R is
almost never zero.

(If R is zero, you?re dealing with cryogenics, so all you?ve done is shifted
into a different class of cluebie errors that?s more likely to leave said
cluebie injured.)

Software is ?pure thought-stuff,? to quote Fred Brooks.  We have very little
constraint on the scope and range of things we can create in software.  Any
attempt to package software up into a usefully-small set of
precisely-characterized little black boxes is a Quixotic dream.
>> Why even bother with ksh or Bash extensions, for that matter?  The
original Bourne shell achieved Turing-completeness in 1977.  There is literally
nothing we can ask a computer to do that we cannot cause to happen via a shell
script.  (Except run fast.)
> 
> Well, Bourne didn't deal with sockets.
BSD Sockets didn?t exist in 1977.

In any case, you?re willfully ignoring the nature of *ix type shell script
programming.  A shell script?s ?function library? is the set of all programs in
the PATH.  Drop nc/ncat/netcat/socat in the PATH, and suddenly your shell script
knows how to talk to BSD sockets.  It?s really no different than installing
libnsl on a Solaris box.

No nc-alike here?  Okay, echo the machine code to disk for an ELF binary that
makes the necessary syscalls, using octal escapes.  No, don?t cheat and echo out
a C or assembly language program, go straight to the metal, you softie.
> My opinion is that you'd be
> better off switching to perl at the first hint of needing
> arrays/sockets or any library modules that already exist in CPAN
> instead of extending a shell beyond the basic shell-ish stuff.
And there you are, foot on the slippery slope; down you go.

Perl is even less widely deployed than Java.  It isn?t even on all *ixes by
default.  The BSDs, Cygwin, and Arch (at least) all leave it out of the stock
install.  POSIX doesn?t require it, so it also isn?t in most small embedded *ix
systems, where you at least find a POSIX shell.

If you were to try to get Perl into POSIX, I think you?d fail.  Perl 5 is just
too big and hairy.  No one is going to try to reimplement the whole thing.

Python has been reimplemented several times, but I think it?s still got a
smaller installed base than Perl, simply due to getting popular later.

Lua?s small enough to reimplement relatively easily, but not powerful enough on
its own to rival the POSIX shell as a general-purpose *ix programming system. 
It needs to be embedded into something else, which provides a richer function
library.

Ruby and Scheme are powerful and small enough to make it as a stepping stone in
POSIX between shell and C, but not popular enough to win the war a champion for
either would have to fight to accomplish it.

There you have the mess.  There is no universally-installed language today that
fills the gap between shell and C, and there?s no likely prospect for such a
thing.

You can?t just wish it away by telling everyone to switch to Java, or
JavaScript, or whatever else.  All you?re going to do is create another
?standard? in the XKCD sense:

    https://xkcd.com/927/
> pretty much anything you ever wrote in perl will still work.
That?s becoming less true as Perl becomes stricter.  A lot of old code won?t run
without warnings any more, and if you turn on things like ?use strict,? as Perl
books have been recommending for over a decade, a huge amount of old code won?t
even run.

Then you have the Modern Perl movement, which is responsible for the increase of
CPAN modules that only work on Perl 5.10+.

    http://www.josetteorama.com/what-is-modern-perl/

Since the capacity of the Perl developers is not infinite, this movement will
cause more and more old Perl mechanisms to be deprecated, so that they can
eventually be removed.

Perl 6 was an attempt to achieve this in one big jump.  Perl 5 is in the process
of slowly accreting some of Perl 6?s features.  Eventually, I think the jump to
Perl 6 won?t look so big, and Perl 6 will finally get off the ground.  Perhaps
even soon.
> holding off on python and ruby until they have a similar history of
> not breaking your existing work with incompatible updates.
Those counters both got reset relatively recently: the Python 3 (ne? 3000) and
Ruby 1.9 transitions were fairly traumatic.

I?m sure Oracle wishes Java 6 would disappear finally, too.

There is no sanctuary, Les.  Change is everywhere in computing.
>> Or were you planning on demanding that EL5 be supported forever, with
no changes, except for magical cost-free features?
> 
> No, what I wish is that every change would be vetted by people
> actively managing  large sets of systems
EL7 had a long beta period.  Where were you?

Yeah, I know, not your job.  But since you?re choking throats over here on the
CentOS ML instead of choking Red Hat?s throat via a RHEL support contract, I
think that puts the responsibility on your shoulders.  You can?t expect someone
else to scratch your itch just because you loudly demand it on the Internet. 
You either have to pay for it somehow, or hope that someone else also has your
itch *and* wishes to pay for it themselves.

Is that all this is?  Trying to get someone else riled up enough that they?ll
fork EL6 for you?

On Tue, 2015-01-06 at 16:07 -0700, Warren Young wrote:

>     "There is nothing new to be discovered in physics now. All that
>      remains is more and more precise measurement.?
> 
>          ? William Thomson, Lord Kelvin, 1900
Now means the current time. Now is not, and never will be, The (unknown)
Future.

In the real world of using computers productively for repetitive tasks,
people want stability and perhaps faster running programmes. No one ever
wants a major upset of being forced to use a different method to perform
the same tasks.

Young men are enthusiastic about implementing new ideas. Old men with
substantially more experience wisely want to avoid disrupting
well-running systems. Time is money. Disruptions waste money and cause
errors.


-- 
Regards,

Paul.
England, EU.

On Tue, Jan 6, 2015 at 5:07 PM, Warren Young <wyml at etr-usa.com>
wrote:
>
>>> There are more JavaScript interpreters in the world than Dalvik,
ART,[2] and Java ? VMs combined.  Perhaps we should rewrite everything in
JavaScript instead?
>>
>> I'm counting the running/useful instances of actual program code,
>
> I rather doubt you?ve done anything like actual research on this.
Not really, but start with the number of running android devices - and
I think it is reasonable to assume that they are running something,
checking gmail, etc.   It's safe enough to say that's a big number.
> If you?re trying to say that there?s more CPU-hours of JVM use on *ix than
JS in browsers, that sort of elitist argument has been repeatedly defeated.  Big
Iron vs minicomputers, Unix workstations vs the PC, ?real? Unix vs Linux, the PC
vs the smartphone?
No, I'm saying it pretty much owns the phone/tablet space and the
examples of elasticsearch (and other lucene-based stuff), jenkins,
etc. show it scales to the other end as well.
> Time and time again, the forces driving the end-user market end up taking
over the hrumph hrumph serious computing market.  This has already happened with
JS vs Java in the ?3 billion? space Oracle wants to claim, and I see no reason
why it can?t eventually steamroll the *ix world, too, via node.js.
node.js seems like the worst of all worlds - a language designed _not_
to speak to the OS directly with an OS library glued in.  But it is a
good example of how programmers think - if one says you shouldn't do
something, it pretty much guarantees that someone else will.
> I think the real difference we have on this point is that I?m not actually
serious when I propose that the whole world rewrite all software in My Favorite
Language just to make my job easier.
I'd settle for just not changing the languages in ways that break
already written software.  But even that seems too much to expect.
>> JavaScript
>> is on the rise mostly because the interpreters upgrade transparently
>> and the hassle is somewhat hidden.
>
> No, JavaScript is on the rise because the web is on the rise, and it
managed to secure the spot as the web?s scripting language through an accident
of history.  That is all.
I think you are underestimating the way the working interpreters get
to the users.  And the way the code libraries mask the differences.
If users were exposed to version incompatibilities the popularity
would vanish. In fact, being able to actively detect and work around
incompatibilities is a large part of the reason it is used at all.
>> I thought CPAN was approaching that long ago, or at
>> least getting to the point where the new code you have to write to do
>> about anything would take about half a page of calls to existing
>> modules.
>
> Ah yes, the ever-near future where everyone will plug a few Lego-like
software blocks together and thereby construct any useful program they wish,
while lacking any clue about what?s going on.  That future?s been 5 years away
for the past 5 decades.
Not it the sense that there's nothing new to invent, but that every
sysadmin in every organization and every home user should not need to
invent new processes to manage their machines.
> It?s as likely today as ever ? which is to say, ?not? ? and it isn?t the
Fedora development community?s fault that we have not yet achieved this nirvana.
Really?   How have they made it any easier to manage your 2nd machine
than your first?
> Software is ?pure thought-stuff,? to quote Fred Brooks.  We have very
little constraint on the scope and range of things we can create in software. 
Any attempt to package software up into a usefully-small set of
precisely-characterized little black boxes is a Quixotic dream.
It is also purely reproducible.  Do something right once and no one
should ever have to waste that thought again.
>>> Why even bother with ksh or Bash extensions, for that matter?  The
original Bourne shell achieved Turing-completeness in 1977.  There is literally
nothing we can ask a computer to do that we cannot cause to happen via a shell
script.  (Except run fast.)
>>
>> Well, Bourne didn't deal with sockets.
>
> BSD Sockets didn?t exist in 1977.
Precisely.  Once there was close to a 1-1 mapping of shell and
external commands to system calls.  Now there isn't.
> In any case, you?re willfully ignoring the nature of *ix type shell script
programming.  A shell script?s ?function library? is the set of all programs in
the PATH.  Drop nc/ncat/netcat/socat in the PATH, and suddenly your shell script
knows how to talk to BSD sockets.  It?s really no different than installing
libnsl on a Solaris box.
I wasn't ignoring it. I just was avoiding another rant about how those
have not been maintained in a backwards compatible way either.  Even
though shell syntax is stable, the programs are usually just glue
around an assortment of tools that no longer match section 1 of the
unix manuals.
> No nc-alike here?  Okay, echo the machine code to disk for an ELF binary
that makes the necessary syscalls, using octal escapes.  No, don?t cheat and
echo out a C or assembly language program, go straight to the metal, you softie.
I might have done that for 8-bit z80 code, but I've since learned that
it is rarely worth getting that intimate with the hardware.
> You can?t just wish it away by telling everyone to switch to Java, or
JavaScript, or whatever else.  All you?re going to do is create another
?standard? in the XKCD sense:
>
>     https://xkcd.com/927/
Well no, at this point you can't say that java is yet another new
thing - probably not even groovy since that's mix/match with java.
Maybe scala.
>
> Perl 6 was an attempt to achieve this in one big jump.  Perl 5 is in the
process of slowly accreting some of Perl 6?s features.  Eventually, I think the
jump to Perl 6 won?t look so big, and Perl 6 will finally get off the ground. 
Perhaps even soon.
I think everyone involved with perl is sane enough to know that perl 6
is not a replacement for perl 5.  It's something different.  I just
hope the Fedora people get it.
>> holding off on python and ruby until they have a similar history of
>> not breaking your existing work with incompatible updates.
>
> Those counters both got reset relatively recently: the Python 3 (ne? 3000)
and Ruby 1.9 transitions were fairly traumatic.
Well, I've avoided a couple of traumas then.  But those transitions
don't seem to have completed.  And they probably won't until all
distros ship multiple versions so programs can co-exist long enough to
fix the broken parts.
> Is that all this is?  Trying to get someone else riled up enough that
they?ll fork EL6 for you?
No - mostly hoping someone would point out something I had overlooked
that makes the transition easy.  I thought the computers were supposed
to work for us instead of the other way around.


-- 
    Les Mikesell
      lesmikesell at gmail.com