How long do you go without upgrading FreeBSD to a newer release?

[Mehmet Erol Sanliturk]

On Thu, May 20, 2010 at 10:28 AM, Roger Vetterberg <roger at vetterberg.com>wrote:

> On 2010-05-16 17:42, Dan Naumov wrote:
>
>> Hello folks
>>
>>  [snip]
>
>>
>> Do you liva by the "If it's not broken, don't fix it" mantra or do you
>> religiously keep your OS installations up to date?
>>
>>
>> - Sincerely,
>> Dan Naumov
>>
>
> Depends on the installation requirements.
>
> I know of two 2.2.8 installations on PII hardware still running like
> champs, not a glitch in god knows how many years of 24/7 operation. None of
> them are exposed externally so there are no security considerations. The
> customers that runs them are still more then happy with their servers so I'm
> actually a bit curious to see how long they will keep them running.
>
> I have a few other servers that are highly exposed. My mantra there is to
> run _verified_ software. Not necessarily the latest, but software that has
> no known bugs and has been well tested.
> To religiously update everytime there is a new version and blame it on
> security is stupid. How do you know that a brand new version of a software
> does not contain a big gaping security hole unless it has been tested in the
> wild yet?
>
> --
>
> R
>


More than two years I am studying FreeBSD and some Linux distributions ,
mostly I am using Mandriva Linux ( attaching USB sticks mounts them
automatically , and burning CD/DVD is very easy . No one of them require
mount . )  .

After very desperate experiences ( loss of collection of large amounts of
downloaded documents and other files after upgrading the operating system
either by automatic update , or approved update of installed components ) I
have learned that upgrading an actively used operating system ( including
Windows ) is plainly wrong .  Now I am NOT upgrading any more any one ( I
have turned Off automatic updates , and I am ignoring notices about
availability upgrades ) .

The best policy seems to be one of the following :

 (i) install onto a new computer , test it , and if it is working very well
transfer data onto
     new system , and keep old system for a new release/update cycle .
     This step is most suitable for production systems exposed to outer
world .
(ii) attach a new hard disk to the computer , copy all of the present files
to the new
system ,
    update it , test it , if it is successful , use previous hard disk for a
new release/update
    cycle ,
(iii) back-up all of the data , and try update . Testing suitability may
take a long time .

In steps (ii) and (iii) , do not load new data during tests , because at the
end , all of them may be destroyed .
( No one of the above steps are suitable for a proprietary , activation
based operating system because they are not allowing so many computer and/or
hard disk changes . )

Therefore , the problem is a "system analysis and design" process .

Thank you very much .

Mehmet Erol Sanliturk