Tuesday, October 7, 2008

On Developer - User Relations

There's a problem in the Linux user community that nobody seems willing to address - the pink elephant in the back of the room that nobody sees yet everybody smells. Here's the problem, in a nutshell: if you're not a developer, we don't want you. This isn't universally true, of course; and it's generally not the first reaction of any person you ask for technical support. The problem is this: when you have a real issue, the probability that you'll hit someone who is willing to provide a patch or script that can fix your problem versus someone who tells you how to fix the problem is astronomically low. It goes deeper than that, too: the average response to an end user with an update issue who doesn't want to code? "Wait for the next release." That's unacceptable, particularly when somebody COULD be coding a quick solution that effectively delivers the desired result in the interim.

Here's the issue, at its core: end users don't WANT to code. In the average day, if they have to see the URLs in a browser's address bar, that's enough CLI interaction for them. So why do we insist on forcing end users into the coding mindset?

There's something to be said for the heritage of Linux versus, let's say, the heritage of Windows. Historically, the more informed among software developers have sought to develop on the platform with the most technical freedom. This practice originated on System V, and has carried over to function-alikes such as Linux and BSD. Windows, as it exists today, is a concept based on the WIMP model introduced first by Xerox and made economically viable by Apple. At its core, it attacks an issue of apathy and ignorance - user-friendliness. Many of the people who use a WIMP interface neither know nor care how their system works "under the hood", they simply want to do what they're used to doing with it. Linux, on the other hand, has a long tradition among people who want to get their tasks done as quickly and efficiently as possible, so it should be seen as a failing of that model when users seeking an easy experience are met with the most grossly inefficient solution from their stance.

The simplest answer to this problem is to educate the populace, but it is hardly the most practical; many users are so entrenched in the anti-coding mindset that they don't realize that Windows, Macintosh, their TVs, microwaves, iPods, clock radios, many of the features on modern automobiles, any form of airline flights or scheduling, and so much more would be practically impossible without it. In the meantime, the easiest solution is this: don't push updates until they're ready. If you're of a mindset that you truly want to solve a problem for somebody else, get your hands dirty - if only in something as menial as BASH.

For all the good the Ubuntu Code of Conduct does, it lacks what I feel is one crucial if not obvious rule:
"If a real answer exists, mention it. DO NOT push updates until they're ready."

Saturday, October 4, 2008

Perhaps an Automated Setup?

Here's an older concept of mine, that plays on the wide availability of wireless drivers and ndiswrapper. Why not take the two, have a script that runs a dmidecode to determine system stats, then set up ndiswrapper correctly? It's hideous in its current form, but it can be refined and even lightened with the right review practices.

(Developer's Note: It's MONSTROUS, and I mean Frankenstein-style GROTESQUE. It's only designed to work with my system right now, and it needs to be saved as ndismart in order to function properly. Woe be unto he who runs this script without a Broadcom card.)

Monday, September 29, 2008

Spotlight: Starcannon (Ubuntu Forums)

Check out this guy. Every single one of his posts is a gem, with directions carefully selected and verified to do what the end user needs. This is the model of good technical support right here.

Starcannon, we salute you!

Profile | Contributions

The Trouble with Tribbles; or, Why It Takes So Long to Update Gtk-Gnutella

I want to apologize in advance for what I'm going to be posting on this blog in the future. I love Ubuntu, and I have yet to find a distribution that rivals it in both pure operation and the friendliness of its community. That being said, I think it needs to be clarified that "having a lovefest" should not necessarily be equated to "getting knowledgeable answers on the subject". That being said, I've only been on the scene since 2002 / Shrike, so I suppose I'm a relative newcomer (particularly if we go much beyond "BASH Scripting for Chores"), but I like to at least look into a subject enough to have an answer ready for a question that may never be asked.

That is in stark contrast to this thread. The user enters the forums, basically states that Gnutella cannot be updated to its latest version (0.96.5), and sits back. The first reply is perhaps misguided, but astute (particularly given the ineptitude of the average newbie): check apt-get again. The user does so, and returns back. The next viable solution consists of WAITING FOR THE NEXT RELEASE. I'm sorry, that may be an acceptable solution for people who have no need to update, but the understanding needs to be made that "ancient versions" of Gnutella are essentially blacklisted by 99% of the Internet population as "suspicious activity". It's completely subjective, completely unfair, and a practice that I fell victim to recently.

For the curious, out of more than 200 threads, here is the one post that correctly identifies and solves the problem: read the README. This isn't a difficult concept; after all, any good developer knows that people should enter the restaurant with the big neon sign that says "Joe's" if they want to eat at Joe's, right? Apparently not, and this is a downside to society in general. What's even more remarkable is that almost every single thread lacked even ONE post linking to the solution, even though even the thread in question was formed less than a month after the initial solution.

Bearing this in mind, is it really any wonder that Microsoft is merely concerned about Linux?

UPDATE: Here's a quick solution to the problem, that took me two hours to code - mostly because I forgot the proper orientation of escape sequences (*shudder*). Enjoy.

Of course, there are a few notes:
A. You can name the file whatever you like. The setup depends on an embedded temporary file with a constant filename.
B. The file needs to be given permission to run (chmod +x) in order to function correctly. Since it accesses apt for many of the requirements, it must also be run as sudo (at least until I figure out fakeroot a little better).
C. The "sleep 1m" line waits one minute for the download to complete. This works fine on most high-speed lines, but needs adjustment for sub-optimal (read: Dial-Up) carriers. If there's some better way to prevent execution of the next line until wget finishes its chore, I'm unaware of it.

UPDATE #2 (October 7, 2008): The "sleep 1m" issue has been fixed with a simple Do-While loop that effectively halts further operations until wget completes its task. Of course, being a BASH script, it will still need to be set executable and run as sudo.

UPDATE #3 (October 14, 2008): Here's the fix for some issues introduced the last time I tried to improve this code base. See what I mean about loathing escape sequences?


Raison d'ĂȘtre

How about that title? Sounds like a suitably profound name for a suitably profound blog, ne? Okay, maybe not, but here it is just the same. The average Linux newbie has ZERO clue why he just switched from Vista, or OS X, to this new system that seems to hide untold dangers around every corner. It's a simple enough problem: the user is merely ignorant of the inner workings, and many modern systems have worked hard to keep it this way. The danger, dear readers, is this: imagine a shotgun. Simple, clean, gets the job done when necessary. Now, imagine that same shotgun left aimed and loaded on a stool overlooking hundreds of innocents, or even millions. Imagine a child walks into the room and pulls the trigger without a second thought. A grisly scenario indeed - yet this is what many users are faced with every time they turn on a Linux-based system.

Why is that?

Well, the number one reason, is that there are literally so many ways of "doing things right" in Linux that many users - I'll use a thread regarding the process of getting any given program to work, on Ubuntu Forums - never get the answer they so desperately need. Often, the answer is of the form "wait until the next Service Pack" - an approach that is doing roughly as much good to help Linux as it did Vista. This is completely unacceptable, so this blog exists to chronicle every instance where this happens (or as many as I catch, at any rate).

If worse ever comes to worst, don't read the README. The package authors probably just put it there to screw with you, rather than provide legitimate instructions.