Language Selection

English French German Italian Portuguese Spanish

Stuck on Stux

Filed under
Linux
Reviews
-s

Stux Linux is an unique Linux distribution. Version 0.8.1 was released on the 7th and Distrowatch reports, "The new version is a quick bug-fix update to the new 0.8 series, which the developers launched a week ago. Some of the new features include: "Based on Slackware Linux 10.2 and Knoppix 3.7 for kernel and modules; all procedure and interfaces have been substantially reviewed; added boot option 'toram' to load STUX image in RAM and run from there; STUX Network Panel added - configure network for dial-up, ADSL, ethernet and wireless connections; STUX Media Center added; USB support enhanced; hard disk and USB installation process enhanced; created BitTorrent UI, also integrated in Firefox....""

It was quite the surprise to boot the livecd and watch a Knoppix init and hardware detection, being under the impression Stux was based on Slackware. However, this impression was correct. How did those developers come up with that idea? But the surprises don't end there. Wait until you see the desktop.

The default desktop environment is KDE 3.4.2. What makes this desktop unique is some of the customizations put in place. Granted most of them are mere KDE options, but how many developers have the courage to ship with them? Not so different is the gkrellm on the desktop in a transparent theme, nor the background of the famous blue-blend. Not so distinctive is the menu or even the windec and icons. Where the differences start are the panel arrangements. First is the launcher at the top of the screen, auto-hiding yet with a transparent background when visible. That in of itself may not impress, but it is also accompanied by the main panel at the bottom of screen with of course, transparency enabled, and also a few well chosen applets. The kasbar on the right, auto-hiding, as well as side-bar on the left were also something one doesn't encounter everyday in a distro by default.

        

It's different and refreshing in a way, however I think the main panel is a bit too cluttered. The cpu and memory monitors should probably be turned off and that functionality added to gkrellm, and that mixer is overkill as well. Most functions of a mixer are inoperative or not used very often in my case and suspect it may be so for many folk. That could at least be trimmed down if not removed completely. There is a mixer plugin for gkrellm as well and if stux is gonna have gkrellm on the desktop at boot, I say incorporate what they can into it. In addition, noatun has never been a very good application for me, I'm not sure I'd leave that applet either. But these are personal preferences and if installed onto the harddrive or saved the configuration I could easy change.

I was quite impressed with the Stux Control Center. From there one can configure various hardware devices, install software, and install the system to hard drive or even an usb key. It is different from other distro's control centers in presentation and functionality. Not only can you configure your system through it, but it is also an application launcher. It has several application buttons running down the right side as well as having a menu of clickable links. As stated I was quite impressed with it even if I encountered a few niggles.

I've been using Stux for a coupla days and I first began having issues when I attempted to use the control center to adjust my mouse settings so my scroll button would work. It wrote the new configuration and restarted X, but the system became quite sluggish and there was artifacting and visual corruption afterwards. I figured the scroll wasn't worth it, so I just rebooted to get the original default settings and performance back. But throughout the course of the day, surfing the internet, checking webmail, and trying to take screenshots and write this article, X has crashed out on me a few times and sent me out to the terminal. X always restarts, but it can be annoying when you haven't saved your work in a coupla paragraphs. However, the system seemed much more stable after a hard drive install. Your mileage may vary and you may not experience any negative issues with the livecd at all.

        

The greatest achievement in Stux I believe is their Stux Control Center as introduced above. It's unique appearance and the fact it opens upon start bring it into attention immediately. One of the functions it contains is a package manager. Besides the qtswaret found in the KDE menu, Stux seems to have its own package manager that can download Stux packages and install them to disk or ram. I decided to test the install to ram feature for the nvidia drivers, but alas I was met with a "not enough ram error." As my machine only contains 512mb of ram, my only recourse was to install onto harddrive.

        

The harddrive install is another unique interface with lots of nice options. There's a really nice description on the Stux site, but basically one clicks the harddrive target partition and check boxes for options. Some of these options include Install Current configuration which copies the root and etc partitions as they presently exist, format device, and install bootloader onto harddrive or mbr. There are buttons to launch qtparted or cfdisk if needed as well as option to create a boot floppy.

        

My experience with the harddrive install was mixed. I installed twice on two different partitions hoping to ascertain the most appropriate configuration of the installer. The first time the install itself went smoothly and I made a boot floppy to boot the system. It booted but locked up because of the "nv" driver bug, despite having edited the xorg.conf file for vesa from another linux install in order to avoid that. The fly in the ointment is that on every boot Stux/knoppix hardware detection is not only checking for new hardware each boot, it rewrites every config file previously edited. Not good.

The second install I unchecked "install current configuration" and it wouldn't even boot. It hung right after starting "multi-user" with an error about read-only filesystem. Ho hum.

So back in the original install, I tried to run the Stux package manager to install the nvidia drivers. It downloaded its nvidia package and tried to install it, however it errors out with the message something about the glx library missing. The kernel source was included, so I exited KDE and installed them using nvidia's installer/package. The Stux process edited the correct files however for use of the drivers upon reboot, indicating that it was just a problem with the package itself.

        

With the mixer and noatun applets big and bold and taking up much of the panel, it appears that Stux is trying to be an out-of-the-box multimedia system as well. In testing I found that xine could in fact play most of the video files I had on hand if it was in a standard video format such as mpeg and avi, further the win32codecs were available for installation through the Stux Packages installer. xawtv performs well after configuration of drivers and settings (as with any xawtv install), however I couldn't persuade xmms or kscd to play any audio cdroms. Flash and java weren't installed, but java was available through the package installer and installed without incident.

    

As far as applications, besides the full compliment of KDE applications, Stux is well equipped with many popular packages such as gimp, firefox/thunderbird, abiword and koffice, amule, gaim, xsane and qtswaret. There really aren't too many games, but there are several premier games or demos in available through the package installer.

        

So in conclusion, I think those Stux fellars might be onto a something a little different and out of the ordinary. As many people grow weary of the same ole same ole, Stux might have a chance to rival some of the big boys. They have some brave and bold default configurations that add to the user experience as well as wonderful original tools. Stux might need some more maturing and a bit more refining, but I predict great things to come of this project. If you're looking for something a little different, you just might become stuck on Stux. More Screenshots in the gallery.

More in Tux Machines

50+ Essential Linux Apps[2020] for your Linux Distro

Best Linux Apps 2020: Welcome to Tec Robust. This article is going to be a long stretch of best and essential Linux Applications 2020 for your Linux Distribution. It covers applications for Distros such as Ubuntu, Fedora, OpenSUSE, CentOS, Elementary OS, Zorin OS, Debian, Kubuntu, and more. Without any more delay, we will get into the article. Equip your Linux with the best applications listed down here. Read more

Arcolinux - Too much, too little

Walking the Tux road, one system at a time. A short while back, I thought a departure from the proven mainstream dozen distros would do me some fresh good. So I grabbed Solus OS, I tested Peppermint, and now, I'd like to embark on an Arch adventure. Previously known as ArchMerge, Arcolinux is a distro that obeys Monty Python's rule of three. Three shall be the number of versions, and the number of desktop environments shall be three. Not two, not four. ArcoLinux has the main edition plus D and B builds for tinkerers. I opted for the Xfce-clad 19.12 release. Without further ado, let's see what gives. [...] I am struggling to reconcile with the polar brilliance of the Linux desktop. Even now, some 15+ years since I started using it, I haven't gotten used to it. You get something really cool, and then a bunch of random cosmic events that ruin the experience. And this is because most distros aren't designed with the end user in mind, and they have no product awareness. Arcolinux has some interesting points. But this ain't new, radical or special. You can pick any distro, and it will do something significantly better than others. Then, it will also fail three or five basic things that ordinary folks expect. And most distros have this problem - they do not address the most mundane activities or needs that one wants in a desktop. Arcolinux was fast, it did all right on the connectivity front, but it's quite rough around the edges, and if you deviate from the dark-theme unicorn, the session loses all traces of fun. Which is not how it's meant to be. If you want to test something a bit avant-garde, and Arch-based at this, perhaps you want to look at Arcolinux. For me, this is a classic manifestation of a much wider problem in the Linux space, and once again, sadness rules supreme at the end of the short review. Read more

LibreELEC (Leia) 9.2.2 Hotfix

LibreELEC 9.2.2 (Leia) is a Hotfix release just for the x86_64 Generic (PC, AMD, Intel, NVIDIA …) image. It includes a fix for the missing sound at Intel based systems (mainly NUC) due an Linux Kernel bug. This is just for the Generic image as the fix only targeting this platform. Read more

Kdenlive Beta and Development

  • Mirrors for kdenlive-20.04-beta1-x86_64.appimage
  • Kdenlive 20.04 Beta Released With Continuing To Improve The Open-Source Video Editor

    Open-source video editors over the years have generally fallen well short of the stability and feature set offered by proprietary video editing solutions but in recent years at least there has been some measurable progress to the likes of Kdenlive and OpenShot. Out this weekend for testing is the Kdenlive 20.04 beta. Kdenlive 20.04 is being prepared as part of the "KDE Applications" 20.04 milestone for next month. For those wanting to help in spotting any last minute bugs, the Kdenlive 20.04 beta is available. For easy convenience across distributions, the AppImage is available of this first Kdenlive 20.04 beta.

  • Season of KDE 2020 and GSOC

    The first thing that one has to do before beginning to contribute to an organization is to build the code of the application from the source. And if this is the first time a person is building an app then he/she should be ready to do a lot of googling and praying for the CMake to compile successfully. Kdenlive works with the help of a lot of dependencies and libraries. For the CMake to compile properly the system should have all these libraries installed in it. First things first, I got the Kdenlive source code from the GitLab instance of KDE, invent.kde.org. It is always best to checkout from the master to a new branch to prevent committing incorrect changes and spoiling your whole branch. Then I created a build file and ran the CMake code. This returned a LOT of errors when the required libraries and dependencies were not found in my system. Most of the errors were solved when the following command was executed: