Language Selection

English French German Italian Portuguese Spanish

Installing openSUSE 10.2 on a Compaq laptop (Part 2)

Filed under
Reviews

In part 1, openSUSE got installed and configured on a Compaq Presario V2000 with an ATI Radeon Xpress 200M PCIE graphics chipset and a 32-bit CPU. Now it's time to go for the bling.

How easy is it to get the graphic goodness of Beryl going? Pretty dang easy.

Installing the ATI driver

The first step is getting ATI's proprietary "fglrx" driver installed. (Why do they call it "fglrx"? Maybe it's an acronym for "Free/GPL/Libre Releases X-rays." Who knows?) The openSUSE wiki has a how-to for that, too. The basic steps are as follows:

  • As a prerequisite, install the "gcc" and "kernel-source" packages.
  • Download the latest ATI Radeon driver from their web site (the filename's currently "ati-driver-installer-8.32.5-x86.x86_64.run").
  • As root, make it executable (with "chmod +x") and run it. Installation instructions are here; you may want to print them out. You're looking to make an rpm, or, as ATI calls it, "Generate A Distribution Specific Driver Package."

    The installer can run in GUI mode under KDE, or run in text mode from a console. I'd recommend running it outside of X Windows, in a console, for only one reason: its dialog box was too tall to fit on my screen. Besides, you need to be in a console at runlevel 3 in order to enable it using Sax2, anyway.

    After accepting the license agreement, choose the "Generate Distribution Specific Driver Package" option, and the installer will create an rpm for you (named something like "fglrx_7_1_0_SUSE102-8.32.5-1.i386.rpm"). Install the rpm (with "rpm -ivh").

  • The last step: if you're not already in a console without X Windows running, log out of X, choose "Console login" from the kdm login screen, and log in as root. Switch to runlevel 3 with "init 3". Then type

    sax2 -r -m 0=fglrx

    and Suse will configure xorg.conf to use the driver. Type "init 5" to get back into KDE, and it should now be using ATI's driver. You can verify that you are by running the command "fglrxinfo" at a bash prompt. (Accelleration should be enabled by default.)

(Whew. That was harder to write than it was to do!)

Installing Xgl and Beryl

Unless you specifically deselected them during installation, you probably already have Xgl and Compiz installed. Check with "rpm -q xgl" and "rpm -q compiz" at a bash prompt. If they're not installed, simply install them using your favorite package manager.

There's one change to make to /etc/X11/xorg.conf in order to use Xgl. You'll have to add a section that looks like this to the end. (Please ignore those < br / > tags; they're just a figment of your imagination.)

Section "Extensions"
    Option "Composite" "0"
EndSection

You enable Xgl by going to a bash prompt as root and running the command "gnome-xgl-switch --enable-xgl" and then restarting KDE.

Finally, there's one more configuration change to make. There's a "Translucency" option in KDE that's set by default to "on," which has to be turned off in order for compiz (and Beryl) to run correctly. It's in the KDE Control Center under Desktop > Window Behavior > Translucency. Uncheck the "Use translucency/shadows" box and restart KDE again. You should finally see compiz going, and have a desktop cube, which you can roll around by holding down Ctrl+Alt with one hand, and clicking on the desktop and moving the mouse, with the other.

Installing Beryl

Why not just stick with compiz? You can, of course, but beryl offers a whole lot more options.

By now you know the drill: the openSUSE wiki has a how-to for Beryl. If you're still using YaST to configure repos and install packages, the steps are as follows:

  • Add the following repo: http://software.opensuse.org/download/X11:/XGL/openSUSE_10.2/
  • Install these packages: beryl-core
    beryl-plugins
    emerald : window decorator
    emerald-themes
    aquamarine
    beryl-settings
    beryl-manager
    (You'll probably get updated Xgl and compiz packages along the way, through the Zen updater.)
  • Once again, restart KDE. Then pull up a console window, and, as your normal user, type

    > beryl-manager &

    You should at least see a red gemstone icon show up in your system tray -- that's Beryl-Manager. You may need to click on it, then click "Select Window Manager," and choose "Beryl." After that, you may need to click on "Reload Window Manager." If all goes well, you should see the screen flicker, the Beryl splash screen come up, and you're finally done.

    Well, almost. There's a ton of configuration options available in the "Beryl Settings Manager," and a bunch of window decorations/themes to choose from in the "Emerald Theme Manager." After all that work, you get to play around with it.

    Finally, putting symlinks to /usr/bin/beryl-manager and /usr/bin/beryl-xgl in ~/.kde/Autostart will make beryl start automagically every time you start KDE.

Conclusion

openSUSE is laptop-friendly, has an eye-pleasing KDE configuration, is well-documented and easy to install, and has most of the packages you'd expect from a modern Linux distro. Not everything is perfect, though.

The bad:

  • YaST's software management tools are both slow and clunky. No wonder a lot of people use the SMART package manager. (openSUSE also has hooks for YUM, and you can install APT.) It'd be nice for SMART to become the default package manager at some point in the future. (The Zen software updater works well, though.)
  • Speaking of software updates, it'd also be nice if openSUSE did what Fedora does, namely, move updated packages into their main repos as soon as they're stable. Six months is not a long time to wait, of course, but Fedora seems to be issuing updated packages almost daily.
  • That "kerry beagle" indexer sure seems to slow things down, especially right after you log into KDE. Fortunately, it can be permanently disabled.
  • So can the so-called "SUSE menu style" (aka "Kickoff") -- just right-click on the button and choose "Switch to KDE Menu Style". (OK, it's really not that bad, but simpler is better, IMO.)

The ugly:

  • The Novell/Microsoft patent agreement follows openSUSE around like the cloud of dirt and dust that follows the Peanuts character, Pig-Pen. What a horrendous lapse in judgment on Novell's part. There's really nothing else to say.

How-To's/FAQs:

The end!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

pigpen

"The Novell/Microsoft patent agreement follows openSUSE around like the cloud of dirt and dust that follows the Peanuts character, Pig-Pen."

lol I love that analogy. Big Grin

----
You talk the talk, but do you waddle the waddle?

just went thru a similar install...

A few weeks prior (right after openSuse 10.2 release) to a new little Compaq v6110us... Though my install was i386, not x86_64. Worked like a champ for me, other than I'm kind of a laptop rookie, and let ndiswrapper take a timely tool on myself.

Other than that, install was awesome!

Lots of this laptop Nvidia with related drivers.

-Pat

More in Tux Machines

This week in KDE: fixing up Plasma 5.20

Okular’s editable forms are no longer mis-rendered when inertially scrolling (Kezi Olio, Okular 1.11.2) When your scanner can almost but not quite fit a particular page size, Skanlite will now display the option to scan to that page size anyway (e.g. 215mm wide scan beds now give you the option to scan using the US Letter page size) (Kåre Särs, libksane 20.12) The text of Elisa’s keyboard shortcuts are now translated properly (Nikunj Goyal, Elisa 20.12) Clearing the clipboard history on Wayland no longer crashes Plasma (David Edmundson, Plasma 5.20) Improved the Plasma SVG cache heuristics such that various things which might sometimes be invisible after upgrading Plasma now show up like they’re supposed to (Arjen Hiemstra, Plasma 5.20) On Wayland, clicking on a Task Manager entry while that entry’s tooltip is visible no longer crashes Plasma (Vlad Zahorodnii, Plasma 5.20) On Wayland, clicking on a Task Manager thumbnail now activates that window, as you would expect (Marco Martin, Plasma 5.20) Read more Also: KDE Plasma 5.20 Should Be Crashing A Lot Less Under Wayland

Legacy: Dennis Ritchie's Lost Dissertation and FTP Fadeout

  • Discovering Computer Legend Dennis Ritchie's Lost Dissertation
  • FTP Fadeout

    Here’s a small piece of news you may have missed while you were trying to rebuild your entire life to fit inside your tiny apartment at the beginning of the COVID crisis: Because of the way that the virus shook up just about everything, Google skipped the release of Chrome version 82. Who cares, you think? Well, users of FTP, or the File Transfer Protocol. During the pandemic, Google delayed its plan to kill FTP, and now that things have settled to some degree, Google recently announced that it is going back for the kill with Chrome version 86, which deprecates the support once again, and will kill it for good in Chrome 88. (Mozilla announced similar plans for Firefox, citing security reasons and the age of the underlying code.) It is one of the oldest protocols the mainstream [Internet] supports—it turns 50 next year—but those mainstream applications are about to leave it behind. Today’s Tedium talks about history of FTP, the networking protocol that has held on longer than pretty much any other.

virt-manager 3.0.0 released!

Yesterday I released virt-manager 3.0.0. Despite the major version number bump, things shouldn't look too different from the previous release. For me the major version number bump reflects certain feature removals (like dropping virt-convert), and the large amount of internal code changes that were done, though there's a few long awaited features sprinkled in like virt-install --cloud-init support which I plan to write more about later. Read more Also: virt-install --cloud-init support

today's leftovers

  • 7 Alternatives to Google Earth

    Google Earth has received so much press coverage that many users will appreciate that it is one of the coolest applications to download. In brief, it is a feature-laden 3D virtual globe, map and geography browser which lets users zoom in on their world with fantastic detail. View satellite imagery, maps, terrain, 3D buildings and even explore galaxies in the sky. This application allows the exploration of rich geographical content, save toured places and share with others. The software maps the earth by the superimposition of images obtained from satellite imagery, aerial photography and GIS 3D globe. Google Earth is undoubtedly a very impressive application, and it is extremely hard not to admire the wealth of features that it offers. Its satellite images are unrivaled, it provides useful and accurate statistical information, and the software has many practical benefits, such as helping to find locations and give driving directions. In terms of functionality, this application earns our highest praise. We use the software on a regular basis on both desktop and mobile devices (the latter under Android). However, while Google Earth is available to download without charge, Google do not release the software under an open source license. In the past there have been attempts to reverse engineer Google Earth and implement its features in an open and extensible way. However, these actions were understandably frowned upon by Google. Instead we prefer to see the development of open source virtual globe software which uses freely licensed or public domain data. While the development of open source virtual globe applications may not, in itself, encourage Google to release its application or data under a similar license, it does give users the option to be able to have the freedom to do what they want. This route also helps to foster greater user community support to drive development often in the form of add-ons and plug-ins. There are a number of applications which are credible open source alternatives to Google Earth. While none of the software applications featured in this article have all of the features offered by Google Earth (although some offer some different features), and they are not exactly comparable, they are all worthy of investigating.

  • Warzone 2100 Lands Vulkan Renderer, Adaptive V-Sync For 20+ Year Old Game

    Warzone 2100 as the real-time strategy/tactics game that first premiered in 1999 before becoming open-source in 2004 and then fully open-source with game data in 2008 is now evolving in 2020 with Vulkan graphics support. The open-source Warzone 2100 game not only has a Vulkan back-end that was merged today but also OpenGL ES 2.0/3.0 support for those wanting to relive this late 90's computer game on mobile/embedded devices having only GLES drivers.

  • [NetBSD] Curses Library Automated Testing

    My GSoC project under NetBSD involves the development of the test framework of curses. This is the final blog report in a series of blog reports; you can look at the first report and second report of the series. The first report gives a brief introduction of the project and some insights into the curses testframe through its architecture and language. To someone who wants to contribute to the test suite, this blog can act as the quick guide of how things work internally. Meanwhile, the second report discusses some of the concepts that were quite challenging for me to understand. I wanted to share them with those who may face such a challenge. Both of these reports also cover the progress made in various phases of the Summer of Code. This being the final report in the series, I would love to share my experience throughout the project. I would be sharing some of the learning as well as caveats that I faced in the project.

  • [NetBSD] RumpKernel Syscall Fuzzing

    The first and second coding period was entirely dedicated to fuzzing rumpkernel syscalls using hongfuzz. Initially a dumb fuzzer was developed to start fuzzing but it soon reached its limits. For the duration of second coding peroid we concentrated on crash reproduction and adding grammar to the fuzzer which yielded in better results as we tested on a bug in ioctl with grammar. Although this works for now crash reproduction needs to be improved to generate a working c reproducer. For the last coding period I have looked into the internals of syzkaller to understand how it pregenerates input and how it mutates data. I have continued to work on integrating buildrump.sh with build.sh. buildrump eases the task fo building the rumpkernel on any host for any target. buildrump.sh is like a wrapper around build.sh to build the tools and rumpkernel from the source relevant to rumpkernel. So I worked to get buildrump.sh working with netbsd-src. Building the toolchain was successfull from netbsd-src. So binaries like rumpmake work just fine to continue building the rumpkernel.

  • Full Circle Magazine #161
  • Bandwidth for Video Conferencing

    For the Linux Users of Victoria (LUV) I’ve run video conferences on Jitsi and BBB (see my previous post about BBB vs Jitsi [1]). One issue with video conferences is the bandwidth requirements. The place I’m hosting my video conference server has a NBN link with allegedly 40Mb/s transmission speed and 100Mb/s reception speed. My tests show that it can transmit at about 37Mb/s and receive at speeds significantly higher than that but also quite a bit lower than 100Mb/s (around 60 or 70Mb/s). For a video conference server you have a small number of sources of video and audio and a larger number of targets as usually most people will have their microphones muted and video cameras turned off. This means that the transmission speed is the bottleneck. In every test the reception speed was well below half the transmission speed, so the tests confirmed my expectation that transmission was the only bottleneck, but the reception speed was higher than I had expected. When we tested bandwidth use the maximum upload speed we saw was about 4MB/s (32Mb/s) with 8+ video cameras and maybe 20 people seeing some of the video (with a bit of lag). We used 3.5MB/s (28Mb/s) when we only had 6 cameras which seemed to be the maximum for good performance.

  • Get involved – Meet the TDF team

    Joining a free and open source software project, such as LibreOffice, is a great way to build your skills, gain experience for future career options, meet new people – and have fun! But sometimes, joining a large and well-established project can be a bit daunting at the start. So here we’ll introduce you to the small team at The Document Foundation, the non-profit entity behind LibreOffice. Most team members oversee certain sub-projects in the LibreOffice community – click on their names to learn more in interviews…

  • Emacs Builders (Together with Richard Stallman) Focus on Learn how to Construct a Extra 'Fashionable' Emacs
  • Lack of Qualified Linux Talent Impedes Enterprise Move to the Clouds

    The Linux Foundation has been working to address the shortage of Linux talent for many years with a combination of training and certification exams. Despite this, the breathtaking growth in Linux adoption, especially as the de facto OS of the cloud, means that there is still a shortage of qualified talent, according to Clyde Seepersad, senior vice president and general manager for training and certification at The Linux Foundation (LF). “We are always supportive of developments in the training ecosystem which help address this gap. In particular, we are finding that demand for our performance-based certification exams continues to be gated by individuals not feeling adequately prepared,” he told LinuxInsider. LF’s certification exams include Certified Kubernetes Administrator, Certified Kubernetes Application Developer, Linux Foundation Certified SysAdmin, and Linux Foundation Certified Engineer. “ACG and LA both have excellent reputations for the quality of their open-source training content so we are pleased to see them come together to better serve the talent development needs of the open-source software ecosystem,” he added.

  • Last phase of the desktop wars?

    Economic pressure will be on Microsoft to deprecate the emulation layer. Partly because it’s entirely a cost center. Partly because they want to reduce the complexity cost of running Azure. Every increment of Windows/Linux convergence helps with that – reduces administration and the expected volume of support traffic. Eventually, Microsoft announces upcoming end-of-life on the Windows emulation. The OS itself , and its userland tools, has for some time already been Linux underneath a carefully preserved old-Windows UI. Third-party software providers stop shipping Windows binaries in favor of ELF binaries with a pure Linux API… …and Linux finally wins the desktop wars, not by displacing Windows but by co-opting it. Perhaps this is always how it had to be.