Why do 'they' keep breaking stuff?

[Theologian]

SOLVED
{This is a deliberately provocative question, but I do consider myself to be a justified cynic, given that Linux is my main OS (I have an old machine that still has MSDOS6/W3.1 on it: it would have FreeDOS on it were it not for the following problem). EDIT: Problem solved courtesy of a PCLOS live cd - 1992 i486 now running FreeDOS, & therefore M$-FREE! }

While I do appreciate that many Linux-based distros (& users) seem to pride themselves on being on the 'bleeding edge', I must ask why developers seem to be dedicated to breaking applications that have been working 'perfectly' for quite some time.

For example, I have been using fdutils to "superformat" floppies to 1722KB for some time, & it has been an invaluable utility, one that is helping to keep an old engine working, up to now!

The latest version of fdutils no longer works properly:

"sudo superformat" will not format a floppy to more than 1440KB,

"sudo fdformat /dev/fd0u1722" now receives the reply of "No such file or directory":

BLOODY MARVELLOUS!

Fortunately, I do know what to do, which at the simplest level means removing the current version & installing the old one that worked, from my personal 'repo'. It is an inconvenience, but this is Linux ... & fortunately it wasn't a system-breaking update.

Of course there are several bug reports relating to this, but is it really a bug, or is it an unnecessary inconvenience? And if it is a bug, then what the hell is the package doing in the repository without a clear warning?

The other factor is that I can be fairly certain that this is not a one-off incident: how many other updated applications are going to not work? Will I have to do a complete reinstall, yet again?

IMHO, this is exemplary of the sort of stuff that either puts newbies off, or, gives the impression that Linux is too unreliable to be worth the effort.

So, if any developers are reading this:

IF IT WORKS, THEN WHY DO YOU KEEP BREAKING IT?

[Suo_Eno]

2 quotes to enter into this subject:-
_____________________________________________________________________________________________________
"Engineers like to solve problems. If there are no problems handily available, they will create their own problems."
Scott Adams (Dilbert)
______________________________________________________________________________________________________________________
Normal people... believe that if it ain't broke, don't fix it. Engineers believe that if it ain't broke, it doesn't have enough features yet.
Scott Adams (Dilbert)
______________________________________________________________________________________________________________________

The man truly deserve a Nobel for these even if it's somewhat obvious common sense.But satirical contents aside, this isn't an easy topic.If adding features means "breaking" out of a mold that can constrain said function(s) then it's an acceptable calculated risk.Unfortunately this theory are a lot harder in practice so yeah...

[pythagorean]

I don't think people intentionally break things really. There are millions of lines code and no one can predict how an actual machine will function once a change has been made. Even if a change breaks nothing on four or five different machines, nothing is to say that the proposed change will work with every possible machine because someone might have some weird legacy system with some unusual packages on it...

The advantage of using Macs is that Apple only installs their OS on a small number of different configurations, so everything works. Linux on the other hand is thrown onto every possible configuration of hardware and expected to work, from machines that were build 10 years ago to the latest laptops. No other OS can boast that.

HEY, that makes me think they ought to invent a "Linux Experience Index" like the Windows Experience Index that rates your configuration's ability to run linux.

[Theologian]

...

Scott Adams' work is brilliant, insightful & SO accurate!

[waldo]

IF IT WORKS, THEN WHY DO YOU KEEP BREAKING IT?

One could ask of you a similar question:

If it works, then why did you replace it with a newer system?

The answer, of course is simple. We are all tinkerers. That's what we do!

[grey1960envoy]

I believe "if it ain't broke ,you haven't learned !!!!

[Pilosopong Tasyo]

as a programmer/developer (albeit old-school - DOS-based C, Pascal, dBase, etc.), here's my personal point of view.

there are a lot of reasons why users have this perception of [sic] "if it works, then why do you (programmers/developers) keep breaking it?" and things they don't understand that involves a program's development cycle.

one perspective i can think of at the moment is dependency purgatory (or hell if you prefer). as pythagorean pointed out, it is not really our intention to break our work out on a whim. during the course of developing a program/project, we may pull in work done by others and incorporate/modify their code according to the project's needs. the project may also depend (and quite often it will) on packages/libraries written by others. these packages/libraries (which btw started as projects in their own right) were written, tested and made available for use as dependencies on which a more complex program is built on. so, instead of reinventing the wheel, we would use dependencies that does the work for the lot of functions in a project. this accelerates program development, lesser coding to be done, lesser bugs to deal with, etc.

so, a project has been written, gets alpha-tested, beta-tested, bugs get ironed out, goes through the RTM stage, gets baked, packaged and released for public consumption. there will be updates, of course. improvements to the program, bug fixes, additional features (humorously referred to as program bloat in some circles), etc. the same applies to dependencies -- packages/libraries that the program relies on for it to function correctly.

the problem here is if a dependency has been changed in such a way that the code in the new version is no longer compatible/no longer supports code in the old version that the program depended on in the first place, then that's the point where the program breaks or strange bugs start to appear. the main program itself IS working. it's the dependency that introduced the bug(s) in the first place. a dependency that was written by a third party and thus beyond our control.

sure, we can make adjustments in the project's code to adapt to the dependency improvements/changes. isn't that what bug reports are for in the first place? we're not psychics and can't be expected to anticipate and squish every bug in a program. just like everyone else, programmers/developers are human too.

sure, we can just rip the actual code that works from the dependency and put that as part of the project. that'll ensure the program will work since it no longer depends on other packages/libraries that get updated in the repositories. but then again, we're introducing unnecessary bloat to the project. it's bad practice and might introduce unforeseen problems in the future.

i don't represent every programmer/developer on this post. some may agree, others don't and yet others are in-between. as i said earlier, it's my personal point of view, and this is just one of those perspectives.

the way i see it, we usually get the bad rap because of the notion that we intentionally break things. it wasn't intentional, just some circumstances beyond our control.

[jesica]

[waldo]

Perhaps a better answer was given by the great French philosopher, René Descartes:

I break, therefore I am.

[Theologian]

GREAT REPLIES: MANY THANKS!

The world of operating engines continues to amaze & frustrate me, & will probably drive me deeper into the inside of sanity, or worse, into the realm of development/coding rather than just testing.

It still baffles me that the same version (number) of an application will work perfectly on one OE but not on another.

My guess is that it's in the nature of Linux to always be on the edge, never quite complete, never complacent, never boring ... OK, maybe Fedora & Ubuntu are becoming a wee bit 'normal', & idiots like me break stuff like that on some kind of 'principle'!

[thenewguy]

I think it depends on the developer. Some coders aren't happy unless they're re-writing and re-writing again pieces of code to make them better or more modular. I remember working with one guy who re-wrote thousands of lines of code one month because they "weren't to standard". When I pointed out that his new code constantly crashed, wasn't backward compatible and ran on fewer architectures, his reply was that at least it was "standards compliant".

Other developers try not to break things, but have to balance stability with adding new features. Often times adding something new will break something else. Releases become a juggling match between fixing things and trying to please users who are demanding more features.

Some developers just aren't good at what they do and constantly break things because they don't know what they are doing.

Sometimes developers end up breaking something because something else on the software stack broke. As an example, a little while ago I ran into an issue where I was using library version 1.2. When library version 2.0 came out it wasn't backward compatible at all. So I was faced with re-writing large chunks of code or being stuck with an unmaintained library which would probably be dumped by the distributions shortly.

[Pilosopong Tasyo]

It still baffles me that the same version (number) of an application will work perfectly on one OE but not on another.

Well, if we keep certain conditions/complications/exceptions out of the equation, it's simply because the application in question was designed and written to natively work well under that particular environment using supporting libraries and dependencies for that particular environment.

Bottom line is, it's a great injustice to put a 100% blame on the programmer(s)/developer(s) for "breakage(s)." Let's also add other mitigating circumstances, like the variety of hardware the application is to be run on, support libraries written by 3rd party, and the end-user -- yup, you read it right -- YOU, the end-user as part of the equation.

[Theologian]

[quote="Pilosopong Tasyo"][/quote]
Problem solved: I installed LM9 LTS Fluxbox, got rid of 100MiB of things I didn't want, installed 250MiB of things I did want, got a remarkably small update, & everything is working better than ever - at least until I break it.