openSUSE Live!
Using a LiveUSB or LiveCD to test the performance of a new release should never be the basis of migrating or adopting a Linux distribution. However, running on LiveUSB does provide superficial reasons to install an OS on a crash machine or hardware. A Linux distribution, as a bare minimum, should perform adequately when running on a LiveUSB or LiveCD. That said, there are occasions when a Linux distribution performs perfectly while running on Live but fails miserably when installed on to a hard drive (and vice-versa).Historically, openSUSE has been consistent: openSUSE LiveCDs or LiveUSBs work admirably and perform similarly as they would after a full installation.
On testing openSUSE 12.2 via LiveUSB on my Lenovo Ideapad Z360 and first-generation ASUS EEEPC 1000H, I observed the following:
1. The SUSE Studio Image Creator for Windows, which once worked perfectly for 11.x and 12.1, no longer works for openSUSE 12.2. After two attempts with two different USB sticks, I switched to Ubuntu and ran the dd procedure via Terminal to create the LiveUSB instead. A warning to users who create the LiveUSB using the dd command: Ubuntu and other Linux distributions would have problems mounting the USB and Windows will offer to format the USB stick once connected.
2. The under-the-hood improvements to openSUSE 12.2 (such as systemd, kernel 3.4, and Qt 4.8.1 ), does improve KDE boot speed. openSUSE 12.2 loaded so quickly on the Ideapad I never got to see the openSUSE logo with flying bubbles until I tried the LiveUSB on the netbook (but I did get to see the KDE loading screen). Obviously, openSUSE would perform well on any Core Duo system (even on my first-generation Core i3 processor with 4GB of RAM), but I was particularly impressed when I booted into a working desktop on the 1000H.
I had been using openSUSE 12.1 KDE on the system for over the last year or so until I switched to Lubuntu last month due to server issues in China. Although I had grown used to it, openSUSE KDE 12.1 took more than two minutes to boot up on the EEEPC 1000H even after optimizing desktop effects and startup options. The LiveUSB of 12.2 booted up much faster and the desktop effects performed like it was designed for the netbook. Hopefully, a full installation on the 1000H would contribute to an even faster boot up speed.
3. The LiveUSB, as previously noted, performed very well on the first-generation Intel Atom processor the 1000H toted. Window management and transparency was working without any lag. I switched off the desktop effects to check if the desktop would perform even better (which I normally did for any Linux distribution on a netbook). Surprisingly, the 1000H suddenly became sluggish and almost ground to a halt until I switched the desktop effects back on again (after patiently clicking on the icons and waiting for windows to come up).
This is a curious anomaly that I hope doesn't occur on a full installation. Although I do like KDE's transparency effects and collapsing windows, they don't really contribute much to me as a user.
4. The touchpad worked perfectly on the 1000H! Unlike recent releases of Lubuntu and Fedora, openSUSE still manages to support the touchpad of the 1000H out-of-the-box. Although this may not seem that important, openSUSE has been consistent in providing support for the tap-and-drag feature for the touchpad. I don't understand why Fedora and Ubuntu would require additional steps or packages just to get the touchpad working properly. Other users may rarely use their touchpad to tap and drag items on the desktop, but it's essential if you're working without a mouse.
5. The wireless FN key now worked for the 1000H! Previously, I've had to install and run the rfkill command to switch on wireless on the netbook. While running the openSUSE 12.2 LiveUSB, a quick FN+F2 did the trick. Of course, Lubuntu never had this issue but it's still nice to know that openSUSE corrected this problem (which had been around since openSUSE 11.x). The release notes indicated improvements to the Network Manager but I didn't think they'd fix that age-old problem too. 1000H users, however, would be disappointed to find out Bluetooth still needs to be unblocked via rfkill but who uses Bluetooth anyway?
0 comments:
Post a Comment