Showing posts with label fedora. Show all posts
Showing posts with label fedora. Show all posts

Friday, April 24, 2009

Linux Distribution Logos - An Interesting Collection

Happy Friday to everyone,

If you haven't left work yet (assuming you made the double mistake of waking up "and" coming in ;), here's hoping you can get out the door fast. I don't know what the weather's like in your area, but it's going to be nice and balmy around here for the next few days, after which it will, once again, be freezing cold and snowy (I love Chicago :)

I came upon this random collection of Linux logos on Tech Source From Bohol and thought it would be interesting to share. Most of these are just visually interesting. Some of them (like the logo for "Blag" Linux, which I didn't know existed and am dying to try out - yes, just because of the name ;) are a bit amusing. You be the judge. No one should have me as the arbiter of their taste ;) I've only included 20 of them because my bones are brittle and ...I just couldn't stand the copy and paste any more! ;)

Enjoy your weekend and enjoy the logos. Also, stop by Tech Source From Bohol and check out the rest of the 50-logo set, plus all of the other interesting articles and showcases they have over there :)

Cheers,







, Mike




Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!



Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Saturday, November 29, 2008

The Fedora Girlfriend Test - More Linux and Unix Humor

Hey There,

This Saturday's over-sized slice of, possibly funny, Linux humour comes to use via ITKnowledgeExchange. It's actually a review of an original article entitled "Linux: The Girlfriend Test" from TechRadar.com.

The test itself is fairly self-explanatory, but it's the account of one Linux writer's test of the user-friendliness of Fedora 9 using the perfect test subject: His girlfriend :) As the review of the original article notes (and this is one of the funnier parts, in my opinion), no mention was made of how the writer fared in the "boyfriend shopping test" ;)

Hope you enjoy this, and please check out the original article (a very interesting and funny read) that's referenced in the article below and a few paragraphs above.

Enjoy your weekend :)




Fedora gets mixed review in "girlfriend test"



Everyone agrees that the Linux desktop has a lot of work ahead to transform itself from a techie obsession to the intuitive, user-friendly desktop of a Macintosh or Windows machine. Even Mark Shuttleworth, founder of the popular Ubuntu Linux desktop, blogged about the shortcoming in a recent column and vowed to close the gap.


In the meantime, however, U.K.-based TechRadar.com recently published Linux: The Girlfriend Test, and a tough test it was indeed. The goal: to find out if a first-time Linux user, presumably a female college student, could accomplish nine familiar Windows tasks using Fedora 9, the community version of Red Hat.


Here are the tasks and how she fared on each one:

1. Bookmark a website in Firefox. No problem.

2. Write and print a letter in OpenOffice. The first part was easy but the letter wouldn’t print and no error message appeared with a reason or resolution.

3. Rip a CD. Task accomplished. But Fedora failed to identify all the output options.

4. Send an instant message. After several unsuccessful attempts, she succeeded by going to msn.com and inputting user data from her Windows Live Messenger account.

5. Create a pie chart in OpenOffice. No problem.

6. Transfer the ripped CD to her iPod. Attempt failed because of a protocol problem. Again, no error message appeared to identify or fix the difficulty.

7. Move a photo of her head onto a photo of her boyfriend’s body using Photoshop. Easy.

8. Watch a video on YouTube. Failed because Firefox was unable to install Flash player due to a malformed file. There was no work-around explanation.

9. Make an international phone call using Skype. Application installation was successful but audio playback problems prevented communication.


The writer concluded that Linux needs to do more with wizards and pop-up instructions to help new users without a technical background successfully transition from Windows or Macintosh to the Linux desktop.


I agree. But I have to say it was a pretty tough test, and the writer never mentioned how he fared in the “Boyfriend Shopping Test” that was his part of the bargain. Inquiring readers want to know.





, Mike




Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

Friday, June 13, 2008

Using NTSYSV To Manage Linux Services

Hey There,

Picking up where we left off in yesterday's post regarding using chkconfig to manage Linux run levels, today we're going to take a look at another common, and helpful, tool you can find on Redhat, Fedora and other such similar Linux distro's, named ntsysv. Actually, we'll be looking at two commands, since there's a slight dependency (which we'll get to befoe this post is over) between ntsysv and another command named service.

Click on the image below to see it in its unaltered state ;)

The intuitive user interface for ntsysv

ntsysv is a great tool to use if you like GUI-based interaction and aren't able to run an X-Windows session. Since it's basically a tty GUI (Sometimes referred to as a TUI), you can enjoy the graphical interaction through any terminal software that supports basic color in the shell.

You may also have noted, in the past, that the menu we created in our post on creating a simple menu using tput and ANSI colors looks eerily similar. This is only true at the base level, as our TUI menu was much more limited. Check out either of the above links for pictorial depictions of all the various very-portable colors you can use in the shell and some good information on how to make use of color in your Linux shell.

Back to ntsysv :) This command is very simple to use and can be invoked in only a few ways. The most common is without arguments, like this:

host # ntsysv

This will bring up the TUI, which should look roughly like the image near the top of this post. The contents of the ntsysv interface will probably differ, since it's populated with the names of packages (or services) that you have installed on your system and that it is able to control. The interface is very simple to use and the interaction basically consists of your either checking, or unchecking, the box next to the service name on any given line. When you exit ntsysv (by selecting OK or Cancel), all the services that have their checkboxes checked, will be considered active, and the unchecked services will be rendered inactive (see below for a small "gotcha" concerning ntsysv's specific behaviour in this matter).

By default, when you invoke ntsysv with no command line arguments, you'll be editing only the run level at which you invoke it. So, if your system is at run level 3 and you just run ntsysv, you'll only be editing the on/off functionality of services at run level 3. If you want to be more specific, and make changes across multiple run levels, you can specify that at the command line when you invoke the program, like so:

host # ntsysv --level 2345

The above, for instance, would bring up the same interface, but you'd be editing run levels 2, 3, 4 and 5 all at the same time. The other nice thing about this command is that, unlike using chkconfig to manage run levels you'll just be using your space bar (or mouse, depending on how you have your setup set up ;) to check and uncheck boxes, rather than typing on or off on a per-service basis. A workaround to that is posted in yesterday's write up on chkconfig, but ntsysv has that functionality bundled in. On the flipside of the coin, you can't use ntsysv to add new services. You only get to work with what the TUI shows you.

Some versions of ntsysv also have a --back flag that you can use to modify the look and feel of the Cancel button (in other words, it will change the text on the Cancel button to Back). Useful? You be the judge ;)

host # ntsysv --back <-- Note that this can also be used in conjunction with the --level flag.

And, for that "gotcha" I promised to deliver way back near the top of this post ;) This is something to keep in mind if you need changes to be enacted "immediately." ntsysv's default behaviour is to automatically start (or stop) a service, after you've select/unselected it in the TUI and entered OK. But, this automatic starting and stopping of services only works for services managed by xinetd.

If you, for instance, wanted to stop any service not managed by xinetd (which you can determine by looking for it in the /etc/xinetd.d directory), you would need to follow up your ntsysv session by stopping the service with the "service" command, like so:

host # service SERVICENAME stop

Of course, if you want to start it up, you'd use "start" in place of the "stop" directive (other options for the "service" command include restart, status, etc, and can be highly specific to the service itself since those directives are derived from the specific service's init script). If you don't do this, for services not managed by xinetd, your changes won't take place until run levels change in the appropriate manner (like during a reboot, for instance).

For those of you who've never used ntsysv, I'd suggest giving it a try. While it is limited, it's a great tool for getting tedious work done simply and can also be a great way to visually check on the status of services at any run level.

Enjoy :)

, Mike

Thursday, June 12, 2008

Using chkconfig To Manage Linux Service Run Levels

Hey there,

If you're like me, you've probably gotten used to creating init scripts and all the various linking to run level directories that needs to be done so that certain services will start and stop at the run levels you decide you want them to.

Even so, I'm always impressed with ways to make this sort of setup easier. Especially when it comes to manipulation of start and stop (init) scripts that come with system software. Solaris' mish-mosh of hard and soft linked run level scripts can be a headache, for sure, but Redhat, Fedora and other Linux flavours can be a bit of a pain, as well. The main problem I run into is making a customized change that ends up getting overwritten by an RPM upgrade or things of that nature.

Thankfully, that issue has been addressed, more than adequately, in a few ways. One of my favorites is the chkconfig command (usually located in the /sbin directory). This tool makes it very easy for an administrator to control at what run levels virtually every system-controlled service starts and stops.

Today, we're going to look at a few common ways to use chkconfig to make administration of run levels more convenient.

The first way is the most obvious. If you want to know everything that's going on with every service that's being controlled, simply type:

host # /sbin/chkconfig --list

and you'll get output similar to this:

acpid 0:off 1:off 2:off 3:off 4:on 5:on 6:off
anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off
...


An easy way to find out what services are "on" is to just pipe the above command to grep. If you want to know what's running "now" (or, at least, what should be ;), you can find your run level with the who command and then use chkconfig to find all the active services:

host # who -r
run-level 3...
host # chkconfig --list|grep "3:on"


or, if you're only interested in one service, you can specify it and chkconfig will query its state at your current run level, like so:

host # chkconfig anacron

More specifically (since that would only show you services that get started at run level 3, you could do this:

host # chkconfig --list|egrep '[123]:on'

and you should see all the services that are running currently (assuming your machine boots normally, through run levels 1 and 2, before getting to 3).

You can also use chkconfig to configure any listed service to start and/or stop at any run level you choose. You can even do multiple run levels at once. So, all of the following commands would be valid (assuming you have the service "anacron" on your machine):

host # chkconfig anacron on
host # chkconfig anacron off
host # chkconfig --level 3 anacron on
host # chkconfig --level 3 anacron off
host # chkconfig --level 235 anacron on
host # chkconfig --level 046 anacron off


Also note that on some systems, on and off only apply to run levels 2, 3, 4 and 5. Setting other levels may not work, but should not cause failure.

An alternative to on or off, is to use reset. This keyword will reset the service to start and stop at the run levels it defaults to (look near the bottom of this post to see from where chkconfig gets that information).

host # chkconfig anacron reset

Some simple scripting can make it so that you can replicate this behaviour for multiple services. At this point, to my knowledge, you can only either make changes globally or per-service. In any event, something like this is simple enough to work out at the command line (after checking out all of the services with --list, put the ones you want to start at runlevels 3 and 5 , and be turned off at all other levels, into a text file, one service per line). Note, that this is just my little command line script, and can be done a lot of different ways, so you should do this however makes the most sense for you:

host # for x in `cat MYSERVICES`;do /sbin/chkconfig --level 35 $x on;/sbin/chkconfig --level 01246 off;done

And the final (and most helpful, since it keeps you from having to remember how to format an init script to work with chkconfig) thing chkconfig does, is allow you to add and delete services. If your service isn't standard, you may still have to write your own init script, but for all packaged (and handled) services, this is a snap.

To remove a service that's currently active, just type:

host # chkconfig --del anacron

And to reinstate it, just type

host # chkconfig --add anacron

And, bingo, you're all set :) Note that the above add/del function really only creates and destroys symlinks from the init directory to the run level directories, so if you've deleted the actual init script, using chkconfig to re-add the service probably won't work. If you still have access to the RPM for that package, you can fix it to replace any missing files that way first.

If you do decide to create your own init script, and want it to be controlled by chkconfig, just make sure that you have these lines near the top of the script, in the comment section, below the shebang line and above any other comments in the script, like this:

#!/bin/sh

#
# chkconfig: 235 10 60


This part of the init script is what chkconfig looks for, and, in this instance, it tells chkconfig that the service should start at run levels 2, 3 and 5, it should be turned off for all other run levels (chkconfig's default assumption) and that it should have a start priority of 10 and a stop priority of 60. The priority numbers that you include in your script are relative and shouldn't generally be an issue. The defaults are usually 20 and 80. You can also add a "#description:" line (directly after the required chkconfig line) to your script if you want to be able to see that in chkconfig output, but it's not necessary.

Here's hoping this helps your run level management step up and get easier, all at the same time! :)

Cheers,

, Mike