any problem going from 9.x (don't laugh) to 11 directly?

Polytropon freebsd at
Thu Feb 15 08:07:16 UTC 2018

On Wed, 14 Feb 2018 23:08:26 -0800, C Gray wrote:
> Moving to something called stable means that the build (not the
> release) is stabilized. 

FreeBSD's terminology is quite simple and works like a destillery:

HEAD / CURRENT	-> experimental changes, stuff might disappear,
		   code might not even build; very frequent updates
		   to repository

STABLE		-> changes verified will usually build and run as
		   intended; still frequent updates

RC		-> release candidate, still changes possible for
		   actual release; fewer updates

PRERELEASE	-> about to be released; only smaller fixes

RELEASE		-> tested and verified; updates only as security

Each stage is more reliable than the one before, better tested,
and more suitable for general use.

> [...] it goes for anything manufactured in a world where fixing
> costs and the "customer is always right" has been mutated into
> "the customer is always ripe". ] 

Or: As long as you pay, you get what we want!

The customer (or consumer) hardly has a choice. Due to excessive
vendor lock-in by means both of software (proprietary, nonstandard,
classified) and of legal (contracts), they hardly can change their
fate once they got "on hook". Entry is cheap, but keeping systems
alive becomes more and more expensive. For business users, this is
absolutely no problem due to tax law: (1st) they can mark the ex-
penses as material costs and use them for deduction, and (2nd) they
can relay their increasing costs all the way down to the final
consumer who has no other choice than paying all the parasites
along the way.

> In Test and QA (integrated in with Development) we were taught
> (by losing customers and costs/time/resources lost to fixing
> issues directly related to poor-planning, short-cutting, and
> thinly-testing) NOT to pass those inherent problems on to
> later and to end-users/customers, because it all comes back
> to you in the end... 

No, because customers have a volatile memory. Remember Intel's
trouble with Meltdown and Spectre? Nobody cares. Car manufacturers
cheating? No consequences (especially not in Germany). Planned
obsolescence? Doesn't matter, just buy a new one.

Oh, regarding Intel: Why not leave the testing to the customers?
"Here is a patch for the microcode. Go ahead, install it, and
when your system should crash, please create an excessive report
for us to examine. Thank you!" :-)

But that's not specific to Intel. Sometimes, I have to deal
with "premium business software" where "premium" seems to imply
that you get buggy software, no support, no explanations, and
you should call a specific phone number - with "premium" pricing
of course. And users actually _pay_ to be treated like that!
Unbelievable... but reality.

> Spaghetti code, non-modularity, platform-dependencies... they're
> all coming back as "computer science" is fully replaced by the
> rapid-release strategies of  "computer marketing".

There is a term for this, more than 30 years old: RAD (Rapid Appli-
cation Development). :-)

> Planned obsolescence is a behavioral issue more than a materials
> problem, and as a view accepted tends to hurt you directly at a
> cellular level rather than indirectly at an update level.

It is accepted as a requirement (!) for a "free market" to work.
The "invisible hand" seems to enforce this mindset.

> If FreeBSD r11 doesn't show me less issues than r10 which
> should have less issues than r9, then the opposite may actually
> be true (or TrueOS).

The main problem here is that every new release introduces new
functionality, and sometimes includes fundamental changes to
system-vital infrastructures. Those additions to the codebase
need special care, as you pointed out correctly.

> The drive to eradicate real-world stability is lost to the
> fetish of "new"-ness. 

This is what consumers have been trained to "want". There now
often seems to be the mindset "when it's new, it's good", no
matter if it's _really_ good.

> That is a capitulation to the extraction and exploitation of time.
> As Orwell put it quite well, and which also covers the speeding
> of "now" into a disappearing "then", the "future" really ceases
> to exist at all:
> 	"Who controls the past controls the future. Who controls
> the present controls the past."
> The squeeze between deleting the past by PCers and PCs
> 'transmerging humans' in the future is suffocating and the only
> way to stop to allow [an unsuffocated] thinking is to do just
> that.... 

As business dictates: Thinking should be left to those who create
the ad content. Mindless drones can implement the crap that "happy"
consumers will finally buy. ;-)

> My suggestion would be to go for 10.4! It's tested more to itself
> than 11 is to itself. Other peoples release habits have little
> to do with actual quality because they do not assure QA. Time
> allows people to use "the town square" approach to solving
> issues, and at least creates known "avoid" flags and "workaround"
> shares.

Still the v10 branch approaches EOL, and v11 will soon be the
only branch that receives support.

> Maybe trust your experience rather than a release#-incrementing
> algorithm, esp. when it is followed by ".0".

That's why today version numbering starts at N.1. :-)

> Decide based on the rate of flaws rather than on a speed of
> releases, and consider that "change for change's sake" is a
> pastime (the passing of time) and investing habit of wasting
> your future time by "selling the past short".

Speed of releases doesn't really seem to be an indicator for
software quality. Yes, I know: "release early, release often".
You can probably do that when you're a web-based startup in
the Bay Area. But there are customers who want to install
something _once_, and then keep using it for years (and not
only months or weeks before the first updates and security
patches for the newly installed product arrive).

Sidenote: I have a customer with a FreeBSD 4.4 server in his
office (for special purposes). The machine still works, and
it does what its users expect. For almost 20 years now. Let's
see which "essential software" of today will still run un-
changed (!) in 20 years. ;-)

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list