[kwlug-disc] What's the best desktop distribution?

[Khalid Baheyeldin]

On Mon, Feb 8, 2010 at 2:44 PM, unsolicited <unsolicited at swiz.ca> wrote:

>
> Khalid Baheyeldin wrote, On 02/07/2010 10:46 PM:
>
>> On Sun, Feb 7, 2010 at 10:08 PM, unsolicited <unsolicited at swiz.ca
>>    Khalid Baheyeldin wrote, On 02/07/2010 7:37 PM:
>>
>> With Drupal, it is only one application, and I know where to get updates (
>> drupal.org <http://drupal.org>)
>>
>> and how to get alerted on new updates (update.module in Drupal 6). That
>> works well for minor version updates (6.x to 6.x).
>>
>> The Drupal cycle is now around 2 years, if not more. So major version
>> upgrades are the less painful when we had a 6-8 month cycle.
>>
>> With Drupal, I can replicate the site to a test machine in 10 to 15
>> minutes, and upgrade it there. I can't upgrade my laptop from a non-LTS
>> version every 6 months and find out that wireless did not work, or the
>> screen resolution is bad, and then back it out. I can't do work without my
>> desktop.
>>
>> This is why the rule is to be on LTS, and make exceptions where the need
>> arises (e.g. KDE unstable, Drupal on servers, ...etc.)
>>
>> Did I get it this time?
>>
>
> Gotcha. In essence, the non-repository updates are well quantified /
> identified / bounded. The LTS updates have, traditionally, not broken
> critical functionality for you, such as wi-fi, or KDE. Non-LTS updates have,
> such as 8.x to 9.04.


Yes, that is the gist of it. Drupal is an controlled exception to "be on
LTS, upgrade only from the repository".


> [Mind you, we should all have paid more attention to the little voice in
> the back of our heads telling us to be wary of a major upgrade of KDE.]


No amount of caution could have prepared me for the degree of broken-ness in
Kubuntu 9.04. I am glad it was only a few months of paid (Sept and Oct). I
am glad that 9.10 was smooth.


>
>         First, a bit of background: One thing that Ubuntu does which is
>>        disconcerting is that after a while the repositories of non-LTS
>>        versions will be made unavailable, meaning
>>        that you cannot install anything some time after the release
>>        becomes unsupported.
>>
>>        The reason I use non-LTS releases on the desktop is Ubuntu's
>>        decision with 8.04. That release was meant to be an LTS release,
>>        supported for 5 years for servers and 3 years for desktops. That
>>        was true for servers and the Gnome Ubuntu. For KDE, the release
>>        of KDE 4 caused the Canonical team to decide that 8.04 will NOT
>>        be an LTS release for Kubuntu. I decided to skip 8.04 on the
>>        desktop. When I got a new laptop I installed 9.04 on it since it
>>        was the latest available. That was a very buggy release, and had
>>        lots of problems. Now with 9.10 out, things are back to being
>>        both stable AND functional. But it is not LTS and hence I have
>>        to keep upgrading until an LTS comes out.
>>
>>
>>    I remember your commenting on 9.04, which matched my own experience,
>>    and others. How likely are you to not stay with a more current
>>    release on the desktop, anyways? Heck, there are still warts in 9.10
>>    that I don't expect to be fixed until the next release. And not long
>>    after we'll be into this cycle again.
>>
>>
>> If I were forced to stay with 9.04 (e.g. 9.10 hypothetically never was in
>> the making), then I would have done something drastic. I was already
>> considering Xubuntu (no Gnome, no KDE) because 9.04's KDE 4.x was so bad.
>>
>
> I'm guessing going back to 8.x wasn't an option, it being a new laptop for
> you at the time. And we're back to hardware / security support of old
> version on new hardware.
>

No, going back to 8.x was not an option, since Kubuntu 8.04 was non-LTS and
would be obsolete soon (is it 18 months?), and I would be left in the cold.
There was also the factor of "KDE 3.5 will soon be obsolete, and only KDE
4.x will be available, might as well get on the bandwagon, since I have to
do that anyways.


>   From a day to day thing, they are the same. I feel at home enough on
>> client
>> machines that are Debian. Did not do full version to version upgrades
>> though
>> to say one way or the other.
>>
>> Now, if it is RedHat/CentOS with Plesk, I start cursing in Arabic ...
>>
>
> (-:
>
> Thanks for this. Good to know.
>
> Including, yes, even at just a command line, that the differences between
> Debian/Ubuntu and CentOS/Fedora are significant enough to be irritating and
> annoying, if you're not 'native language' comfortable with both. Even for a
> former Mandriva user.


Mandriva is ancient history for me, so have not been doing much with it for
many years. Also, I never used it for remote servers, so can't say how
good/bad it is in that scenarios.

One issue with CentOS and RedHat is that the default repositories that come
with it are not enough to contain all the apps needed. On Debian and Ubuntu,
the base repositories have everything on them (things like Munin, htop, and
many more). No need to hunt for repositories of configure them.

The other issue is cPanel and Plesk. Most hosting companies have one or the
other installed on RHEL or CentOS for lots of money (subscription). As
useful as these two are (nice web admin interface, ...etc.) they lock the
server configuration to a certain set of software version, and
configuration. Changing things in the normal Apache, MySQL, PHP files only
lasts for a few minutes before cPanel/Plesk reverts your changes. Very
annoying when you are trying to tune a server. This is not Redhat's fault,
but that is the most common combination configuration you find in the field
out there.
-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20100208/a3255726/attachment.htm>