Time-Stamping Weirdness

[SteveRiley]

As you probably know, Debian Stable is known for being "slow" (by some folks' standards) to adopt new versions... The "Testing" and "Unstable" releases are far more "bleeding edge"; but in most cases, that's not what you want in a production environment.

Debian's pace is fine for servers. For desktops? Not so much. The kernel in Debian 7.8 is 3.2, which is quite far behind now. Many improvements have been made since then -- better graphics handling, better and newer device drivers, more efficient use of power. Debian stable is a poor choice for desktops, which is why most desktop-oriented derivatives use unstable. Debian is so good with their packaging that their "unstable" is more solid (in most cases) than most other distros' "stable."

This is precisely the same logic which prompted me to use v14.04.2 LTS when I decided to set up a Kubuntu system, rather than v14.10.

In the land of Ubuntu and its flavors, LTS is not an indication of higher quality. It simply means that the release will receive patches for more than nine months. LTS releases will age over time; there is a backports repository than receives some, but not all, updated software.

OK. I'll take your word for that. But then, why do the version numbers for the packages in question all carry "ubuntu", as opposed to "kubuntu" in their names? For example, "kde-runtime" is version "4:4.13.3-0ubuntu0.2"; and the various Samba-related packages ("samba-common", "samba-common-bin", "samba-libs", "libsmbclient", etc.) are all version "2.4.1.6+dfsg-1ubuntu2.14.04.5".

The dfsg suffix in a version number indicates that the source code was modified to meet the Debian Free Software Guidelines before it was compiled. The ubuntu suffix indicates that minor changes were made to the source code to enable it to compile correctly to work on any flavor of Ubuntu, including Kubuntu. More info: http://www.justgohome.co.uk/blog/201...-versions.html

In the interest of completeness, I'll endeavor to file the bug report (when I finish writing it) to KDE.org as well as to bugs.launchpad.net/ubuntu. But as of the moment anyway, I'm betting that the latter is the more appropriate venue.

KDE will probably just punt it to Kubuntu, so filing only on Launchpad is fine.

KDE4 was a MAJOR upheaval to the entire user base... It was not until at least several "point releases" down the line that KDE4 was sufficiently "tamed" to make the transition (from KDE 3.x) tolerable.

And KDE made much noise about 4.0/4.1 not being intended for packaging by distributions. Alas, these warnings were ignored. (I can't speak for Kubuntu's history here; 4.0 came about before I got involved.)

But NONE of that is what a normal end-user sees, or cares about.

Really? None of it? So a window manager that can take advantage of modern GPUs doesn't matter? More control over power usage doesn't matter? Better support for multiple monitors doesn't matter?

the more it's different, the more it requires re-learning, and re-evaluation of working procedures, and all sorts of other follow-on effects. That, in and of itself, is ALWAYS a liability, and a larger one than (it would seem) most developers are capable of understanding or appreciating... it looks, feels, and works absolutely as close to the old one as possible, even if the developers HATE the old version. The "new stuff" can be configurable options or similar; but it should NEVER be forced upon the user, or even presented as the default

How much did you pay for KDE or Kubuntu? Right. It's free software that the developers (1) build for themselves and (2) share with the rest of the world. How dare we demand that they never change anything on the software they create for themselves.

Just as important (if not more so) is that when KDE5 is released, it looks/feels/tastes/seems -- and especially *works* -- just like KDE4 in every way possible, at least until the user deliberately changes settings to enable the new eye candy or whatever. This would likely take a major mindset change on the part of the developers; but it's what is needed.

The intention of KDE 5 is most definitely not to be exactly like KDE 4.

[Weary1]

Debian's pace is fine for servers.

ITYM "Debian Stable's pace". That "Stable" part is a critical qualifier -- and a very large part of what makes Debian so good (especially for servers, as you note; but not exclusively so). At any given moment, Debian Testing is essentially a snapshot of the *next* release (in this case, v8.0, "Jessie"), as a work-in-progress. A quick check shows that at least some of the packages currently in "Testing" are newer than those in my copy of Ubuntu/Kubuntu; certainly not far behind.

For desktops? Not so much.

That depends largely on your point of view.

The kernel in Debian 7.8 is 3.2, which is quite far behind now.

Perhaps so. But that is of essentially no importance compared to having something which works reliably and can be counted on for STABLE day-to-day operations. Remember the basic precepts here: "Newer" does NOT necessarily equal "Better", and "If it ain't broke, don't 'fix' it."

Besides, even that "quite far behind now" 3.2 kernel still gets any important updates AS NEEDED on an ongoing basis, through the normal routine update procedures. For example, the kernel version currently running on my Debian Stable systems is "3.2.65-1+deb7u1", released January 12, 2015 -- hardly ancient.

Many improvements have been made since then -- better graphics handling, better and newer device drivers, more efficient use of power.

Again, perhaps so. But if an existing Debian Stable system is already working acceptably well, then those "improvements" become vastly diluted in value. In some cases, they may even constitute net negative value, especially if they impose undesired follow-on changes/effects.

Debian stable is a poor choice for desktops, which is why most desktop-oriented derivatives use unstable.

I think you're painting with too wide a brush. Sure, some folks (particularly the young and/or inexperienced) will value "New & Shiny" over "Tried & True"; and "New & Shiny" certainly gives folks more to talk about (i.e., "buzz", etc.). But at the end of the day, it's about what *works* better. If a particular change is needed to improve real functionality, that's one thing; but if it's largely "change for the sake of change" (as was the case to a VERY great extent with both KDE4 and Firefox "Australis") -- or even simply appears so to the user -- then that's arguably a step backwards, in at least some important ways.

So no, I would NOT call Debian Stable a "poor choice" for desktops in general. It's a matter of your priorities. To the rank-and-file USER, who views the computer as a tool (not a hobby) and simply wants to get his work done, the top priority is nearly always stability and reliability.

All that said, it turned out that the version of K3B included in Debian Stable 7.x was either incompatible with my hardware, or had some sort of bug (perhaps exacerbated by the hardware) which caused it to be effectively unusable on that particular system. After limping along with Brasero (which worked, but is horribly limited compared to K3B) for awhile, I really wanted to get K3B working. A little research turned up some indications that it was indeed a bug in that particular version of K3B which was primarily responsible for my issue. Now, I could have made the leap of faith into Debian Testing; or I could even have APT-Pinned a newer version of K3B into the existing Stable system, which *might* have done the trick. But by this point I also knew that I needed to build up a new workstation for other reasons; so I started experimenting. And that's what (eventually) led me to Kubuntu LTS for the "new" workstation.

BTW... Debian "Unstable" is several miles closer to the bleeding edge than even Debian Testing; and using it blindly is almost always a mistake. The stuff that lands in that repository is barely-out-of-the-oven, and often half-baked. Now, an organization (and "community") as large as Ubuntu/Kubuntu can probably provide at least most of the necessary "polishing" such half-finished code invariably needs. But many of the smaller distros simply don't have the resources to do that in a timely manner (that's what effectively killed what was at one time my favorite desktop distro, Simply MEPIS).

Yet, even with all those resources at hand, in the case which inspired this thread we found a situation where (by best estimate, anyway) applying that "polish" went wrong and added a bug to what was otherwise properly-functional code. Or maybe it was a case of failing to squash a bug that briefly existed when a given program version was in (and subsequently snatched from) "Unstable" but which was later fixed before the package in question made it into Debian Stable. Either way, that bug has languished unfixed on the Kubuntu/Ubuntu side for more than eight years, which doesn't exactly speak well for the "rush to release" model.

Debian is so good with their packaging that their "unstable" is more solid (in most cases) than most other distros' "stable."

Again, too wide a brush. But to the extent the basic sentiment may hold, that's more an indictment of "most other distros" than an accolade of Debian.

For as long as I can remember, one of the "Holy Grails" of Linux in general has been to increase its share of the desktop "market" (particularly vis-a-vis the proprietary OSs from Redmond and Cupertino), which in turn will presumably draw more support, more development, wider awareness & acceptance of FOSS in general, more opportunities for both profitable and not-profit-related innovation, and so on. Two far-too-classic ways in which the Linux community in general has repeatedly shot itself in the foot on this front has been rushing stuff "to market" before it's *really* ready, and changing things too much, too fast, leaving a bewildered John Q. User in the dust. (Neither of these foolish actions are exclusive to Linux, of course; but they are more immediately damaging here than to an established/monopolistic commercial player with a huge "steamroller effect" which can be used to plow through such gaffes.)

In the land of Ubuntu and its flavors, LTS is not an indication of higher quality. It simply means that the release will receive patches for more than nine months. LTS releases will age over time; there is a backports repository than receives some, but not all, updated software.

It's not so much about "higher quality" (tho' in a way, that's part of it) as it is a matter of a release having been given enough time to get the kinks worked out. Anything really important (such as security fixes) gets pushed through to the main repositories anyway (that's the major point of the "LTS" designation, after all).

It's also about NOT having *unnecessary* changes pushed at me every six months, at most (and in some cases, a lot more frequently than that, even).

The rest of it is largely irrelevant to someone who has an existing system which is working in an acceptable manner. Typically, one only needs the newest/shiniest software if one has the newest/shiniest hardware, which in turn needs direct support. But that is not the case for MOST folks running any OS, let alone Debian Stable or Ubuntu/Kubuntu LTS. Save for that "brand new hardware" scenario, even if the "New & Shiny" stuff doesn't break something (or worse, cause the user to have to change the way he works), it is effectively unnecessary.

The dfsg suffix in a version number indicates that the source code was modified to meet the Debian Free Software Guidelines before it was compiled. The ubuntu suffix indicates that minor changes were made to the source code to enable it to compile correctly to work on any flavor of Ubuntu, including Kubuntu. More info: http://www.justgohome.co.uk/blog/201...-versions.html

OK, thanks for the "decoding". Now, if I follow that correctly, this means the packages in question here ("kde-runtime" version 4:4.13.3-0ubuntu0.2; and "samba-common", et al, version 2.4.1.6+dfsg-1ubuntu2.14.04.5) are indeed "Ubuntu" packages, not specifically "Kubuntu" packages, correct? Am I also correct in saying that for most things not specific to the GUI (and perhaps even some of that), Kubuntu pulls code more-or-less directly from Ubuntu?

KDE will probably just punt it to Kubuntu, so filing only on Launchpad is fine.

That's probably where I'll start.

(Stuff about how KDE5 is internally structured, what languages are used to write it, how it will make future development easier, etc. -- obviously, I'm paraphrasing here.)

But NONE of that is what a normal end-user sees, or cares about.

Really? None of it? So a window manager that can take advantage of modern GPUs doesn't matter? More control over power usage doesn't matter? Better support for multiple monitors doesn't matter?

First, those were not the sort of things I was addressing.

Second, if those particular functions/features are important enough to a particular user to inspire him to seek a better solution than whatever he has now, then of course the "New & Shiny" stuff in KDE5 might well turn out to be that solution (or maybe not; maybe it will be something else entirely). But the over-arching presumption here is, and has always been, the case of the user who has a system which currently works at least "acceptably" to him. And that's most "normal" users, or they wouldn't be using KDE in the first place.

It's not that functional improvements are unwelcome -- far from it, in fact. It's that such improvements need to be made while still respecting that which has gone before, and recognizing that many/most/(all?) the current users are counting on the way things are NOW, in order to do their jobs. Forcing the user to change the way he works with his computer, or making him re-learn old tasks, or jump through hoops to restore things as closely as possible to what he's used to, is a VERY bad idea.

Every time.

Only when such operational/procedural changes are ABSOLUTELY necessary in order to make the system function "acceptably" (or at all) should they be deemed tolerable.

How much did you pay for KDE or Kubuntu?

Oh, come on. That's not the issue, and you know it!

And besides, my comments regarding many developers' penchant for "change for the sake of change" applies far beyond "Free" software of any stripe. Look at Windows "Vista" and/or Windows 8 for shining examples of commercial products where that mindset went completely wrong. Heck, go back even further in the annals of "change-for-the-sake-of-change" marketing disasters: Remember "New Coke"?

Right. It's free software that the developers (1) build for themselves and (2) share with the rest of the world. How dare we demand that they never change anything on the software they create for themselves.

Your sarcasm is noted, if grossly misplaced.

And for the record, it is completely implausible that either of the "Free" examples I happened to cite -- KDE4 and Firefox -- were written exclusively (or even primarily) for the developers' own use, or that public release is/was merely coincidental. Were it not for that expected (to the point that all concerned can count on it) public release, at least the vast majority of the development would never have happened.

The intention of KDE 5 is most definitely not to be exactly like KDE 4.

It may not be the "intention"; but if the folks at KDE.Org are smart, they'll make it at least appear that way, out of the box. For just one example, and as I mentioned earlier: Having user-selectable settings to bring forth the latest eye candy (or changed functionality, or whatever) is fine. But shoving that eye candy (or changed functionality, or whatever) in the user's face, often without warning or clear and prominent instructions on how to un-do it, is both short-sighted and counter-productive -- *ESPECIALLY* if the "New Shiny Stuff" forces the user to change his day-to-day operating procedures in ANY way.

[kubicle]

We're all entitled to our opinions, but the issue is not "what users want vs. what develelopers do", simply because there are many kind of users (and many kind of developers) that each want and do different things.

No one is qualified to say what users want/need, "what you want/need" != "what users want/need".

There is a golden rule in FOSS...those that do the work (or in case of paid developers, those that pay for the work) get to decide what is done and how it gets done, not random people on the internet. No other method would work. If developers aren't motivated (either by getting to work on things they wish to work on, or by getting paid), nothing would ever get done (I know this from personal experience).

However, we do have a lot of different FOSS projects (and many linux distributions) with different priorities and goals, so both users and developers can pick which they wish to use (and develop), projects that do not attract users and developers will eventually die out. Sort of survival of the fittest.

As far as KDE goes, I can't say I've personally liked all changes in it's history (or every new iteration initially), but for me things have generally kept improving even with the inevitable regressions/bugs every now and then. That doesn't mean it is the same with everyone, if stability is an important priority for you, you should use a more conservative distribution. Like you said, Debian stable might be a really good distribution for you, but that doesn't mean that Debian is "doing it right" and Kubuntu is "doing it wrong".

Actually, it was "Places" --> "Network" --> "Add Entry..."

My mistake, wrote the path from memory without checking...but it did have the setting?

In the land of Ubuntu and its flavors, LTS is not an indication of higher quality. It simply means that the release will receive patches for more than nine months.

IIRC, LTS releases sync from Debian Testing, while non-LTS releases pull from Debian Unstable, so LTS releases are somewhat more conservative.

And KDE made much noise about 4.0/4.1 not being intended for packaging by distributions. Alas, these warnings were ignored. (I can't speak for Kubuntu's history here; 4.0 came about before I got involved.)

Kubuntu switched to KDE 4.1.2 in 8.10 release (the previous LTS 8.04 used KDE3 by default, but there was an option to also test KDE4). At that point, KDE4.1.2 was quite useable (but not without regressions).

[Weary1]

We're all entitled to our opinions, but the issue is not "what users want vs. what develelopers do", simply because there are many kind of users (and many kind of developers) that each want and do different things.

No one is qualified to say what users want/need, "what you want/need" != "what users want/need".

Up to a point, I agree with that. And this little side trip has already gotten far more "involved" than I'd intended when I originally made my offhand comment about hoping KDE5 was still a long ways off. I was simply trying to point out a difference in perspective -- a difference which I think is far more pervasive than many folks seem to realize, and very often gets overlooked. Now, I *could* be completely off-base; but I still think that considering that difference in perspective is important in any product-development scenario.

As far as KDE goes, I can't say I've personally liked all changes in it's history (or every new iteration initially), but for me things have generally kept improving even with the inevitable regressions/bugs every now and then. That doesn't mean it is the same with everyone, if stability is an important priority for you, you should use a more conservative distribution.

Sometimes, yes.

But recall that I'm here because I *did* choose Kubuntu LTS for my latest build; and I made that choice in large part *because* it offered newer versions of certain packages which were giving me trouble under Debian Stable. In short: There's no one "perfect" answer; everything is a trade-off. But in the "best of all worlds" scenario, those trade-offs would be both rare and of very little "cost" (particularly in terms of how much stability and consistency one has to sacrifice in order to get the particular features/functions one *does* need). [Note that I am using the term "stability" here not in the "buggy app which crashes a lot" sense; but rather, in the sense of "No sudden surprises, including in terms of how I do my work".]

Like you said, Debian stable might be a really good distribution for you, but that doesn't mean that Debian is "doing it right" and Kubuntu is "doing it wrong".

Nor did I ever intend to imply such.

Again, it was just a means of contrasting a somewhat different approach, or perhaps a different set of priorities. I found Steve's rather dismissive comments with regard to Debian (and in particular his near-exclusive focus on how "outdated" it might be vs. the newest stuff, and the strongly implied presumption that the older versions MUST therefore be inferior) to be somewhat myopic, in the bigger scheme of things. And in turn, it is precisely that sort of "close-up view" which (I think) leads to some of the problems I described. Forrest vs. Trees, and all that. I am by *NO* means advocating the stifling of development; I just wish that developers (in general; not just KDE or Kubuntu or whatever) would give somewhat greater weight to how important consistency is to the average user. [And yes, any possible hubris aside, I think I *am* qualified to speak at least somewhat on behalf of that "average user": I ran my own computer systems consulting firm for well more than 20 years, directly supporting a variety of small business and individual user clients. I'm now 99+% retired, in part due to some health issues. But along the way I've gathered a LOT of experience with how "John Q. User" (who is by no means a computer geek) thinks, and what is important to *him*.]

OK... Off the soap-box for good -- I hope.

Actually, it was "Places" --> "Network" --> "Add Entry..."

My mistake, wrote the path from memory without checking...but it did have the setting?

IIRC, only the one I mentioned previously: "Only show when using this application (Dolphin)"

IIRC, LTS releases sync from Debian Testing, while non-LTS releases pull from Debian Unstable, so LTS releases are somewhat more conservative.

Which, from *MY* perspective, makes LTS that much more attractive.

;-)

[kubicle]

IIRC, only the one I mentioned previously: "Only show when using this application (Dolphin)"

Oh wait, you mean you right-clicked "Network" and chose "Add entry" from the menu?

You can add an entry to places like that, but I meant Left-clicking on "Network" which opens network folders in the files pane (and among those there should be an item "Add network folder")

OK... Off the soap-box for good -- I hope.

I'm fine with that, the thread went a bit off course