I tried to use Linux GUI for Fedora but I did not find it intuitive than that of windows. Whenever I tried installing any software using rpm file by double clicking file, many times it stuck and when I reinvoke that from terminal it says yum is already locked and some other  installation process is already running and I always have to force quit that process. From OS point of view this seems to be Scheduling problem. (How) can we replace scheduling  for Linux x window? Is there any better scheduling available for Fedora linux x window?Update: Sorry about late response: => When I double click rpm package , it does not show up anything even after waiting for two minutes. => When I try to invoke that package from command line thinking something wrong with Fedora GUI it throws me a message saying some other process has the lock. => When I kill that process using kill command and try to install using command line it starts with no problems. => Many times when I don't kill the process after invoking rpm installation package, I start doing some other work, after more than 15 minutes the installation window comes from nowhere asking for root password, after entering which I get window for downloading dependencies ?Can somebody clarify me how this problem is not related to scheduling ?
Fedora GUI package installer takes very long (>15min) to start
linux;fedora;gui;package management
(This is only an answer to your incidental question, not to your main question, but it's too long to put in a comment.)Your problem has nothing to do with processor time scheduling, which is about sharing CPU time between concurrent applications. When you click on a rpm package, the GUI package manager starts, and it continues to run until it's done its job; that's exactly the desired behavior. The fact that the package manager takes more than a couple of seconds to do its first visible subtask (show the password prompt) is a bug or misconfiguration, but it has nothing to do with scheduling.More generally, scheduling can refer to the attribution of a shared resource to concurrent processes over time. Here the interesting shared resource is the package database. Here also, everything is happening normally: when you click on the rpm package, the GUI package installer immediately starts using it, which is exactly what you requested. Since only one package manager can use the package database at the same time (which is why it takes a lock), you can't start the command-line package manager (rpm) while the GUI package manager is running; even looking at it from a highly theoretical perspective, this is a locking issue, not a scheduling issue.Scheduling can also refer to scheduling a program for later running; I think it's the primary meaning of the word in the Windows world (scheduled tasks), but it's not used as much in the unix world (where scheduling out of context refers to CPU scheduling as in my first bullet point above, and people tend to speak of cron jobs).Turning to your main question, the long delay in starting the GUI package manager is a bug or misconfiguration in that particular program. I don't know anything about that program, so I'm afraid I can only provide a few generic investigation suggestions. I'll be asking many questions; the more you answer, the better help you're likely to get.Is this happening from Fedora out-of-the-box or did you configure some things that may be relevant? What exact version of Fedora is this anyway? What architecture (e.g. i386 or amd64)? Is there any virtualization involved?Does anything appear in the system logs? (ls -ltr /var/log, and look at any log entry produced when or after you click on the rpm package)What is the package manager doing? Is it taking CPU time (top or htop or any of many GUI system activity monitors)? Is it doing disk I/O (iotop or any of a few GUI system activity monitors or listen to your hard drive if it's near you)? Is it doing network I/O (tcpdump or Wireshark or ntop)? Even better, use ps xww or some other process viewer to find out the process ID and run strace -s9999 -p$PID to observe what it's doing that's taking so long.Do you have the same issue if you start the package manager from your desktop environment's menus?