Ivor O’Connor

October 31, 2009

Why Ubuntu Sucks

Filed under: Uncategorized — ioconnor @ 11:05 am

Perhaps the question “Where Ubuntu Does Not Suck” should be discussed. It is free which is very good. It has standard Unix commands which is very good. It has the best geek tools available. Very few viruses. That’s pretty much it.

On the negative side.

  1. Anything graphical sucks on Ubuntu. Ubuntu uses an ancient set of bad programs to handle the screen. We aren’t talking about something from 2001. Or even 1995. It goes back to the early 1970s. Can you say “clunky and slow”? It’s worse than that. Some say it’s beyond bad because the drivers for graphic cards are proprietary. This means that instead of using the CPUs on the graphical cards hardware to drive the pixels every pixel is calculated by the CPU instead. And remember the CPU is using programs from the 1970s. Hence you’ll often see processes like “gs” using 100% of the first CPU and “socket” taking 100% of the second CPU. What does this mean to you the user? It means it can take 10 seconds to update a simple click of a box in firefox. It can take 30 seconds or more to alt-tab to another window. And this is on machines with 4GBs and 2000+ MHz dual CPUs.
  2. Almost all peripheral hardware is not supported. Sure you can find the hardware you want on the officially “supported hardware lists” but it’s not really supported. Take my printers. All of them are supposedly fully supported. None of them work worth a crap unless driven by M$. Sure the laser printer will print off a single color page or two. Give it a 6 page color PDF and it may or may not get around to printing it during the next few hours. Print it from M$ and it’s done within seconds.  Same thing with FAXing, scanning, etc.. So very pathetic. Ubuntu is so bad you must have a separate M$ machine to handle the peripherals.
  3. The best new software, whatever the topic, rarely gets ported from M$ and the Mac to Ubuntu. If you need this software then you’ll need a token M$ machine.
  4. Generally horrible support. There’s practically no documentation on anything. Either you are good with computers and can find enough hints by googling to fix your problems or you should not use Ubuntu. It is that simple. However it is funny in a bad way to watch the various fly-lords in IRC and such tell others with about the same experience to RTFM.



October 25, 2009

Speeding Up Ubuntu

Filed under: Uncategorized — ioconnor @ 3:25 pm

I’m getting tired of Synaptic taking a minute or more to add a new package. I complained briefly on the Ubuntu IRC channel about this but nobody was interested. It seems like whoever programmed the application to check dependencies must have used a O(N2) algorithm. In other words the first few applications you add are done quickly. For example if this is the 2nd addition it might take only 2*2 seconds*.1 or .4 seconds. If you add 100 packages then it takes 100*100*.1 or 1000 seconds. That a bit of an exageration. It’s only taking about two minutes to have it check dependencies. Still this should be a split second task.

Anyways things are so poorly coded on Ubuntu, though better than M$, that I don’t trust things. So my next question was how fast are the CPUs running? Well a

cat /proc/cpuinfo

showed me the CPUs were running at about 1/3 speed. Look for the lines starting with cpu MHz:. Apparently the CPUs are suppose to react and increase their CPU speed if needed. I don’t trust anything, given how badly everything else is coded, so I did the following:

sudo cpufreq-selector -c 0 -g performance

sudo cpufreq-selector -c 1 -g performance

Now both CPUs are running at the max speed all of the time. Whether needed or not.

It’s probably possible to put these commands as the default in /etc/rc.local but I don’t know how. Instead edit the file /etc/default/cpufrequtils and add the following lines:





Now the CPUs will be running at maximum speed across reboots. I’ve tried this and it does work.

It’s amazing people pay lots of money for fast computers yet the developers cut your performance by two thirds and don’t even tell you.

UPDATE 2009.10.26: Seems as if it was not that easy. Apparently it will reset itself to lower speeds if it gets hot. Or confused. Or the defective circuitry DELL stuffs inside batteries and battery charges is not working correctly as in my case. To get around this I’ve had to edit the file sudo gvim /usr/sbin/laptop_mode and make some obvious changes. I’ll see if this does work over the period of a few days. So far so good.

UPDATE 2009.10.28: When booted from battery the CPU speed lowers itself despite the above settings. So for now I’ve manually put the commands into the bashrc script. Since I always work from a shell this works for me. Maybe someday I’ll figure out a better solution.

Create a free website or blog at WordPress.com.