Linux Blog

PulseCaster

Filed under: Linux Software — TheLinuxBlog.com at 6:30 am on Wednesday, January 26, 2011

pulsecasterI stumbled upon PulseCaster while searching through Fedoras repositories, I was intrigued and had to give it a try. By the website this is the description:
“PulseCaster is a simple PulseAudio-based tool for making podcast interviews. It is designed for ease of use and simplicity. The user makes a call with a preferred PulseAudio-compatible Voice-over-IP (VoIP) softphone application such as Ekiga or Twinkle, and then starts PulseCaster to record the conversation to a multimedia file. The resulting file can be published as a podcast or distributed in other ways.”
It works really well for phone interviews or just recording that call you want to remember. I wouldn’t advise recording conversations without the other parties permission. I don’t know what the law is on that, but if you’re using it for its intended purpose (podcasting) then it serves its purpose. I actually used it to record the Asterisk Area Code Lookup Script.

When not to script it

Filed under: General Linux,Linux Software — TheLinuxBlog.com at 10:37 am on Wednesday, December 2, 2009

I’ve come across a number of programs in the past and thought to myself,

“Why didn’t they script this, it would be so much easier.”

After thinking about it for a while it all makes sense now. It seems that I had the shell script bug, everything must be done in the shell! In reality while the shell is great and all, it is not without its flaws. There are somethings the shell is great at and should be used for, then there others it shouldn’t.

Don’t get me wrong, I like to script as much as the next guy, but sometimes I think people get lost in its simplicity. Some people use it for everything without fail. Perhaps this is because they don’t know otherwise, or maybe because they too have the shell script bug.

There are many reasons to use the shell and I’m not against using it by any means. This is simply a list of when it may not be suitable to whip out the shell and start scripting. If there is any I missed, please add them in the comments and they may eventually make it into a revised post. I’ll do the same if I come up with any more. Onto the list!

Distribution / Portability – Ever try to distribute a script? Well, most of the time its not a problem, but sometimes you’ll get bit in the ass. Not all systems are created equal. Some have missing packages, or something doesn’t work the EXACT same way.

Simplicity – Sometimes bash is elegant. Well, it depends on your definition I guess. Some argue that scripting is simple, where as others that have to support or maintain it will be ready to cut you. I know I’m sharpening my shanks right now for some revenge. Seriously though, choose a language that makes it easy to K.I.S.S (keep it simple, stupid.)

Performance – Lets kick in the after burners. This is one I don’t have much experience in although I should probably look into it. The shell is sort of like a glider, it gets the jobs done, but I wouldn’t want to race it against a jet or anything. If you’re considering scripting, just time the process to make sure it meets your performance needs. Most of the time, if it is for you, you’ll be fine right? I mean you’ve got all of the time in the world and can wait overnight if you have to. I’d rather not, but have been known to wait on a slow script out of laziness.

Maintenance – Nightmare code. Dependency Hell. Some may have seen the t-shirt or heard the phrase,

“Programming is like sex; one mistake, and you’ll support it forever”

Yea scripting this is sort of like that, except you can always abandon and upgrade your scripts :)

Security – Keep it secure, there are many issues with security in shell scripts. We wont get into them now but if you wear a tinfoil hat when using a computer, you may not want to rely on shell scripts to do your top secret stuff.

thinkpad_handler ACPI Script for Lenovo T61 hotkeys

Filed under: Shell Script Sundays — TheLinuxBlog.com at 2:54 pm on Sunday, January 18, 2009

Lenovo T61 Thinkpad_Handler ACPI hotkey

This weeks shell scripting article showcases the modifications I have made to the thinkpad_handler script that normally resides in /usr/lib/acpid on an OpenSuse distribution. For any one not using a Lenovo T61 this may or may not be useful, however anyone interested in shell scripting can take a look at the file and see the simplicity of shell scripts that are used in production environments.

Here is my modified thinkpad_handler script

One of the reasons I chose to post this was because an OpenSuse upgrade broke my brightness keys support, so I figured it would be another good place to back it up while providing a reference. My modifications are very minimal at the moment, I still have a lot of work to do.

Here are my minor modifications:

Line 102 to add support for suspendon Fn+F4

Line 127 to eject /dev/cdrom on Fn+F9

I used to have a special script for Fn+F8 which enabled me to toggle support for the touchpad and track point mouse. Until I find that script I’ll endure excruciating mental anguish every time I accidentally hit the touchpad. I’ll have to make an update to this script once I change all of the other hotkeys for OpenSuse on the Lenovo T61 or other similar Lenovo notebook computer. I should also probably upgrade to OpenSuse 11.1 and see if that makes a difference in the keyboard shortcuts.

Until next week, happy scripting!

An rsync primer

Filed under: General Linux,Linux Software — TheLinuxBlog.com at 12:55 am on Tuesday, January 13, 2009

An rsync Primer

rsync is a great tool used to copy or “sync” files locally or remotely. Having just lost a fair amount of important personal data its good to make the point that you can lose data if you use rsync, so make sure that you know what you are doing works before putting it into production.
“Whats so great about rsync?”
I hear you ask.

Well, there are many ways of copying data around, regular old cp, scp and rcp but what sets rsync apart is that it’s capable of syncing those files that have changed, or those that are missing. In other words, why do a full copy of all files, risking further corruption when only some have changed?
rsync also handles compression and verifies that the files were written correctly.
The syntax for rsync is fairly straightforward, those of you familiar with the rcp or scp should be easily able to relate to that of rsync.

The syntax for a local file copy is:

rsync [OPTION...] SRC... [DEST]

-avz is the option that I use most commonly.

-a for archive, -v for verbose and -z for compression. As lame as it may sound, I actually remember the syntax for this as “Alien Vs. Zeus.” Sounds stupid, but it actually works.

Since I do not normally sync directories locally, one of my hosts is usually remote. rsync is configured to use SSH by default, but rsh can be used if preferred. I stick with the default SSH for simplicity. The syntax is very similar to scp’s

To Pull: rsync [OPTION...] [USER@]HOST:SRC... [DEST]
 
To Push: rsync [OPTION...] SRC... [USER@]HOST:DEST

If you like to back up all files matching a pattern the same syntax applies but you specify a pattern. An example is you could backup all .conf files from /etc (provided you have read access) to another host by doing the following:

rsync /etc/*.conf [USER@]HOST:DEST

If you do the above, I am assuming that you would also want to backup other configuration files within the /etc/ directory. Instinct tells you if you have read the man page to just use -r however you may want to just do a full backup as rsync with a pattern by default does not traverse into directories.

Compression is really a nice feature for transferring large amounts of data. To demonstrate the speed increases that the -z option gives my full /etc/ directory which is 48M. It took 0m12.671s with compression and 0m35.657s without. This was over wireless from a dual core 2GHz laptop to a 1.8GHz wired desktop, so your results may vary. Either way compression or no compression rsync is a handy utility that should be able to make your life of copying files around a little easier.

The New Gentoo

Filed under: General Linux,Linux Software — TheLinuxBlog.com at 9:23 am on Tuesday, July 8, 2008

I don’t keep up with releases of new Linux distributions really. If I did then I probably wouldn’t have time to write on this blog, but I noticed that Gentoo was released on Sunday the 6th of July (http://www.gentoo.org/news/20080706-release-2008.0.xml) I’ve never been a big Gentoo guy, I’ve dabbled with it but it never really caught my attention. I think it may be time for me to revisit Gentoo, at least in a virtual environment to check it out again. I do have a need for a small footprint, easy to maintain and expandable operating system. I have been using Slackware for simplicity and small footprint, but it is not the easiest to maintain or expand. Gentoo on the over hand can be configured well, updates easily and is pretty expandable through portage and emerge. The only thing that concerns me is the compile time, often the reason I want a minimal installation is for a project that has to run on less than adequate hardware. Using Gentoo rather than another distribution could be a problem since it seems like it takes for ever to install by copying and extracting files, let alone compile them.

Anyhow, have fun with the new Gentoo!

Package management on Slackware

Filed under: General Linux,Linux Software — TheLinuxBlog.com at 6:38 am on Friday, December 21, 2007

People complain that Slackware is hard to use. I don’t believe that thats true. I don’t think that its any harder to use than any other Linux distribution. I also believe that there is perfection in simplicity. Believe me that it isn’t the easiest to set up but once its up it is actually easy to update and maintain once you learn how.

Despite popular believe Slackware does have good package management software. The main ones that come to mind are slapt-get, slackbuilds, pkgtools, swaret and slackpkg. Below is a small amount of information about each of them.

I’ve never myself used swaret so I don’t know too much about it other than its a package manager that manages dependencies. I also know that a new version will be released soon. If your interested in finding the best package management for Slackware you might want to check swaret out.

slapt is a mashup of the two words slack & apt. Those familiar with Debian or Ubuntu will know apt-get is at the heart of these systems, slapt-get is a clone of this system. Its been in Beta since its creation but works perfectly. There are graphical front ends for this software. I personally don’t use it because I can not find a fast repository in my area.

slackbuilds are kind of like the Gentoo package management. They are distributed with the source code on the Slackware DVD. They are basically scripts that help compile the source code. Its pretty easy to use, for more information visit: slackbuilds.org

pkgtools are the base of Slackware package management. Basically it is a suite of utilities that you can use to install, remove and upgrade software. The best source I’ve found for finding extra packages is linuxpackages.net.

My favorite for updating Slackware is slackpkg. It uses pkgtools to install and remove packages. It comes on the Slackware CD’s / DVD’s in the extras folder and is pretty easy to use. Basically you install it, select a mirror from the config file and then run:

slackpkg update

Once its finished doing its thing you can then do:

slackpkg upgrade-all

This will start a fairly lengthy process of downloading and installing all of the new packages. Other options are available such as options to install new packages, remove packages revert to vanilla system and many more. One thing I have to caution on is updating to current. Its not as easy as upgrading from release X to slackware-current all the time. This is due to the different versions of GCC, glib, solibs and various other types of libraries. Always read the UPGRADE.TXT or at least have a back up of all of your critical data before attempting to upgrade.

There are a lot of options, if your interested in running Slackware I suggest you try them all and then use the one you like. If you don’t want to run Slackware because another distribution suits you better try not to use the “I don’t use Slackware because its hard to maintain” card.