• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Linux GUIs are so slow

Red Squirrel

No Lifer
Compared to windows I find the GUI in windows is insanely slow. Is there anything I can do to speed it up?

For example i just setup a fresh CentOS box and it takes about 5 minutes to log in, while on Windows its near instant. (same machine, this is ESX).
 
Are you complaining that the GUI isn't responsive enough, or that there are too many background processes being started when you begin your CentOS session?
 
It's just so unresponsive. Anything I do within the GUI. Like opening the terminal takes about a minute. I can shift+alt to another terminal and do stuff at normal speed in plain text, so I know it's not the actual system being slow, it's the GUI. I noticed this in most distros. I think ubuntu is about the only distro that seems somewhat responsive, but not as much as Windows xp. (Vista is another story)
 
Don't lay the blame on Linux until you are running it on native hardware and NOT in a VE and still have the slowness.

Your problems probably stem from using ESX + VESA driver instead of an accelerated driver.
 
Originally posted by: Crusty
Don't lay the blame on Linux until you are running it on native hardware and NOT in a VE and still have the slowness.

Your problems probably stem from using ESX + VESA driver instead of an accelerated driver.

But why would Windows not be affected by this? Even without VMware tools Windows is still responsive the same it would be on a physical box. There must be some kind of setting i can change maybe to speed up the GUI. like when i start a terminal it just sits at "starting terminal" for a super long time until it finally decides to come up. Logging in is by far the worse though as it sits at the loading splash screen for a good 10 minutes. The cpu is hardly even working.
 
These are running under virtual machines? Are there any other virtual machines running on this box? Are the cpu and memory settings the same?

I agree that the only fair comparison would be on bare metal. In my experience though, linux seems to be much more responsive than windows. I typically don't use GUI on anything other than Ubuntu desktops though, so I don't know about CentOS. Also, I know RedHat Enterprise Linux (of which CentOS is a clone) installs a LOT of extra stuff. I can't tell you from memory though how many of those things are services that would be running on bootup, but it may be one thing to consider that your CentOS install could be slower because it is doing a lot more by default than Windows.

Also, VMWare Tools is a must and has a big impact on responsiveness in both systems, in my objective experience.
 
Even without VMware tools Windows is still responsive the same it would be on a physical box

No, it's not. The VESA driver that Windows uses by default in VMware is horribly slow. Once you install the VMware tools you get an accelerated VMware driver that's many magnitudes faster. In fact Linux should be faster by default because the Xorg VMware driver is included with Linux but it's not with Windows.

There must be some kind of setting i can change maybe to speed up the GUI. like when i start a terminal it just sits at "starting terminal" for a super long time until it finally decides to come up. Logging in is by far the worse though as it sits at the loading splash screen for a good 10 minutes. The cpu is hardly even working.

Sounds like you've got another issue instead of (or on top of) the video driver issue, probably DNS or something.
 

Try XFCE or other light weight windows managers to see which one fit your needs.

My fav is FXCE, then Gnome.
 
Why would DNS slow down the GUI? Why would I even need network access on that VM? (there is no network access)

Because most of Linux is network capable on some level or another and having DNS lookups fail will slow things down. If you can ping both localhost and the hostname of the machine without any delays then that might not be it, but it's still worth fixing if you plan on having that installation use the network.

If you really want to see where a process is hanging on startup run it through strace and see what syscalls are taking the longest, that usually points you in the right direction as well.
 
There is no DNS on that machine. This is just a very base install with SSH. All other ports are blocked. Do I really need DNS access just for a terminal window or a user manager app to load? I don't get why it would be required.

I did not get a chance to read up on strace yet but I'll try it when I get the chance.
 
Originally posted by: RedSquirrel
There is no DNS on that machine. This is just a very base install with SSH. All other ports are blocked. Do I really need DNS access just for a terminal window or a user manager app to load? I don't get why it would be required.

I did not get a chance to read up on strace yet but I'll try it when I get the chance.

Are you sure you've left all access open to and from the lo interface?
 
Do I really need DNS access just for a terminal window or a user manager app to load? I don't get why it would be required.

IMO DNS should be a very basic requirement. There's no reason not to have it working...
 
Originally posted by: Brazen
Originally posted by: RedSquirrel
There is no DNS on that machine. This is just a very base install with SSH. All other ports are blocked. Do I really need DNS access just for a terminal window or a user manager app to load? I don't get why it would be required.

I did not get a chance to read up on strace yet but I'll try it when I get the chance.

Are you sure you've left all access open to and from the lo interface?

From his thread on iptables no, the only traffic that's ever going to hit this box(assuming they are the same ones in question) is incoming port 22, everything else is blocked.
 
Originally posted by: Crusty
From his thread on iptables no, the only traffic that's ever going to hit this box(assuming they are the same ones in question) is incoming port 22, everything else is blocked.

And OpenSSH likes to have DNS. 😛
 
Originally posted by: n0cmonkey
Originally posted by: Crusty
From his thread on iptables no, the only traffic that's ever going to hit this box(assuming they are the same ones in question) is incoming port 22, everything else is blocked.

And OpenSSH likes to have DNS. 😛

Not really, unless you're going by hostname.

But disabling the firewall did speed up the GUI. Still not as fast as Windows, but close. I don't get it, why would a LOCAL activity require DNS? It's like if MS made it so you need internet access to play solitaire. Can I get away with setting up named and just adding localhost to the resolv.conf file? I need this machine to have zero outside access.
 
/etc/hosts is all you need to provide name resolution for localhost

Your idea is right, but execution is wrong. Your iptables rules are blocking all traffic on all interfaces except for anything incoming port 22. Open up your lo interface to incoming/outgoing.
 
Not really, unless you're going by hostname.

Actually it does, if you don't have working DNS it'll take longer to login as it fails to resolve stuff.

I don't get it, why would a LOCAL activity require DNS? It's like if MS made it so you need internet access to play solitaire

Because there's networking involved in X. If you had an X server installed on Windows and ran an X app locally on the same machine you'd need some networking to work on Windows too.

Can I get away with setting up named and just adding localhost to the resolv.conf file? I need this machine to have zero outside access.

Just setup your hosts file properly and make sure all traffic across the loop back and to/from itself on any network interfaces is allowed.
 
What changes do I need to do to the host file? I always had the impression I'd never really needed to touch that unless I want to setup a local host resolution without using DNS.
 
Back
Top