mebbe Kubuntu should be thinking ...larger picture

[woodsmoke]

I've posted elsewhere on this...but...

Shuttleworth has basically said that YOU had better somehow get on with your life because he has washed his hands of it..rather kind of like...



I, personally, woodsmoke think that

YOU......reading this thread.....

YOU...........YOU................YOU....

could have "the idea" that could actually do what Shuttleworth does not have the ....ummm guts...b@l#s to do....

POST YOUR IDEA ABOUT HOW KUBUNTU COULD....do....SOMETHING!!!!!!!! and walk all over Microsith....

Now....not...later...NOW...NOW....NOWWWWWWW!!!

woodwaitingtoseeyourreplysmoke

[Detonate]

This does not fit your "Now....not...later...NOW...NOW....NOWWWWWWW!! !" requirement, but I have dreamed that Kubuntu users infiltrated the IT departments in their organization and rose to a position where they had decision making powers.

[woodsmoke]

TUP!!

woodsmoke

[texaswriter]

Unfortunately, Canonical and Shuttleworth haven't used their community to its full advantage. Although you can find links to Kubuntu/Xubuntu/Lubuntu from Ubuntu's website, the idea of each of these covering all spectrums of computing isn't covered well. Ideally, Xubuntu, Kubuntu, vanilla Ubuntu, Ubuntu server, and headless Ubuntu server (no GUI) should be equally supported. Not only this, but further down, no main differences that would make development of either of these (or any derivative) unnecessarily difficult. Unity makes this hard. Mir makes this nearly impossible.

If all development contributed to all of these derivatives easily, then it would be far easier to promote Ubuntu (whichever flavor) as exactly what you needed. Do you desire artistic freedom --> Ubuntu Studio; Do you desire minimal interface and minimal interface lag --> Lubuntu/Xubuntu; Do you desire a highly customizable, highly appealing, full-featured desktop --> Kubuntu; Do you desire a responsive, customized Ubuntu experience that works out of the box --> Unity Ubuntu (vanilla);. etc etc for Mythbuntu, etc

Instead of how they present them now, the download screen would focus on what the main intent was. In fact, you could throw away the whole "Lubuntu, Xubuntu, Kubuntu".. It would all be Ubuntu --> Ubuntu (KDE Flavor), Ubuntu (Unity Flavor), Ubuntu (Studio Flavor), Ubuntu (Myth flavor), etc.... All roads lead to Ubuntu... but it's customized by what the user wants and needs and not what Canonical/Shuttleworth deem.

Unity was totally unnecessary. Mir is totally unnecessary. These are alienating the Ubuntu community and open-source community.

And Ubuntu should have really gone to a rolling release with POINT RELEASES (CD/DVD ISOs released) every six month for the publicity... Take the drama out of it for the *regular* users... I've thought of going to Sabayon dozens of times just to get away from the six month apprehension (haven't really had problems, but MIR drama is going to bring it back until we either figure out Kubuntu is hosed or see how it will be okay long-term)

[woodsmoke]

good comments!

woodsmoke

[SteveRiley]

I have often wondered why these smaller distros feel the need to reinvent packaging. RPM/YUM/Zypp and DEB/dpkg/APT are so mature now that it seems rather silly to start over every time.

[SteveRiley]

I thought Sabayon packages were pre-compiled?

[bweinel]

This does not fit your "Now....not...later...NOW...NOW....NOWWWWWWW!! !" requirement, but I have dreamed that Kubuntu users infiltrated the IT departments in their organization and rose to a position where they had decision making powers.

I sent this over to the IT manager at our office the other day with the following comment:
"I'll bet you don't have an MS based server that can do this uptime...."

cnu1
Time on system: Mon Aug 19 17:16:32 2013
Kernel and CPU: Linux 2.6.28-18-server on x86_64
Processor information: AMD Opteron(tm) Processor 246 HE, 2 cores
System uptime: 952 days, 6 hours, 29 minutes

cnu2
Time on system: Mon Aug 19 16:58:59 2013
Kernel and CPU: Linux 2.6.28-19-server on x86_64
Processor information: AMD Opteron(tm) Processor 248 HE, 2 cores
System uptime: 803 days, 1 hours, 44 minutes


cheers,
bill

[woodsmoke]

lol GREAT!!

woodsmoke

[verndog]

Just a little observation re. Sabayon, for a while I've been running it on a somewhat older computer and it is a really nice looking and feeling system....And once you run into issues because of a failed update you are without specialist knowledge basically SOL.

I've had bad experiences with Sabayon (Sabayawn), and at the time at Distrowatch many users agreed. This was a few years ago. I'm surprised that it works so well on your older computer. It was dog slow when I tried it, at the time on my P4 system. I do know that it is very popular, so something is done right, it just didn't work for me.

I have often wondered why these smaller distros feel the need to reinvent packaging. RPM/YUM/Zypp and DEB/dpkg/APT are so mature now that it seems rather silly to start over every time.

That's my thinking also. I'm so use to the debian culture I feel lost with rpm/yum and Gentoo's Portage was just to much work.

[SteveRiley]

"I'll bet you don't have an MS based server that can do this uptime...."

System uptime: 952 days, 6 hours, 29 minutes
System uptime: 803 days, 1 hours, 44 minutes

As an experiment, it may be interesting to see how long a system can stay up. (I have seen Windows servers achieve similar numbers.) But as a systems management discipline, extended up times are invitations for trouble.

A system up for 900 days has not had its kernel updated in 900 days (except if you're using ksplice). That's a risky position -- think about the number of vulnerabilities discovered and patched during the intervening time. I would certainly not reward a person for failing to update servers.

If you absolutely need 100% up time, the proper design involves clustering and load balancing. This gives you the freedom to manage individual nodes without disrupting overall availability.

[bweinel]

But as a systems management discipline, extended up times are invitations for trouble.

A system up for 900 days has not had its kernel updated in 900 days (except if you're using ksplice). That's a risky position -- think about the number of vulnerabilities discovered and patched during the intervening time. I would certainly not reward a person for failing to update servers.

True.. However in this case these two servers are behind multiple firewalls and are basically just 'scratchpad' file shares. So nothing of any consequence is stored on them. Just daily work flow. (In fact, I have a bash script that executes every evening which cleans them off for the next days files.)

We do have clustering blade servers for critical applications... But I thought it interesting in light of difficulties with stability experienced by some O/Ses, that this says a lot about the stability of the linux kernel.

I guess maybe I should think about rebooting them before too long.

cheers,
bill

[michaelferrie]

Since we have been cast from the nest by Ubuntu its time to fly alone.