Monitors become wider and wider due to the entertainment industry, but changing proportion in fact decreases a number of pixels from top to bottom of a screen. If you look at some program code now, you see just some lines clustered along the left boundary of a screen and lots of free space.
A standard coder should not appreciate that, unless he is me and likes spaghetti code style (by this I mean lines 200 symbols wide). However, this is applicable only for code in the functional paradigm. In the imperative style I don't do this. And anyway, there are usually code style conventions limiting that for a project.
I've seen some people using two source code windows filled with different source files. This could be nice, especially for diffs. However, I think, a coder should appreciate increasing number of lines vertically. The ultimate solution is to buy a monitor with the pivot function --- switching between landscape and portrait on-the-fly. Of course, this requires support from drivers/OS. And nvidia, radeon drivers provide that.
Switching under Windows is easy, for Linux it required some investigations. You enable it first in /etc/X11/xorg.conf (Section "Screen"):
Option "RandRRotation" "true"
This is for nvidia card, but I guess, radeon drivers should provide the same. Then under KDE you run a command:
xrandr -o left
to switch to the portrait mode or "-o normal" for switching back.
I also tried krandrtray application, but it didn't work for me. By the way, don't logout from KDE during the portrait mode. I filed a bug for the KDE team.
I had three HDD drives, and I made a mistake installing Linux on the third one. I think, "the third" means that it hangs on SATA-channel 3. But GRUB sees a (first on that drive) boot partition at it as (hd0,0), if I choose the drive as the first to boot from in BIOS.
So, I removed one drive from a system, and my /dev/sdc became /dev/sdb. Of course, /etc/fstab still contains /dev/sdc* references and I get a kernel panic at boot. Actually, my GRUB also contains reference to the root partition at /dev/sdc, but this can be changed in interactive GRUB mode.
The issue can be solved changing /etc/fstab with a sytem rescue cd/usb, but I prefer to have no limitations on changing drives. I took a clean HDD, put it on SATA-channel 1 (it appears as /dev/sda), partitioned properly and copied everything from an old drive. Then edited /etc/fstab, grub-install --no-floppy /dev/sda with a proper grub.conf and it just works. Now I have two identical Linuxes on different drives, and I will probably keep the old one for a while (just in case).
By the way, at first I made a mistake copying with bare cp -r command. This made user accounts (except root) not usable, as access rights were changed. Copy with cp -a in this situation.
Meditating whether to merge docs for some package, I asked myself "why not to grab all those tons of mans available and store them locally?" Indeed, there's plenty of space on modern HDDs. So, I've set globally the "doc" flag and run rebuild of the whole system.
Strangely enough, adding this flag seems to require recompilation of binaries, but that's not the worse thing. Rebuild proccess just hangs on kdelibs package (exactly when installing help docs). Pressing Ctrl+C and trying again several times gives the same. I've hit upon such a phrase in a handbook:
The best way of enabling the doc USE flag is doing it on a per-package basis via /etc/portage/package.use, so that you get documentation only for packages that you are interested in. Enabling this flag globally is known to cause problems with circular dependencies.
What a poor excuse this sounds to me! Anyway, disabled that flag and recompiled everything back.
The most easy-to-use Scheme compiler/interpreter is PLT, simple IDE is included. Emerging the latest ebuild gives errors under -O3 optimization flag, I confirmed it at the bugtracker. The solution is to switch temporarily to -O2.
I installed X, then KDE using the following manuals:
Building by itself caused no troubles. But testing clean X after the first step brought a problem with unresponsive mouse and keyboard, I couldn't even drop back to console with Ctrl+Alt+Backspace. Some gentoo forum topic (don't remember which) gave a solution - adding
Option "AllowEmptyInput" "false"
to the section "ServerFlags" of xorg.conf helped.
I wanted to install Gnome as well, but there are two packages blocking each other, namely avahi and mdnsresponder, one is default for Gnome, another for KDE, they both do the same and cannot live together on the same system. Strange, a year ago, when I assembled a Gentoo system with KDE and Gnome, there was no such problem. Anyway, there is a topic at the forum suggesting some solutions, but I'll try them later, no need to hurry with Gnome currently.
My m/b (ASUS M3N78-VM) requires the kernel 2.6.25 or newer, even the latest Gentoo livecd didn't boot on my system. I used the SystemRescueCd on USB to boot it. Important thing was to load it with 64-bit kernel (in 32-bit we cannot be chroot'ed into 64-bit stage-3 gentoo image). Then everything was according to the Gentoo Handbook. As I wanted everything optimized for my CPU (quad-core Phenom), it was neccessary to update a toolchain. GCC at the Gentoo stable branch cannot compile with -march=amdfam10 flag, so I switched competely to the testing branch. I updated toolchain, then built the latest kernel (2.6.28-r1) and some must-have terminal applications - everything went smoothly.
And yes, the m/b works in AHCI-mode, max of 6 SATA-devices are accessible. This I couldn't get under Windows.
Nemerle is waiting, but it have to wait more, while I'm learning Scheme. I have a plan to solve some problems from Project Euler, first with brute-force (however, it is not always possible), then using smarter ways, and post some solutions here under the tags "projecteuler" and "scheme".
Another thing, I am setting up currently a Gentoo Linux system on my workstation, so, some postings about this will come under the tag "gentoo". One of the reasons to install it is an unexpected difficulty with SATA-drives under Windows. The motherboard (Asus M3N78-VM) supports SATA-devices in three modes: SATA (only three accessible), RAID and AHCI. The latest is preferable for me, as I need more than three drives.
It was understandable when WinXP 64-bits (I didn't try any 32-bits systems, as I need more than 4 Gb of RAM) refused to work in AHCI-mode despite all my tricks with this and that, particlularly, manufacturer's drivers embedding with the nLite tool. But when Vista x64 with proper drivers could not load after switching m/b into AHCI, I decided that it's time to try Linux again. I prefer Gentoo, one of the most hardcore distributions available.
