Software errors

[Mark Greenwood]

On Sunday 23 May 2010 19:35:45 Reinhold Rumberger wrote:
> On Sunday 23 May 2010, Mark Greenwood wrote:
> > On Sunday 23 May 2010 14:06:47 Reinhold Rumberger wrote:
> > > On Sunday 23 May 2010, Mark Greenwood wrote:
> 

<snip snip snippety snip>
> 
> No, you didn't - but you've obviously missed my point... :-P
> (I don't have any "buttons" about closed source software - it's how I 
> earn my living. I have one about MS, but that's different)

Well, there's something we agree on :)
 
> > Forget about comparisons with Windows and Macs, those
> > are not even relevant to what I'm trying to say. Forget about
> > 'software quality' because that's also not part of my argument,
> > it's a meaningless bullshit phrase invented by people with
> > spreadsheets.
> 
> That isn't true, and anyone who ever touched a line of code written 
> by someone else knows that. Well-written software follows some design 
> and has a decent architecture which means that problems can be fixed 
> with relative ease and the handling, etc. is consistent.

True, but that's not what I mean by 'software quality' and it's not what the people with spreadsheets mean either. Good design is what engineers strive for, but it's not measurable and so the clipboard-ites don't understand it. They want numbers, more bugs fixed means more quality. This pushes one of my buttons :)

> 
> > What I'm talking about is the nature of, let's call it 'Free
> > Software Development',
> 
> How about "open collaborative software development"? ;-)

Agreed :)

> Just since it has nothing to do with price and we might want to try 
> to emphasise what you think is causing problems... :-)
> 
> > and the inevitable outcome of that
> > process.  A distro release is a snapshot of many different
> > threads of development at a point in time.
> 
> It isn't. It is a snapshot of many different threads of development 
> at many different points in time with some changes by the 
> distributor.
> 
> > This may easily mean
> > that the release of one thread of development has not yet caught
> > up with the latest changes in the release of another thread. Now,
> > the distributors have the control to fix bugs, and to choose
> > which versions of applications to take, but are you seriously
> > suggesting that if some fundamental library completely changed
> > its API that Kubuntu would fix every application that depended on
> > it? If you are, you are a fantasist my friend.
> 
> Why are you assuming that they would ship this new lib if it broke 
> half the system? 

It was an extreme example. But it happened to me on a monthly basis with Karmic. Every time I installed a new version of KDE4 (from the ppa repo) there was some library incompatability (usually an update of Qt) that broke a lot of stuff. I ended up having to compile digikam, kdenlive, and one or two others from SVN source on a regular basis.

> Also, most libraries will be backwards compatible 
> and/or installable side-by-side with older versions. That's what the 
> version numbers in the name are for.
> 
> My point is that the same problems occur in the CS world, Windows 
> being an example. Sure, not in the base release, but then that is 
> unusable because it contains little to no end-user software.

And that's my point too. The base release of Kubuntu contains *all* the end user software. Testing it is an unimaginably complex problem. Breakage is assured at some point. The same thing doesn't happen all that often in the closed source world because there isn't the collaboration that means application A depends on library B and library C which are all written by different people working to their own schedules. The app developers on Windows have a (reasonably) stable baseline to develop on. Linux app developers have a constantly shifting base system to cope with. The fact that Windows Vista is a pile of steaming horse dung has no bearing on this opinion, this specific point still stands :)

> You 
> tried upgrading to Vista when it came out? 

That's what made me switch to Kubuntu :)

> I was unfortunate enough 
> to be forced to work with it, and believe me, that kind of breakage 
> is *not* unique to open/free software development.
> 
> > That's the way it is, and that is why things that worked in one
> > release are often broken by the next. It's just the way it is -
> > lots of individuals working to no particular plan with no
> > resources for testing.
> 
> That, too, is incorrect. IME, testing in popular open source software 
> projects is better organised and more effective than in most big 
> software houses. 

I simply disagree. Testing in a large software house is what I do. Believe me, we have resources and automation that any OSS project would kill for, and we still don't catch all the bugs. A 6 month testing cycle is standard for our large projects. Kubuntu has a 6-month *release* cycle, and most of the testing is done by volunteers who download the betas. You can't call that thorough or organised.

> And your idea of the chaotic development in OSS is 
> rather strange to me - no software can grow in size to a point where 
> it seriously matters without some pretty well-defined kind of plan 
> behind it.

But surely nobody working on a particular oss project is working to deadlines for distro releases (unless they're employed by the distro of course)? Why would anybody do that?

I'm not knocking open source development, don't get me wrong. This all started because I told a guy that stuff like this just happens in Linux, it's the nature of the beast. I speak from personal experience. I'm not trying to make any judgements, just pointing out a fact. It's a fact that my Kubuntu system breaks more often than my Windows XP one or my MacOS X one, and I believe that the nature of the way they are released and developed is the reason for that. But I live with it, because I believe in it.

Mark

> 
>   --Reinhold
> 
>