Recently, Phoronix featured a comparison between the same linux version installed with support for 32 bits with or without PAE and 64 bits. While their original intent was to find out the differences between the 32 bits kernel and the 32 bits kernel with PAE, the results they obtained are quite amazing.
The first graphic shows all three version running at par. This is no wonder, since the main work is done by an external device (and the drivers pushing data towards that device), but after this graphs just take an amazing turn. The most spectacular improvement is the apache server that serves 1689% more static pages. Yes. 1689% more. The rest of the results are pretty impressive too - with improvements in database benchmarks, processor intensive tasks like raytracing and encryption, but with most amazing results in the disk-dependent tasks (like the apache server that gives out static pages).
How is this possible and what does it mean? First of all, there is definitely something wrong with the disk drivers in the 32 bits kernels or with the testing conditions. Since the people from Phoronix know their own stuff, we can safely assume that this really points out to huge problems in the 32 bits drivers. Second of all, maybe the best thing that could be done is to repeat the tests, and somebody show the results to Linus Torvalds, so that he can kick the corresponding asses. If, however, this is not a bug, then it shows out pretty much what we normally call the creeping bugs problem.
Back in the days when I used to build kernel by hands and had lots of fun with things like LFS, and you couldn't deliver a i686 kernel because it was not so fun for the whole bunch of i586 systems out there, the problem was obvious. Building a kernel that would work on all the machines meant including a lot of patches and kernel options that would slow down the system. Not only the kernel was built like that, but the standard C library as well (glibc); since the glibc was committed to support a huge range of kernels, and a lot changed with each year. If you tried to support all the kernels ever released, you'd have to support a lot of mistakes done throughout the years, a lot of different methods of doing the same thing, or slightly different.
Probably something similar happens with the current kernel - and the current drivers, and possibly the C library. The 64bit one has a lot less mistakes to support. Kludges that are quite costy, it seems, from the phoronix test results.
It was one of the reasons why I always used or tried to use first the 64bit versions of the OSes at hand - they may be less than perfect (no flash in browser, some apps not working/not compiling), but let's get serious, which OS is?
I must confess tho' that I don't really see the difference between the two on my machine. It feels indeed a lot snappier than the 32 bits version, but I am not sure, since I cannot really compare in a scientific maner. But the 64bit linux is now a complete and viable solution just like 32 bits versions are - so if you have a choice, go for the 64bit version :)
Probably this was the last post of the year, so let's say goodbye together to the 00s , and let us see each other next year :)
Thursday, December 31, 2009
Wednesday, December 30, 2009
Erasing a rewritable dvd
Well, it's never easy to switch from an operating system to another. One reason in particular I'll talk about right now.
I used to like the DVD writer embedded in Windows 7's explorer. Two, three clicks, push 'Burn' then you wait (although you don't actually understand very much of what happens there).
Switching to Linux means that my rewritable DVDs have to be written with something else, k3b for example, a nice application that mimics in a pretty KDE way the modus operandi of Ahead's Nero. But to my amazement, writing was not possible with various errors involving the Restricted Overwrite mode.
The solution I found was to fully erase the DVD, not once but twice. The first time, for a reason I couldn't see, the blanking stopped at 76%. The command I used that eventually worked was:
dvd+rw-format -force=full -blank=full /dev/dvd. The previous tries failed, and although I should've note all my tries and failures I didn't (actually, the idea to write this post came to me too late to act. cdrecord will not work for DVD erasing not because it shouldn't work, but simply couldn't handle whatever W7 did to those discs (probably by changing the mode). If you want to blank a disc with cdrecord, probably the way to work (after fixing the disc) would be: cdrecord blank=all -force -dvd /dev/dvd.
After the dvd+rw-format reaches 100% (it works for DVD -RW, not only for +RW) you can use the disc with your usual writing software (k3b for me). Obviously, this is true until you write it again with some Windows software, which tends to make the discs unusable again.
I used to like the DVD writer embedded in Windows 7's explorer. Two, three clicks, push 'Burn' then you wait (although you don't actually understand very much of what happens there).
Switching to Linux means that my rewritable DVDs have to be written with something else, k3b for example, a nice application that mimics in a pretty KDE way the modus operandi of Ahead's Nero. But to my amazement, writing was not possible with various errors involving the Restricted Overwrite mode.
The solution I found was to fully erase the DVD, not once but twice. The first time, for a reason I couldn't see, the blanking stopped at 76%. The command I used that eventually worked was:
dvd+rw-format -force=full -blank=full /dev/dvd. The previous tries failed, and although I should've note all my tries and failures I didn't (actually, the idea to write this post came to me too late to act. cdrecord will not work for DVD erasing not because it shouldn't work, but simply couldn't handle whatever W7 did to those discs (probably by changing the mode). If you want to blank a disc with cdrecord, probably the way to work (after fixing the disc) would be: cdrecord blank=all -force -dvd /dev/dvd.
After the dvd+rw-format reaches 100% (it works for DVD -RW, not only for +RW) you can use the disc with your usual writing software (k3b for me). Obviously, this is true until you write it again with some Windows software, which tends to make the discs unusable again.
Monday, December 28, 2009
Environment variables in Linux
Ok, one of the first problems I encountered getting back in Linux is the management of environment variables. As a developer I am used to testing lots of new stuff, leaving the comfortable cushion of the click&install paradigm that the latest distributions try to deliver. But by doing so I don't want to sacrifice the few things that really make sense, like simply running an application compiled by hand from the RUN prompt that usually is invoked with ALT-F2. Or, even, to have an icon for said application posted in the desktop folder.
Things are not so easy, of course, you'll find to your amazement. As we know, UNIX environments are quite flexible: so flexible, in fact, that it's impossible to have a consistent behavior.
What happens if, for example, I set up a local installation folder for the software I compile (in this case, codelite). For the software to run I need at least two things (or three, in this case, but we'll settle with only two as well):
- The PATH variable should contain my local bin folder /home/spooky/local/bin, and
- Either the LD_LIBRARY_PATH or the ld.so.conf (the linker configuration file) should contain the library folder /home/spooky/local/lib.
Fairly easy, but virtually no solution will make me run the application from my current graphical shell without a log-out/reboot in between. Why is that?
Probably because the Linux desktop environment is fairly complex, and it has no unified logic or structure. Desktop environments differ a lot and can become quite confusing for a user. Just take a windows-user and put him in front of a WindowMaker desktop. Then congratulate yourself for the idea.
So what's the solution? The help page I found most intelligible and easy to understand is the "Environment variables" from the Ubuntu help pages. There we find that the right location for these variables may be (but we're not certain) either in /etc/profile.d (if you create there an entry that will contain the definitions of PATH and LD_LIBRARY_PATH, make sure you name it whatever.sh) or in the ~/.profile (better, but not system-wide, only user specific).
Ok, what's missing? First of all, even after you will corrupt the profile file with your evil entries, you will need to restart - running the application you want from the ALT-F2 run prompt will not work (yet) but running from a terminal will. The reason is that the desktop environment is not and will not be aware of the change until you log-out and then reinitialize the session. Groovy, isn't it?
Theoretically, such a problem would be easily solved for a desktop environment, since all the processes are spawned from the same base process. In Windows, this is a lot easier, since the environment is controlled and the spawning process, explorer.exe, is the same that does a lot of other things - implementing the change of an environment variable on-the-fly is very easy (you can do it from somewhere around the My Computer Properties page).
Why nobody in the Linux community would create such a feature? Well, aside from the technical impossibility of offering the same feature over N desktop managers (a practical impossibility, with tens of combinations that should be maintained), it's actually the number of possible locations for such a variable that would make it confusing for such an implementor to create it. Do you want it in /etc/profile? /etc/profile.d/*.sh? /etc/bashrc? /etc/bash.bashrc? /there/and/back/again? Too many options sometimes it's just that. Too many options.
Of course, there are some prospects for such a feature. It could be implemented. Who needs it, tho'? Only picky programmers that don't want to log out of their system. Probably no user would ever and should never touch system variables - they are there just for us, for the developers.
As a conclusion, since there is no user friendly way for the users to modify a system variable, one should always make sure that his program doesn't need it. Relying on the capacity of the user to modify system intimate features like this should be avoided. Forcing the user to such dramatic actions like logging off or rebooting should be forbidden for any installation of your program. No matter the reason.
The only way that a programmer should use environment variables should be to respect them, act accordingly to their meaning (if their meaning is useful to one's application), and make sure that they will not add extra-requirements from the environment unless the programmer really really really really (have I said it enough times?) really really knows what he does.
Even if it's just because we don't like to wait while our computer reboots.
Revitalizare: back on Linux
M-am întors în sfîrșit pe Linux - pentru a x-a oară, și de data asta mă simt destul de confortabil cît să stau o perioadă mai îndelungată. Sper doar să nu fie o experiență dezastruoasă în timp.
Adevărat, însă, că de data asta mă simt mult mai bine pe Linux, după ce o vreme îndelungată am cochetat cu sistemul de operare al 'dușmanului'. Fără răutate, nu a prea funcționat pentru mine, dar e bun pentru muncă. Apropos, vă recomand Windows 7 pentru o experiență desktop destul de curată, și cu puține bătăi de cap dacă îl tratați cu mănuși.
Redeschid blogul tehnic pentru că simt că mi-aș îndepărta cititorii de pe blogul personal. Cum nu aș dori să îi înstrăinez pe cei care mă citesc din alte motive decît cele tehnice, prefer să adun rant-urile tehnice aici, în speranța că vor deveni din ce în ce mai numeroase. Da, în speranța, nu în certitudine ;)
Bine ați venit, așadar :)
Ah, încă o treabă: postările o să le fac în engleză. Nu de alta, dar sper că în cele din urmă vor fi de ajutor cuiva care nu-i român ;)
Monday, July 27, 2009
Subscribe to:
Posts (Atom)