Now that I've had a break that's longer than the blog's initial run of energy, you must have your doubts about Total Slackware Linux Fun's longevity. I apologize for the recent radio silence. I've just been busy with real life-type problems. If you write to me about wanting a review of a certain package or to discuss how you personally use Slackware, that will accelerate my return to form. I will be writing more soon.
I just wanted to make a little announcement: I'm going to stop pretending not to know what a cloud is and build one.
There, I said it.
Friday, June 8, 2012
Friday, May 11, 2012
Easing Memory Issues on the Cheap
At the end of this post there will be a brief tutorial on how to improve performance on computers that are strapped for cache for the cost that ranges from "pulled it out of a box of junk" to $5 at your favorite retailer (even the grocery store). It's no more or less than a step-by-step guide to taking your swap off of your ancient spinning platter drive and onto a USB flash drive. After another sentence or two of introducing the idea, I'll go into a spiel on why using Linux is "green." If you're not into that sort of thing, skip to the last section.
Most of the time, my aging laptop gets along just fine without having to swap anything off to the disk. Even if I'm making a panoramic image or editing or transcoding video, I can often keep my swap usage to under 20 MB. If I get much past that 20 MB mark, though, the thrashing becomes unpleasant.
The other day, I was rendering an HD video and I noticed my swap usage approaching 200MB when I remembered reading about ReadyBoost, which allows Windows to use USB mass storage devices for swapping. It's a great idea because USB flash drives have better read/write speeds than platter-based storage (alleviating or delaying thrashing) and because USB flash is a lot more economical than most solid state media. When your $5 drive wears out quickly, you won't be too bothered.
Of course, using USB flash as a swap partition (or to store a swap file) has been possible on Linux for as long as there has been support for USB mass storage on Linux. It's just that I've been reading about Linux every day for many years and I've never seen it discussed. Maybe I'm the only one who's been missing out. Somehow I doubt it.
Green computing, or using a computer until it dies
As several of you are already aware, I was a longtime Red Hat / Fedora user before I switched to Slackware earlier this year. I wasn't unhappy with anything about Fedora other than its performance -- even using 4 KB of swap meant I was in for a bad day.
I'd had previous good experiences with Slackware having relatively new versions of my favorite packages, great stability, and sane, readable configuration options. To top it off, I'd used it in the past to squeeze good performance from truly ancient hardware. Slackware used to be my go-to distro for older computers. Now that my only computer is older, I've gone to it.
When I finally get a newer machine, I'll stick with it. I'm impressed by how straightforward it is. Best of all, the work I put into untying the knot (getting it run initially) has allowed me to experience a new state of mind where things just make sense and good things come to those who do little-to-nothing.
I've been duly rewarded for the switch. As I mentioned, the threshold for thrashing has been raised from 4 KB to 20 MB, and Slackware has changed my video editing metric from "abject despair" to "frustrating." I don't expect I can do much better than "mildly frustrating" at video editing, since I have an integrated graphics chip.
So far, I've focused on how Slackware has kept me using different binary packaging of the same programs with better performance. That is, I'm talking about a Linux-to-Linux switch that's kept me happily using the same old gear for longer. What make it "green" is that my trusty old laptop isn't in the landfill yet. Now, I've never run Windows on this laptop, but I have a story that should put the inherent greenness of switching to any Linux distro in perspective.
My graphics chip is so bad that when it was still brand new, it was the subject of a class action lawsuit. Careful readers and pedantic fanbois will no doubt point out that it was an unsuccessful suit, but I argue that even in a litigation-happy country like the United States things have to get bad before people will sue over computer chippery. Anyhow, the chip as allegedly less than "Vista capable." Where Aero would have crippled me, Compiz was working alright and now with Gnome Shell things are going so smoothly that I forget that it demands hardware acceleration.
Wikipedia reports that the chip will, in fact, run Aero. I suspect that it only does so begrudgingly, and you can forget about its running Crysis. You can split hairs if you like, or you can accept my simple point that this laptop would barely get going with Windows, yet I use it for photo editing, audio/video editing, and all the daily browsing, music-playing, and video-watching you'd expect.
Of course, I might just upgrade the RAM if things are getting a little sluggish. As it is, I've already maxed out at 2.8GB, slightly more than the manufacturer-reported maximum of 2GB. Still, that's not enough for editing videos and other heavy tasks.
Now that I've begun using USB flash for my virtual memory needs, I've managed to squeeze out a bit more performance. That doesn't change the fact that I don't have a dedicated GPU, and my CPU has to carry the full weight of rendering the videos, but it does make it so that the I/O is no longer the bottleneck.
That is, the problem used to be swapping information onto my PATA hard drive (which isn't as impressive as it once was). Now that swapping isn't a problem, my overworked CPU becomes the weakest link, and modern multitasking allows me to keep browsing the web or listening to music while my video renders. In fact, if I wanted to (and I did, for testing purposes), I can open an instance of every GUI program I have without experiencing any slowdown like I did before.
You shouldn't expect a miracle. If you couldn't play HD videos before, you probably won't be able to now. But if financial worries will keep you using the same PC for a few more years, you should at least get a responsive desktop out of the deal.
The Tutorial
There are two possibilities for swapping on a USB flash drive. You can allocate an entire partition to the task (the whole drive, or a part of it with the rest used for storage), or you can make a swap file. Since I make frequent use of an external hard drive for storage and backup needs, I've chosen the latter option. To clarify, my external drive isn't a flash drive, but I want to be careful not to use it for swapping by accident.
If you're using the swap file option, first you make the file itself. Mount the drive you want to use, then issue the following command as root:
dd if=/dev/zero of=/media/yourusbdisk/swapfile bs=1024 count=512000
Where:
dd is a utility for copying and converting files
The if argument specifies the input file or device. In this case, we're just reading zeros.
The of argument specifies the output file or device. In this case, we're writing those zeros to a file called "swapfile" on the disk called "yourusbdisk."
The bs argument specifies how many bytes we want to read and write at a time. A bs of 1024 means we're working with 1KB of information per count.
The count argument specifies how many times to copy information from /dev/zero to your swapfile. In other words, this is how big the file will be. You can figure out what your count argument should be by multiplying the desired file size in MB by 1024. So, a count of 512000 yields a file that's 510 MB or 512MiB.
Whether you're using a swap file or a swap partition, you'll need to use the next steps:
For files: mkswap /media/yourusbdisk/swapfile
(Where that argument should be the location of the file we made in the previous step)
For partitions: mkswap /dev/sda1
(Where /dev/sda1 is the partition you want to make your swap partition. Hint: it probably won't be sda1.)
Now, all we have to do is turn off our slow platter-based swap partition:
swapoff /dev/cryptvg/swap
(Where the argument is your swap partition.)And turn on our flash-based swap partition:
swapon /media/yourusbdisk/swapfile
If you've got enough new swap space and very little RAM, you might want to increase your swappiness. For instance, if you only have 512 MB of RAM, but you've got 1GB or more of flash-based swap, you'll want to turn it up to 100:
echo 100 > /proc/sys/vm/swappiness
After you reboot, your swap file/partition will still exist, but it shouldn't be automatically kept on to the next
session unless you specifically make it so. See your distribution-specific tools for doing this. Likewise, you'll
need to take further steps to permanently alter your swappiness parameter.
You can add me on Google+ to read my latest writings as soon as I post them. You can also call me bad names or write to thank me in the comments section.
Sunday, May 6, 2012
Friday Fun and Failures: This Week's Experiments
Quick note: I like the alliterative title too much to get rid of it. Also, this is a blog for Slackers. If you don't like that my Friday blog took til Sunday night, maybe you're not a true Slacker.
This week, I've done plenty of complaining about my attempts to get Xfce 4.10 running, but I'm not done yet. I also complained about my inability to compile the GIMP 2.8. I'm not done trying there either. But that doesn't adequately sum up all the Slackware-related things I've tried at and royally screwed up this week.
Also, hey, success!
Believe it or not, I've had a great deal of fun at all this, in spite of the failure. Aside from the freedoms using Linux affords me, the thing I love most about it is the feeling of exploration. All this hands-on time is as good as it gets. I'm learning more about Linux than I have since those first few months. I doubt that any Windows or Mac user can claim to know their computer's brain so well.
I can't get Xfce 4.10 to build and after a little more experimentation with Ralvex's builds, I reverted to Pat's 4.6 build. I stuck with Xfce for a few days, and during that time, I preferred it to my usual Gnome setup, but Gnome has and probably always will draw me back in the end.
In spite of Gnome Shell's alien appearances, there is a distinct Gnome feeling that ties it to Gnome 1, where I started out almost ten years ago. Someday I may try to articulate precisely what that is.
Why didn't I stick with Ralvex's Xfce 4.10 once I got it installed?
VLC
One striking quirk I've noticed due to my recent desktop hopping is that Alien's VLC 2.0.1 looks better in GTK+ environments (Gnome and Xfce) than it does in a Qt environment (KDE). For those who don't know, VLC is most commonly seen in its Qt4 form. That is, it is built from Qt widgets and should look most at home and integrated on a desktop that's also built on Qt. Instead, running VLC on KDE in fullscreen mode leaves the controls looking a right mess.
In this case, I'm glad I'm a Gnome user.
Kernel 3.x
One big complaint I've had since switching to Slackware is that I was having daily crashes. On average, it had been once a day. Sometimes it wouldn't happen at all; sometimes it would be two or three times a day. The kernel panic message onscreen indicated a problem with the wifi driver. Also, there seemed to be a correlation with heavy wifi traffic and the crashes. That is, the longer I ran Deluge, the more problems I would see.
How did I fix it?
First, I tried upgrading to the 2.6.38 kernel from /testing on the Slackware64-13.37 servers. In my use over about two weeks, that didn't seem any different from 2.6.37. Failing a fix when I reinstalled my card's microcode, I tried building the latest kernel myself.
Kernel 3.3.4 builds, installs, and boots using Pat's configuration from the 2.6.37/38 series. Most everything works but I have to turn off the firewall to use the Web (yes, it's configured properly for normal use). It feels faster than 2.6.3x, but the interference with the firewall is a showstopping bug and I would worry about other troubles in the future.
Finally, I decided to grab the kernel from Slackware-current (3.2.13), and I've been running that for a couple days without any trouble at all. Best of all, there are no more panics. However, I don't feel the improvement in speed I saw from 3.3.4. That said, keeping all the functionality from previous kernels and adding in the stability they were missing is more than good enough.
If I feel it necessary, I'll try building the latest kernel again. This time, though, I'll use the configuration from the 3.2 kernel. It will probably work better.
Goodbye, crashes. Hello, famous Slackware stability.
gtkmm compatibility fixes
This item will be of interest to Gnome Slackbuild users who also use packages from Salix or SlackBuilds.org. For those who don't know, gtkmm is the C++ binding to GTK+.
Earlier, I had complained that I had to choose between gtkmm2 and gtkmm3 programs, as installing the GSB package kept other programs working and installing gtkmm2 kept gtkmm3 programs, including Gnome's System Monitor, from running. I've found a workaround.
Since the files in GSB's packages are fully separate from Salix's package's files, there are two ways of going about it.
(1) You can alter one of the packages' names to trick your package manager into installing both. Ordinarily, it will see gtkmm3 as an upgrade when in reality it is no more an upgrade than GTK+3 is over GTK+2. As with GTK itself, most users will want both versions side-by-side. Simply unzip gtkmm2's txz, change the slack-desc file, zip it back up, and instal it.
(2) Alternatively, you could repackage both gtkmm2 and gtkmm3 into one file. I chose the first option for its simplicity, but this is just as viable. Just keep your eyes open for upgrades upstream.
For maximum fun, and since at least one Slacker is a fellow Deadhead, I'm going to name a Grateful Dead performance of the week. I've really been enjoying the concert captured on One From the Vault this week. I hope you will, too.
Please feel free to comment with questions, concerns, and requests for future posts. And follow me on Google+ to hear about new posts as soon as they come out.
This week, I've done plenty of complaining about my attempts to get Xfce 4.10 running, but I'm not done yet. I also complained about my inability to compile the GIMP 2.8. I'm not done trying there either. But that doesn't adequately sum up all the Slackware-related things I've tried at and royally screwed up this week.
Also, hey, success!
Believe it or not, I've had a great deal of fun at all this, in spite of the failure. Aside from the freedoms using Linux affords me, the thing I love most about it is the feeling of exploration. All this hands-on time is as good as it gets. I'm learning more about Linux than I have since those first few months. I doubt that any Windows or Mac user can claim to know their computer's brain so well.
I can't get Xfce 4.10 to build and after a little more experimentation with Ralvex's builds, I reverted to Pat's 4.6 build. I stuck with Xfce for a few days, and during that time, I preferred it to my usual Gnome setup, but Gnome has and probably always will draw me back in the end.
In spite of Gnome Shell's alien appearances, there is a distinct Gnome feeling that ties it to Gnome 1, where I started out almost ten years ago. Someday I may try to articulate precisely what that is.
Why didn't I stick with Ralvex's Xfce 4.10 once I got it installed?
- Ralvex's build omits Thunar. With all the other libraries and base packages pre-built, it is no trouble at all to build Thunar from source. However, I think this fact alone will make it unsuitable for users looking for a pre-made solution.
- It has a screwed up desktop. My desktop background isn't shown, and the file manager doesn't handle putting up file and folder icons. I didn't investigate the cause of this one too thoroughly, but I imagine Xfce-desktop is missing. That's another non-trivial omission.
- It seems to rely on Qt widgets even to the point that Xfce's settings manager doesn't change their theme but KDE's does. This one has me totally befuddled. Part of why I feel so at home in Xfce is that it uses the GTK+2 widgets. I've never been a fan of the Qt look-and-feel. To add to that insult the (resource) injury of starting KDE services just to change the appearance of my controls totally defeats the two main purposes of running Xfce (namely the familiar looks and light memory/CPU needs).
VLC
One striking quirk I've noticed due to my recent desktop hopping is that Alien's VLC 2.0.1 looks better in GTK+ environments (Gnome and Xfce) than it does in a Qt environment (KDE). For those who don't know, VLC is most commonly seen in its Qt4 form. That is, it is built from Qt widgets and should look most at home and integrated on a desktop that's also built on Qt. Instead, running VLC on KDE in fullscreen mode leaves the controls looking a right mess.
In this case, I'm glad I'm a Gnome user.
Kernel 3.x
One big complaint I've had since switching to Slackware is that I was having daily crashes. On average, it had been once a day. Sometimes it wouldn't happen at all; sometimes it would be two or three times a day. The kernel panic message onscreen indicated a problem with the wifi driver. Also, there seemed to be a correlation with heavy wifi traffic and the crashes. That is, the longer I ran Deluge, the more problems I would see.
How did I fix it?
First, I tried upgrading to the 2.6.38 kernel from /testing on the Slackware64-13.37 servers. In my use over about two weeks, that didn't seem any different from 2.6.37. Failing a fix when I reinstalled my card's microcode, I tried building the latest kernel myself.
Kernel 3.3.4 builds, installs, and boots using Pat's configuration from the 2.6.37/38 series. Most everything works but I have to turn off the firewall to use the Web (yes, it's configured properly for normal use). It feels faster than 2.6.3x, but the interference with the firewall is a showstopping bug and I would worry about other troubles in the future.
Finally, I decided to grab the kernel from Slackware-current (3.2.13), and I've been running that for a couple days without any trouble at all. Best of all, there are no more panics. However, I don't feel the improvement in speed I saw from 3.3.4. That said, keeping all the functionality from previous kernels and adding in the stability they were missing is more than good enough.
If I feel it necessary, I'll try building the latest kernel again. This time, though, I'll use the configuration from the 3.2 kernel. It will probably work better.
Goodbye, crashes. Hello, famous Slackware stability.
gtkmm compatibility fixes
This item will be of interest to Gnome Slackbuild users who also use packages from Salix or SlackBuilds.org. For those who don't know, gtkmm is the C++ binding to GTK+.
Earlier, I had complained that I had to choose between gtkmm2 and gtkmm3 programs, as installing the GSB package kept other programs working and installing gtkmm2 kept gtkmm3 programs, including Gnome's System Monitor, from running. I've found a workaround.
Since the files in GSB's packages are fully separate from Salix's package's files, there are two ways of going about it.
(1) You can alter one of the packages' names to trick your package manager into installing both. Ordinarily, it will see gtkmm3 as an upgrade when in reality it is no more an upgrade than GTK+3 is over GTK+2. As with GTK itself, most users will want both versions side-by-side. Simply unzip gtkmm2's txz, change the slack-desc file, zip it back up, and instal it.
(2) Alternatively, you could repackage both gtkmm2 and gtkmm3 into one file. I chose the first option for its simplicity, but this is just as viable. Just keep your eyes open for upgrades upstream.
For maximum fun, and since at least one Slacker is a fellow Deadhead, I'm going to name a Grateful Dead performance of the week. I've really been enjoying the concert captured on One From the Vault this week. I hope you will, too.
Please feel free to comment with questions, concerns, and requests for future posts. And follow me on Google+ to hear about new posts as soon as they come out.
Thursday, May 3, 2012
GIMP 2.8 for Slackware
The long-awaited 2.8.x series of the GIMP was released today. You can download the source here and read the official release notes here. Below my discussion of the new features, I give instructions for how to install it on Slackware.
A quick summary of the new features:
GEGL has been totally integrated into the backend, bringing with it support for higher bit-depth colors, non-destructive editing, and other features. The increased number of color profiles and the new single-window layout are sure to please converts from the proprietary competition. Of course, users who have become set in their multi-windowed ways (like me) can switch it back to the classic layout if they so desire.
There are also plenty of new options in terms of formats you can export to, including JPEG2000 and PDF. One downside to the newly rewritten save and export routines is that the GIMP team have chosen to separate save and export, with saving now exclusively reserved for the GIMP's native format.
Without having seen the code, I have to speculate that this has to do with the new focus on non-destructive editing and the complexity this adds to the setup. Often, non-destructive editing relies on layers, and most of the non-native image formats do not allow for layers.
Another change for layers is that GIMP 2.8 will allow them to be set up in groups, much as your desktop environment allows you to tab items in a window list. Once you get past two or three layers, a completely linear layering structure becomes confusing. Adding a second dimension to the logic allows the user to keep better tabs on things.
Two other changes that are relevant to most users are the change to Cairo for rendering and improvements in adding text to images. There are dozens of other changes to brushes and things, but I'm no illustrator. I'm afraid I'm not qualified to make a comment on them.
How to Install on Slackware64-13.37:
Since neither Pat, nor Alien Bob, nor the SlackBuild community have provided an updated package yet, early adopters will want to know how to get the GIMP up and running on their system. I haven't yet had the chance to properly test these instructions or SlackBuild file, as I spent the last two hours doing this writeup and trying to compile the sources from scratch without the build script. Some users over at LinuxQuestions are reporting issues with updated libffi.
Here is a list of the dependencies, with a link to a thorough README and a SlackBuild which was done for a pre-release version (2.7). You will have to alter the build script slightly. More to come when I've had success with these instructions.
I didn't have any luck getting the GIMP to find the version of Babl I built myself. I seem to be in pkgconfig hell, as per usual.
Don't forget to check out the documentation and tutorials on the GIMP's web page.
Happy Slacking!
UPDATE: Users of Gnome SlackBuild have a slight advantage here: most of the upgrades that need to be performed on GIMP's dependencies have already been made by GSB. We only need to upgrade Babl, GEGL, and GTK+2.
UPDATE 2: This leads me to believe that many users who prefer DEs other than Gnome could benefit from the txz's available from GSB. You can find the appropriate packages by correlating the above linked list of dependencies with either a Slackware-13.37 or Slackware64-13.37 repository.
UPDATE 3: With the binaries or sources/SlackBuilds from Gnome SlackBuild (listed in UPDATE 2), you can install several of the dependencies. With the GTK+ team-given sources on the other three dependencies, I've begun work on SlackBuild scripts. I have successfully built the appropriate version of Babl, but both GEGL and GTK+2 seem to have errors in them. Obviously, the GIMP won't build without them. Please stand by.
Don't forget to comment with suggestions, questions, or angry ranting and follow me on Google+ for future updates.
A quick summary of the new features:
GEGL has been totally integrated into the backend, bringing with it support for higher bit-depth colors, non-destructive editing, and other features. The increased number of color profiles and the new single-window layout are sure to please converts from the proprietary competition. Of course, users who have become set in their multi-windowed ways (like me) can switch it back to the classic layout if they so desire.
There are also plenty of new options in terms of formats you can export to, including JPEG2000 and PDF. One downside to the newly rewritten save and export routines is that the GIMP team have chosen to separate save and export, with saving now exclusively reserved for the GIMP's native format.
Without having seen the code, I have to speculate that this has to do with the new focus on non-destructive editing and the complexity this adds to the setup. Often, non-destructive editing relies on layers, and most of the non-native image formats do not allow for layers.
Another change for layers is that GIMP 2.8 will allow them to be set up in groups, much as your desktop environment allows you to tab items in a window list. Once you get past two or three layers, a completely linear layering structure becomes confusing. Adding a second dimension to the logic allows the user to keep better tabs on things.
Two other changes that are relevant to most users are the change to Cairo for rendering and improvements in adding text to images. There are dozens of other changes to brushes and things, but I'm no illustrator. I'm afraid I'm not qualified to make a comment on them.
How to Install on Slackware64-13.37:
Since neither Pat, nor Alien Bob, nor the SlackBuild community have provided an updated package yet, early adopters will want to know how to get the GIMP up and running on their system. I haven't yet had the chance to properly test these instructions or SlackBuild file, as I spent the last two hours doing this writeup and trying to compile the sources from scratch without the build script. Some users over at LinuxQuestions are reporting issues with updated libffi.
Here is a list of the dependencies, with a link to a thorough README and a SlackBuild which was done for a pre-release version (2.7). You will have to alter the build script slightly. More to come when I've had success with these instructions.
I didn't have any luck getting the GIMP to find the version of Babl I built myself. I seem to be in pkgconfig hell, as per usual.
Also, if you use fx-foundry or other plugins, you may have to recompile them for use with the new series.
Don't forget to check out the documentation and tutorials on the GIMP's web page.
Happy Slacking!
UPDATE: Users of Gnome SlackBuild have a slight advantage here: most of the upgrades that need to be performed on GIMP's dependencies have already been made by GSB. We only need to upgrade Babl, GEGL, and GTK+2.
UPDATE 2: This leads me to believe that many users who prefer DEs other than Gnome could benefit from the txz's available from GSB. You can find the appropriate packages by correlating the above linked list of dependencies with either a Slackware-13.37 or Slackware64-13.37 repository.
UPDATE 3: With the binaries or sources/SlackBuilds from Gnome SlackBuild (listed in UPDATE 2), you can install several of the dependencies. With the GTK+ team-given sources on the other three dependencies, I've begun work on SlackBuild scripts. I have successfully built the appropriate version of Babl, but both GEGL and GTK+2 seem to have errors in them. Obviously, the GIMP won't build without them. Please stand by.
Don't forget to comment with suggestions, questions, or angry ranting and follow me on Google+ for future updates.
Gnac: Better Know a Package
As many of the several of you know, I use a blend of Slackware64-13.37, Gnome SlackBuild, some Salix packages, some of Alien's packages, and a bit I've built on my own. That means sometimes things can get a little confusing when it comes to compatibility or remembering what version of what libraries I have installed. I'd like to tell you about that confusion and about one package that's not in any repository I know of but is very useful to Gnome-friendly Slackers who are particular about their audio codecs.
My compatibility confusion is largely due to the introduction of certain Gnome 3 dependencies. For instance, gtkmm2 and gtkmm3 (C++ bindings for GTK+ 2 and 3, respectively) are both called "gtkmm," and I can only have one installed at a time. That means choosing between GTK+ 2 packages and GTK+ 3 packages, and given the staunchly anti-GTK+ 3 nature of Slackware and Salix, that can mean choosing between having a working GParted or a working System Monitor.
Now, I understand why a distribution that has no plans to include Gnome would want to include libraries whose main function is to get Gnome up and running. I have no complaints about it. It's an inconvenience at worst and an opportunity for exploration at best. The wonderful SoundConverter tool for transcoding audio files en masse (after all, if you wanted to convert just one file, you'd use your everyday audio editor and it wouldn't be any trouble to do so) is, unfortunately, one of the packages affected by the transition to Gnome 3. I can compile the present 2.0.x series, but it won't start due to mismatched libraries, and I can't yet get the development version, which targets Gnome 3, to compile.
That's where Gnac comes in. Gnac is the GNome Audio Converter. Its UI is extremely similar to SoundConverter's -- so much so that a first-time user could be forgiven for believing they were using a slightly-improved version of SoundConverter. As far as the backend goes, Gnac also uses Gstreamer for its conversions. As far as the end user is concerned, the only difference is Gnac's flexibility in setting conversion options.
But for you, the Gnome-happy Slacker who has to compile the package yourself, the portability of the code is nothing to sneeze at. SoundConverter's dependency on Gnome-python means that if you can get it to build on your GSB-enabled system, it won't run for you. In general, SoundConverter has many more dependencies, and those dependencies are more complicated. On my older laptop, that means a lot of compile time gets rewarded with a program that's kaput.
In contrast, Gnac is pure C code. To run the latest version, as I've done, all you need is a standard GCC installation and the appropriate GTK+ 3 packages that have come with your GSB installation. If you're not a Gnome user, you'll want to grab an earlier version of the code that uses GTK+ 2 widgets. In practical terms, we're talking about the difference between building half a dozen dependencies plus the desired package vs. simply building the desired package. Even on aging hardware, the build takes less than a minute.
All you have to do is unpack the source from the project's download page and follow the simple process outlined there under the "Build from sources" header. And it just works.
None of this is to knock the SoundConverter package or developers. I used it for years with nothing but pleasure. It's just that it doesn't work with my present setup. In fact, what I like most about Gnac is its similarity to SoundConverter.
As I hinted at earlier, Gnac makes one minor improvement over its cousin: the granularity of control over how your files are encoded. Instead of the fixed profiles seen in SoundConverter, SoundJuicer, and others, with new profiles added by searching the Web for cryptic text to enter into a dialogue box, Gnac comes with only one profile. However, no searching and no copying is necessary to add new ones. All of Gstreamer's codecs are available from a drop-down menu from within the profile editor.
All the preferences about a how that codec is used are set from the profile editor, with standard options always visible and Geek++ options available by opening the "advanced options" tab with a single click. Also, not (initially) having a single, fixed profile for each codec means that you can be sure each one is set to your liking and that you can have multiple presets per codec. That would be useful if you wanted to have low-bandwidth and high-quality options of a podcast available without having to fumble over the controls each week, or you have two portable media players of different sizes or that accepted only particular formats.
Also promising is the talk on Gnac's developer pages about their ambitions to video transcoding. I don't want to name names, but I find all the FFmpeg GUI transcoders available as SlackBuilds to look ugly and to have unyielding profiles in case I want to take advantage of a particular feature. If the Gnac team bring a similar sensibility to the forthcoming features, then they will have achieved something truly great: a program that's as simple or advanced as the user desires that has a clean and attractive UI and is not stressful at all to package maintainers. Well done, team.
Have fun!
I would love to hear what you think of what I've written, or what you'd like to read about in the future. Please don't be shy about commenting on this page or about adding me on Google Plus, where I share more geeky/Linux things and fewer personal things than I do on other social networks, so I'm more comfortable adding Internet strangers (please don't ask to join my other networks, strangers).
My compatibility confusion is largely due to the introduction of certain Gnome 3 dependencies. For instance, gtkmm2 and gtkmm3 (C++ bindings for GTK+ 2 and 3, respectively) are both called "gtkmm," and I can only have one installed at a time. That means choosing between GTK+ 2 packages and GTK+ 3 packages, and given the staunchly anti-GTK+ 3 nature of Slackware and Salix, that can mean choosing between having a working GParted or a working System Monitor.
Now, I understand why a distribution that has no plans to include Gnome would want to include libraries whose main function is to get Gnome up and running. I have no complaints about it. It's an inconvenience at worst and an opportunity for exploration at best. The wonderful SoundConverter tool for transcoding audio files en masse (after all, if you wanted to convert just one file, you'd use your everyday audio editor and it wouldn't be any trouble to do so) is, unfortunately, one of the packages affected by the transition to Gnome 3. I can compile the present 2.0.x series, but it won't start due to mismatched libraries, and I can't yet get the development version, which targets Gnome 3, to compile.
That's where Gnac comes in. Gnac is the GNome Audio Converter. Its UI is extremely similar to SoundConverter's -- so much so that a first-time user could be forgiven for believing they were using a slightly-improved version of SoundConverter. As far as the backend goes, Gnac also uses Gstreamer for its conversions. As far as the end user is concerned, the only difference is Gnac's flexibility in setting conversion options.
But for you, the Gnome-happy Slacker who has to compile the package yourself, the portability of the code is nothing to sneeze at. SoundConverter's dependency on Gnome-python means that if you can get it to build on your GSB-enabled system, it won't run for you. In general, SoundConverter has many more dependencies, and those dependencies are more complicated. On my older laptop, that means a lot of compile time gets rewarded with a program that's kaput.
In contrast, Gnac is pure C code. To run the latest version, as I've done, all you need is a standard GCC installation and the appropriate GTK+ 3 packages that have come with your GSB installation. If you're not a Gnome user, you'll want to grab an earlier version of the code that uses GTK+ 2 widgets. In practical terms, we're talking about the difference between building half a dozen dependencies plus the desired package vs. simply building the desired package. Even on aging hardware, the build takes less than a minute.
All you have to do is unpack the source from the project's download page and follow the simple process outlined there under the "Build from sources" header. And it just works.
None of this is to knock the SoundConverter package or developers. I used it for years with nothing but pleasure. It's just that it doesn't work with my present setup. In fact, what I like most about Gnac is its similarity to SoundConverter.
As I hinted at earlier, Gnac makes one minor improvement over its cousin: the granularity of control over how your files are encoded. Instead of the fixed profiles seen in SoundConverter, SoundJuicer, and others, with new profiles added by searching the Web for cryptic text to enter into a dialogue box, Gnac comes with only one profile. However, no searching and no copying is necessary to add new ones. All of Gstreamer's codecs are available from a drop-down menu from within the profile editor.
All the preferences about a how that codec is used are set from the profile editor, with standard options always visible and Geek++ options available by opening the "advanced options" tab with a single click. Also, not (initially) having a single, fixed profile for each codec means that you can be sure each one is set to your liking and that you can have multiple presets per codec. That would be useful if you wanted to have low-bandwidth and high-quality options of a podcast available without having to fumble over the controls each week, or you have two portable media players of different sizes or that accepted only particular formats.
Also promising is the talk on Gnac's developer pages about their ambitions to video transcoding. I don't want to name names, but I find all the FFmpeg GUI transcoders available as SlackBuilds to look ugly and to have unyielding profiles in case I want to take advantage of a particular feature. If the Gnac team bring a similar sensibility to the forthcoming features, then they will have achieved something truly great: a program that's as simple or advanced as the user desires that has a clean and attractive UI and is not stressful at all to package maintainers. Well done, team.
Have fun!
I would love to hear what you think of what I've written, or what you'd like to read about in the future. Please don't be shy about commenting on this page or about adding me on Google Plus, where I share more geeky/Linux things and fewer personal things than I do on other social networks, so I'm more comfortable adding Internet strangers (please don't ask to join my other networks, strangers).
Tuesday, May 1, 2012
Xfce 4.10 Progress Report and SlackBuild
Just a quick progress report on my attempt to build Xfce 4.10:
First, ralvex has written a SlackBuild for Xfce 4.10. All you have to do is untar the fat tarball and run his script in the directory above it. Now, your mileage may vary. Users at LinuxQuestions reported success with ralvex's script, but it didn't work for me. That said, I'm running Slackware64 + bits of Gnome SlackBuild + bits of Salix + a few modifications of my own design (I'll talk about this all in good time, friends). It may be something I've done that keeps it from running.
The build didn't go so well for me yesterday because I was tired and frustrated before I sat down to work on it. That said, with a little detective work, I found a place where the otherwise excellent documentation will lead you astray. The docs call for you to set $PREFIX before you get to building, but the Makefile looks for $prefix. So, if you've followed the docs precisely, your basic libs will get put in the wrong place and the next stages of the build will throw a fit about outdated files.
Now that I've set the environment variables properly, things are humming along nicely. I've never written a SlackBuild or made a Slackpackage, being a new Slackware user, but I'm reading up on it right now. I'm not a total newb to packaging, though: I used to make RPMs for a little program I wrote.
All that said, the Xfce build documentation is the most clear and concise I have yet to encounter. Kudos to them. Now if only we could get Clem to write build docs for his little desktop environment....
I'm busy having fun at the moment, but there's more to come, Slackers.
UPDATE: Sadly, Xfce seems to be inconsistent in the way it sets its path- and prefix-type environment variables. Xfce-panel throws up red flags when it looks for Exo or Garcon, and it depends on both of these. I'll get this sorted later, but I think a pause is in order so that I might better pursue Slack.
I would love to hear what you think of what I've written, or what you'd like to read about in the future. Please don't be shy about commenting on this page or about adding me on Google Plus, where I share more geeky/Linux things and fewer personal things than I do on other social networks, so I'm more comfortable adding Internet strangers (please don't ask to join my other networks, strangers).
First, ralvex has written a SlackBuild for Xfce 4.10. All you have to do is untar the fat tarball and run his script in the directory above it. Now, your mileage may vary. Users at LinuxQuestions reported success with ralvex's script, but it didn't work for me. That said, I'm running Slackware64 + bits of Gnome SlackBuild + bits of Salix + a few modifications of my own design (I'll talk about this all in good time, friends). It may be something I've done that keeps it from running.
The build didn't go so well for me yesterday because I was tired and frustrated before I sat down to work on it. That said, with a little detective work, I found a place where the otherwise excellent documentation will lead you astray. The docs call for you to set $PREFIX before you get to building, but the Makefile looks for $prefix. So, if you've followed the docs precisely, your basic libs will get put in the wrong place and the next stages of the build will throw a fit about outdated files.
Now that I've set the environment variables properly, things are humming along nicely. I've never written a SlackBuild or made a Slackpackage, being a new Slackware user, but I'm reading up on it right now. I'm not a total newb to packaging, though: I used to make RPMs for a little program I wrote.
All that said, the Xfce build documentation is the most clear and concise I have yet to encounter. Kudos to them. Now if only we could get Clem to write build docs for his little desktop environment....
I'm busy having fun at the moment, but there's more to come, Slackers.
UPDATE: Sadly, Xfce seems to be inconsistent in the way it sets its path- and prefix-type environment variables. Xfce-panel throws up red flags when it looks for Exo or Garcon, and it depends on both of these. I'll get this sorted later, but I think a pause is in order so that I might better pursue Slack.
I would love to hear what you think of what I've written, or what you'd like to read about in the future. Please don't be shy about commenting on this page or about adding me on Google Plus, where I share more geeky/Linux things and fewer personal things than I do on other social networks, so I'm more comfortable adding Internet strangers (please don't ask to join my other networks, strangers).
Monday, April 30, 2012
Xfce 4.10
NOTE: I've written more about Xfce since this post. This was just the first day. The blog is searchable and tagged. Also, you can add me on Google+ for relatively frequent updates about all things Slackware.
Today marks the latest stable release of Xfce, the lightweight yet full-featured desktop environment. I won't rehash all the features until I can get my fingers on them myself. If you're curious now (i.e., before I write about it), you can check out their website or your favorite Linux news source for more information.
That said, a quick look over the repos indicates that neither Pat nor Alien has compiled a version of Xfce after the 4.6 release. No, not even slackware-current has a newer build. 4.8 was released a little over a year ago, around the same time as Slackware 13.37.
I don't know if it was simply deemed unready at release time or if there is a philosophical or technical reason for not upgrading. I do know that Xfce 4.8 broke certain features for BSD users and that it began the slow march away from HAL, which Slackware still installs and presumably uses. So, for some there may have been feature regressions. I doubt that will be the case for us Linux users, the main audience for the Xfce team.
Since there aren't newer binaries available, I will attempt to build my own in the next day or two. If it succeeds, I'll give a full feature writeup and make my Slackware64 binaries available as a single txz, as Pat has it now. So, you'll only need to remove one package and install mine. If demand from my readership of several calls for it, I can probably borrow time on a Slackware (32-bit) machine to build binaries from there.
Is anyone yet having fun on Xfce 4.10?
As always, I welcome your questions, comments, and requests for future posts, whether they are related to what I've just posted or not. Also, I promise a return to the ongoing narrative and fun sometime in the near future. I just have too many projects going at once to promise a regular schedule.
Today marks the latest stable release of Xfce, the lightweight yet full-featured desktop environment. I won't rehash all the features until I can get my fingers on them myself. If you're curious now (i.e., before I write about it), you can check out their website or your favorite Linux news source for more information.
That said, a quick look over the repos indicates that neither Pat nor Alien has compiled a version of Xfce after the 4.6 release. No, not even slackware-current has a newer build. 4.8 was released a little over a year ago, around the same time as Slackware 13.37.
I don't know if it was simply deemed unready at release time or if there is a philosophical or technical reason for not upgrading. I do know that Xfce 4.8 broke certain features for BSD users and that it began the slow march away from HAL, which Slackware still installs and presumably uses. So, for some there may have been feature regressions. I doubt that will be the case for us Linux users, the main audience for the Xfce team.
Since there aren't newer binaries available, I will attempt to build my own in the next day or two. If it succeeds, I'll give a full feature writeup and make my Slackware64 binaries available as a single txz, as Pat has it now. So, you'll only need to remove one package and install mine. If demand from my readership of several calls for it, I can probably borrow time on a Slackware (32-bit) machine to build binaries from there.
Is anyone yet having fun on Xfce 4.10?
As always, I welcome your questions, comments, and requests for future posts, whether they are related to what I've just posted or not. Also, I promise a return to the ongoing narrative and fun sometime in the near future. I just have too many projects going at once to promise a regular schedule.
Subscribe to:
Posts (Atom)