The art of endless upgrading | Hacker News Reader

The art of endless upgrading

kk.org

95 pointsAndrewDucker19 comments

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...

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.

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.

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.

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.

The rolling release model is great, but only if there is a separate stable track (Chrome is a great example of this approach). This distinction assures that developers can stay on the cutting edge and experiment with new ideas, while users keep a working system.

Of course I'm not taking about a Debian-like stable, but a rolling stable delayed at most a couple of weeks, during which the most important bugs can be caught and resolved.

Arch is great, but I would never use it on a production server, the risk is just too high.

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

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?

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.

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.

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.

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

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.

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.

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.:-)

That which you own, owns you.

It's called "entropy".

Excellent read!

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.

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

Reply on news.ycombinator.com