history of CADT

Posted May 1, 2016 19:04 UTC (Sun) by josh (subscriber, #17465)
In reply to: history of CADT by ebassi
Parent article: Devuan Jessie beta released

I doubt it was all that accurate when jwz first said it, either; it just seems like a generic insult, about as meaningful as "young whippersnappers". For that matter, "CADT" was originally used to describe the case of marking bugs in an old system obsolete because a new system exists that (probably doesn't) have those bugs, rather than triaging them; it doesn't represent a completely general catch-all for every gripe about GNOME 3 differences.

I do find it rather amusing, having followed the GNOME 1 to GNOME 2 transition, how remarkably similar the complaints are. If the complaints about GNOME 3 have seemed more voluminous, I think it might just be because GNOME 2 had far more users than GNOME 1 ever did.

to post comments

history of CADT

Posted May 1, 2016 19:21 UTC (Sun) by hitmark (guest, #34609) [Link] (1 responses)

The basic problem though is that if those bugs had been fixed, one now had assurance that they were fixed. But by rewriting the relevant components, one do not know that. And the rewrite is likely to hide a whole pile of new bugs.

history of CADT

Posted May 1, 2016 19:44 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

>The basic problem though is that if those bugs had been fixed, one now had assurance that they were fixed

Hardly the case. There are no assurances that a bug will not popup again due to mere code changes. It doesn't require a rewrite to introduce regressions at all. Testing can help reduce such instances but don't eliminate it.

history of CADT

Posted May 1, 2016 19:46 UTC (Sun) by louie (guest, #3285) [Link]

Yeah, I should have added sarcasm tags - sorry for any confusion. I am literally the CADT so I Have Opinions. ;)

history of CADT

Posted May 1, 2016 20:32 UTC (Sun) by epa (subscriber, #39769) [Link] (38 responses)

I understand 'Cascade of Attention-Deficit Teenagers' to refer to the process where an older release of some software is marked 'out of support' and all bugs in the bug tracker filed against that version are automatically closed (unless someone explicitly reopens them or updates the version). This is particularly noticeable with Fedora, where a release goes out of support a year and a bit after it first came out. All the bug reports, which could contain useful information and more likely than not(*) are still applicable to the latest release, are essentially dropped. That may be an unavoidable choice if there just isn't the manpower to triage and fix bugs properly, but it is certainly dispiriting to file a bug, see it sit around in the tracker for a few months, and then be closed with some automated message.

(*) Even in the fast-moving world of Linux and Fedora in particular, code doesn't get thrown out and rewritten in one year. The half-life of code, and bugs, is much longer than that.

If there are legitimate reasons to believe that old bugs will have been fixed (or at least rendered unreproducible) by a rewrite of some component, then it's fine to go and close them en masse. If the distribution moves from SysV init to systemd, to pick an example entirely at random, it might make sense to close bugs filed against the older init system. But not to just spray the whole bug tracker with CLOSED because Fedora 22 is now out and so Fedora 20 is no longer 'supported'. Bugs are not requests for support and need not follow a 'support' cycle. For sure there are lots of useless bug reports but the good ones are invaluable information by someone who has taken trouble to send it to you. If you do get so overwhelmed that you have to throw away all reports older than a certain point, this should be a case by case decision.

history of CADT

Posted May 1, 2016 21:56 UTC (Sun) by pboddie (guest, #50784) [Link] (37 responses)

That may be an unavoidable choice if there just isn't the manpower to triage and fix bugs properly, but it is certainly dispiriting to file a bug, see it sit around in the tracker for a few months, and then be closed with some automated message.

Indeed. I just read Luis's blog post admitting his role in the JWZ rant on the topic, but the point of the rant is not that some specific fault existed somewhere in the code and thus didn't exist any more because that code was gone: it is that a problem was observed with the software and suddenly an assertion is being made that the software no longer has the problem, with no effort made to check whether this is really the case.

It's like claiming that some gadget, having had a component replaced, will no longer suffer from a problem purely because a new component has been used, while it is possible that the new component has precisely the same design defects that caused the reported problem. As an end-user, having bugs closed ostensibly for housekeeping purposes gives the impression that you care more about the design and architectural issues of the software than the people supposedly responsible for writing it.

history of CADT

Posted May 2, 2016 3:20 UTC (Mon) by pizza (subscriber, #46) [Link] (36 responses)

> [...] it is that a problem was observed with the software and suddenly an assertion is being made that the software no longer has the problem [...]

No, the tickets were marked as NEEDINFO, with a message that basically amounted to "hey, let us know if this problem is still relevant."

> As an end-user, having bugs closed ostensibly for housekeeping purposes gives the impression that you care more about the design and architectural issues of the software than the people supposedly responsible for writing it.

Or, perhaps, it's a sign that the developers need to know if this problem still exists (and thus still worth looking into) when they already have a ton of other stuff to do that they already know is important.

(Incidentally, if you want someone to be responsive to your bug reports on any sort of guaranteed schedule, that's called a service level agreement and requires forking over a non-trivial pile of money on an ongoing basis)

history of CADT

Posted May 2, 2016 8:13 UTC (Mon) by ovitters (guest, #27950) [Link]

To add to this: http://yarchive.net/comp/linux/bug_tracking.html, as written by Linus Torvalds on Mon, 30 Apr 2007:

> On Mon, 30 Apr 2007, Adrian Bunk wrote:
> >
> > My ideal was always that reported bugs should be fixed.
>
> ..and this is where we differ.
>
> OF COURSE bugs should be fixed. But you seem to think that there is
> something magical and special about every single bug-report.

The entire conversation is worthy to read and goes way more into detail than some black/white view on things. This thread changed my view on things. Before this one, I was in the "never ever close a bugreport unless it is fixed" camp.

history of CADT

Posted May 2, 2016 9:29 UTC (Mon) by pboddie (guest, #50784) [Link] (34 responses)

No, the tickets were marked as NEEDINFO, with a message that basically amounted to "hey, let us know if this problem is still relevant."

My problem with this, and I've noted this a few times previously, is that such things can be far easier to check for the people developing the software: it may well be a case of the end-user having to upgrade large parts of their distribution the hard way, whereas the developers are actually building and presumably running the software themselves on a frequent basis. I know that end-users are often perceived to be whiners with an entitlement complex, but asking them to go through substantial inconvenience, just to verify what might be regarded as a mere assertion of a problem that supposedly doesn't affect anyone else, is only going to elicit the kind of rant that brought us the CADT label.

In addition, checking certain things and not "needing info" would also be part of any kind of release validation process. You can't check everything, but automated testing is a lot more widespread than it was when JWZ coined the CADT label. Asking end-users to "beta test" software is somewhat optimistic: it assumes that those people are as enthusiastic about the development of the software as the developers when they may actually depend on the software for real-world use. Indeed, the end-users may in some cases be more serious users of the software than the developers, but that doesn't mean that their seriousness should be called into question because they aren't willing to break their setup just to run an errand.

(Incidentally, if you want someone to be responsive to your bug reports on any sort of guaranteed schedule, that's called a service level agreement and requires forking over a non-trivial pile of money on an ongoing basis)

Well, sure. And they can even still ignore those bug reports, anyway, if my experience with one enterprise distribution is any indication. Maybe my employer wasn't paying enough money or something. Meanwhile, if people want high-quality bug reports, they should at least preserve a culture in which those reports are considered to have some value. Otherwise, what's left is just a mountain of reports that might as well be swept off the desk, whose owners have probably moved on to using something else, anyway.

history of CADT

Posted May 2, 2016 11:24 UTC (Mon) by pizza (subscriber, #46) [Link] (33 responses)

> Meanwhile, if people want high-quality bug reports, they should at least preserve a culture in which those reports are considered to have some value.

The sad fact of the matter is that the overwhelming majority of bug reports are of very low quality and have even less intrinsic value. Raising those up to a level in which they are actually useful (if that is even possible) takes a great deal of time and effort. Time and effort that most developers don't have to spare. Heck, more time and effort than even the reporters themselves seem to have.

And yes, that "time and effort" includes translating that bug report into an automated test. If it's something that can even be automated. How do you test something on a platform you don't personally have access to, or in the case of OSX, can't even *compile* for?

Sure, you can claim that developers have some sort of moral obligation to care about each and every every special snowflake of a reported bug, but that is a naive view utterly divorced from reality.

I can't even count the number of bugs I've personally closed after after effectively sitting in a NEEDINFO state for months; quite frankly if the reporter doesn't care enough to actually answer basic questions, then there's no point in my taking time away from something that is already actionable.

history of CADT

Posted May 2, 2016 12:49 UTC (Mon) by pboddie (guest, #50784) [Link] (3 responses)

Sure, you can claim that developers have some sort of moral obligation to care about each and every every special snowflake of a reported bug, but that is a naive view utterly divorced from reality.

I'm not saying that at all. What you quoted even indicates that I said pretty much the opposite of that:

Meanwhile, if people want high-quality bug reports, they should at least preserve a culture in which those reports are considered to have some value.

There will always be reports that are incoherent, incomplete or even incorrect. But developers should realise that they are missing an opportunity to reassure themselves of the quality of their work if they bulk-close bugs because the high-quality reports will be lost. And not taking such opportunities tends to store up problems for later.

You can say that developers have priorities and that they might have better things to do with their time. That, and the closely-related "nobody is paying me to do this" phenomenon, are separate topics with the latter being a particular area of concern because it shows how the investment priorities around Free Software development (and software development in general) can be misguided and self-defeating.

history of CADT

Posted May 2, 2016 14:05 UTC (Mon) by pizza (subscriber, #46) [Link] (2 responses)

> it shows how the investment priorities around Free Software development (and software development in general) can be misguided and self-defeating.

If by "investment priorities" you mean someone in a suit making funding decisions for other people's employment, then yes, I'd agree with you. Such is the disappointing reality of commercial concerns. But for the majority of Free Software developers/projects, even the higher-profile ones, "investment" means "donating their time."

My F/OSS, first and foremost, is written to meet my own personal needs, but it is released to the public "in the hope it will prove useful, but without any warranty whatsoever..." Anything beyond that will require someone to convince me the effort is worthwhile. Sometimes it is, sometimes it isn't. It's not that I necessarily expect to get paid, but rather a matter of opportunity cost and attempting to have a healthy work/life balence.

I'll end this by pointing at a recent _On the Fast Track_: http://comicskingdom.com/on-the-fastrack/2016-03-17

history of CADT

Posted May 2, 2016 17:05 UTC (Mon) by pboddie (guest, #50784) [Link] (1 responses)

If by "investment priorities" you mean someone in a suit making funding decisions for other people's employment, then yes, I'd agree with you. Such is the disappointing reality of commercial concerns.

Indeed.

But for the majority of Free Software developers/projects, even the higher-profile ones, "investment" means "donating their time."

And this is where everybody gets short-changed, although I'm not currently sure of the strategy required to transform the environment from "work for free to impress some random company to hire you to work on something else/proprietary" and "it's a labour of love and they don't expect to get paid for it" to one where companies might actually understand that properly investing in Free Software helps keep them and their economic venue viable in the long term.

My F/OSS, first and foremost, is written to meet my own personal needs, but it is released to the public "in the hope it will prove useful, but without any warranty whatsoever..." Anything beyond that will require someone to convince me the effort is worthwhile. Sometimes it is, sometimes it isn't. It's not that I necessarily expect to get paid, but rather a matter of opportunity cost and attempting to have a healthy work/life balence.

Sure. If someone says that "it would be really nice if you added this or I'll have to stop using it" but doesn't actually offer any incentive, which is a classic guilt-tripping technique pulled by random Internet people, then after a while you get to learn that you let those people go. Then again, some people might want to persuade other people that their work is hot stuff: there, the level of pandering to random strangers might need to be somewhat different, but nothing I've written falls into that category and I don't have any aspirations for it to do so any more, either.

I'll end this by pointing at a recent _On the Fast Track_: http://comicskingdom.com/on-the-fastrack/2016-03-17

(After a script-induced trawl of the Internet instigated by the page concerned...) Well, there's some truth in that. But when my work involved such activities, I did find that some of the more frustrated people did have a point, even if I had to sit and listen to a lengthy rant in a language I did not learn as a child which mostly reflected that person's fairly legitimate frustration with something I probably only had some involvement in delivering.

history of CADT

Posted May 2, 2016 18:53 UTC (Mon) by pizza (subscriber, #46) [Link]

> And this is where everybody gets short-changed, although I'm not currently sure of the strategy required to transform the environment from "work for free to impress some random company to hire you to work on something else/proprietary" and "it's a labour of love and they don't expect to get paid for it" to one where companies might actually understand that properly investing in Free Software helps keep them and their economic venue viable in the long term.

The OpenSSL fiasco is a good example of what happens when critically important Free Software gets short-changed. ("Which fiasco," you might ask? And that is exactly my point)

Fortunately, it seems to have accomplished quite a lot of good. At least now more folks are aware that software doesn't grow on trees..

history of CADT

Posted May 3, 2016 16:09 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (28 responses)

You're right that bug reports are often of low quality. For example last night I read the original post in this thread:

https://community.letsencrypt.org/t/error-creating-new-au...

... and just now I popped back to see "whoops" the user reporting the problem omitted to mention that they had set up a cron job that was repeatedly issuing authorizations. When they got an error about too many authorizations they just couldn't conceive that this might be related, and so they just didn't even mention it at all. Such people aren't able to help themselves, it's a huge burden to try to help them with even the simplest problems they run into...

But the thing that gets projects a reputation for CADT isn't that, it's where a project does rewrites _rather_ than even examine bugs. That's a huge problem with Free Software, but it's one that we could do a LOT more to resist. Today if you say you're making Version 2 of program X and it's a rewrite so you won't be reading any of the old bug reports, we package up Version 2 as if it's somehow an improvement. We may even say people should move to Version 2 because the prior software is "unsupported" which implies Version 2 will be supported. But that's a lie. The decision to not read the old bug reports is a tacit acceptance that Version _2_ is unsupported, that in fact you don't support software at all, whatever the version. Which is fine, it's your time to spend as you please, but packaging the Version 2 software up and telling people to upgrade makes this error look like success and so the distributions are doing their users a disservice by encouraging it.

The persistent belief that if only we could start over from a clean slate things would be better is not a disease unique to Software Engineering, you'll find it in town planning, in product marketing, all over the place. You have to learn to stop thinking that way, and for the teenagers who are often most enthusiastic about "burn it down and start fresh" projects that's not going to happen overnight. But as I wrote, we should be _discouraging_ this, not encouraging it.

history of CADT

Posted May 3, 2016 16:18 UTC (Tue) by louie (guest, #3285) [Link] (27 responses)

GNOME had a paid full-time person working on "examining bugs" at the time we closed Jamie's bug (me!), as well as a small-but-quite-active community of bug-reviewing volunteers. It was all we could do to keep up with new, incoming bugs, much less bugs that were years old and applicable to a completely different codebase. The assertion by anyone that we simply didn't want to review bugs is insulting to all the hard work we did to make GNOME 2 successful.

On the code side, rewriting for rewriting's sake is of course a bad idea, but that wasn't the case for either GNOME 2 or GNOME 3: there were deep technical and design debts that had to be addressed comprehensively in order to provide a modern desktop experience. That required, as I said in another comment, pretty comprehensive rewriting of both underlying technology and user interfaces. So even if the bugs had been high quality when they were written, they still likely would not have applied.

Maybe to put the whole thing another way: there is an assumption of bad faith/incompetence in the CADT claims that is deeply corrosive to healthy communities. It places a burden on volunteers who've made this their passion project for years that is somewhere between insulting and hurtful, and presumes knowledge of a complex problem space that many of the critics don't actually have. Perhaps no surprise that it came up in this thread, then, since the same threads - lack of respect for the hard work of others, failure to actually understand the problem space - come up a lot around systemd.

history of CADT

Posted May 4, 2016 0:19 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (26 responses)

_Everybody_ who sets out to burn things down and start from scratch convinces themselves that _this_ time they're doing it for the right reasons. Perhaps some of them are even correct. But certainly most of them are wrong, yet no less convinced anyway. I have worked on several "burn it down and start from scratch" projects, some of which are GPL'd and some not, and the only one that I'm even somewhat convinced was appropriate after decades of experience was the one which most resembles Brooks' "build one to throw away" pilot system approach.

In particular your apparent belief that if roughly the same group of people write a program again it will have completely different and unrelated bugs is pure wishful thinking. Those people are going to keep making the same mistakes, they're going to keep forgetting the same basic use cases, keep testing only the scenarios that apply to them and not other scenarios, and keep tripping over the same misunderstandings of their language, their libraries, and their environment. But now instead of ten unread bug reports over five years saying that app X can't do Y properly, you can start "fresh" and discover a remarkable thing - app X version 2 can't do Y properly either. Huh, who'd have thought? Only everybody who has been paying attention :/

history of CADT

Posted May 4, 2016 5:58 UTC (Wed) by louie (guest, #3285) [Link] (25 responses)

I agree with your general skepticism of rewrites - they're often done by inexperienced developers for bad reasons, and (as with most software) often take longer than they planned. But they're also often done for good reasons, and they're almost always criticized by people who have no idea about the underlying user needs or suitability of the technology.

I think in the case of GNOME, history bears out that we were generally right to make the decisions we did. Projects tried to fork what was left of GNOME 1, and went nowhere; they found that both the old infrastructure was hard to modernize (i18n, a11y, etc.) and that there wasn't actually much interest despite some very loud complainers. (Again, sounds familiar!)

The main fork of GNOME 2 (MATE) has done somewhat better - there are a lot more happy MATE users than there ever were of GNOME 1, which is a great credit to the MATE developers! Still, Fedora and Debian have kept GNOME as their default, and debian popcon suggests 6x as many people have GNOME 3 installed as MATE (based on the installs of the respective file and window managers). In terms of developer activity, the 20th most-active MATE module on github was modified 26 days ago; the 20th most-active module on GNOME 3 was modified 9 hours ago. (You have to go through 240+ projects to find the GNOME module modified more than 26 days ago.) And the 600+ extensions in extensions.gnome.org shows that the decision to move to a scriptable shell interface (the biggest "rewrite" of GNOME 3) is both drawing developer interest and empowering users. So, yes, perhaps incremental improvement of GNOME 2 could have been successful, but a group of folks are literally trying that and not doing well by most reasonable metrics as the main core contributors.

history of CADT

Posted May 4, 2016 6:46 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

> I think in the case of GNOME, history bears out that we were generally right to make the decisions we did.
You guys _REALLY_ need a reality check.

history of CADT

Posted May 4, 2016 7:33 UTC (Wed) by louie (guest, #3285) [Link] (10 responses)

Because the old code bases (or similar ones) are doing so well, or...? I mean, obviously we're not Android or iOS, but if that's your standard for success pretty much all open source is a failure. So what's the alternative path we should have followed? Would we somehow have become Android if only we'd stuck with GTK 1? Would we somehow have become OS X if only we'd kept our 1.4 preferences dialog? I think it's pretty clear that, even if they didn't take over the whole world, the big gambles we made were a lot better than sticking with what we already had. The one metric that suggests otherwise is application uptake: maybe if we'd stuck with GTK 1 we'd have more apps? (We certainly seemed to have more Back In The Day.) But I suspect even there, the answer was that we needed to be more bold and do more rewriting (mono or Java), not stick with the old stuff.

history of CADT

Posted May 4, 2016 8:00 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Because the old code bases (or similar ones) are doing so well, or...?
I'm talking about achieving your goals.

From what I see, there are now more desktops running Unity than GNOME3. And even RedHat ships GNOME3 with Classic mode. The fact that people are still using (and actively developing!) MATE built on GTK2 released back in 2002 speaks volumes.

You've also lost applications. Many projects actually switched from GTK2 to QT rather than to GTK3: https://blog.wireshark.org/2013/10/switching-to-qt/ , https://subsurface-divelog.org/ , Unity, http://wiki.lxde.org/en/LXDE-Qt and so on.

And it doesn't appear that all that pain has attracted new users in great numbers - desktop Linux marketshare still hovers around 1%.

history of CADT

Posted May 4, 2016 23:12 UTC (Wed) by bronson (guest, #4806) [Link]

> But I suspect even there, the answer was that we needed to be more bold and do more rewriting

I have to ask... Do you really think Gnome's problem is not enough rewrites?

I'd guess that would have encouraged me to leave earlier. Even less stability doesn't seem like a winning strategy to me. But, admittedly, I'm not in Gnome's target audience.

history of CADT

Posted May 10, 2016 8:15 UTC (Tue) by paulj (subscriber, #341) [Link] (7 responses)

Your 1.4 prefs dialogue is using the stock widget look. If you were trying to make 1.4 look bad, that's what you'd choose. I doubt anyone shipped with stock/no-theme as the default theme. There were a lot prettier themes. E.g. "ThinIce" still looks fairly good today.

history of CADT

Posted May 10, 2016 15:37 UTC (Tue) by raven667 (subscriber, #5198) [Link] (6 responses)

That is a very weird thing to say, that showing the default operation of a particular software would be considered "trying to make it look bad" and that this would be considered a defense of the software in question. Are you saying that the people who built this software and chose the default look were "trying to make it look bad" ??!! My head goes all 'splody trying to understand what you are implying here.

history of CADT

Posted May 10, 2016 15:46 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

Louie seemed to be arguing that the GTK look from GNOME 1.4 days was ugly and using that as evidence for some greater argument about need for GNOME to rewrite stuff. I agree the /default/ GTK library look from those days, as shown in the example, was indeed a bit ugly. However, I don't think any distro shipped with the stock/no-theme default widget set as the distro-default. I don't know why the library default was ugly, but that library default look was *not* what users got anyway in those days - so using a screenshot of that library-default seems unrepresentative, and hence not a good support for whatever argument louie was making.

history of CADT

Posted May 10, 2016 16:00 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

> Louie seemed to be arguing that the GTK look from GNOME 1.4 days was ugly

That isn't it at all. The image shown is the control center setting overloaded with geeky options. The look of the toolkit is irrelevant to the point being made there.

history of CADT

Posted May 10, 2016 16:11 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

I think the point wasn't the actual widget appearance, but the complexity of the preference dialog and the implications it had for both usability and testability of GNOME 1.x as a whole.

history of CADT

Posted May 10, 2016 16:36 UTC (Tue) by paulj (subscriber, #341) [Link]

Ah. :)

Ok. On that, I'd whole-heartedly agree. GNOME 2 was a huge improvement in that regard. It should be noted that, a factor in the (eventual) success of GNOME 2 was that the changes were driven by empirical HCI studies carried out by Sun Microsystems. The results of which led to the GNOME 2 HIG.

GNOME 2 wasn't just arbitrary change. It was change based on objective evidence.

history of CADT

Posted May 10, 2016 16:12 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

> Louie seemed to be arguing that the GTK look from GNOME 1.4 days was ugly

I didn't get that at all, I didn't see this as making a comment about the aesthetic qualities of grey, which I think is largely irrelevant, but as a comment about the organization and number of preferences, which was greatly simplified in the move to GNOME 2, so that every user didn't have to wade through a cacophony of irrelevant sliders and tabs, to change the few options that were most likely to be changed, while still retaining many of the variables exposed in a more advanced interface for those who want it.

This was a major change and rewrite that most people seemed to like better than the old tool in time, you could make the same kind of comparison between Sawmill and Metacity, would GNOME be stronger today if Sawmill had stayed as the default, to maintain compatibility, same as if the original Control Center had stayed?

history of CADT

Posted May 10, 2016 21:41 UTC (Tue) by nix (subscriber, #2304) [Link]

I would certainly be hugely happy if Saw{mill,fish} had stayed alive, rather than its main developer being hired by Apple on the condition he stopped working on it. It was and is the best Lispy WM out there, bar none.

history of CADT

Posted May 4, 2016 6:46 UTC (Wed) by louie (guest, #3285) [Link]

Sorry, not doing *as* well. They're definitely doing pretty well overall, and again - serious kudos to them. I'm glad they're using the freedom our licenses granted them and successfully empowering users that way.

history of CADT

Posted May 4, 2016 7:48 UTC (Wed) by johannbg (guest, #65743) [Link] (10 responses)

"600+ extensions in extensions.gnome.org"

Does windows have "extensions"
Does MacOS X have "extensions"
Does Android have "extensions"

It goes without saying desktop environment should be growing application not extension to workaround it's poor design.

+If memory serves me correct then extensions were never planned to be part of Gnome but grew out of necessity to their keep end user base.

Now the fundamental problem with Gnome is the instability of it's UI design and always has been ( 1.x, 2.x 3.x does not matter ).

That was the thing novices end users complained most to me about when I was Fedora Ambassador.

Those end user did not what shiny new things with "effects" and gazillion default applications to be confusion about.

They wanted a boring stable UI with the exact same applications in the exact same place as before so they did not have re-learn where applications and system configuration was placed or start using new applications they where entirely unfamiliar with.

And that was why novice end users did not use Fedora which ironically is to many ( Red Hat ) people it's "target audience" and why the Red Hat desktop team is forcing Fedora's release cycle in sync with the Gnome one again ( despite 10 years of history telling them not to but hey let's tear the community a new one with now with no mass rebuilds to achieve that impossible goal! Fracking idiots )

history of CADT

Posted May 4, 2016 10:53 UTC (Wed) by pizza (subscriber, #46) [Link] (8 responses)

> Does windows have "extensions"
> Does MacOS X have "extensions"
> Does Android have "extensions"

FYI -- Yes, Yes, and Yes.

> +If memory serves me correct then extensions were never planned to be part of Gnome but grew out of necessity to their keep end user base.

Extensions were *always* part of the plan and were a core feature of Gnome-Shell. Specific extensions, on the other hand, may not have been. Which leads me to...

> It goes without saying desktop environment should be growing application not extension to workaround it's poor design.

No, it's called designing sufficient flexibility so that functionality use cases not part of the core design can be added by those who want or need said functionality. There's quite a lot of stuff that doesn't rise to the level of an "application" or by necessity needs information only known to the shell itself.

> They wanted a boring stable UI with the exact same applications in the exact same place as before so they did not have re-learn where applications and system configuration was placed or start using new applications they where entirely unfamiliar with.

Users want nothing to change except for the things they want to change, then loudly complain when the changes they want require changes elsewhere.

Meanwhile, if you wanted a "Boring stable UI" then we'd all still be using CDE. Heck, one of the "enterprise" applications I have to use would look right at home on that platform. It's also a festering pile of swill.

history of CADT

Posted May 4, 2016 11:09 UTC (Wed) by johannbg (guest, #65743) [Link] (7 responses)

> Does windows have "extensions"
> Does MacOS X have "extensions"
> Does Android have "extensions"

"FYI -- Yes, Yes, and Yes."

Please provide me with links to documentation to the extension framework those other OS provide.

history of CADT

Posted May 4, 2016 11:24 UTC (Wed) by pizza (subscriber, #46) [Link] (6 responses)

> Please provide me with links to documentation to the extension framework those other OS provide.

Okay, I'll do this, even though what you're asking is literally as simple as plugging "X shell extensions" into google and pressing "I'm feeling lucky".

"windows shell extensions" returns: "creating shell extension handlers" on MSDN:

https://msdn.microsoft.com/en-us/library/windows/desktop/...

"Finder shell extensions" returns "App extension programming guidelines" on Apple's developer site:

https://developer.apple.com/library/ios/documentation/Gen...

Now Android's a little more complicated; "extensions" in the classical sense are really a per-application thing, and there are many applications which implement their own extension mechanism. However, the Android core is built around the concept of "intents" which allow arbitrary code to implement various activities. For example, every application in the "Send to..." list is there because it's registered an intent that can be used by anyone). Here's the "I'm feeling lucky" link returned from searching for "android intents", called "Intents and Intent filters" on the android developer site:

http://developer.android.com/guide/components/intents-fil...

history of CADT

Posted May 4, 2016 14:10 UTC (Wed) by johannbg (guest, #65743) [Link] (4 responses)

"Okay, I'll do this, even though what you're asking is literally as simple as plugging "X shell extensions" into google and pressing "I'm feeling lucky"."

You where the one that was claiming that the other OS had extensions and it's framework and their implementation was comparable with Gnome so it goes without saying you refer to what exactly you yourself are referring to so one can make the same comparison and reach the same or different conclusion as you did.

I view extension or "plugins" as highlighting underlying design deficiency ( the more extension people install or the higher usage of specific extension indicate something that should be the part of the default design since from my point of view people should not have to install extension or plugins to get the functionality they require from the desktop environment but providing the framework to overcome limitation of the desktop environment is not something I'm against ) so our opinion on that topic differ.

And the boring stable UI conclusion comes from being Fedora Ambassador for 8 years installing Fedora on those novice end users hardware and helping them with problems they experienced running and using Fedora as their day to day desktop in the process. These where regular technology challenged individual not tech savy people who know or want spending hours setting up, tweak (or otherwise fight the desktop environment to be able to use it.

In the end of the day what matters the most is what works for the end users, ( them, they are the ones who will be using that computer on a day to day bases not me, not you or anyone else which often seems to be forgotten ) and makes their life easier and helps them get their work done and is least in their way in doing that.

If Microsoft Windows works for them good, if OS X works for them great, if Linux works for them fantastic but in reality Linux on desktop is failing to work for 98.35% [1] people using computers as their desktop on the planet that's undisputed fact otherwise it would be more popular and would be more widely used.

1. https://www.netmarketshare.com/operating-system-market-sh...

history of CADT

Posted May 4, 2016 15:14 UTC (Wed) by anselm (subscriber, #2796) [Link] (1 responses)

I view extension or "plugins" as highlighting underlying design deficiency ( the more extension people install or the higher usage of specific extension indicate something that should be the part of the default design since from my point of view people should not have to install extension or plugins to get the functionality they require from the desktop environment but providing the framework to overcome limitation of the desktop environment is not something I'm against ) so our opinion on that topic differ.

Sometimes it is difficult to figure out before the fact what functionality people would actually like to have. In that sense, providing an extension framework is like sowing a huge lawn in the town square and then later paving over those paths where people have been walking a lot, rather than paving a bunch of footpaths first and hoping that people will follow them and not walk on the grass. Similarly, the most popular extensions can then be made part of the core product.

It would be great if a large and complex piece of software like GNOME could be all things to all people from the get-go, but that's not what usually happens. In view of this, an extension framework is the next-best thing because it lets users scratch their itches in all the places that the original designers didn't foresee or didn't consider important. On the other hand, deliberately omitting basic functionality that is obviously desirable to a large proportion of known users, and relying on extension developers to put it back (which I hear is something the GNOME developers subscribe to – I'm not a GNOME user myself so don't have first-hand experience) is probably not the wisest approach.

history of CADT

Posted May 4, 2016 17:49 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> Sometimes it is difficult to figure out before the fact what functionality people would actually like to have

It also makes niche but very useful extensions possible. The existence of extension frameworks is a good thing.

history of CADT

Posted May 4, 2016 15:34 UTC (Wed) by anselm (subscriber, #2796) [Link]

but in reality Linux on desktop is failing to work for 98.35% people using computers as their desktop on the planet that's undisputed fact

I don't think it is quite correct to say that desktop Linux is “failing to work” for all those people when the reasonable assumption is that the vast majority of them has never actually tried a Linux system in the first place. Something “failing to work”, in my opinion, implies a reasonable attempt to make that something work to begin with. (Incidentally, arguably there are many people whose entire computer needs could be adequately covered by Firefox and LibreOffice, and it would probably not matter in the least to them whether these run on Windows or Linux.)

As long as virtually all desktop PCs come with a pre-installed operating system that isn't Linux, and only comparatively few people actually care enough to install Linux, talking about Linux “failing to work” for everyone who stays with their factory-provided (non-Linux) default operating system is unreasonable. In any real sense, Linux has only “failed to work” for those people who actively installed it, gave it a try, and then went back to whatever they used before, and that will be considerably fewer than 98.35% of all desktop PC users.

history of CADT

Posted May 4, 2016 15:51 UTC (Wed) by pizza (subscriber, #46) [Link]

> In the end of the day what matters the most is what works for the end users, ( them, they are the ones who will be using that computer on a day to day bases not me, not you or anyone else which often seems to be forgotten ) and makes their life easier and helps them get their work done and is least in their way in doing that.

End-users want absolutely nothing to change. Except for the things they want changed. And then it needs to be exactly the same, only different.

...Yes, I've been through this quite a few times. Suffice it to say that I have very strong feelings on the subject.

> If Microsoft Windows works for them good, if OS X works for them great, if Linux works for them fantastic but in reality Linux on desktop is failing to work for 98.35% [1] people using computers as their desktop on the planet that's undisputed fact otherwise it would be more popular and would be more widely used.

I don't doubt that Desktop Linux is insignificant (Steam claims ~1% of their users do so on Linux, for example) but that Netmarketshare.com's claim that *Windows 3.1* comprises of 0.45% of the installed base makes me distrustful of the quality of their other figures.

I also wonder where they're slotting in Chromebooks, which on their own would account for more than Linux's total reported share.

history of CADT

Posted May 4, 2016 17:28 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> "windows shell extensions" returns: "creating shell extension handlers" on MSDN
Shell extensions are not really comparable with GNOME plugins. They were used to do stuff like virtual filesystems in Explorer or additional toolbars, not to change the way Windows looked.

Now, since Windows tried to preserve binary compatibility, lots of products hooked into the deep levels of system and provided lots of customizations.

Mac OS X had even less customizability.

history of CADT

Posted May 4, 2016 11:49 UTC (Wed) by nye (subscriber, #51576) [Link]

>Does windows have "extensions"

Yes, in unimaginable numbers. First literally - shell extensions are extremely common, and a great many applications come with them.

Also less literally there are a huge number of utilities which aren't technically 'shell extensions' but which are functionally the moral equivalent in that they are programs that adjust the behaviour or functionality of bits of Windows. For example, simple utilities like 7+ Taskbar Tweaker do the kind of thing that might be done by a Gnome extension, and you might also consider larger scale things like Classic Start Menu or DisplayFusion to be comparable.

history of CADT

Posted May 5, 2016 18:52 UTC (Thu) by sionescu (subscriber, #59410) [Link]

Having to install 16 extensions to make gnome-shell useable, that are sometimes incompatible even among themselves and break with updates, that does not "empower" me, just makes me curse at GNOME devs for not having those features in the base distro.