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

[Edward Middleton <emiddleton@example.com>]

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