Debian User Forums

And breaking everything in the process?

Oooo! (furious hand-waving)... I know this one!!

Because they imagine that they are just so much smarter than everyone who came before them (*cough*systemd*cough*).

Yes, genuinely new requirements do some along every once in a while (e.g., digital video editing). But let's face it, we have existing code to fire LEM retrorockets, control robotic explorers on other planets, position telescope mirrors with exquisite precision, just to name a few. When it comes to code, the fact is that most wheels have already been invented.

But every generation decides that it has to "improve" things, even when we know from experience that such "improvements" mean lower-quality code, more bugs, more pointless features, etc.

I am reminded of a moment from back in my school days, when a classmate proposed to examine the question of "Why systems fail." I pointed out that that particular topic has already been researched to death, and I suggested that a more appropriate question was something like, "Given that we already know why systems fail, why do we keep building systems that fail??"

The subtlety was lost on him.

More's the pity.

weedeater64 wrote:

Code: Select all

jeff@hp-630:~$ soundinfo 
soundinfo Ver. 2.3.10 (May 2008)  (c) 1996-2008  Jim Jackson
[soundinfo] No such file or directory : /dev/mixer
[soundinfo] No such file or directory : /dev/dsp

And breaking everything in the process?

in the meantime (jessie 64bit)

Supplemental answer, particularly applicable to re-writes: Because they are too damn intellectually lazy to do the "hard part" of code maintenance--diving deep into existing code to truly and fully understand everything it's doing.

It's commonplace to hear devs complain about how the existing code is too complex and too convoluted to maintain, and therefore simply must be rewritten from scratch.

But the actual fact is that virtually every patch, every kludge, every bugfix in the existing code is a living example of a failure by the original developers (and everyone who followed them) to fully and completely comprehend the requirements and the use-case of the software in question. But because reading code is way harder than writing it, the young Turks decide to scrap everything and start over.

Here's the problem: At the end of the day, the young Turks are no better than the original coders at understanding the "edge cases" that necessitated the need for all that "convoluted" code in the first place. By throwing away all the existing code, they are essentially giving themselves a lobotomy.

One example among many: When the KDE devs scrapped KDE 3.x in 2008, they lamented at great length about how the existing 3.x code base had become unmanageable and unmaintainable. Fast-forward six years, and the KDE devs justified a rewrite-from-scratch by lamenting at great length about how the existing 4.x code base had become unmanageable and unmaintainable. (Do we detect a pattern here?)

In my experience, the very best coders are so meticulous in their thinking and so comprehensive in their internal documentation that their code almost never needs to be rewritten, merely adapted ever-so-slightly to accommodate a new use-case. More to the point, their thinking so straightforward and so clearly articulated that their existing code can be reused and repurposed with virtually no effort at all.

But in coding, as in all things involving humans, mediocrity inevitably prevails, simply because mediocrity is far more commonplace than excellence.

(At least that's what they tell me.)

fireExit wrote: bla..bla..bla..bla...
[/code]

And how is that siggen working out for you?


Also, Debian loves to brag about how it has 20,000 packages, but how many of those 20,000 packages stopped working years ago?

Why do you leave them in the repos if you broke them?

It is very tiresome, searching for apps, installing them, only to find out they have not worked in years.

weedeater64 wrote:And how is that siggen working out for you? Asshole.

Talking to the mirror, again?

dasein wrote:..... the young Turks

I don't understand this reference and I don't think you're referring to a rap group like Google seems to tell me.

No_windows wrote:

dasein wrote:..... the young Turks

I don't understand this reference and I don't think you're referring to a rap group like Google seems to tell me.

C'mon, let's see a screen cap of a working siggen.

No_windows wrote:

dasein wrote:..... the young Turks

I don't understand this reference and I don't think you're referring to a rap group like Google seems to tell me.

The magic search syntax is define, as in (Try it at Google or Startpage)

@weedeater64
Uncalled for and in violation of forum rules - take a break.

Change for the sake of change? Probably.

Here's one perfect example:

In Debian 7 Synaptic has a quick search box on the toolbar. Quick and easy.


But, in Debian 8, the quick search box is gone, replaced by a button, doubling the effort to get to search.


Why?

Damn you for pointing out this thing I hadn't noticed... Now it's going to annoy me forever.
There seems to be some weird push for "everything as a cryptic icon where once was a menu / text input" in UI design these days, I don't know where it's coming from, but it's utterly infuriating.
At least this one still says "search" on it.

NFT5 wrote:But, in Debian 8, the quick search box is gone, replaced by a button, doubling the effort to get to search.

Reminds me of something Mandriva did circa 2008. They have their own equivalent of Synaptic, and some GNOME-headed numbnut convinced the devs to suppress library packages from the package list, claiming that it was "too confusing." As a result, displaying all packages available in the repo required an extra (and unnecessary) step of ticking a check box (which, of course, wasn't displayed on the main screen).

Of course, you know what happened. The frequency of folks asking "Where the farq is library X?" in the forums skyrocketed, leeching time and attention away from actual problems. But the devs (many of them GNOME-heads) were too damn stubborn to admit (and correct) the error.

(Wow, I sure am feeling chatty.)

dasein wrote:(Wow, I sure am feeling chatty.)

Maybe because the thread topic is the equivalent of nerd-sniping for disaffected old geezers.

dilberts_left_nut wrote:

dasein wrote:(Wow, I sure am feeling chatty.)

Maybe because the thread topic is the equivalent of nerd-sniping for disaffected old geezers.

Yeah, and I used to get paid for it, too.

(Man, that was one great gig.)

NFT5 wrote:Change for the sake of change? Probably.

Here's one perfect example:

In Debian 7 Synaptic has a quick search box on the toolbar. Quick and easy.


But, in Debian 8, the quick search box is gone, replaced by a button, doubling the effort to get to search.


Why?

open synaptic now.

Thanks fireExit. Can't whinge about that one any more.

My point remains, though. Why change it?

NFT5 wrote:Thanks fireExit. Can't whinge about that one any more.

Oh yes you can. And you should.

NFT5 wrote:My point remains, though. Why change it?

Exactly.

A(ny) UI change has to be able to justify its own existence, in terms of reducing either time-on-task or error rate. A(ny) change that can't do that does not qualify as an improvement. At best, it's gratuitous, and therefore a waste of developer resources.

NFT5 wrote:My point remains, though. Why change it?

Maybe because the search through the button has better results than the quick search box?

I used to have this experience in my Ubuntu era (so pre-2008) where I found that the quick search box worked quite crappy whereas the button search actually found things. Not sure if Synaptic in Debian had the same issues, because in that case I understand the change.

I think there are several things here that, while vaguely related, should be treated separately:

1. A genuine and (relatively) objectively justified need for a new code base that will make progress/maintenance easier.

2. A change that favours new paradigms that will be liked by a "newer generation" and disliked by others who have
a working paradigm they don't want to give up.

3. A change for change's sake which no one asked for, usually just of an aesthetic or trendy nature.

I think that in FOSS we mostly discuss the really large projects and they will have individual components which will
adhere to all of these categories. Hence I don't like the example of a massive conversion such as KDE4 to 5 as a
justification for a futile change. While that may be true in some cases, it's also great to see
-the better support for Wayland and more recent Xorg hacks which make the DE depend less on deprecated and unmaintained
technology
-the split and reduction of KDE backend functionality to individual pieces, so that we don't have to pull in
a myriad of dependencies just to run a programme on another DE
(and thinking of how I don't like what GTK3 is becoming, I'm looking forward to a time when running LxQt
with individual KDE programmes will be the lean option )

Same goes for the KDE3 to 4 conversion. Most people criticise the whole endeavour, but actually just mean the
UX/UI changes, the borked file search or Kmail, but this massive conversion surely had a lot of good benefits, like
a more modern desktop with better theming capabilities and font display.

I guess it boils down to what target group one belongs to, but in our pain over the loss/lack of support of something
we find to be a great computing experience, we tend to project the frustration onto the entire very complex phenomenon.