.comment: Separated By a Common Operating System - page 3
From Disaster Arises . . . More Disaster
I really like SuSE 7.2. If I knew someone who thought trying Linux would be a good idea, it's the distribution I'd recommend. It installs easily, and once it's installed it's easy to use. Someone who has never used computers would have no more trouble mastering this than mastering Windows, though I suppose that person would remain ignorant about crashes and reboots. This is no small thing: There are lots of countries that aren't rolling in money, and one cannot get another operating system that combines the ease of use, robust functioning, and good selection of applications for what SuSE costs. The anti-piracy "features" of Windows XP will create a perfect market for alternatives in such countries. If SuSE doesn't move to capitalize on these emerging markets, then the people at SuSE are crazy. Likewise a number of other markets, from schools to small OEMs.
It was of course only seconds after I'd booted my nice new SuSE 7.2 that I began making changes. I don't like icons on the desktop, so I nuked 'em. Next, I needed to figure out why my KDE settings hadn't survived, in that my ~/ had. I looked around and found that instead of ~/.kde, SuSE used ~/.kde2. I nuked it and made a symlink to ~/.kde until I could track down the source of the problem.
I always keep a copy of XF86Config in my home directory, for occasions just such as this. I dumped out of KDE -- and back to the KDM graphical login. Okay, back into KDE, open a konsole. Looked like hell -- letter spacing was all over the place. Awful. Typed "xhost + localhost" and then sued root and typed "nedit /etc/profile" which informed me that I no longer had nedit. The smart thing would have been to "rpm -Uvh download/nedit-5.0.i386.rpm," but I didn't. I did "kedit /etc/profile" and changed the default runlevel to 3, saved the file, opened /etc/lilo.conf and changed the "vga=" line so that it was now "vga=normal," saved lilo.conf, ran /sbin/lilo, exited konsole, dumped out of KDE, rebooted from KDM, and pretty soon saw the nice text bootup -- which in SuSE is especially pleasing, because as it starts services and loads drivers it presents it all in an appealing and useful way. I logged in, sued root, and copied the XF86Config from my ~/ to /etc/X11/, and while I was at it copied my TrueType fonts to /usr/X11R6/lib/X11/fonts/truetype, and ran ttmkfdir. Then exited root and did "startx," and things were returning now to normal.
Next came editing ~/.xinitrc so that it would start xscreensaver right before it started KDE. This didn't take, and I discovered that though I thought I'd installed Jamie's can't-live-without screensavers, I hadn't. Grabbed the latest source, but the GL stuff wouldn't build, because the GL stuff included with SuSE 7.2 lacks the right pedigree or something. Back to the SuSE CD to go traipsing around in search of their xscreensaver rpm. Found it and installed it and all was well. Except that the GL screensavers are unbearably slow. (As is their GL stuff in general; "gears" at its default size from the commandline does 40fps, which is glacial -- why can't anybody get this right?)
Time now to put a modern KDE on the machine. SuSE ships with KDE-2.1.2, which is -- okay -- the current release. But a lot has happened since it was rolled out, and I've grown to enjoy it (note to KDE users: You're going to love KDE-2.2). So I grabbed the latest CVS and began by building QT. The QT that SuSE ships is 2.30, which Is fairly modern, but qt-copy from KDE's CVS tree always has some little tweaks. As expected, ./configure told me that the QT directory was set to "" and it needed to be where the source was, so I edited /etc/profile again to give it the QT environment variables and rebooted. And now, on reboot, I noticed an error after I'd logged in: /bin/ksh was not found. This had no effect, in that I don't use ksh, but it was annoying. I looked around and found nothing interesting -- I did have /bin/ksh (though I have no need for it), and in any case it had no effect on things working. Still, it bothered me, so I posted a note to the SuSE list. Before long came word: I'd edited /etc/profile in kedit, hadn't I? And kedit has word wrap on by default (as, in my opinion, no Linux text editor should). So I installed nedit and fixed /etc/profile, and the error disappeared.
Then I built qt-copy. As noted above, I don't like to keep multiple versions of things all over the place. I don't run multiple versions of things at once. For years now, my QT has been /usr/lib/qt; my kde, /opt/kde. In these two cases, because I build them both fairly often, I make a small exception: both of these locations are symlinks, to /usr/lib/qt[date] and opt/kde[date] respectively. When you're building from CVS, things blow up from time to time, and an exit strategy is good, and this is the easiest one I know -- just change the symlink to the previous, working, version. Next build, nuke the older of the two existing, working versions and add the new one.
Renaming the stuff in /opt, as provided by SuSE, was a little more complicated, but it became less so when I learned that /opt/kde was essentially empty. Also, it seemed that SuSE's YaST2 wanted to look at /opt/kde2. So I renamed /opt/kde2, made a directory in /opt for the new CVS stuff I was about to build, symlinked /opt/kde to it, and /opt/kde2 to /opt/kde, and started building KDE from CVS.
I lucked out -- I picked a time when everything in the CVS tree built just fine, though kdelibs reported the absence of OpenSSL (though some form of it had been installed by SuSE), and kdebase said I had no lesstif, though SuSE had provided it. Someday someone is going to realize that it will be much harder for Linux to be taken seriously unless backward and forward compatibility is provided in things like dynamic libraries. Yeah, that makes it tougher for developers. It can be argued that developer convenience is not what we're all here to achieve.
Anyway, after many, many hours -- KDE does not compile quickly, but there's a lot to it -- I fired up X. And there was the latest KDE. With an ugly background.
Ages ago I set up XPlanet (a really neat application; if it's not your desktop background, it probably ought to be) with a moon map to be a realtime moonphase indicator in high resolution on my KDE desktop. Then I realized that I didn't have Opera installed, so I ran its rpm, then went to the Xplanet website to see if, while I was at it, there were a newer version, which there was. (I use Opera for web browsing, most of the time. I very much like Konqueror, and for file management and ftp duties it's unsurpassed, but I'm more comfortable, at least for now, browsing with Opera.) I snagged the new XPlanet, built and installed it, copied my moon.jpg from my home directory to /usr/local/share/xplanet, and a minute or so later my moon desktop was back.
I was mostly done, but there were still a couple of tasks to perform: Getting the CD-R to work properly and seeing if maybe I could fix the abysmal GL performance. Each required a kernel recompile.
I already had the Linux-2.4.5 source in my ~/download directory (SuSE 7.2 ships with 2.4.4), so I decided I'd use it and base my build on SuSE's configuration. Where did I get that configuration? I'm glad I asked that: it's in /boot/ as vmlinuz.config. Load it after making mrproper in the kernel source, and you'll see what you've got -- which is a module for just about everything supported by Linux. I mostly didn't mess with it, though I did remove support for some things I know I will never use. Then I set about fixing things.
It shouldn't matter, but here it consistently does: If you have a Matrox Millennium MGA G-400 video card, and if GL performance matters to you, compile agpgart.o and mga.o -- AGP and MGA direct rendering -- into the kernel itself (Y instead of M) and do not enable framebuffer support. (As a benchmark, run gears in a virtual terminal before and after. Here, it went from 40 frames per second to 342 fps.)
I also enabled support for generic scsi and ide-scsi translation, and removed support for ATAPI CD-ROM drives. Then I built and installed the kernel. All was well.
Except for XCDRoast, which had worked just fine under Caldera and which now blew up, when I tried to run it SUID, with the news that GTK+ objected to this. The alpha XCDRoast 0.98 that SuSE ships has this added feature over the 0.96ex I was using; some, myself included, would not consider this an advance, nor the switch from Tk to GTK+ -- it's a friggin' CD burner! It doesn't have to be pretty! I visited RPM -e on it and downloaded the source for 0.96ex. Which blew up on ./configure, citing the absence of Tcl/Tk/Tix, which was a hell of a note because I specified them for installation when I installed SuSE 7.2. The RPM database reported them installed. But they were and are nowhere to be found (though I haven't searched /var yet, SuSE's very favorite directory).
I went to the SuSE online update site, using the YaST2 configurator, and grabbed the security fixes that had been posted. Interestingly, the next time I started the machine, I was in runlevel 5, even though I'd edited /etc/inittab to default to 3. This was an issue because KDM, at the moment I'd grabbed it from CVS, had a little problem: it wouldn't accept keyboard input (this has since been fixed). I clicked on the menu, asked for a console login, didn't get it, but now KDM was accepting letters. (This is one of the multitude of reasons I have for despising KDM and, before it, XDM. If you can't login at a text prompt and remember the command "startx," then you probably shouldn't be using a computer at all.) Anyway, it turns out that everytime SuSE's configuration program runs, it resets /etc/inittab to runlevel 5 unless you've edited its startup scripts to do something else. This is one of the stupidest things I've ever encountered, the kind of stuff we'd expect from Corel or somebody but not from an outfit that bills itself as "the Linux experts." There is just flat no need for it.
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.