General view that fewer releases == fewer failures is generally not
true, especially in today's data driven age. That is why Mozilla
improves/fixes/releases Firefox often.
In general, Firefox quality has improved for most users since they
started rapid releases. They can support it by real data.
I understand that thing might not always work for your exotic setup.
You might have to, eventually, file bugs and submit patches to Mozilla
to keep it working for you.
I would definitely encourage to see yearly State of DevOps compiled by
Puppet for data on that more frequent software product and service
releases and enabling automation increases quality and reliability.
Findings from the 2015 State of DevOps Report:
* High-performing IT organizations experience 60X fewer failures
and recover
from failure 168X faster than their lower-performing peers. They
also
deploy 30X more frequently with 200X shorter lead times.
* Lean management and continuous delivery practices create the
conditions for delivering value faster, sustainably.
* High performance is achievable no matter if your apps are
greenfield, brownfield or legacy.
* DevOps initiatives launched solely by C-level executives or from
the grassroots are less likely to succeed.
* IT managers play a critical role in promoting diversity and
limiting burnout.
There is more about this in: https://en.wikipedia.org/wiki/DevOps
It goes beyond upstarts like Puppet, here is IBM (source of your
beloved T60's)
https://www.ibm.com/developerworks/library/se-devops/part1/
It is worth considering.
-Tomas
On Sat, 2017-05-13 at 17:28 -0700, Keith Lofstrom wrote:
> On some of my machines, I run 32 bit Scientific Linux
> 6.9, a clone of Red Hat Enterprise Linux 6.9. RHEL6.x
> is supported until November 2020, perhaps to 2023 if Red
> Hat repeats past practices, and SL (supported by a team
> at Fermilabs, with extra scientific packages added), is
> an enhanced clone of RHEL.
>
> However Firefox 52.1esr, the supposedly stable extended
> release, SEGMENTATION FAULTS with the 32 bit version.
> Safe mode ditto. No trace files left after the segfault.
>
> Could be worse; On one of my laptops (hacked hardware),
> Firefox sometimes crashes Linux, causing a reboot.
> My favorite programming language is solder, but that
> doesn't leave trace files, either.
>
> So, I downrevved Firefox to 45.9esr, turned off automatic
> updates, and will put up with the nagging messages from
> websites demanding the latest and greatest. Better than
> crashes. Maybe the next ESR release won't segfault, and
> I can turn updates back on.
>
> I'm told that version 52 is a MAJOR re-redesign of Firefox,
> an all-singing all-dancing multithreaded media munching
> monster. Not competely tested, apparently. Perhaps
> Mozilla should work on their testing processes first.
>
> BTW, the good thing is that Firefox stores itself
> entirely in /usr/lib/firefox, so changing versions is
> as easy as moving them into directories with names like
> /usr/lib/firefox45, then simlinking /usr/lib/firefox to
> that. When the next version XXesr comes along, I will
> remove the symlink, install to /usr/lib/firefox, rename
> that to /usr/lib/firefoxXX, then symlink to that. A
> small hassle, but better than crashes.
>
> ------
>
> While I am slowly upgrading the machines to SL7.3 64 bit,
> I have a 20 year accumulation of more than 1000 binaries
> to recompile and verify, so this will take a while.
>
> I run long term support distros so I don't have to do this
> often, but our friends at Mozilla seem to prefer churn.
> Perhaps they should get a job at Microsoft, churning Word.
>
> I prefer the fewer failures, fewer features corner of the
> map. I can generate plenty of my own failures, thank you.
>
> Keith
>
_______________________________________________
PLUG mailing list
[email protected]
http://lists.pdxlinux.org/mailman/listinfo/plug
