Published on October 30, 2008 by Godji
It seems to be fashionable these days to use time-based version numbers on many large software releases. Gentoo is at 2008.0 - the first release of 2008. Ubuntu released 8.10 today - the release of 2008, month 10. Solaris 10 10/08 - the month 10, year 08 update of the Solaris 10 operating system - is just around the corner. Mandriva is already at version 2009. There have been discussions to change Linux’s version number from 2.6.x.z to yyyy.x.z. Surely I am missing many other examples.
Time-based version numbers have replaced monotonically increasing number-based version numbers (the good old 1, 2, 3) for one reason alone - PR. You see, back in the old days there was a guy called Joe Clueless, who thought that something at version 6.2 was more mature, more tested, and better than something else at version 3.1. There was also the irrational fear of 1.0 - a 1.0 program must be brand new and untested. The widespread stupidity on the matter reached a level of insanity prompting various projects - from commercial ones like Netscape and Internet Explorer to free software ones like Slackware - to skip several version numbers in order to appear “better” in Joe’s eyes. Time-based version numbers were the solution - even Mr. Clueless could figure out that 2009.0 was about the same as 9.04, or so they say.
But time-based version numbers are a disaster waiting to happen. What can a vendor (or a community release manager) do if they just cannot get ta good release on time? They have few options:
a) Release a release that is not ready for release. (I apologize for that sentence.)
b) Miss their deadline and rename the release.
Option a) is a bad idea for the obvious reason, and option b) implies taking a PR hit - just like the one the time-based versioning scheme was designed to avoid. I’m worried that most vendors will opt for a), fixing the inevitable bugs with the first rounds of updates, after declaring victory and releasing. And while this may work every now and then, it invariably leads back to Joe Clueless - who will learn to fear a final release until the first update, .1 release, first service pack, or whatever the fix ends up being named. It is the 1.0 problem all over again.
These are no hypothetical worries; they have happened and will continue to happen. I am writing this in the evening of 2008-10-30, less than 36 hours until the end of the month. October promised two releases I am looking forward to - Ubuntu 8.10 and Solaris 10 10/08.
Ubuntu released while I was typing. While it is good to see the release coming on time, I cannot help but ask myself whether a delay of several days would not have been a better idea. Kubuntu 8.10 (released simultaneously with Ubuntu) has at least two known problems at release that affect me - no Bluetooth, and no graphical static IP configuration. They will be fixed in a matter of days (teaching a few more users that “final is the new beta”), but the pressure was to release immediately. 36 hours later the whole thing would have to be renamed to Kubuntu 8.11, and we cannot have that, can we? This dilemma was caused entirely by the versioning scheme; had Ubuntu not been called 8.10, nobody would have minded a 2008-10-03 release.
Solaris, on the other hand, has not released yet. Mind you, Sun has a web page showcasing new stuff in 10/08, as well as a press release that talks about it. But Sun’s download page indicates that 10/08 is planned for the end of October. Will they make it? Sun’s Solaris 10 has the reputation of a very stable and well-tested release within many enterprises, so putting out a half-baked release is not an option. Most likely the new Solaris will not arrive in October, making the version number 10/08 a misnomer. Renaming it 11/08 or just releasing 10/08 in November are both bad from a PR standpoint, and there is no reason why Sun could not have called the new operating system Solaris 10.6 and released it in early November with no consequences whatsoever.
UPDATE 2008-11-03: I was wrong - Solaris 10/08 was released on time. Apart from two bugs where a package should have depended on another package, I have not run into problems. While that ruins my example, my general point still stands.
I could give more examples - remember how Gentoo 2007.1 was canceled in favor of 2008.0 when they were the same release? Remember all the noise about the project being dead? All of that could be avoided if 2007.1 (now known as 2008.0) was called Gentoo 2.4 or whatever the number should have been.
Now that I have given two examples of what can go wrong, I’ll give you an example of what can go right: Debian.
Debian wanted to release 5.0 (codenamed “Lenny”) in September, but they did not make it. Then they really tried to do so in October, but they will not. The Debian community is getting slammed left and right for it, when in fact that is how it should be - I will gladly take a quality release over a timely release. Now imagine what that backlash would have been if they had called Lenny 2008.09 instead, then renamed it to 2008.10, then 2008.whenever. Developers would be under pressure to release whatever they have and fix it later. Now they have as much time as they want to get it done right, and whenever it is out it will be called 5.0 and it will be extremely good even before any updates. (The impatient can go check out the beta version right now.)
Times-based version are a bad idea. The comments area is open for counterarguments.
Posted in Uncategorized
Published on October 27, 2008 by Godji
You just got a new computer. You turned it on, it loaded whatever OS came with it, and it seemed fine. A little later howeever strange malfunctions started happening - the machine hung, rebooted itself, turned itself off, programs crashed, or you could not access certain files. Did you run into a software problem or is the computer somehow defective after all? This tutorial will help you find out. After all, hardware that does not fail outright could still be fairly broken - it could fail after some time has passed, under load, or randomly.
To test your hardware means to test every important component in turn, and ensure that none of them fails under stress.
Memory
The first component you need to check is your RAM. If your memory banks store one thing but retrieve another, then your CPU may execute random instructions or may lose the intermediate results of computations, misleading you into thinking that the CPU is at fault.
Memtest86+ is a free tool whose only purpose is to make sure your memory works reliably. It is a tiny (less than a megabyte!) operating system which you can boot from a CD among other ways. Upon starting, it will run a series of tests on your memory. When all tests complete and a full pass is done, it will immediately proceed to repeat the tests for another pass - and so on indefinitely. Repetition is useful because a faulty memory location may have returned the right answer by chance and passed the test the first time, or because memory might overheat over time and begin to fail only much later. The program reports the total number of errors encountered so far. I recommend you run memtest86+ for 12 hours or more, and if you see even a single error, you should consider the RAM defective.
If memtest86+ begins reporting hundreds of errors immediately, do not panic! The reason could be that you have USB device emulation enabled. You must disable USB emulation from your BIOS setup utility before you run memtest86+. USB device emulation allows you to use a USB keyboard and mouse in an operating system that has no USB support itself; you do not typically need it.
Get memtest86+ here. Do not confuse memtest86+ with memtest86, which is an older utility that serves the same purpose and looks the same (to be precise, memtest86+ is a fork of memtest86).
Processor(s)
Assuming all RAM works, the next thing to test is the CPU. The best tool for the job that I have found is called mprime (Prime95 on Windows). Its main purpose is to find Mersenne primes, and in doing so it stresses your CPU to the maximum while loading all other systems as little as possible. Recognizing that property, mprime comes with a “stress test” mode, which runs calculations with a previously known result and compares it against what the CPU comes up with.
You can find mprime here. Note that its license is unclear; while it’s free to download, I could not find any source code.
Download the .tar.gz file and unpack it. Open a terminal and run the mprime executable. Answer the first question with N. Now enter the number of total processor cores on your system, and you will be asked what tests you want to run. Choose one and confirm with Y to start the test.
I recommend running each of the three tests for 6 hours or more. If your computer freezes completely, or if any of the test threads terminates with an error, then your CPU may be detective. Alternatively, your motherboard may be failing or you may have overclocked too aggressively. This is especially true on Intel platforms up to and including the Core 2, where the memory controller is on the motherboard rather than on the CPU. (AMD and Intel Core i7 processors have it on the CPU instead.)
One thing you could try is to lower the CPU or FSB frequency or to very slightly increase the CPU or northbridge voltage. Only do this if you know what you are doing; you might end up with dead hardware or a voided warranty.
I recommend that you keep a look on CPU temperatures and frequencies during the test. It is possible that as your processor heats up under stress, it lowers its frequency to avoid overheating, resulting in lower performance. Modern processors can change their frequency several times every millisecond and you want to make sure that your CPU will not do so while the test is running. Of course, CPUs also lower their frequencies when they are idle; this is normal and desirable because it saves power. When the CPU is under load however, the frequency must remain at its highest possible value.
Hard Drive(s)
Hard drives, being the mechanical black magic that they are, tend to cause problems more often than other components. Hard disk failure can be catastrophic as your data is stored in there. The health of your hard disks is often more important than the health of any other part.
The most effective way to test a hard drive is to let the drive test itself. Hardware specifications vary from iteration to iteration of what is otherwise the same drive model; thus only the drive itself knows with any certainty what it is going on inside of it. Consequently hard disk manufacturers have standardized on a system for monitoring and testing drives, which is built inside the disk itself and is always available. This system is called S.M.A.R.T..
To access S.M.A.R.T., you need software such as smartmontools, which is free and runs on just about every operating system. After you install it, open a terminal and type:
sudo smartctl -a /dev/sda
Replace /dev/sda with the device name of your hard disk. On Linux, the first hard disk is usually called either /dev/sda or /dev/hda.
You will see a long table of various data about your disk. Two sections are of particular importance. One should say that no errors have ever been encountered; if it says otherwise, your disk is probably failing or about to fail. The other is a list of the S.M.A.R.T. tests that have already been completed, and may or may not be empty.
To run a new test, run:
smartctl -t long /dev/sda
This runs a full test on the drive. The command will tell you approximately how long the test will take. While the test is running you can still use your hard drive because the test is happening inside the disk and the operating system is not aware of it. If you use the disk heavily it will automatically pause the test, carry out your request, and then resume testing. After the indicated amount of time has passed, rerun the smartctl -a command to see the result. If a new test has appeared in the list it means the test is complete and any errors that may have been found have been reported in the error log. If the new test is not in the list of tests, you need to wait a bit longer. It will eventually appear. Do not reboot your computer or turn off the disk, or the test will show up as “interrupted by host reset” and you will have to start another one. A S.M.A.R.T. test takes more time on a larger disk - a 1TB drive can take over 5 hours.
If even a single error shows up, panic! Your data is in danger. Back it up now while you still can. (If you do not have any errors, keeping a backup is still a good idea.) Backup is very easy to do on Linux with rsync; hopefully I will write a tutorial about that too.
The S.M.A.R.T. test does not touch your data in any way. It is recommended that you do a long test once a month or more often. Be advised that no mechanical machine is perfect, and a hard drive that works today may corrupt data tomorrow and completely die the day after.
Video Card
A modern video card resembles a small integrated computer. It has many tiny processors (mine has 128!) and memory of its own. Simply displaying things takes a tiny portion of its total resources, but as soon as one runs a 3D application or uses a modern compositing window manager, the card will come under stress. Unfortunately, I am not aware of a reliable way to test a video card. I typically run some heavy OpenGL application (such as a game) at the largest possible resolution and with anti-aliasing and anisotropic filtering enabled. To ensure that the video card is fully loaded, I make sure that CPU usage is below 100% at all times during the test.
When it comes to video memory, the best program I know of is VMT, which stands for Video Memory Stress Test. It is a proprietary program that only runs under Windows, but it is the only thing I have found. Get it here. It looks and functions similarly to memtest86+, except that you cannot boot it but you must run it from Windows.
If anyone knows of a better video card testing tool, please let me know!
Power Supply
Power supply failures can be very tricky to detect. A hardware component that normally works might cause problems due to insufficient power, which is in turn caused by stress applied to a different component. The only way to ensure that all parts will work under stress at all times it to test stability of the entire system at maximum power draw. To achieve that simply run as many of the above tests simultaneously. Read from your hard drives (as in sudo dd if=/dev/sda of=/dev/null which reads your entire hard drive and discards the data), run mprime on all cores, and run a graphically-heavy program, all at the same time. Why not write a DVD too? Hook up a few USB devices for good measure, such as USB sticks, mice, mobile phones, etc. Draw as much power as you can for an hour, and if your computer does not hang or reboot by itself, you can finally declare your machine to be reliable.
Conclusion
Running such thorough tests may at fist seem to be an unnecessary waste of time. The choice whether to test or not is entirely yours, but should strange problems occur, you can use these techniques to eliminate the possibility of failing hardware. This can be especially handy if you like tinkering with experimental bleeding-edge software. At least once in my life these tests have saved me the embarrassment of submitting a bogus bug report for a problem that was caused by hardware. As usual, if you think I have missed anything, let me know!
Tags: Hardware, test, tutorial
Posted in Hardware
Published on August 23, 2008 by Godji
After months of hard work, I’m happy to say that my MSc thesis is complete! I just submitted a 45-page document describing a special kind of search engine - and though it’s no Google-killer, I hope it will find its own little niche. (No, it’s not online anywhere until further notice.)
For months I channeled the majority of my energy into my thesis, leaving little of it for other creative work. This is why most of my posting ideas for this site were scrapped and why this site has not grown at the pace that I had planned for it. But now, with my workload dropping from 95% to 0%, this will change.
(I’m actually quite surprised how hard it is to write these sentences. My brain is so tuned to formal scientific writing that I am completely unable to write a simple “casual” post. I need to reset my brain.)
I will be writing about my search engine here soon, but right now I’m more interested in looking into the future. Having finished my studies for the time being, I finally have the complete total unlimited freedom to do as I wish… at least until I find some work. In the meantime, I have an ever-growing list of things I’d like to do with my time. On that list are also a few projects of the computer geek variety which I will be indulging myself in starting sometime in the next weeks. I’ll write more about them as the story develops…
All I really want to communicate is that I’m alive and kicking, and I will be writing here much more often than I have been until now. It’s just that I can hardly put together a single coherent thought at this moment, so I will put a full-stop in 3, 2, 1, now.
P.S. I kan haz my brein bak?
Posted in Uncategorized
Published on July 13, 2008 by Godji
Several people convinced me to check Audible out. Audible is an online store for audiobooks. You can go to their website, buy a book through their catalog, download it as a file, and supposedly listen to it on your computer or portable audio player. Think of it as taking podcasts to the next level - audiobooks are to podcasts what movies are to TV shows, except even longer. Although skeptical that I could afford to pay undivided attention to a book for several hours at a time, a week ago I decided to give Audible a chance.
Prologue: Joining the Fun
Signing up was a breeze. I went to www.audible.com and entered my details, including my credit card number. I used a special code, which you can also get if you listen to any of the This Week in Tech podcasts. The code gave me credit for 1 free audiobook. In any case, I was a trial Audible member within a minute. Good!
Chapter 1: My First Audiobook (The Promise Of)
I bought an audiobook in a matter of seconds. I did not actually pay anything, because of the free credit I had, but I still got to use the same interface I would use if was actually paying. It was clear and well organized. Once “payed for”, the book was available in my library for download. Audible allows you to download a book you bought an infinite number of times even if you cancel your membership, which is rather nice. Every online store should pay attention to this point.
Next to the title of the book was a choice of three formats. They do not tell you what the formats are, but you can see the file size of each file. I guess all three choices are the same format but in a different bitrate, which I confirmed via some digging through their help system. Of course I went for the largest - 104 Mb for a just-over-7-hour-long piece.
Clicking the download link got me to a page where I was asked whether I had an iPod, a different portable device, or if I wanted to play the thing on my PC. I chose the latter only to get a “Save As” dialog for… an .exe Windows program. That could only mean one thing - DRM!
The whole problem is that Audible indeed uses DRM on their audiobooks - Apple’s DRM no less. Unless you have a supported portable device, you have the binary choice of either using Apple’s iTunes or something called “Audible Manager”. Let’s analyze the choices in detail:
a) iTunes is an ugly proprietary program that does not run on Linux. (Note to Apple fanbois: Maybe it looks good on MacOS, I have no clue. On Windows it does not, and by extension, on Linux with Wine it would not either.)
b) The Audible Manager is just like iTunes, except with much less functionality, and a much much uglier look, as unlikely as that may be. It even has the same layout as iTunes.
I commend having the option of not using iTunes, but when the only alternative is something even worse, it does not work for me. All my listening on the PC happens in Amarok, and until a better free program comes along, that is not going to change. And because free software does not support DRM by definition, I will never listen to anything with DRM on it. Besides, my simple phone that I use for podcasts plays MP3 and DRM-less AAC only. Guess whether that works with Audible.
(By the way, someone told me Audible books are watermarked too. I do not know if that is the case.)
Obviously, I could not play Audible content on Linux in any reasonable manner. Not only that: I could not even download the content. It knew I did not have the software and refused to give me the .aa blob. It was not serving me an unknown mimetype or protocol (ala Valve’s Steam game purchase links), which would at least have Firefox complaining. No, it silently dumped me to the software download page instead.
My course was clear. I had to use a Windows machine to get my book, strip the DRM, and convert it into something both Amarok and my simple phone could understand. All that was necessary so that I could listen to the book I just bought! Very disappointing.
Chapter 2: An Experience Like No Other
A nearby machine was running 64-bit Vista, so I decided to use that. I fired up Firefox 3, logged into Audible, got the software, installed it, restarted Firefox as per their instructions, and went to the website again. I clicked the download link in anticipation… and bummer. I was at the software download page. What the hell? I was now running on Windows (which I strongly dislike), using their ridiculous official software. How could that possibly not work?! I then remembered that Firefox 3 sometimes fails to learn the fact that it can now use certain software to handle certain types of content. That, or they needed to do something special to support Firefox 3, which was very new at the time. That, or they just hate free software.
I decided to play their game, for a moment. What is the most proprietary and “approved” way to get one of their books, I wondered. That is when I did the unthinkable: I did it the Microsoft way. I launched Internet Explorer to venture into the open Internet. I felt dirty inside.
Well, Firefox was new and all, but Internet “Illegal Monopoly with 85% Market Share Despite Having More Security Holes than a Ton of Swiss Cheese Has Any Holes” Explorer had to work. Right? I was completely mesmerized to discover that I still could not get to my book, with either the 32-bit for 64-bit version of Internet Explorer. I was on the software download page again. What are they thinking?
I proceeded to commit another unthinkable act - I installed the latest iTunes. I tried all four combinations of 32/64-bit Internet Explorer and iTunes. Software download page every time. What. Are. They. Thinking?!
Pause for a moment and picture this. A free software enthusiast and advocate with a very acute dislike for all proprietary software and all DRM, I was running Internet Explorer 7 under Windows Vista Ultimate, trying to import a DRM-ed file into iTunes. I subjected myself to this moral, technical, and aesthetic horror only in order to obtain an encrypted version of something that was presumably mine.
By then I had completely given up on Audible. But I was not about to give up my free book.
Chapter 3: Doing It Unprotected
The next morning I had my moment of sudden inspiration. It was a hunch that came out of nowhere, but it proved correct. It turned out Internet Explorer 7’s “protected mode” caused it not to pass Audible content to the Audible Manager. No, I do not know why. And no, I do not know how a typical computer user who cannot tell the Firefox icon on the desktop from the Internet is supposed to figure that one out. And no, it does not matter if Audible fixes any of it. It would be too little, too late.
For the record, they do offer streaming for their books. Going for that results in a tiny .pl file, but what the hell can I do with it? Even the mother of all media players (VLC) cannot make sense of it.
Chapter 4: Liberty or Death
The binary .aa blob which I downloaded after hours of struggling faced one of two fates - DRM removal or deletion. To achieve the former, I quickly searched online for a method to strip the DRM away, and found several. The first one required software which was horribly broken. The second one required a particular version of iTunes in combination with some other program, the latter of which would not run under Vista. Finally, a third method required a particular old version of the Audible Manager and a particular version of a shareware audio editor called GoldWave. I would never use either on a daily basis, but having subjected myself to so much moronic nonsense already, I was willing to try anything. Once.
To make a long and boring story short (but still boring), this would never work under 64-bit Vista. I had to pull my old laptop away from its duties and do an image-based install of Windows XP, in order to do the procedure there. This particular installation method is something every computer geek should know in their sleep - I hereby promise to describe it very soon. An hour later everything was ready, and the method had worked. I was looking at a gigantic .wav file.
Even though I had chosen the largest file Audible offered, it was only a 22 kHz waveform. For non-geeks, this means that the sound is of low quality and sounds muffled, even on pathetic laptop speakers. Come on, Audible! I would normally have to pay almost $20 to get this file. Could you at least encode it properly? Even podcasts, which too contain long recordings of speech, keep their sample rate at 44 kHz. This is the de facto standard of all modern digital audio recordings. What many podcasts do is cut the bitrate - which does ugly things to music, but does not noticeably impact speech. It certainly sounds better, at only a slightly worse length to size ratio. What is Audible saving on? My storage is dirt cheap, and their bandwidth was just payed for; the book should have been a 250 Mb 44 kHz recording, and anything less is so 1995. But I digress.
The gigantic .wav file was brought to Linux where it was encoded to FLAC for my PC and to AAC for my phone. I triumphantly played the book in Amarok! Bite me.
Epilogue: Adding Insult to Injury
That was all. I had my free book on my phone, and Audible had their head up their ass. I would never put up with an experience like theirs. I went back to their website to cancel my membership, where I was greeted by a page that offers several choices as to why one wants to cancel. I selected the “I am upset with Audible” option. I was given a US phone number with the instructions to call them because they wanted to hear from me. You see, they must think it impossible for a customer to be upset with their wonderful service. Surely, they must be right!
My second choice was “Audible does not work with my device”. I am not sure how that was worded, it may or may not have been “My device does not work with Audible”, which amounts to the same thing but has a completely different connotation. In any case, I was given the same phone number, which I had to call to cancel - lest I be charged for membership in a few days. So much for their free trial: it was free to get on, but I had to pay to get off. The number may be toll-free, but tell that to your phone company of choice on the opposite side of the planet.
So in the alternate reality of Audible, free is only free if you are in the USA, the set of operating systems is { Windows, MacOS X }, people are free to choose their favorite audio playing software as long as they choose iTunes, and every portable device is either an iPod or some kind of fancy smartphone that is happy to waste battery life decrypting DRM in real-time. I will have nothing to do with this.
To their credit, once I called, their customer support was friendly. I told the guy I was quitting because the DRM would not let me play books in Linux. I hope he wrote that down.
Conclusion
I never meant to get that free book and put it out on the Internet. If I had meant to do so, their DRM could not have stopped me. I was probably not going to give it to a friend either, even though that would be a huge advertisement for Audible. Their DRM could not have stopped that either, of course. And I may have been hooked on the idea of audiobooks and payed them some money to get a few good ones, but their DRM completely prevented that.
When I tell some people why DRM is bad, they give me the same look they give me when I tell them why free software is good. They say: “What you are describing is a theoretical possibility. Yours is a theoretical argument. This is not what happens in practice, and that is all I really care about. DRM is not a show-stopper, and I do not care if it is there or not.” I hope they get to read this real-life example. I additionally hope that Audible will get their act together and drop DRM entirely.
Audible verdict: dead to me.
Tags: Audible, DRM
Posted in Media
Published on July 12, 2008 by Godji
I am working hard on my MSc thesis, which ends in August. This explains why I have not written here for two months now. This is only temporary!
Posted in Uncategorized
Published on May 7, 2008 by Godji
As of right now, my domain name has changed from metapenguin.org to 300penguins.org. Although www.metapenguin.org will redirect to the new name, any bookmarked links will probably not work until you change the domain name on them. All links on the site itself have now been updated.
The downtime in the last few days happened because I forgot to change the domain name in WordPress’s settings menu, and that caused circular links because of the automatic redirection. Oops!
Posted in Uncategorized
Published on April 27, 2008 by Godji
Two weeks ago I posted a tutorial describing how to set up the NVIDIA binary blob on Kubuntu Hardy. As it turns out, that method was wrong. Although I used the Kubuntu-provided package for the driver itself, I suggested manually updating xorg.conf - which appears to be the wrong way to go about installing the driver.
The problem is that when I followed my guide and later enabled compiz (”Desktop Effects”), I had no window decorations. Although there are ways to fix this (see “Some Theory” below), that would ruin Kubuntu’s user experience. Luckily, there is a way to install the driver and run compiz correctly. Described here is the right way to do it.
(Ironically, this proves my point from my previous post. If you do not use the recommended way to do something but rather try to work around and circumvent the system, you are much more likely to have problems.)
As an additional bonus, you will not even touch a terminal. That is how good the graphical configuration of Kubuntu has become.
Installing the NVIDIA Driver Correctly
WARNING: If you are installing on a fresh system, make sure you have refreshed the online repositories at least once. To do that go to K -> System -> Adept Manager and look at the status bar on the bottom. If the number of available packages is 902 as opposed to some 24000+, you need to press “Fetch Updates” so that Kubuntu will see the full set of packages available for online installation. If you skip this step, the NVIDIA driver installation will not work.
Next, you must use what was previously called the restricted manager. In Kubuntu Hardy, it is called “jockey-kde” (WTF?) and is available under K -> System -> Hardware Drivers Manager. I have to admit that the program seems slightly immature - sometimes it will ask you for your password to get root privileges, and sometime it will just get them automatically. In any case, if it fails at becoming root, it will display an error message. If that happens, exit and start it manually with kdesu jockey-kde.
In the Hardware Drivers Manager you will see the NVIDIA driver listed opposite a checkbox called “Enabled” and a status field which says either “In use” or “Not in use”. Strangely enough, on the clean system where I tried this “Enabled” was already checked, but the driver was “Not in use”. If that is the case, uncheck “Enabled”, press “OK” and the program will close. Start Hardware Drivers Manager again, and this time check “Enabled”. What should happen is that the program will launch Adept to install the binary blob and update xorg.conf automatically. You do not have to touch xorg.conf yourself, let alone repeat anything every time you update X, like I had suggested previously.
I do not have the hardware to check this, but it is possible that the package manager might pick the wrong NVIDIA blob to install. I cannot verify how smart it actually is in picking the right one, and the default one (nvidia-glx) just happens to match my hardware. For GeForce 2 or earlier you need nvidia-glx-legacy, whereas for GeForce 5 or later you should use nvidia-glx-new. Watch carefully which one Adept will install by itself, and if it picks the wrong one, just wait until it is done, run Adept, uninstall the one it picked, and install the one that corresponds to your device.
Once driver is in place, reboot your system whether you are prompted or not, and the driver will be activated. Verify it by running glxinfo from the mesa-utils package or by turning your screen off with xset dpms force off. Move your mouse to get the screen back.
Desktop Effects
Compiz has been stable and well-integrated into GNOME for ages now, but it is only recently that it has become good enough to use with KDE (by mortal people that is). Kubuntu now includes it, so it is finally time for KDE users to get some eye candy!
1. Default effects
Assuming you installed the NVIDIA driver correctly, go to K -> System -> Desktop Effects and hit Install. When it is done, the three modes will be activated. Switch to “Standard Effects” or “Extra Effects” to make sure compiz works. Once you choose a setting, you will need to log out and back in to actually see any change.
2. The real deal
Note: This information was contributed by Dimitar Nedev. Thanks!
If the default effects worked, it is time to get serious. From the Adept Manager, install kicker-compiz, kicker-taskbar-compiz, and compizconfig-settings-manager. Then go back to the Desktop Effects configurator, and select “Custom Effects”.
The first two are patched versions of the KDE desktop pager and KDE taskbar respectively. Because you are no longer using KDE’s window manager (KWin), there may be some mismatch between the number and arrangement of desktops. The taskbar will likely show windows from all desktops rather than just the current one. The two kicker* packages resolve these problems. To make them work, you need to remove the old taskbar and desktop pager first, and them replace them with the compiz-aware ones.
If your panel is locked (it is unlocked by default, but that is the first thing I do on a fresh system), unlock it. Now right-click on the panel, choose Remove from Panel -> Applet -> Desktop Preview & Pager and then repeat this for Taskbar. Now right-click the panel again, and choose Add Applet to Panel.... You need to add Desktop Preview & Pager - Compiz and Taskbar - Compiz. Arrange them as you like, and optionally lock the panel.
The compizconfig-settings-manager is a configuration interface for compiz. By selecting “Custom Effects”, you chose to have full control over the compiz configuration, which is very extensive and can be somewhat overwhelming at times. The configuration interface is available under K -> Settings -> Advanced Desktop Effects Settings. Enjoy!
Some Theory
My previous guide asked that you install the NVIDIA driver yourself through Adept and modify xorg.conf. One drawback is that you had to modify /etc/X11/xorg.conf yourself, and in doing so, claim responsibility for keeping it updated from the package manager. The modification was a simple call to use the NVIDIA driver module.
The reason why there are might be no window decorations in Compiz is the screen color depth. The Hardware Drivers Manager additionally sets the color depth to 24 bits and enables the AddARGBGLXVisuals setting in the driver. The resulting xorg.conf sections look like this:
Section "Device"
Identifier "Configured Video Device"
Driver "nvidia"
Option "NoLogo" "True"
EndSection
Section "Monitor"
Identifier "Configured Monitor"
EndSection
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
Defaultdepth 24
Option "AddARGBGLXVisuals" "True"
EndSection
If you already installed the NVIDIA driver manually, uninstall it via Adept and reset xorg.conf by running:
sudo dpkg-reconfigure -phigh xserver-xorg
Then, just install the driver again as described above.
It Just Works(TM)
It is great to see that you can now have an immensely beautiful and powerful desktop without touching a Linux terminal. Some people wonder when Linux will be ready for the desktop, if it is not already. Here is my answer to that question: as soon as one can set up, configure, and do everything one needs to do without ever opening a terminal, then Linux will be good enough to finally take market share from the illegal monopoly in Redmond. With compiz now configurable by mere mortals, we are one step closer.
With that said, I would love to see the kicker-compiz/kicker-taskbar-compiz step handled automatically. Even more so, I would like to see KDE4’s compositing support mature to the level of compiz today. Ah, would that blow even MacOS away!
Tags: compiz, Hardy, Kubuntu, Linux, NVIDIA, tutorial
Posted in Linux
Published on April 27, 2008 by Godji
In this tutorial I will show you how to set up and use QEMU, a free software virtualization tool. With QEMU, you can run many operating systems right inside Linux, with average to high performance, depending on your hardware. I will show you how to set up and run a Debian system inside Kubuntu 8.04 (Hardy), but the information should apply elsewhere too.
Note that QEMU is particularly effective at running desktop operating systems that have a GUI. It is easy to set up, and does not require significant setup overhead on the host operating system (the one which runs on the actual hardware). That said, if you do not need graphical output, but only console access to a virtual server, then Xen may be a better choice for its higher performance. Xen is more difficult to set up, however, because you need a specially modified guest operating system.
Before You Begin
There are 3 “variants” of QEMU:
1. Vanilla QEMU emulates all processor instructions and peripheral devices in software. It runs entirely as a user-space application. As such, it does not require any kernel modules present in the host, or any special hardware. The downside, as you have already guessed, is performance that is only acceptable on the fastest modern CPUs.
2. QEMU + kqemu requires installing a kernel module (kqemu) in the host OS. In this mode, QEMU emulates all peripheral devices as well as all kernel-mode CPU instructions normally. User-space CPU instructions, however, are executed directly on the CPU, and are not emulated. The combination requires no special hardware and has good performance.
3. KVM is a modified QEMU that executes all guest code on the CPU, and only emulates the peripheral devices. It requires a kernel module that is included in the Linux kernel as of version 2.6.20, so in Kubuntu Hardy for instance you can load it simply by running sudo modprobe kvm. KVM is the fastest of the three, but it requires that your CPU has virtualization extensions, available only on the latest AMD and Intel CPUs. You can easily check whether your CPU has these by running:
grep -E '^flags.*(vmx|svm)' /proc/cpuinfo
If you see any output, you can run KVM. If you get no output, but you think your CPU should have virtualization support, it is possible that the extensions are disabled by default in your BIOS.
Because my laptop does not have virtualization extensions, this tutorial will not cover KVM.
To install QEMU, you need to enable Kubuntu’s universe repository, which is already enabled by default in Kubuntu Hardy.
Installing kqemu
This step is optional, but highly recommended!
1. Compile and install kqemu
Kqemu is a kernel module which has to match your kernel exactly. To achieve that, Kubuntu has inherited some black magic from Debian - the module-assistant. The module-assistant will automagically install the minimal set of development tools one requires to build a kernel module, compile kqemu from source thus matching your kernel, and install the module in the right place. To have it do all that, install the kqemu-source package and execute:
sudo module-assistant prepare
sudo module-assistant auto-install kqemu
Make sure that the Adept package manager is closed while you run these commands, because they need to install some software.
2. Allow yourself to use kqemu
If you run the kqemu module right now (sudo modprobe kqemu), you will notice a problem - the kqemu device (/dev/kqemu) is owned by root, and nobody else is allowed to use it. You do not want to run QEMU as root, so this has to be fixed. If you modprobed the module, unload it now (sudo rmmod kqemu).
crw-rw---- 1 root root 10, 62 2008-04-26 14:27 /dev/kqemu
The way this issue is usually addressed is to create a special group of users, add yourself to that group, and allow the group to use /dev/kqemu. To do that:
sudo addgroup --system kqemu
sudo adduser $USER kqemu
This will add the kqemu group and make you a member of the group. BTW, you can check what groups you are a member of by typing groups. If you do this now, you will most likely not see the kqemu group in the list - to apply the change, you must log out and log back in.
Next, you need to tell udev (the system which assigns device nodes, i.e. files under the /dev directory, to various things in your system) to set the group ownership of /dev/kqemu to kqemu, and allow users in that group to read and write to the device:
kdesu kate /etc/udev/rules.d/60-kqemu.rules
This will create a new file, whose contents should be:
KERNEL=="kqemu", NAME="%k", GROUP="kqemu", MODE="0660"
If you are curious why you need to write this, here is some detailed documentation. Basically it means, “whenever a device called kqemu appears, change the group ownership to the kqemu group and set permissions to rw-wr----“.
If you sudo modprobe kqemu now, you will see that it has the right permissions:
crw-rw---- 1 root kqemu 10, 62 2008-04-26 14:40 /dev/kqemu
Installing and Using QEMU
With or without kqemu, QEMU itself is easily installed via the qemu package.
To actually use it, you also need an operating system and a virtual hard drive. To get an operating system, just download any ISO image you could use to install on actual hardware. If you have a physical disc, you can use that too. For example, I downloaded the smallest possible Debian CD and saved it as debian32.iso.
To create a virtual hard drive, run:
qemu-img create -f qcow debhdd 2G
This creates a 2-gigabyte virtual hard drive in the qcow format and calls it debhdd. The version of QEMU that comes with Hardy also supports qcow2. I have no idea what the differences between qcow and qcow2 are. However, using qcow will allow you to migrate the machine to KVM, which I believe is based on QEMU 0.8 and only supports qcow. Notice that the file debhdd is very tiny. It will grow as you fill it with data, which means you can fit a whole lot of virtual machines in a tight space as long as you do not fill up their virtual hard drives. Each one will think it has its own large hard disk.
To turn on your virtual computer:
qemu -kernel-kqemu -net nic,model=rtl8139 -net user \
-hda debhdd -cdrom debian32.iso -boot d
-kernel-kqemu tells QEMU to use kqemu, which by default it does not. If you forget to specify it, or get a warning that it cannot be used for any reason, QEMU will emulate all CPU instructions of the guest OS and run slower.
-net nic,model=rtl8139 -net user puts a 100Mbit LAN controller (Realtek 8139) in your virtual computer, and puts it behind software NAT. Your machine will be able to use the Internet normally after obtaining an IP address from your host via DHCP, but you will not be able to initiate connections to your virtual machine. This is also QEMU’s default mode, except that it will use a 10Mbit LAN controller instead (NE2000). For some reason if you change the -nic parameter you also have to explicitly add -net user or the network will not work.
-hda debhdd -cdrom debian32.iso specifies the hard drive and the CD-ROM drive. Obviously, you only need the CD-ROM during installation. The CD-ROM is a virtual IDE drive (QEMU does not support virtual SATA) sitting in the second master IDE channel. If you do not specify any drives, you will get a machine that has no storage and no CD-ROM and that will not boot.
-boot d will make QEMU boot from the CD-ROM drive. By default, QEMU boots from the hard drive (more precisely, from the one that sits in the first master IDE channel). This is equivalent to -boot c. Does that particular choice of letters seem a little Windows-centric to you too?
Running Debian in QEMU
With the command above, you should see the Debian bootloader running in a window on your system. If you just hit Enter, it will load with its default settings.
You will soon notice that rendering text is fairly slow - to fix that, disable the framebuffer by passing fb=false to the bootloader. If the text rendering speed is good enough on the other hand, you can get a bigger screen by passing vga=### where ### is one of 786 for 640×480, 789 for 800×600, 792 for 1024×768, 795 for 1280×1024, or 799 for 1600×1200. If you are running out of physical screen space, pressing Ctrl+Alt+F will toggle between full-screen and windowed modes for QEMU (but do not do this if you are using compiz, a.k.a. “Desktop Effects”!). Note that Debian will remember what parameters you started its installer with, and will make them the defaults for the installed system.
On my Kubuntu Hardy with qemu-0.9.1, Debian’s boot sequence will halt, eventually displaying several “hda: lost interrupt” messages. I could only reproduce this if kqemu was active. If it happens to you, disable ACPI by passing -no-acpi to QEMU. If you are using an older QEMU which does not have this parameter (0.8), then you can achieve the same effect by passing acpi=off to Debian. Don’t worry: a virtual machine has no use for hardware power management, because it has no hardware.
Again, the fb=false, vga=###, and acpi=off above should be passed to Debian, not QEMU. You do this by typing them at the boot prompt, like this:
install fb=false acpi=off
Alternatively, you can use expert instead of install, to have more control over the installation.
Go ahead and install Debian on the virtual computer. As soon as the installation finishes, and before you install any software with aptitude, shut it down and make a copy of the virtual hard drive. You can now deploy more Debian virtual machines by simply running them with their own copy of the reference hard disk image you just created.
Tags: Debian, Hardy, Kubuntu, Linux, QEMU, tutorial, virtualization
Posted in Linux
Published on April 13, 2008 by Godji
Do Not Use These Instructions
UPDATE (2008-04-27): This is not the correct method after all. Please use this one instead! I apologize for the inconvenience.
Introduction
If you are like me, your itch to tinker with cool software sometimes overcomes your common sense and you wipe out the OS of your only production system to replace it with the unreleased BETA of the next version.
If you have an NVIDIA graphics card, you probably want to install the binary driver in order to use your hardware. In Kubuntu 7.10 (Gutsy), all you had to do was install the right package and it Just Works™. Not so in the beta of Hardy; this time around, nothing happens when you install the right nvidia-glx-* package.
This guide shows you how to get it to work.
Installing the Driver
1. Enable the restricted repository.
To do that, go to K Menu -> System -> Adept Manager -> Adept menu -> Manage Repositories. Check Proprietary drivers for devices, and click Close.
Wait a few seconds while the package repositories are updated.
2. Install the correct nvidia-glx-* package.
Depending on your hardware you need one of these:
- For GeForce 2 or older, nvidia-glx-legacy
- For GeForce 5 or newer, nvidia-glx-new
- For anything in between, nvidia-glx
You can check what hardware you have by running lspci | grep -i nvidia in a terminal.
The nvidia-glx-* package will install everything the driver needs, but unlike in Kubuntu Gutsy, it will not activate it. If you tried to modprobe nvidia to manually load the kernel module, you would see a message telling you that the module will not be loaded because the X server would not use it anyway.
3. Enable the nvidia driver.
You still need to tell the X server to use the new driver.
As root, edit your /etc/X11/xorg.conf. Find the Device section which has an Identifier which says Configured Video Device and add a Driver "nvidia" line. The section should now look like this:
Section "Device"
Identifier "Configured Video Device"
Driver "nvidia"
EndSection
4. Save, reboot, test!
Save xorg.conf and reboot to check whether the new driver will be automatically loaded at start-up.
To ensure that 3D acceleration works, you could install the mesa-utils package and run glxinfo and glxgears. Alternatively, you could just start [favorite game that runs on Linux] and waste a few hours doing a “combined performance and stability test”, solely to ensure that everything works…
To check that power management works, run xset dpms force off, which should turn off your monitor. Move the mouse to get it back.
Note that by modifying xorg.conf, you have claimed responsibility for its contents from the package manager. It will no longer be modified if you update X. To surrender it back, you must run sudo dpkg-reconfigure -phigh xserver-xorg, as explained in the file itself. This will erase your modification, however. Thus, it is a good idea to run this command just before an X server update, and then modify the line again (or reinstall nvidia-glx-* and hope that it will update xorg.conf by itself).
Closing Words
Most other guides that I found on the web generally involve downloading and installing the binary driver manually. It will work, but it is not a good idea in the long term, because a manual install bypasses the package manager. This can cause problems in the future, and in particular it can break the driver if you upgrade your X server, simply because Kubuntu has no idea you ever installed that driver.
That’s all. You now have have 3D acceleration, power management, multiple monitor support, and a binary blob in your kernel that is bigger than the rest of the kernel combined, and can do anything it wants in kernel space. That is what you get for buying NVidia (until they either get their act together and release source like everyone else, or the free alternative called Nouveau becomes good enough).
Tags: Hardy, Kubuntu, Linux, NVIDIA, tutorial
Posted in Linux
Published on April 12, 2008 by Godji
You are reading the first post in what will hopefully be a series of many.
Although I have owned the metapenguin.org domain for quite a while, I never really used it for anything. But this has changed as of today. Finally, I am here! :) I will be posting a few things in the next few days, and then again, and again, until I run out of ideas (unlikely) or time (likely).
What makes my rather empty blog special in comparison to the gazillions of blogs on the Internet?
Absolutely nothing.
In fact, nobody will ever read this, so I might as well write some nonsense. eq%^%$#w23eqr342das52e33ufh. I had to let it out somewhere, I guess. Alright, I’m ready to go back to reality now…
Posted in Uncategorized
No Comments