What Fedora 11 should do better:

[Clean Mind]

1)Better xorg.conf to reduce flickering during start up.
2)Better compatibility between Yum and Package Kit (this is kind of tedious.)
3)Better XFCE and LXDE (I still need Gnome for quite a few things.) or better integration between XFCE and Emerald.

[Demz]

3) its not up to Fedora to make xfce better, its up to the xfce devs to do that,
2) PackageKit sucks anyway so who cares
1) perhaps we'll see this in the beta

[ilja]

Clean Mind, just be reminded, that this is a user forum. Developers mostly do not look here. They do however look into the developer mailing list and bugzilla.
If you would fancy real change and not only a nice chat, you might consider checking them out and rethinking the way you are suggesting things. Everybody wants things to be "better", but the only detail you give is the flickering for xorg. Try to think what you really want in concrete terms, before you go on.

[JonathanR]

The best way to change things is "upstream". File your wish/bug report with your distro (in this case Fedora) and with the project developers (i.e. xorg). Use their mailing lists, and irc. Get involved. Do some research as to what is being done, what is being addressed, and find out what they need. The biggest gripe developers have is that they don't get the feedback they need. Not enough bug reports and things like that. Typically, what they get is a lot of whining.

A flickering screen is most likely due to the driver, so depending on the driver you use, you need to file the bug report with those that make the driver. For example, ati, nvidia, intel, and so on.

What I'd like to see is better community involvement. More people getting involved, and filing better reports. The more people we have testing the product, and the more reports that are done, the more "polished" the product gets.

[bob]

And, I'm moving this to the Alpha/Beta/Snapshot Forum for better placement.

[JN4OldSchool]

Please dont file bugs on this stuff, the poor devs are busy enough and they already got bug reports out the...you know...

These are all personal problems, not bugs.

To reiterate what Greg said, and add my 2 cent,

1. As JonathanR says, check your driver. This does not seem to be a common problem.
2. PackageKit sucks anyway, so who cares? Install yumex
3. Xfce and LXDE are Xfce and LXDE. My Xfce works great and that is running compiz-fusion and emerald. If it does not work for you then stick with Gnome.

[JonathanR]

I don't get packagekit. There is rpm, which is the base layer for package management. Then there is yum that is the second layer. yum connects to and utilizes rpm. Now we add packagekit which calls on yum, and yum calls on rpm........ I'm sorry, but in my opinion, this is stupid. It is unnecessary. Actually, you could say that even yum, smart, synaptic, apt, yast, are unnecessary. RPM by it self can work just fine. You can add repos to rpm. RPM just doesn't have a gui. There is even rpm-python, so you can write plugins for rpm, if you wanted.

[JN4OldSchool]

I don't get packagekit. There is rpm, which is the base layer for package management. Then there is yum that is the second layer. yum connects to and utilizes rpm. Now we add packagekit which calls on yum, and yum calls on rpm........ I'm sorry, but in my opinion, this is stupid. It is unnecessary. Actually, you could say that even yum, smart, synaptic, apt, yast, are unnecessary. RPM by it self can work just fine. You can add repos to rpm. RPM just doesn't have a gui. There is even rpm-python, so you can write plugins for rpm, if you wanted.

You are right. But many people do not want to use the terminal and cannot bother to type man rpm. Yum is awesome, it provides much function. And I agree with a GUI frontend for yum. I understand what packagekit is trying to do, and there are some good ideas there. I think having a single, universal frontend for all the various package systems is silly, I mean, I can figure out yast, synaptic, yumex...whatever...as I use them. The PK developer always talks some mystic dribble about yumex being dangerous because it runs as root, blah, blah, blah...Maybe I just dont get something, but I want my package manager running as root. I know what I am installing, I am invoking it myself, typing my strong password in each time, and I do not want anyone else screwing with my packages. At any rate, if my old bud hughie ever gets PK running right I am sure it will be a good front end. But I have seen nothing but problems with it so far.

[JonathanR]

You are right. But many people do not want to use the terminal and cannot bother to type man rpm. Yum is awesome, it provides much function. And I agree with a GUI frontend for yum. I understand what packagekit is trying to do, and there are some good ideas there. I think having a single, universal frontend for all the various package systems is silly, I mean, I can figure out yast, synaptic, yumex...whatever...as I use them. The PK developer always talks some mystic dribble about yumex being dangerous because it runs as root, blah, blah, blah...Maybe I just dont get something, but I want my package manager running as root. I know what I am installing, I am invoking it myself, typing my strong password in each time, and I do not want anyone else screwing with my packages. At any rate, if my old bud hughie ever gets PK running right I am sure it will be a good front end. But I have seen nothing but problems with it so far.

Well, there are pros and cons to running package managers as root. What could be done to resolve this is set up a directory tree in the users account. This way they have access to all that they need, but at user levels. You could then run rpm, or various admin tools, at that user level, only affecting that user. To make it affect the entire system, run it from the root users account.

I to, am very familiar with the various package managers, and do like the ideas and concepts. I just think various layers are stupid. I think more time should be spent on making rpm a better tool, instead of all these various tools trying to make rpm function the way they think.

[JonathanR]

In fact, there was a rpm gui designed for the mac os: http://www.algonet.se/~afb/rpm/

[William Haller]

Jonathan R. You could do that, and in fact if you install a package from source as a normal user you sometimes have to install in your own account.

But in general, that's a bad idea.

I know I'm a dinosaur from the days when all you had was a floppy and were thankful you weren't using punched cards and disks are cheap and everything, but why would you want to waste space with multiple users installing several hundred megabyte games?

It makes backing up a much worse undertaking than it is now - as it is I have a script that isolates all files that aren't part of an installed RPM (or that are part but have been reconfigured), and creates a compressed tar ball of them every night that I can move to different systems and to offsite backups when I get a minute.

When you get a fully loaded system (even a fast fully loaded system) it's a long process. It would be even worse with another thousand packages to do.

You can say it would only be one or two, but with all the dependencies it would be a huge number. You couldn't depend on the system dependencies because if the user doesn't upgrade their packages you can't update the system. Dependencies are bad enough as it is now. Think of what it would be like to have each user updating all of their dependencies whenever they needed.

[JonathanR]

Jonathan R. You could do that, and in fact if you install a package from source as a normal user you sometimes have to install in your own account.

But in general, that's a bad idea.

I know I'm a dinosaur from the days when all you had was a floppy and were thankful you weren't using punched cards and disks are cheap and everything, but why would you want to waste space with multiple users installing several hundred megabyte games?

It makes backing up a much worse undertaking than it is now - as it is I have a script that isolates all files that aren't part of an installed RPM (or that are part but have been reconfigured), and creates a compressed tar ball of them every night that I can move to different systems and to offsite backups when I get a minute.

When you get a fully loaded system (even a fast fully loaded system) it's a long process. It would be even worse with another thousand packages to do.

You can say it would only be one or two, but with all the dependencies it would be a huge number. You couldn't depend on the system dependencies because if the user doesn't upgrade their packages you can't update the system. Dependencies are bad enough as it is now. Think of what it would be like to have each user updating all of their dependencies whenever they needed.


A soft link with appropriate permissions would solve that problem.

[JN4OldSchool]

A soft link with appropriate permissions would solve that problem.

It would. As would the administrator simply controlling the system.

[AdamW]

The point about permissions is the reason PolicyKit was invented.

The point is basically that you don't need *everything* a package management app does to have root permissions. It doesn't need root permissions to show you what packages are available, let you browse them, and so on. It only needs root permissions to actually install them.

This applies to lots of apps - almost every GUI app that needs root for some purpose, in fact.

The security aspect is about the code itself, not about your interaction with it. If the coder screws up and leaves a buffer overflow or something in there, if it's in code running as root, that's a more serious exploit than if it's in code running as a user. That's what fine-grained permissions projects like PolicyKit are intended to address. They allow you to just have a specific operation within an app run as root, rather than the entire app running as root, all the time. So PackageKit uses PolicyKit to only run the package installation step with root privileges, rather than having the entire app run as root all the time.

The reason yum, apt, urpmi, smart etc all exist is, basically, dependency resolution. RPM doesn't do this. If your 'rpm -U' or 'rpm -i' transaction doesn't include all the necessary packages, RPM just tells you so, and stops. This is what people used to call 'dependency hell', a long time ago. No-one likes it. :) The main function of yum/apt/smart/urpmi is, instead of just complaining that a dependency is missing, to go out and add it to the transaction.

PackageKit also has an important function, which I think is misunderstood by people who only see it as a GUI package installation tool. It isn't. The PackageKit-based GUI package installation app is, really, just a proof-of-concept.

The point of PackageKit is to be a standard cross-distribution package management API. It's *not* really aimed at the case where you, as a user, are initiating package management operations. The point of PackageKit is for other scenarios.

Say you've got an app that needs to trigger the installation of a package, in some particular scenario. There's really no good way to do that before PackageKit came along, because there's no unified API. You could make it only work on Debian and not care about other distros, or you could write a *lot* of conditional code to handle it on a set range of packaging systems.

With PackageKit, an app can just call PackageKit and ask it to install the package named 'foo'. It doesn't need to care what distro it's running on, or how to install the package 'foo' on that distro. That's PackageKit's job. It's an abstraction layer, like many libraries are on Linux, so to understand why it's useful, you have to understand the scenarios where that level of abstraction is helpful.

[JonathanR]

The point about permissions is the reason PolicyKit was invented.

The point is basically that you don't need *everything* a package management app does to have root permissions. It doesn't need root permissions to show you what packages are available, let you browse them, and so on. It only needs root permissions to actually install them.

This applies to lots of apps - almost every GUI app that needs root for some purpose, in fact.

The security aspect is about the code itself, not about your interaction with it. If the coder screws up and leaves a buffer overflow or something in there, if it's in code running as root, that's a more serious exploit than if it's in code running as a user. That's what fine-grained permissions projects like PolicyKit are intended to address. They allow you to just have a specific operation within an app run as root, rather than the entire app running as root, all the time. So PackageKit uses PolicyKit to only run the package installation step with root privileges, rather than having the entire app run as root all the time.

The reason yum, apt, urpmi, smart etc all exist is, basically, dependency resolution. RPM doesn't do this. If your 'rpm -U' or 'rpm -i' transaction doesn't include all the necessary packages, RPM just tells you so, and stops. This is what people used to call 'dependency hell', a long time ago. No-one likes it. :) The main function of yum/apt/smart/urpmi is, instead of just complaining that a dependency is missing, to go out and add it to the transaction.

PackageKit also has an important function, which I think is misunderstood by people who only see it as a GUI package installation tool. It isn't. The PackageKit-based GUI package installation app is, really, just a proof-of-concept.

The point of PackageKit is to be a standard cross-distribution package management API. It's *not* really aimed at the case where you, as a user, are initiating package management operations. The point of PackageKit is for other scenarios.

Say you've got an app that needs to trigger the installation of a package, in some particular scenario. There's really no good way to do that before PackageKit came along, because there's no unified API. You could make it only work on Debian and not care about other distros, or you could write a *lot* of conditional code to handle it on a set range of packaging systems.

With PackageKit, an app can just call PackageKit and ask it to install the package named 'foo'. It doesn't need to care what distro it's running on, or how to install the package 'foo' on that distro. That's PackageKit's job. It's an abstraction layer, like many libraries are on Linux, so to understand why it's useful, you have to understand the scenarios where that level of abstraction is helpful.

rpm can resolve dependencies if it's configured with repos, in which I wrote a howto for. So with this, rpm can be just like yum, smart, apt, yast, and so on. See here: http://forums.fedoraforum.org/showthread.php?t=214822

[AdamW]

Interesting - wasn't aware of that. Reading between the lines, it's rather old code of Jeff's (the examples seem to date from Red Hat 8). Is it maintained any more? I don't seem to have an 'rpmcache' command available here, and I can't seem to find any Fedora package which would provide it.

[JonathanR]

Interesting - wasn't aware of that. Reading between the lines, it's rather old code of Jeff's (the examples seem to date from Red Hat 8). Is it maintained any more? I don't seem to have an 'rpmcache' command available here, and I can't seem to find any Fedora package which would provide it.

As of rpm-4.6 solvedb was removed.
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch-customizing-rpm.html

rpmcache was never a command, but something set up via rpm macros (which is still present with rpm 4.6.

I'm still investigating to see how, or even if, it can be done with rpm 4.6. Those still using rpm 4.4.x can still use rpmcache.

[lmcogs]

Would like to see
1 right click file/folder in dolphin with action burn.
2 never seem to use icon top right corner
3 I know it's probably k3b but what annoys my head is evertime I drag something to current project it changes the name and it can't take too long names.