Date: Thu, 15 Feb 2018 09:07:04 +0100 From: Polytropon <freebsd@edvax.de> To: C Gray <frankfenderbender@council124.org> Cc: freebsd-questions@freebsd.org Subject: Re: any problem going from 9.x (don't laugh) to 11 directly? Message-ID: <20180215090704.c1f4dd98.freebsd@edvax.de> In-Reply-To: <8212BAA6-DC01-4AD5-BCBF-012D97447060@council124.org> References: <20180215011907.6620E1B2DE28@ary.qy> <868tbvhwix.fsf@red.stonehenge.com> <7795e899-160e-f6af-c02d-6fa44982f864@ShaneWare.Biz> <8212BAA6-DC01-4AD5-BCBF-012D97447060@council124.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 patches 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. ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180215090704.c1f4dd98.freebsd>