Tuesday, November 17, 2009

Blog Revamp

No, I didn't die; unlike a solid third of my family in the past month alone, I'm still around.

Look for a complete redesign of this blog in the days ahead, along with a new domain.

Wednesday, April 15, 2009

Open Source versus Proprietary Software

Much ado has been made over the adoption of open-source software in government operations, and how that potentially impacts the adoption of proprietary software in the private sphere.

There are two primary issues that I see with this interpretation of events:
1. Government operations need to run with as much transparency as possible, so as to work in the citizens' interests.
2. Private sector businesses tend to follow the actions of larger, public sector businesses. The latter category includes the government.

Enough text has been typed - oftentimes half-baked, seldom fully-formed - on both sides of this issue to fill the libraries of the world many times over. The simple fact of the matter is that government should use the most open solution to any given problem possible to remain accountable to the public. If those solutions are polished enough to be adopted by the general public, then perhaps those are areas where proprietary solutions deserve to fail. The effective lifetimes of proprietary solutions should not be artificially kept afloat, lest public standards grow stagnant and obsolete. Many a government web site has fallen by the wayside simply because the administrators decided on a decades-old management model, then fell victim to proprietary lock-in that kept it from being developed into the ruthless model of efficiency that - as a government site - it should be.

I take issue with the notion that open source software costs proprietary software in the public sphere. Under any circumstance, source transparency must be maintained to provide governmental transparency. Despite all that I've implied, what happens in the private sector need not affect the public sector, nor vice-versa.

Monday, April 6, 2009

Spotlight Categories

A great deal of technical assistance has been rendered to the general public on Ubuntu Forums in the past two months. As such, I'm proud to introduce the new Category setup for my Spotlight: Ubuntu Forums section. The categories shall be as follows:

* Glaring Spotlight (for items of personal concern)
* Question of the Month (for overlooked questions that should be relatively easy to address)
* Technical Spotlight (for those who provide the best technical assistance for Linux)
* Gaming Spotlight (for those who contribute to gaming on Linux)

The general idea is that areas that need to be addressed will be followed by those who address issues particularly well, so as to end on a positive note.

Monday, February 23, 2009

Sigh... Time for a Good Rant!

http://www.zdnet.com.au/insight/software/soa/Is-it-Windows-7-or-KDE-4-/0,139023769,339294810,00.htm

Okay, anyone bothering to read this, listen up. Windows 7 is a real threat, KDE 4 is making real inroads for GUI usability issues, and ZDnet is a bunch of idiots for not passing that knowledge along. Here's another one: hardcore Windows gamers, shut the hell up. I get that you HAVE to have the latest and greatest titles running at optimal efficiency, and that even a two-day wait (take a gander at the WINE AppDB times on major titles some time) would make you commit seppuku. The world doesn't begin and end at a damn EXE. Don't get me wrong here, I think the average computer user wouldn't know Linux from a hole in the wall, but the simple fact of the matter is that you guys are in the minority. The average user just wants to email, type, and maybe watch a few DVDs or kick back to some tunes. Anyone that thinks Linux can't do this - and do this easily - obviously has ignored distributions like Ubuntu and Mint, as well as the progress on Firefox, Evolution, OpenOffice, mplayer, VLC, amarok, gtkpod, and a whole host of others. The ignorance of those who not only desire, but demand the latest gaming titles should not be used to justify the dismissal of throngs of technological neophytes.

Where is Linux failing? Gamer fanboys who honestly have nothing better to do than criticize anything that isn't Microsoft's latest pandering to their interests. Incidentally, Gabe Newell - that name should be familiar to anyone playing ANYTHING based on DirectX right now - blasted Microsoft for locking DX10 to Vista. You remember Vista, right? The bloated turd that took another few hundred megs worth of a six-month patching effort to be considered reasonably usable?

Where is Linux succeeding? The server room, and the desktop is next. To hell with your pissant laptop (mine worked after some futzing around with ndiswrapper for wireless, which really ISN'T as big a deal as some might say, and certainly less strenous than trying to get the drivers for that cheap, junky MP3 watch you just scavenged off Lian-Li to do their job), the future of Linux is on professional workstations, a realm which is held by Microsoft in homes, and Apple in any serious A/V studio.

The simple fact of the matter is that change is around the next bend, and that scares the fanboys, who have to keep moving the goalposts for adoption farther and farther back. Should Blackcomb/Vienna live up to publicised DRM shortcomings, will they then still back Microsoft over a simple majority, rather than a complex one that discards several other players?

Friday, February 20, 2009

Spotlight: Taurus (Ubuntu Forums)

In light of my last post, I'm considering making this a monthly "feature" of sorts. Each month, I intend to highlight the parts of the Linux community that seem to be working (to some extent), and exactly what they're doing right. This month, I've selected Taurus of Ubuntu Forums to receive this honor. Okay okay, he's just another Linux nerd, right? Well, I think you should see for yourself - he's not condescending, he knows the subject matter, and he's genuinely helpful. This is the perfect example of what Linux support should be; were I to nominate him for specific support teams (see my previous post), he'd be up for General Implementation (Thorough) with potential inclusion in a Java Implementation Team and Drive Configuration Team.

Taurus, we salute you!

Profile | Contributions

Monday, February 2, 2009

What's wrong with Ubuntuforums?

Well, in short, nothing's wrong with Ubuntuforums; on the other hand, everything's wrong with Ubuntuforums.

Say what?

There's nothing wrong with a large community of people attempting to help one another out with an alien technology. Absolutely nothing wrong whatsoever. However, the problem exists where each member is considered as credible as the next in all given subjects, since there are multiple ways of getting things done in Linux and a number of ways to find out the solution to any given problem. There is a fundamental flaw that needs to be addressed here. Every human being is physically capable of discovering some way of making brain surgery work, regardless of what impediments they might otherwise have in life. Does that mean all people are well-suited to being brain surgeons? Absolutely not. Some are better suited to mechanical work, and still others are more adept at handling social issues. This is why we have Presidents, technicians, and grocery baggers. So what happens when everyone tries to solve the problems of others with no central authority for the relative validity of those "solutions"? In short, Ubuntuforums.

That being said, there are a few basic steps that can be addressed to improve the overall workflow on Ubuntuforums, some of which Canonical has already addressed in the formation of certain core teams. Here is my proposal: take this to its logical end, with teams that have greater experience with certain parts of the system being differed to first. Here's an example to see my point:

Current situation: Sally is having issues with her BlueTooth connection between her cellular phone and PC. She enters Ubuntuforums and posts a question regarding the issue. A number of replies are issued, with everything from a really technical answer to a simple "change your distribution". The actual answer that she needs is eventually lost in the flurry of frustrated replies, where insults get levelled. The answer may be elsewhere on the forums, but she never sees it. Sally leaves the Ubuntu community, frustrated and confused at the complete lack of help even though somebody posted the "right" answer.

Proposed situation: Sally is having issues with her BlueTooth connection between her cellular phones and PC. She enters Ubuntuforums and posts a question regarding the issue. A number of replies are issued, with everything from a really technical answer to a simple "change your distribution". A member of the BlueTooth stack team notices the issue, fixes it, and top-posts a solution to her issue and the thread is closed; failing that, a conversation begins between Sally and the BlueTooth stack team with appropriate information being provided to fix her issue; failing even that, the issue is handed to the BlueTooth implementation team, who works with Sally to attempt to solve her issue. When all else fails, the continuing dialog between Sally, the teams, and the general public attempts to find a solution to Sally's issue. That way, everyone can contribute, but people will be looking to people with experience in a particular field first. Once an acceptable answer to the issue is discovered, it is top-posted and the thread is closed.

The basic concept here is that discussions that are vital to development can take place, but the solutions are made obvious as soon as they're available. Perhaps that can make Ubuntuforums a nicer, more informative place to visit for all.

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."