Jan Stary wrote on 11/14/16 03:00:
On Nov 14 00:14:19, pa...@ecentryx.com wrote:
But the very next step in the upgrade blows away the system by overwriting
it anyway. Right?
What could happen? What if following the normal procedure of untaring the OS
sets on top of the existing system fails midway? Then you have an
inconsistent system too.
Yes, you have an inconsistent system, as opposed to nothing.
This sounds like someone who is not confident in their backup/restore
procedure, if one even exists. I think you need to worry more about that
than me saving a few megabytes with my upgrade process.
Like I mentioned a couple times in the thread, I have "level 0" dumps;
that's consistency. I would not classify that as "nothing." There is a
reason why restore(8) and ftp(1) are included on bsd.rd.
This behavior of mine may stem from my days as a hard-real-time embedded
systems engineer where we had to get rid of every single byte that did not
matter. I used to count the assembly instructions and add up all the clock
cycles for each hardware interrupt routine to make sure we would never
stall/slow the system. I just like minimal I guess.
Say I compile a C program on your system,
which gets linked to /usr/lib/libc.so.84.2.
After an upgrade, my program no longer works.
Bad, bad admin!
Oh yeah, and before you know it your crufty libc.so.84.2 is 2 years old
and full of security vulnerabilities. Thank god your users can still use
it and you don't have to bother them with a recompile.
I thought the philosophy of the project is to move forward for the sake
of proactive security and correctness, not to rely on buggy legacy code
because it's convenient and lazy.
