

The art of endless upgrading - AndrewDucker
http://www.kk.org/thetechnium/archives/2011/04/the_art_of_endl.php

======
sivers
There's a wonderful Linux distribution called Arch Linux -
<http://www.archlinux.org/>

The best thing about it is its "rolling release" release cycle - constantly
updating - every day. See
[https://wiki.archlinux.org/index.php/ArchLinux:About#Release...](https://wiki.archlinux.org/index.php/ArchLinux:About#Release_Cycle)

Part of my daily boot-up of my laptop is to run `pacman -Syu`, which updates
anything that updated in the world. It's so easy! Only tiny changes. Never a
big new release. Just constant little updates. Feels like nothing. You don't
procrastinate because there's nothing to it.

There's gotta be a good metaphor for the real world, there.

~~~
zyfo
Among these "tiny changes" there are also plenty of Big Things. Kernel updates
and python3 migration to name two. Not to mention the sometimes conflicting
packages as a result of staying on the bleeding edge.

Don't get me wrong, I've used Arch Linux as my primary distro for the last two
years and I like their model a lot, but it's more than "nothing to it".

EDIT: Sorry about the somewhat gloomy reply. I agree with your comment in
spirit and think the model is, despite its inevitable problems, a great one.

~~~
mechanical_fish
This model sounds like fun if it's your hobby.

In my world, however, spontaneously upgrading a library or a language runtime
from one major version to the next will cause a bunch of websites to break.
This is exactly what customers pay our company to avoid.

Because, in fact, the "continuous" model is a poor fit for software ecosystems
unless your time scale is sufficiently long. If you don't care about downtime
as measured in hours or days, go ahead and sync up every day. But if you care
about downtime as measured in _minutes_ or _seconds_ , the continuous model
isn't good enough, because at that scale software doesn't evolve continuously
at all. It lurches ahead in sudden jolts, and each component lurches ahead on
its own timescale, and only when you stand way back does the process look
continuous.

The other problem with the "continuous" model is bugs. Software only lurches
ahead on _average_ ; in practice any given patch is as likely to move you
_backwards_ as forwards. Three steps forward, two steps back. If I could be
assured that every change in the Linux kernel was permanent and perfect, it
might be worthwhile to run my websites off the latest kernel source HEAD, sync
up every day, and fix bugs as they arrived. But in the real world, if someone
commits a bug to the kernel source tree on Monday, and it breaks my site, so I
work around the bug, and then someone fixes the bug in the kernel on Friday,
and then I roll back my workarounds, I have just wasted hours of my life that
I will never see again. I have churned my code for no net gain.

(Of course, you may ask: Why didn't I just fix the kernel bug on Monday
instead of working around it in my site's code? Well, the Linux universe is
too complicated for any of us to hold all of it in our heads: I can't fix
kernel bugs, at least not on a timescale of days. So "this isn't the Apple II
anymore; the universe is too big to patch the whole thing at once" is yet
another reason why the continuous model doesn't work.)

It's just not that simple.

~~~
zyfo
Obviously one should not use this frivolous upgrading scheme on a server - I
don't think anyone thinks otherwise.

At my own computer I don't see the problem. Python 3 replaced Python a couple
of weeks ago in Arch, but it's possibly to use Python 2 (which I do,
professionally) without too much hassle. As for kernel upgrades, I can always
wait a couple of days to see if any major bugs creep up (obviously this
requires keeping up with the news, which in itself is a small time
investment).

Since I'm not too experienced I guess there are situations when I would
wholeheartedly agree without you, but I've yet to come across them.

------
auxbuss
Great read. This is something you come to assimilate as you get older --
unless you are very wise, very young. Or perhaps it's cultural. But it
something you are aware of from very early on. And so, so many folk fight it.

To put a geek twist on it, this behaviour always reminds me of kipple; the
concept coined by Philip K Dick. I remember first reading about it -- in Do
Androids Dream of Electric Sheep? -- and being quite struck by the idea.

There's the First Law of Kipple... 'Kipple drives out nonkipple.'

<http://www.43folders.com/2007/12/12/dick-kipple>

~~~
robertk
What makes me weary is the idea of kipple in my brain. If the Singularity
comes, would uploading my consciousness be the equivalent of saving an old,
cluttered hard drive? Won't a fresh install always be superior?

~~~
delinka
Define 'superior' in this context.

Also, how do you have a 'fresh install' of what's in your brain and yet
maintain the experiences that make you who you are? You _are_ kipple.

------
hxa7241
I think there are two different things happening here, which are not quite
pinpointed. We have to work for both, but they are different kinds of work.

With physical things, you want them to keep doing the same thing, but they
degrade themselves. With software, it just stays being the same, but you want
to keep changing what you do with it.

Are there not rather different kinds of knowledge-work demanded there? With
keeping things the same, you have a basically closed-ended aim -- you just
gather more knowledge and you have it cornered. But with changing things
everything is always open-ended -- what you will need to know seems basically
unpredictable.

That is why there is subtle mistake in trying to _design_ software to be
adaptable. It is a contradiction. Design is using knowledge to make something,
but the whole point about the kind of change we are facing here is that it is
basically unpredictable. You cannot design for the future, because you cannot
design for what you do not know. You just have to adapt when it arrives.

Or something.

------
bluehavana
I think people that live on the bleeding edge have know this for a while,
especially devs that live on the bleeding edge.

I've always said software that isn't currently being developed is dead.

~~~
cot6mur3
Agreed. Poorly paraphrasing a line I read somewhere: "Software is like a fish:
once it stops moving it dies."

------
DanielBMarkham
There's a corollary to this: if you value your time, aggressively limit the
number of components in your life.

We do this in tech by bundling up things: I don't have to worry about a
certain cellphone chipset's lifetime because I just toss the entire unit after
a certain period and replace it.

------
16s
Really great article with a good insight into daily life. I like the way he
talks about basic physical maintenance/updates and applies the same concepts
to software/hardware updates. Cleaning the gutters is no fun, but I have to do
it every week in the spring and fall. The moral, I think, is to accept or even
embrace change and learn to deal with it.

------
peterbotond
yes, real life pain is the first step of your immune system. The warnings in
your log should be the software equivalent. Attending either or both requires
human maintanance. Training the body is equivalent of testing software. Yes,
there is something to learn from this articel.:-)

------
itgoon
That which you own, owns you.

------
Jebdm
It's called "entropy".

------
geekzgalore
Excellent read!

~~~
wladimir
Right. The world of software is much more biological than people dare to
admit. Change is a fact of life and every piece of software needs to
continuously adapt (both at the side of platform interfaces and the side of
user requirements), or die.

------
jpr
I wish I could go all Dijkstra on this stupid "must upgrade everything all the
time" -attitude that seems to pervade everyone.

