Linux instructions

Have you noticed that a lot of instructions on how to do things in Linux are a bit like this picture:-

Funny :grin: :grin: :grin:

I've found man pages come in two lengths:

Usage:  command [-vrxtasjagelnh] infile

See also:  ....
Authors:  ....
Usage:  command [-alnvergh] [-c config] infile outfile

Synopsis:  When I was a young child, my father would bring me along as he hunted for quail.  It was through this early bonding opportunity that I first discovered the ordered rhythm of life.  And so, I began a decade-long journey to devise the ideal algorithm for coordinating the venerable timer (as you might find in /proc/kernel/....

<425 pages later>

... and so you may wish to correlate the oscillation of rubidium to the polling frequency with which you query the server, or otherwise tune the COSMIC_QUANTA_MANIPULATION field to a suitable integer between 7 and the natural log of ....

For the love of... I just want to know how to synchronize the system clock to my time server on boot-up... =( This has got to be a common scenario! I could've written my own driver by now!

SirNickity:
I've found man pages come in two lengths

If you want a real fun one to read, check out the man page for "sudoers" (ie - the list of sudo users, more or less).

That file has a particular "grammar" behind it, described in something called "Extended Backus-Naur Form (EBNF)"; because I imagine most people have no idea what that means, the author of the sudoers man page decided to stick a "Quick guide to EBNF" in the middle of the man page.

It's not that it is long, it's just that it is weird and dense - a strange little bit in the overall landscape of *nix...

:slight_smile:

SirNickity:
For the love of... I just want to know how to synchronize the system clock to my time server on boot-up... =( This has got to be a common scenario! I could've written my own driver by now!

Also, honestly - this doesn't look that difficult (mind you, I've never tried):

Grumpy_Mike:
Have you noticed that a lot of instructions on how to do things in Linux are a bit like this picture:-

What I have found in my years of linux (been playing with it since 1995 or so) has been either instructions/tutorials to solve an issue tend to be extremely dense (verbiage, or just a lot of steps, or both) - or that they feels like a LISP program (at every turn, there is something different to do, nested lower - and in many cases a lot of dependencies to fight over until it comes back together at "the top").

Yes - sometimes I have run into the "draw an owl" scenario, but more often than not, the above two scenarios seem far more common to me.

Not that I mind - in fact, I enjoy it to an extent. I look upon it as a puzzle to solve - and most of the times I manage to get it figured out (often forgetting why I was there in the first place!). Part of it stems from my personality (and/or lack thereof), but part of it had to do with my masochism of one of my first linux installs a long time ago:

Turbo Linux 2.0 on a 486 laptop with 8 meg of RAM; I had to learn not only how to install it, but also how to re-compile the kernel in order to get the sound card, PCMCIA slots, and other peripheral devices all working properly. Ultimately, I got it done, but not without a lot of reference to man pages, the internet (over a modem back then), and more than a few books.

If that didn't scare me away, nothing will (actually, I had a small amount of prior Unix experience under my belt, so I wasn't all that unfamiliar with the "density" of *nix)...

cr0sh:
Turbo Linux 2.0 on a 486 laptop with 8 meg of RAM; I had to learn not only how to install it, but also how to re-compile the kernel in order to get the sound card, PCMCIA slots, and other peripheral devices all working properly. Ultimately, I got it done, but not without a lot of reference to man pages, the internet (over a modem back then), and more than a few books.

I make my first encounter with Linux in the late '90s, with SUSE Linux 6.something.
I had an average PC so I didn't have problems to install it. But when I tried to install it on my girlfriend's machine, a Pentium I 133 (maybe...) I stucked with the sounc card of her PC, a Creative SoundBlaster32, if my memory is correct... No sound. No module in the default kernel. So I passed several hours recompiling the kernel to add the modules to support it.. and finally I got it. :wink:
Ahhh. the good old days :stuck_out_tongue_closed_eyes:

cr0sh:

SirNickity:
For the love of... I just want to know how to synchronize the system clock to my time server on boot-up... =( This has got to be a common scenario! I could've written my own driver by now!

Also, honestly - this doesn't look that difficult (mind you, I've never tried):

Time Synchronization with NTP

It's isn't, really. This is probably a bad example, but it's inspired from a real life event:

The NTP package maintainers are threatening to remove ntpdate from the distribution. "This functionality is now available in the ntpd program ... after a suitable period of mourning, the ntpdate program is to be retired..."

Now, if you didn't already have ntp.conf set up for continual synchronization or time serving, the procedure has effectively changed from a simple "ntpdate some.ntpserver.com" into an exercise in configuring permissions and one-executable-to-rule-them-all-ness. Not a very Unix-like philosophy (do one thing, well), and otherwise not an improvement in any meaningful way.

Since I literally just wanted to set the time, once, and get on with what I was doing, I ended up using the manual "date" command instead. I just needed the clock to be in the right year.

SirNickity:
The NTP package maintainers are threatening to remove ntpdate from the distribution. "This functionality is now available in the ntpd program ... after a suitable period of mourning, the ntpdate program is to be retired..."

The reasoning behind that is because there's no one to maintain the code and it's fallen into disrepair over the years. So you could say it's being dropped because all of its users are too lazy to take it on and fix it up.

If you look in /usr/doc/how_to, there are more than a few pages that have

"....the the the..."

this should tells us the author typed them just before dawn, after WAY too much coffee

Keep in mind, he may just have had a stutter.

I hope I understand the main point of this discussion and that is: man pages for gnu/linux tools are not a good resource for beginners.
as far as I know, man pages are not intended to be the primary resource to learn new things (i.e.,, they typically lack examples which is a crucial feature for newcomers), man pages are designed to act as exact reference for the linux tool/binary (specification).

To use man page to learn e.g., vim compares to use npn transistor datasheet to learn how transistors work.

It's not specific to man pages, I don't think. I've read several walk-throughs that were intended to be consumed by beginners, and had lots of step by step instructions before turning into something like: "Then edit your network configuration files as necessary."

Part of it is the experience gap between the user reading the guide, and the programmer / enthusiast writing it. It's hard to know or remember what things are going to go over the heads of an inexperienced audience. Then there's the complexity of a modern Linux system, where you could be doing any of a hundred different things. Documenting them all, exhaustively, without reading like a Choose-Your-Adventure novel would be a considerable undertaking. There's also laziness, as the author runs out of motivation after writing five pages of elementary text.

SirNickity:
It's not specific to man pages, I don't think. I've read several walk-throughs that were intended to be consumed by beginners, and had lots of step by step instructions before turning into something like: "Then edit your network configuration files as necessary."

Part of it is the experience gap between the user reading the guide, and the programmer / enthusiast writing it. It's hard to know or remember what things are going to go over the heads of an inexperienced audience. Then there's the complexity of a modern Linux system, where you could be doing any of a hundred different things. Documenting them all, exhaustively, without reading like a Choose-Your-Adventure novel would be a considerable undertaking. There's also laziness, as the author runs out of motivation after writing five pages of elementary text.

This where distros like Ubuntu come into play.
If you've wrestled with Debian or (god forbid) any redhat distro, installing and running Ubuntu feels like you're back in ME land.

My first Linux system was a DX4-100, which is still running Potato and DR-DOS, configuring things like X was a bit of a trial, the network stuff was easy, right up until I tried using samba to get the 'doze machines into the fray.
Netatalk, for the older Mac's I have was pretty simple, but I never did get the bridge on the Mac side of things to work, which meant the Linux and 'doze machines couldn't print directly to the LaserWriter.

I'm really not sure why a "beginner" would run vi or emacs, right from the get go I always used MC's internal editor.
That being said my mate who got me into Linux threw me in the deep end straight away by getting me started on compiling a custom kernel.

With ANY Linux package compiling starts with

./configure

from there you get to see if all the tools are there and working, you follow it up with

make

for a kernel it's

make bzlilo modules modules_install

Things are a bit different with grub, but it's a similar process
Compiling quake(n) or mjpegtools or what ever is a similar process.

But it's not something a beginner is going to NEED to do, not unless you have a video capture card or get into SDR or something.

It is actually quite hard to really "break" a Linux system badly enough you will need to re-install.
As for man-pages being hard to read, I don't get it.
Most man pages and the newer doc system have groovy little examples right at the end.

Under a Debian based distro, either vanilla Debian or Ubuntu, go to your package management weapon of choice, install the Linux How To's, there is some great reading in there.

These days configuring X, CUPS and a network is a hell of a lot easier than it ever has been.

cyberteque:
for a kernel it's

make bzlilo modules modules_install

You should be doing "make deb-pkg".

Chagrin:

cyberteque:
for a kernel it's

make bzlilo modules modules_install

You should be doing "make deb-pkg".

maybe in new versions, but this is potato, still using lilo rather than grub

I get that you can change a running kernel but I've never tried

As a Gentoo user, I've always compiled my own kernels. You have to know a lot about your hardware to make it work, and be on top of the constant changes. It can be enormously frustrating to start building a desktop system, then get stuck in a text-mode shell for two days while you figure out what the !%$* the X guys have done to break compatibility with the way you used to build your in-kernel video drivers.

Well, in general, video drivers are about the worst thing about Linux. You have to have something that's popular but not too new. And there are often very serious bugs. I recently went through some frustration converting a work computer to Linux. It had an ATI professional (4xDVI) card that crashed X randomly and didn't work well even when it was stable -- turns out the revision I had wasn't very well supported. I installed an nVidia card I had lying around, but that wouldn't work with multiple monitors (I only needed two). Finally ended up swapping computers with one that had on-board Intel graphics, since they've been somewhat open with the OSS driver crowd. I still get random glitches and OpenGL doesn't work, but it's usable. However, KDE 4.10 seems to have gone yet another step backwards, and now screen boundaries aren't respected, so maximizing a window stretches over both screens. I read some KDE forum posts where the developers defended the changes saying "it should never have been an option in that control panel -- window management doesn't belong at this layer." URGH. ><

Still love Linux though. Wouldn't trade it for Win 8 and a free bag of quarters.

SirNickity:
As a Gentoo user, I've always compiled my own kernels.

I do remember some years ago, recompiling the kernel - the OS. Quite successfully and relatively easily.

Cannot now remember why, but I just sat there as it all scrolled past thinking - "This sure isn't Windows!"

{Perhaps the understatement of all time.}

As a Gentoo user, I've always compiled my own kernels.

I used to make my own capacitors by filing down coins for the silver content, then melting it onto sheets of mica.
I hope you find a better way soon.