LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Blogs > Musings on technology, philosophy, and life in the corporate world
User Name
Password

Notices

Hi. I'm a Unix Administrator, mathematics enthusiast, and amateur philosopher. This is where I rant about that which upsets me, laugh about that which amuses me, and jabber about that which holds my interest most: Unix.
Rate this Entry

Thoughts on problem solving for new Linux users

Posted 02-02-2009 at 12:40 PM by rocket357
Updated 02-03-2009 at 09:05 PM by rocket357

One of the hardest issues to grasp for many Linux newbies is not a Linux issue, rather it's their problem-solving approach. With the closed-source Windows business model, you really only have one problem-solving option available: tech support. While members at sites such as LQ do their very best to provide something like tech support, there really is a lot more that newbies can do to speed up both their understanding of Linux and finding a solution to whatever problem they're looking at right now.

First and foremost, there is almost always an "obvious" fix. I don't mean the solution is obvious, I mean what needs to happen is obvious. For instance, it is NOT obvious that line 987 of some_src_file.cpp needs to be modified, but it IS obvious that the compiler pukes when trying to compile said source file. From that, you can gather that fixing the source file is the obvious approach...but not always the best approach!

Now, the first thing to remember is:

1) Problems can be fixed on multiple levels

At the absolute lowest level, you can simply not use that package or port. Hardly a solution, but it *does away with the issue* all the same.

At a slightly higher level, you could search for a different build of the same package (you don't have to use the default debs or what-not...OpenBSD even includes what they call "build flavors" for pre-compiled packages, so check if your distro's package manager has similar capabilities =), or you could try to use a different *version* of the same package.

Or, you can find an alternative package that provides the same or similar functionality. Sometimes this works, sometimes it does not.

Moving up a level again, you could search for a known fix to the issue. Probability states that somewhere, at some time, someone has experienced this issue. If you're lucky, they may have even come back to the forum or mailing list or whatever and posted the solution (side note: if you find a solution to something, ALWAYS post the solution! Don't just wander off content that your machine is fixed!).

At a higher level yet again, you could actively inquire about a solution. This level hurts more newbie feelings than any other (especially if alternate routes haven't been tested by the newbie) because developers tend to fire off "RTFM"s if a newbie's question is along the lines of "how do I install package X?" If the problem isn't "I don't know how to install package X", then ask more verbosely: "When I go to install package X, I get <blah blah> errors". If the problem really is that you don't know how to install the package, read the README, google it, search your favorite forum, etc... before asking the question. Linux projects tend to come with documentation, so please use it.

Higher up from that, you could dig in to the problem and see if you can figure out problem characteristics yourself. Try to figure out if the problem is distro-specific. Perhaps the problem is *version-specific* for your distro. Test the same scenario under different distros and versions (this can be easily accomplished with VMWare Server/VirtualBoxOSE/etc...) Armed with this knowledge, it's typically easier to ask a question in such a way that developers and forum gurus can pinpoint the problem (and perhaps even explain *why* the problem occurred) and provide a solution much faster.

At perhaps the highest level of problem solving is digging into the code and finding out what the hang-up is. It really does seem intimidating, but this is the "gold-standard" of problem solving. A user capable of providing even a line number and basic description of the problem will certainly get more help than one that asks a question that's covered in the FAQ.

And if you can *fix* the problem and provide the developer with a patch you're worth your weight in gold...

To continue on:

2) Problems can be fixed in more than one way

I was involved in a project where a very large closed-source project was being modified to interact with another large closed-source project. There was a step involved that required the two projects to "synchronize" with each other. The synchronization would tell the first application which location to write metadata to for the second application. Sadly, the synchronization would sometimes fail, and metadata would be written to the wrong location. Since the locations contained the same data (just timestamped versions of each), writing metadata to the wrong location didn't hurt, but not having it in the *right* location caused problems. So in a meeting the lead developer was giving quotes on how long it would take to hunt down the synchronization bug, fix it, and roll it out to customers. He expected the entire process to take six+ weeks, and management was pissed.

I took a deep breath (I was a *VERY* junior programmer at this point), raised my hand, and asked why we couldn't just write the metadata to *ALL* locations, since the metadata update had virtually no overhead. The room fell silent, and I had a very rough time over the next eight weeks (lead dev was none too happy that he'd told senior management it'd take us six weeks to fix, no other way around it, and some programmer intern come up with a solution that could be implemented in 30 seconds). Ahh well, you win some, you lose some.

The important thing to keep in mind is that the problem can be solved in ways other than the "obvious" fix.

3) Ask yourself: is this really a problem?

Sometimes you curse and fret and stew over an issue only to find out it really wasn't an issue. While many times this isn't the case, for tough problems it sometimes helps to step away from the issue for a while. Sometimes you have to step away from the trees to see the forest, in other words. Perhaps there's a big-picture solution that works better for you anyways, and you wouldn't have seen it while stewing and fretting over the original "problem". Better yet, ask yourself if what you are trying to accomplish in-line with what the software was designed and intended to do? If not, perhaps you should rethink what it is you'd like to accomplish.

4) Beware of interactions.

Some problems *only* arise when two or more components are in place to interact in a negative way. A failure in one component doesn't necessarily mean it's at fault. Dependencies and "neighbors" can cause problems, (albeit not so much in the *nix world as in Windows, IMHO).
Posted in Uncategorized
Views 1466 Comments 2
« Prev     Main     Next »
Total Comments 2

Comments

  1. Old Comment

    Nicely put...

    ...thanks!
    Posted 02-03-2009 at 03:07 PM by SrDorothy SrDorothy is offline
  2. Old Comment
    Very nicely put.
    Posted 11-04-2009 at 08:35 PM by ofaring ofaring is offline
 

  



All times are GMT -5. The time now is 10:56 AM.

Main Menu
Advertisement

My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration