Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] State of "Linux" documentation [C&C]



Joe Larabell wrote:

On Tue, 10 Jun 2008, Stephen J. Turnbull wrote:

... My point is
that *unlike cars* almost all of what is under the paint (including
the metal of the hood!) of one GNU/Linux is the same as all the
others. So when "skinning" the system the distro vendors have done
their users a disservice by making it ever harder for them to see how
that is being done, or even for a geek buddy who has memorized the
manpage for ifconfig(8) on 6 different systems to figure out how eth0
gets its IP address.

When I installed my first Gentoo system many years ago, I was forced to make decisions on things which I never realized were even open to any decision. Who would have thought that there were multiple ways to write the system log -- or multiple versions of cron? Not just "versions" in name only -- very different implementations with different config files.


I picked syslog-ng and vixiecron. I'm satisfied with my choices but I'm not convinced any of the others would not have been just as satisfying. In fact, I'd be willing to bet someone out there is reading this and saying to themselves (if not to the list, eventually): "No... <whatever>-cron is far more advanced than vixiecron". And, given the number of years that have passed since then, they're probably right. But I know these tools
well by now, they work for me, I know the config format. Why change?


My point, I guess, is that there isn't quite as much in common under the hood as one might suspect. There is no "standard" for how ipconfig should work so when someone gets a new idea to make it work better, they write a new version. If everyone *else* thinks its better, the old one falls into obscurity. That leaves me free to pick whatever variation I like from the choices available at the time. And, presumably, someone does exactly that for each of the major distros. If all the UIs and config files were cast in stone, there would be no room for innovation.

The downside is that it's no longer possible (if it ever was) to document a complete "common" Linux system because everything but the kernel can be swapped out whenever something better comes along (in all fairness, the kernel can be swapped out too -- ie: BSD, etc -- but doing so takes the system out of the realm of the current "Linux" discussion ;-). About the only things for which there are *not* multiple implementations (AFAIK) are the compiler toolchain and the basic shell utilities like "cp" and "mv". And I suspect that the only reason those are common among all distros is because nobody has gotten annoyed enough at how they work to re-implement them to work any differently. But, if someone did, there goes that common Linux documentation out the window.

(New users, by the way, don't generally *want* to know about "cp" and "mv". Whether that's a good thing or not could certainly be debated.)

Having recently been a new user on another OS I can state what I was after. I knew what I wanted to achieve and I wanted to know which tools to use to achieve it. Did I have my preconceived ideas about what was the best way to do this? sure, did that stop me using other more effective tools? no. I would expect that most new users who don't want to know about cp or mv have had bad experiences with DOS. Should we pretend that cp and mv aren't the best tools in many situations, simply because some new users have had bad experiences with DOS?


There are multiple implementations of just about everything, including compilers, which is why learning about one distributions isn't particularly useful. All distributions get EOL and chances are, if you are using a computer 10 years from now, you will be using applications with different configuration files. Understanding something about your system and learning how to analyze and solve your own problems is going to save you far more time and make you a far more effective computer user then learning the solution to any particular problem.


On Tue, 10 Jun 2008, Edward Middleton wrote:

The point is that basically all computers are the same, at both a hardware and software level. If you look at Unix's they are all extremely similar.

Similar, sure. Alike, no -- not enough alike to not confuse beginners. Not when you consider the whole constellation of utilities that can easily be layered on top of the common kernel (which a beginner shouldn't have to deal with anyway). And if we're not talking beginners, then there's tons of books on various bits and pieces of the Linux infrastructure. Too much, in fact, to ever stuff into a single volume. So you have distro-specific hand-holding books to get you started and, once you start to grok the bits and pieces, you scan the O'Reilly catalog for in-depth material on the specific "common" pieces in which you're interested. I'm not sure how we could do any better.

Well it is easy to be confused when you don't know what you doing. The obvious solution to this is to get an understanding about what you are doing, which doesn't take a library of books or a deep understanding of every facet of the UNIX universe.


You can obviously learn about a particular Unix by focusing on the unique implementation of some features, which is what you will get in a distribution specific book. If you do this, every new Unix you learn will be a wonderful mystery ride, but who has the time for this?

When you've just unpacked your system and you're trying to get the printer to work, who has the time to read the entire sordid history of printing on Linux? For a beginner, it would be a disservice (IMHO) to give him much more than some screenshots, step-by-step instructions for the distro he has in front of him, and maybe an appendix called "Once you're ready to swim in the adult pool, read these...".

I would suggest that following advice similar to this is the reasons so many new users have ongoing problems moving from windows to a Unix system. It might be easier to tell someone what to do, but it just keeps them ignorant of what is actually happening and teaches them nothing about solving their own problems.


Also, one could argue that if you end up buying more than one of these distro-specific books, you're probably not the type who's likely to learn the common stuff anyway ;-).

You can always argue ;)

Edward


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links