Ubuntu: "We're not Linux"

[GreyGeek]

Hm. I don't know much at all about RPM. I would have guessed that a fundamental function of any packaging system is to automate much of the manual labor you just described. If RPM is really so broken as this, why does anyone use it anymore?

I bought the book, "Maximum RPM" ten years ago and what I know about RPM is based on my experience and that book. BUT, I haven't used an RPM based distro since Mandriva in 2008. A LOT could have changed with RPM since then. I've played with openSUSE as a guest OS last year and it seemed to be OK. It's GUI package manager behaved pretty much like Synaptic did.

I don't think that the maintainers of $DE-on-Ubuntu really need support in the classic sense. Just a happy place in which to create and maintain their projects. Like, say, Launchpad

All they'd need is money to pay for the hosting services, by donation or sugar daddy. That's about it. Shuttlesworth was the sugar daddy for Kubuntu. He's still paying hosting support, but Kubuntu is only $800 away from running on their on web server.

[bsniadajewski]

@GG

From my experience, especially with OpenSuse, RPM-based distros have improved plenty since you've last used RPM. Among them, I fell that OpenSuse's ZYpper is up there almost with DEB/apt. PCLOS's use of apt-rpm (up through last year, IIRC) was up there as well, despite apt-rpm no longer being maintained as far as I know. (PCLOS has switched to yum, same as used in Fedora, Red Hat and immediate derivatives.)

[vw72]

I agree:
Ubuntu-Unity
Ubuntu-KDE
Ubuntu-Xfce
Ubuntu-Gnome
etc....
But, the msg I believe Shuttlesworth is sending is that he doesn't want to support such a wide variety of DE's any more.

I agree with this. I always thought Fedora's naming system made more sense Fedora, Fedora KDE Spin, Fedora XFCE Sping, etc. Instead of Ubuntu-Unity, I would just call it Ubuntu. The advantage to the Ubuntu-KDE instead of Kubuntu is that it emphasizes the Ubuntu base system and still plugs the flagship product.

As with Fedora, Canonical would only "support" the main version and the other "spins" would be community supported.

[SteveRiley]

When you got to the point were a dependency tested OK and didn't need other dependencies, you would use KPackageKit to install each of them, from the bottom up, until you finally installed the package you originally wanted to install. BUT, finding and installing dependencies was only half of the battle. Say you test dependency "C.x.y" but it says it cannot be installed because "C x.w", which is already on your system cannot be replaced because packaged J, K, L .... T depend on it. You've just encountered "Dependency Hell".

Hm. I don't know much at all about RPM. I would have guessed that a fundamental function of any packaging system is to automate much of the manual labor you just described. If RPM is really so broken as this, why does anyone use it anymore?

But, the msg I believe Shuttlesworth is sending is that he doesn't want to support such a wide variety of DE's any more.

I don't think that the maintainers of $DE-on-Ubuntu really need support in the classic sense. Just a happy place in which to create and maintain their projects. Like, say, Launchpad

[GreyGeek]

I trust Microsoft about as far as I can comfortably spit a dead rat.

You have more trust than I do, Kilz!

[GreyGeek]

How is it that a choice of package management system can influence the stability of an operating system? I ask this because I'm genuinely curious. .....

The Redhat Package Management system was the tool used by my first Linux distro, Redhat 5.0. It was also used by my second distro, SuSE 5.3, in 1998. I never had any problem with RPM with those two distros, mainly because, IIRC, there wasn't such a thing as a "repository". Your packages were either part of the ISO you downloaded, or you went to websites like http://rpm.pbone.net/index.php3/stat/2/simple/2 and downloaded the rpm file of the package you wanted to install. That site offered rpm packages for a wide variety of distros. An RPM package for one distro may or may not install on another distro which used RPM. After I downloaded the package I would open it with KPackageKit which, at the time, was an awesome program. It had a "test" mode which allowed one to see if the putative install would take place without problems. IF it returned a zero you had a 99% chance it would install OK. Otherwise, it would tell you what missing "dependencies" were needed on your system. You would go to RPM BONE and fetch each of the dependencies and test them independently to see if they, too, would install without problems. Sometimes a dependency had one or more dependencies of its own. When you got to the point were a dependency tested OK and didn't need other dependencies, you would use KPackageKit to install each of them, from the bottom up, until you finally installed the package you originally wanted to install. BUT, finding and installing dependencies was only half of the battle. Say you test dependency "C.x.y" but it says it cannot be installed because "C x.w", which is already on your system cannot be replaced because packaged J, K, L .... T depend on it. You've just encountered "Dependency Hell".

And then, there is the "runaway" problem. I was using KNOPPIX, a German distro which, IIRC, introduced the idea of a repository. Or, at least, it was the first distro I used that embraced the concept. It also linked KPackageKit with its repository, much like Muon today. It was, and still is, a good distro. One day I was casually looking through the list of uninstalled files for KDE 3.x when I saw something was looked interesting. I selected it and clicked the "Install" button. I had done it so many times already that I ignored its message about "removing 295 applications and installing 304 applications". I assumed it was going to download and install one package but the first thing I saw was "removing 12 of 295".. :eek: It was too late. If I broke the install I'd have a broken desktop and/or distro. I let it roll. After 30 or so minutes a msg appeared stating "Installing 1 of 304", and the names of programs began to fly by. After another 30 or so minutes the process came to an end with the instruction to log out and log back in. I did. I was presented with the newest KDE 3.y desktop, without even asking for it. :cool:. A couple days later I found another program I thought would be neat to install. Infused with confidence I clicked the "Install" button. I saw another msg appear stating "Removing 1 of 305..." and 30 minutes later "Installing 1 of 295"...
Sure enough. It was downgrading my KDE installation to 3.x because the app I wanted to install required it. "Oh well", I thought, "KDE 3.x was OK", even if I couldn't use the app I had installed a couple days before. When it came time to log out and log back in (or, in effect, to restart the Xserver), I couldn't log back in without dropping to the console. KDE 3.x was hosed. If there was a package to install the KDE DE from scratch, or to repair a broken one, I didn't know about it.

That experience gave me the push to try a new distro called "LibraNet", based on Debian and using the deb packaging system and Aptitude. The differences between RPM and deb was stunning, at least to me. The LibraNet developer died and orphaned the distro, so I went distro hunting again. Never the less, I returned to the RPM and tried Mandrake, and later Mandriva, then PCLOS and back to Mandriva. I had tried Debian "way back when" it came on 15 floppies (or was it CD?) but was unsuccessful in installing it. I only switched to Kubuntu because, unlike Mandriva, it was installing the KDE 4.2 DE with Jaunty in the spring of 2009, and not waiting until the fall or winter of 2009 like Mandriva was. IMO, the deb/apt-get packaging/managing system is significantly superior to the RPM/whatever system to justify staying with deb/apt-get regardless of the distro.

Matter of fact, I wonder if it would be better to drop all the various *buntu names. There could be some benefit to becoming known as "KDE on Ubuntu." For one thing, it would clear up a lot of the confusion now. And the idea would naturally extend to any DE.

I agree:
Ubuntu-Unity
Ubuntu-KDE
Ubuntu-Xfce
Ubuntu-Gnome
etc....
But, the msg I believe Shuttlesworth is sending is that he doesn't want to support such a wide variety of DE's any more.

[Kilz]

Matter of fact, I wonder if it would be better to drop all the various *buntu names. There could be some benefit to becoming known as "KDE on Ubuntu." For one thing, it would clear up a lot of the confusion now. And the idea would naturally extend to any DE.

The only problem is that may lead some people who dont understand the different desktops on Linux (linux newbies) wondering if they will have to deal with some of the questionable Ubuntu inclusions like "Unity".

[Ole Juul]

Matter of fact, I wonder if it would be better to drop all the various *buntu names. There could be some benefit to becoming known as "KDE on Ubuntu." For one thing, it would clear up a lot of the confusion now. And the idea would naturally extend to any DE.

It would indeed clear up a lot of confusion. Perhaps it would also be an eye opener for those who have not yet experienced the freedom of choice. I'm thinking of Windows users who seem to expect very little of their DE because they get what they get, and they accept that. In fact, now that I think about it, binding the OS and DE into one name is a direct copy of what the big proprietary vendors do. Why is a Linux distro doing that?

[dequire]

Honestly, if I were Shuttleworth, I would let Kubuntu thrive. There's no advantage to him if it goes away. In other words, he has potential gains (increased users) without any cost to him. Why would anyone in their right mind get rid of Kubuntu given that situation?

[SteveRiley]

I've had too many bad experiences with the RPM package system in a wide variety of RPM based distros, which is why I prefer distros based on the deb system.

How is it that a choice of package management system can influence the stability of an operating system? I ask this because I'm genuinely curious. The choice of DEB/RPM/whatever would seem orthogonal to the quality of the packages themselves.

Why do you suspect that? And what about Xubuntu, Edubuntu, and any project using launchpad?

Because Shuttlesworth is, IMO, cutting costs by reducing expenditures in areas which have no hope of turning a profit for Canonical. That's why, eventually, "infrastructure support" for Kubuntu will also be cut., effectively cutting Kubuntu loose entirely from Ubuntu/Canonical. With no advantage remaining for Kubuntu to stay based on Ubuntu, moving to Debian is a logical choice.

The logical extension of this notion is that Launchpad will go away. Imagine the hue and cry -- not to mention loss of vast community support -- if that were to happen. Kubuntu is now, like the others Claydoh mentioned, a Launchpad project. And that's not a bad thing.

Matter of fact, I wonder if it would be better to drop all the various *buntu names. There could be some benefit to becoming known as "KDE on Ubuntu." For one thing, it would clear up a lot of the confusion now. And the idea would naturally extend to any DE.

[Kilz]

I suspect that Canonical will keep providing the infrastructure to Kubuntu. I dont think it realistically adds more costs to Canonical because they are already paying for the services for the other buntu's and its probably under some kind of one price for all contract. But even if they dont, Im glad to hear that this distro will remain debian based. Its one of the reasons I use it instead of say fedora. After so many years using Ubuntu, when I switched desktops, at the way things are laid out in the file system and package management remained the same.After the disaster that is Gnome3/Unity I am really enjoying Kde.
But I really dont trust Canonical anymore. The last couple of years the real Canonical has started to show its true self. It is a rather ugly picture imho.

[GreyGeek]

Luke.......

Trust......

the SOURCE ... absolutely.

I was having speed, hanging and disconnect problems with my RealTek 8188ce wifi chip. I am less than 3 meters from my wireless router but rarely got over 60% signal strength. I have four neighbor who are booming in at nearly 100% signal strength.

I down loaded the rtl8192ce source compiled for the 3.2.0 kernel from the RealTek website.. THen I "sudo su" and then untarred it and moved into the directory that was made. There I issued "make install", according the the readme.txt. Within about a minute I had new drivers for the 3.2.0 kernel. The new driver isn't perfect, because my signal strength is at 96% +- 4%, but there are NO MORE slowdowns, hangs or disconnect problems.

[woodsmoke]

Luke.......

Trust......

the original source

[kubicle]

"Upstream" to me always refers to the distro being forked, not a DE. Thus, Ubuntu was forked from Debian. To go "upstream" of Ubuntu is to go to Debian. KDE is not a distro, obviously.

"Upstream" generally means "where the code/software you distribute comes from".

Debian is "upstream" if you build on their sources, but debian also has several "upstream" sources, as they do not write everything that they distribute. You can usually follow "the upstream path" until you get to the original source, which is definitely "The Upstream" for all downstream projects.

If you distribute KDE software, the KDE project is upstream (even though it's not a distro).

http://en.wikipedia.org/wiki/Upstrea...e_development)

[GreyGeek]

Why do you suspect that? And what about Xubuntu, Edubuntu, and any project using launchpad?

Because Shuttlesworth is, IMO, cutting costs by reducing expenditures in areas which have no hope of turning a profit for Canonical. That's why, eventually, "infrastructure support" for Kubuntu will also be cut., effectively cutting Kubuntu loose entirely from Ubuntu/Canonical. With no advantage remaining for Kubuntu to stay based on Ubuntu, moving to Debian is a logical choice.