Linux inconsistency and resulting confusion I'm thinking of setting up a "webcam" on my Linux system, and the
runaround with the howto's is reminding me of what really gripes me
about Linux. It's so bloody inconsistent.
I thought it would be simple ... just google for "linux webcam" and do
whatever the HOWTO's said to do. But the problem is half the
information I'm seeing doesn't apply to the specific system I have
(ubuntu 5.10 ... I'll note in passing the ubuntu wiki has a page that looks helpful,
but I want to demonstrate the general problem).
The first result is Debian Linux Web Cam
Server Configuration, and since ubuntu is debian maybe that's
the best for me. Nope. Okay, it says that for Sarge
you can probably just plug the camera in and it will work. I
think 5.10 is based on Sarge, but really don't know that (all these
code names tend to obfuscate matters). In any case the
document doesn't describe what to do if the camera isn't automagically
recognised. The document spends a lot of time talking about
stuff that isn't on my system, and/or not appropriate for my
system. e.g. modconf doesn't exist on this system, but
lsmod does exist
and does what the author of that document says modconf would do (I
think). And the problems with the article don't stop with
modconf but go on
to a a whole slew of low level device configuration, module
configuration, trouble shooting and whatnot.
Next is WebCam under
Linux which also
focuses on Debian Sarge but has a completely set of advice, and focuses
on one specific driver. Why? It does mention an
application at http://motion.sourceforge.net/ which automatically detects motion,
which looks like a good security camera feature which I hadn't thought
of.
At LinuxDevices.com they have an announcement of a live
demo webcam run by someone with an office in Manhattan. But
since the announcement is from 2000, I doubt it's still there.
There's some Webcam Installation Notes which don't
mention what Linux system they apply to. It just dives right
into installing software. My experience with Linux systems is
the various distributions are so completely different from one another
that you really need to know which one you have, versus the
distribution a specific HOWTO author had, so that you can interpolate
their instructions for your system.
There's an
announcement that development of the PWC driver has
halted. This is important because the PWC driver
figures heavily in one of the documents above.
linux.com has a howto on webcams. You'd think a
site named linux.com would have a definitive howto, and it probably
is. Again it dives right into low levels, talking about
installing modules, drivers, and whatnot. Oh, and a large
part of the document is about identifying which camera you have, and
what drivers will be suitable for it. This is where I learned
of the lsmod
command I mentioned above. But the examples list usb-ohci as a module,
whereas on my system this module isn't present, and I don't know
whether to be alarmed that it's missing.
The
ZC030X Webcam Linux Driver Project page has
a warning that this project is inactive, and you should use a different
one instead. Over on that page it has a "Jan 1,
2006" date which gives me a feeling it might be actively
maintained. But I'm beginning to feel like I'm in a maze of
twisty passages all alike, but there's no treasure to be found.
The Video For Linux Resources page looks to be
a great overview listing the dizzying array of choices. It's
more than a little displeasure that it starts with a long list of
driver projects. I mean, with so many different drivers, it
looks like a daunting task to figure out what's what.
And then after that the google results become even less useful so
I'm stopping here.
My point is that none of the
results I found did a really good job of describing simple steps to
take to get a webcam running on Linux. Most especially none
of what I saw gave me a clue to solving the specific thing I want to
do, which is videoconferencing. Instead most of the verbiage
I had to wade through was about low level grunty driver talk, and very
little about what useful purpose you might have for having a webcam on
Linux in the first place.
Along the say I did
learn about one idea I hadn't had before ... so this excercise hasn't
been a total loss. The idea of using Linux to run a security
camera setup is very interesting.
The results only confirm what I've said before. The thing hampering Linux's success is the wild differences between linux distributions, the lack of simplicity in using and configuring linux systems. The differences and inconsistencies only create confusion when someone tries to do something. e.g. Which HOWTO do you believe? What resource do you look at for advice? And why does the HOWTO I'm looking at talk about files and commands that aren't present on my system?
I've been using Linux off and on since 1993. Most of the time I've been not using Linux specifically because of these problems.
(2006-01-19 12:18:26.0)
Permalink
A look at another corporate blogging guideline in mid-development
Here's an interesting peek into how another corporation is starting to
encourage their employees to "blog". Corporate Blogging Guidelines, Draft
#2 What's most interesting is they apparently are
revising their blogging guidelines based on input from the
public. If that's not an exercise in transparency, I don't
know what is. On the other hand it's clear they have a degree
of the top-down approach to encouraging blogging, what with a BOC
(Blogging Oversight Committee) made (it seems) of executives.
The guidelines themselves appear to be
reasonable. It does contain the typical double message of
openness and transparency while guideline #7 admonishes the employee to
"keep
secrets". Sigh. Blogging and
transparency are such a challenge to "business as usual" where BAU
includes the corporation keeping most of its activities secret
...
I expect the employees reading those
guidelines to be just as confused as I am ... just what items of
information are we to keep secret, and which are free to be
shared? Confusion like this always comes when there's a
double message. The prototypical double message comes, for
example, with your parents claiming "I love you" while at the same time spanking
you. In this case the employee is asked to be open and
transparent, but if they're too transparent they'll get a modern
corporate form of spanking, and compounding the problem is the line
isn't terribly clear as to what's to be kept secret and what
isn't.
The most interesting thing about their
policy is something they aren't doing. Rather than host the
employee blogs as a company service, they ask the prospective blogging
employee to set up a blog using a public blogging service.
Once they have it configured to their liking, they email the B.O.C. who
will, if it meets the sniff test, enter it into the company blog
aggregator.
This greatly simplifies
the company's IT requirements, because blog aggregator
software is simple to set up and it pretty much runs itself once it's
going. It puts a little burden on the employee, but probably
not too great. The blogging services do a great job of making
it simple for people to get started in blogging.
It's an interesting form of outsourcing, isn't it?
They're pushing what could be a corporate expense over to third
parties. It's worth pondering for a few moments whether this
(hosting the employees blogs) is an expense which the company should
rightly spend, or whether it's "okay" for them to push it off to third
parties.
The only solid result I come up with is the loss
of inbound links. As the company's employees make postings
they will occasionally get links from elsewhere. The
technical term is "inbound links". Inbound links help
somewhat with search engine ranking.
By having
the employee blogs hosted elsewhere the inbound links will help the
search engine ranking of the blog host, and not the
corporation. If, instead, the corporation hosted the blog
themselves, the inbound links would help the corporation.
Another solid idea that arises is, what happens when
an employee leaves the company. This question comes up from
time to time on Sun's blogger email alias. Do we remove the
departed employees blog entirely? Do we leave it there, but
prevent further posting? Do we allow the former employee to
continue blogging? And, finally, how can we robustly connect
employment status with the above decisions?
By
having the employee arrange hosting, the questions are
simplified. Clearly when an employee leaves the company they
can be easily removed from the company aggregation. The
former employee can continue writing their existing blog without muss
or fuss. I'm wondering what the former employee should do
with old postings about their old company? Leave them
there? That's probably up to the individual, and it's clearly
not covered in the policy.
The HR systems which
register whether an individual is an employee, or not, may not be easy
to connect with other systems. In fact there may be laws
preventing such connection. How is the IT department to know
when the employee has become a former employee? Hence, when
or how will IT know when to remove that former employee from the
company blog aggregation?
UPDATE: I forgot to include a thought. Perhaps there's a worthy business to pursue in providing a complete corporate blogging service to corporations. Setting up a blogging service is probably outside the competency of the typical corporate IT department. Even though it's not terribly hard to get expertise in installing, configuring and maintaining a corporate blogging service, some corporations clearly will want to outsource it.
(2006-01-19 09:31:09.0)
Permalink
