You can get a two-column printout from netscape by using the psutils packages. For letter-sized printouts, just change your "Print Command" in netscape to
pstops -q -w8.5in -h11in -pletter "2:[email protected](8.in,-0.1in)[email protected](8.in,4.95in)" | lpr -h
The PSUtils are avalable at http://www.dcs.ed.ac.uk/home/ajcd/psutils/index.html
You will have to edit the Makefile and set PAPER=letter if you live in North America.
Here's something I stumbled across while installing Mandrake 7.1 this weekend. While the installer correctly detects that the machine has more than 64 MB RAM (in my case 128). However - it does _not_ adjust lilo or grub, which it installs as default.
So when you start up with manually editing the config files you only get 64 MB. Which may not be readily apparent (my 700 Mhz machine is like lightning even on 64 MB).
Naturally you may need to add "mem=8m" to your lilo or grub config file.
[See the Mailbag and 2-Cent Tips of the past few issues for a discussion of addingappend = "mem=128M"
to /etc/lilo.conf. Sometimes it's required and sometimes it isn't, depending on the BIOS. -Ed.]
Hello gazette!
2-cent tip for new vi users:
If you have to move your left-hand to hit bye
Searching for more information about the i810 chipset I came across
your [The Answer Guy's] discussion about it and Linux.
I had a similar problem with my Linux installation, where as Linux
installed fine and I could utilize the command line wihtout a problem. However
I had no graphics support, that is to say no XFree86.
The soultion to this porblem is to be found at support.intel.com, under the
i810 fourm site. They have the X server and Kernel module and complete
instrcutions for how to install and use the software. You must however read
the fourm posts as there are a few tricks to the setup procedure.
That being said, I would like to know when/if kernel support will be
provided for the i810 chipset. Actually I would rather learn how to find this
information for myself. If you teach a man to fish, etc....
Here are the disk usage numbers for a kitchen-sink Red Hat Linux 6.0 installation. I got these numbers by installing every package the system installer had to offer on a pair of stock Gateway E-3200's, then pulling the hard drive from one and attaching it in place of the other's CD-ROM drive (that's at hdc). The operating system on the transplanted hard disk was never booted, so as to preserve the exact post-install, pre-boot state of the installation. I fired up the box, mounted hdc, changed the current directory over and did du --max-depth=1 in "/" and "/usr". Then I did it all over again with a different pair of E-3200's to make sure my numbers were consistent. They were. (I was mildly surprised.) My main reason for doing all this is so that I can make educated decisions about my hard disk partitioning (I've had bad experiences following other people's advice on this subject), but of course the data is interesting even in a purely academic sense.
(1) As the result of round-off error, the sum of the individual entries in this column (these columns) in fact comes to 0.01% shy of what it should be.
Note that in the case of both tables, the sum of the component entries in the Disk Usage column (the subdirectories of "/" and "/usr", respectively) is one kilobyte less than the total (the "/" and "/usr" directories, respectively). I thought round-off error, did du --block-size=1 --max-depth=1 and found that the numbers still disagreed. On intuition, I subtracted the --block-size=1 sums from the --block-size=1 totals and found that the sums were exactly 1,024 bytes less than the totals. Aha! I conclude that the two directory contents listings themselves take up a kilobyte each, and this is supported by the fact that "/proc", "/.automount", "/misc" and "/usr/etc" are all four empty, but are reported by du to occupy one kilobyte each. Where does the kilobyte value come from? Dividing the du --block-size=1 entries each by 1,024, I found that they are all evenly divisible. (That's why I ended up making the tables in kilobytes instead of bytes... there is no round-off error here.) Noting that du measures disk usage and not actual file size, I expect that one kilobyte is the cluster size on my disks, but I don't know much about that. If so, that beats Hell out of FAT32... isn't FAT32 four-kilobyte clusters minimum? My curiosity stopped at this point, but if I was to go on, I'd say the next step would be to start exploring the ext2 file system structure... if directory contents listings take up space alongside "regular" files, then there is probably no file allocation table, and I'd be curious to poke around on an ext2 file system with a disk editor. :-)
Here are the disk usage numbers for a kitchen-sink Red Hat Linux 6.2 installation.
(1) As the result of round-off error, the sum of the individual entries in this column (these columns) in fact comes to 0.01% off of what it should be.
Note that in the case of both tables, the sum of the component entries in the Disk Usage column (the subdirectories of "/" and "/usr", respectively) is four kilobytes less than the total (the "/" and "/usr" directories, respectively). I did du -b --max-depth=1 and found that the sums were less than the totals by exactly 4,096 bytes. The directories "/proc", "/opt", "/.automount", "/misc" and "/usr/etc" are all five empty, but are reported by du to occupy four kilobytes each. This is peculiar... if I am correct about cluster size being the relevant issue, why does Red Hat 6.2 use four-kilobyte clusters on the same hardware on which Red Hat 6.0 uses one-kilobyte clusters?
Just use a boot floppy to boot up the machine into single user mode.
From there you can edit /etc/lilo.conf to your liking and run lilo, and
also from there you can delete the encrypted password from either
/etc/passwd or /etc/shadow (the latter if you're using shadow
passwords). Then when you login as root, there will be no password, just
hit enter. Be sure to immediately run passwd and give root a new
password.
Get a rescue disk like tomsrtbt, mount the root partition, and edit
/etc/passwd manually, removing the root password or setting it to the same as
on another computer (it's hashed). Then reboot using the boot disk you made
when you installed Linux, log in as root, and edit /etc/lilo.conf and run lilo.
Hi, noticed your answer regarding "public interfaces" in shared libraries
in the latest Linux Gazette, and I had a couple of comments. (I am a
programmer, and have written several libraries and shared libraries under
Linux.)
There are at least two good reasons to hide functions from public
interfaces:
1) If a function is internal to the library, and it may well disappear or
change incompatibly without warning in future versions, so that you don't
want to be worry about people using it.
Any library will almost certainly contain a large number of such internal
functions, and the code would be utterly unmaintainable if you couldn't
change them between releases because people depended on them.
Of course, it is usually sufficient to simply not document those functions
or declare them in your header files, so that programmers who find out
about them should know that they use them at their own risk. (Some
programmers are foolish enough to do so, even though it is almost never a
good idea. e.g. there was a well-known case where StarOffice had depended
upon internal glibc functions and therefore broke when glibc was upgraded.)
2) If you don't want to pollute the namespace.
If I have an internal function in my library called something generic, like
print_error, I run the risk of accidentally conflicting with a function of
the same name in a calling program, with unpredictable results. One way
around this is to prefix the function with the name of my library, calling
it e.g. foo_print_error if my library is libfoo. But this can be awkward
to do for every little internal function you write, and it is often
preferable to simply hide them from the linker.
There is a solution, however, provided by ANSI C: simply declare your
functions with the "static" keyword, and they will only be visible/callable
within the file they are defined in. This isn't perfect, I suppose,
because they also aren't visible to other files in the same library.
However, it covers the case where foo_ prefixes are most annoying: little
utility functions that are only called within one file.
In linux, a lot of information about the processes and the system in
general is found in the /proc directory. To get the load average as
output by top, use
cat /proc/loadavg
Information about the memory used by particular processes can
be found in /proc/ Well, Alex's reply is partly right, but I *have* seen a 'lovebug.sh',
so if you would allow your browser to execute it, it could do some
damage. Maybe; I have not tried it.
Assuming you are careful and do not read your email as 'root' the
damage that the virus can do is limited. That's what file permissions
are meant to accomplish.
You need to properly configure your video card. Definitely easier said
than done. You can run Xconfigurator, but I assume you've already done
that. A few tips might help though.
* Instead of running startx, run startx 2>&1 | tee startx.txt
This will tell you which modes were accepted and rejected by X at
startup.
* Make *sure* that you tell Xconfigurator the proper values for your max
and min horizontal and vertical scan rates. Using the defaults
will yield the low performance figures you are probably getting now.
* There's a pretty good writeup on how to configure X in Running Linux
from O'Reilly.
* A lot of the SiS cards are not standard. i.e., one card may be
different from another card of the same model. The point is that if
the card is properly configured, it still may not work. In that case,
see if you can find yourself a good Matrox card. A Millenium
II is cheap on e-bay these days and I consider it to be rock solid.
That card probably came as a default in your PC. Don't feel bad;
you had to buy a real modem too to replace that WinModem that
came with it.
Bob Hepple's tip on using multiple X servers when using an XDMCP session
manager was interesting and informative. I had never even heard of Xnest
and it definitely looks worth investigating.
Personally I stay away from the XDMCP session managers. I like being
able to use my computer without the overhead of a GUI, and I find the
text mode easier on my eyes. I still end up using the GUI quite a bit
and find times when running multiple X sessions, either using different
bit depths and/or resolutions, or for different users, is desirable.
The default startx script from the RedHat distributions has display 0
hardcoded into it. I think this is the default script from the people
who make X, but not being sure, this may not apply if you're not running
RedHat.
There is a line in the startx script which reads:
Replace it with:
This checks the locks that X sets when it starts up, and uses the next
available display.
The echo line isn't needed, but I like feedback.
When an X session is running, use Ctl-Alt plus one of the Function keys
to go to an available terminal, log in and run startx and a new X
session will start. Use the Ctl-Alt Function key combinations to go back
and forth between the various terminal and X sessions. You can even
start a new X session by running startx from an xterm ( or equivalent )
from within X, but this makes the new X session a child of the original
one, and when the first one is closed, it brings the second one down.
My comuter under linux redhat xwindow will only run 300x200
graphics. Even if I hit CTRL ALT + , it wont change. I have a SiS620
Card with 8mb. Can you please help. I have spent a lot of time on
the internet, It seems other people have the same problem but no one
can help.
Off-hand, I can think of two possible causes:
1. the "DontZoom" option is set
2. You have only configured the 300x200 resolution.
Both of these problems can be fixed by editing the XF86Config file. I
don't use Red Hat myself, so I don't know exactly where it is.
Normally, typing "locate XF86Config" should tell you the location.
Inside this file, you should look for:
If you find this, place a # in front of it.
If you don't find this line, it means your X server is set up to use
only 300x200 as screen resolution. I think the best way to fix this,
is to use Red Hat's X configuration tool, and to add the resolutions
you want.
Last year I bought one of these cheap(er) east-asian PC computers
(like many of us ?) with the Energy Star feature (i.e. No more need to
press any button to power off).
But this feature is implemented with M$ Win... and I've no idea of
the way they manage the hardware behind this process.
So, as I recently installed a Corel distribution, I would like to
know if there is any mean to power off directly from Linux, and not
Shutdown-And-Restart, Open-M$Windows and Quit-From-There (and
Decrease-My-Coffee-Stock ;-} )
What is the LAST thing you see when you shut down your computer? It should
be "System halted" or "Power down.". If it is "System halted", then auto-off is
disabled in the kernel, and you need to recompile it. If it is "Power down.",
but it doesn't, I'm not sure what the problem is, but I've seen it.
If it says "The system is halted", but does not then say "System halted" or
"Power down.", something else is wrong. One of my computers crashes half the
time, and hangs the other, on shutdown.
How to configure the typical home PC for mail services via your ISP? This
information, though widely available, is not well-known. Many popular Linux
books gloss over the subject, suggesting that Netscape (and Netscape alone) is
the way to go. Unfortunately, this eliminates many fun, geeky, options like
emacs' Rmail.
Most distibutions set up Sendmail and Fetchmail--but configure Sendmail for
a "typical" host machine.
But a home user _can_ figure out how to modify this combination for home
requirements without learning all of Sendmail. And it is relatively painless.
My advice? Read the following short document thoroughly; and follow its
instructions exactly
http://www.linuxdoc.org/HOWTO/mini/Sendmail-Address-Rewrite.html
Then select the mail client of your choice and mail like the big guys!
Have Fun!
Look at the files and directories under /proc. These are "virtual" files
that are updated by the kernel. As I understand it, most programs that
provide process info and the like merely decode and present info gleaned
from the /proc files.
Hello!
My letter with a title "DNS for home mail not working" was printed in # 52
"Mail Bag".
I appreciate the help and attention, but I believe that problem was really
with my service provider. Because my request for help was ignored by
provider we choosed another and installed the leased line. And here is
success story. I laid the printouts of JC Pollman and Bill Mote articles
before me, followed along - and all was working. Fetchmail got the mail from
our mailboxes, procmail and imap delivered mail, sendmail handled outbound
mail.
Thank you, Linux Gazette, Mr. Pollman and Mr. Mote for my first linux
success.
Intel i810
Mon, 26 Jun 2000 21:32:56 -0700 (PDT)
From: GregV <[email protected]>
[Forwarded from The Answer Guy column. -Ed.]
Disk-space usage of Red Hat 6.0 & 6.2
Mon, 26 Jun 2000 21:32:56 -0700 (PDT)
From: Edward Livingston-Blade <[email protected]>
Disk Usage Percentage Disk Usage Percentage Percentage
Directory (recursive) of Installation Directory (recursive) of Installation of /usr
/lost+found 12 KB 0.00% /usr/X11R6 72,925 KB 7.06% 7.62%
/dev 111 KB 0.01% /usr/bin 92,961 KB 9.00% 9.71%
/etc 2621 KB 0.25% /usr/dict 404 KB 0.04% 0.04%
/tmp 17 KB 0.00% /usr/doc 156,448 KB 15.15% 16.35%
/var 22,858 KB 2.21% /usr/etc 1 KB 0.00% 0.00%
/proc 1 KB 0.00% /usr/games 48 KB 0.00% 0.01%
/bin 5448 KB 0.53% /usr/include 11,129 KB 1.08% 1.16%
/boot 6581 KB 0.64% /usr/info 6357 KB 0.62% 0.66%
/home 3131 KB 0.30% /usr/lib 266,192 KB 25.77% 27.81%
/lib 30,454 KB 2.95% /usr/local 20 KB 0.00% 0.00%
/mnt 3 KB 0.00% /usr/man 25,169 KB 2.44% 2.63%
/root 8 KB 0.00% /usr/sbin 11,142 KB 1.08% 1.16%
/sbin 4364 KB 0.42% /usr/share 243,235 KB 23.55% 25.41%
/usr 957,156 KB 92.68% /usr/src 51,959 KB 5.03% 5.43%
/.automount 1 KB 0.00% /usr/libexec 1141 KB 0.11% 0.12%
/misc 1 KB 0.00% /usr/i386-glibc20-linux 12,319 KB 1.19% 1.29%
/ 1,032,768 KB 100.00%(1) /usr/i386-redhat-linux 237 KB 0.02% 0.02%
/usr/cgi-bin 39 KB 0.00% 0.00%
/usr/i486-linux-libc5 5429 KB 0.53% 0.57%
/usr 957,156 KB 92.68%(1) 100.00%(1)
Disk Usage Percentage Disk Usage Percentage Percentage
Directory (recursive) of Installation Directory (recursive) of Installation of /usr
/lost+found 16 KB 0.00% /usr/X11R6 85,540 KB 6.19% 6.50%
/proc 4 KB 0.00% /usr/bin 108,556 KB 7.85% 8.25%
/var 15,256 KB 1.10% /usr/dict 408 KB 0.03% 0.03%
/tmp 32 KB 0.00% /usr/doc 164,712 KB 11.91% 12.51%
/dev 124 KB 0.01% /usr/etc 4 KB 0.00% 0.00%
/etc 5896 KB 0.43% /usr/games 52 KB 0.00% 0.00%
/bin 5760 KB 0.42% /usr/include 18,200 KB 1.32% 1.38%
/boot 2452 KB 0.18% /usr/info 6776 KB 0.49% 0.51%
/home 10,388 KB 0.75% /usr/lib 412,912 KB 29.86% 31.37%
/lib 21,232 KB 1.54% /usr/local 80 KB 0.01% 0.01%
/mnt 12 KB 0.00% /usr/man 20,280 KB 1.47% 1.54%
/opt 4 KB 0.00% /usr/sbin 16,860 KB 1.22% 1.28%
/root 28 KB 0.00% /usr/share 384,752 KB 27.82% 29.23%
/sbin 5184 KB 0.37% /usr/src 70,132 KB 5.07% 5.33%
/usr 1,316,324 KB 95.19% /usr/libexec 2100 KB 0.15% 0.16%
/.automount 4 KB 0.00% /usr/i386-glibc20-linux 14,052 KB 1.02% 1.07%
/misc 4 KB 0.00% /usr/i386-redhat-linux 252 KB 0.02% 0.02%
/tftpboot 48 KB 0.00% /usr/kerberos 5152 KB 0.37% 0.39%
/ 1,382,772 KB 100.00%(1) /usr/boot 8 KB 0.00% 0.00%
/usr/i486-linux-libc5 5492 KB 0.40% 0.42%
/usr 1,316,324 KB 95.19%(1) 100.00%
Tips in the following section are answers to questions printed in the Mail
Bag column of previous issues.
ANSWER: Missing root password
Tue, 30 May 2000 21:47:43 -0400
From: Sean <[email protected]>
Pierre Abbat <[email protected]> writes:
ANSWER: Limiting "Public Interfaces" on Share Libraries
Tue, 30 May 2000 23:56:27 -0400
From: Steven G. Johnson <[email protected]>
ANSWER: calculate cpu load
Wed, 31 May 2000 16:35:02 +0200
From: Ernst-Udo Wallenborn <[email protected]>
I would like to know how one can calculate cpu load and memory used by
processes as shown by 'top' command. It would be nice if anyone can
explain me how you could do these by writing your own programs, or by
any other means.
ANSWER: Linux and the love bug
Wed, 31 May 2000 16:39:48 +0200
From: Vic Hartog <[email protected]>
ANSWER: resolution
Wed, 31 May 2000 12:06:01 -0400
From: Steven W. Orr <[email protected]>
My comuter under linux redhat xwindow will only run 300x200 graphics.
Even if I hit CTRL ALT + , it wont change. I have a SiS620 Card with
8mb. Can you please help. I have spent a lot of time on the internet, It
seems other people have the same problem but no one can help.
ANSWER: Getting the most from multiple X servers - using startx script
Sat, 03 Jun 2000 14:37:14 -0400
From: James Dahlgren <[email protected]>
display=:0
let DISP=0
while ls -a /tmp/ | grep -q ".X$DISP-lock" ; do
let DISP+=1
done
echo "Using Display:$DISP.0"
display=:$DISP
ANSWER: 300x200 graphics
05 Jun 2000 21:23:16 +0200
From: Guy "Iggy" Geens <[email protected]>
Option "DontZoom"
ANSWER: Energy star support
Thu, 8 Jun 2000 14:32:47 -0400
From: Pierre Abbat <[email protected]>
ANSWER: How to properly configure mail on home machines
Fri, 16 Jun 2000 13:59:39 -0400
From: Mark J Solomon <[email protected]>
ANSWER: TOP Calculations
Sun, 25 Jun 2000 07:16:03 -0700
From: Mark Davis <[email protected]>
ANSWER: Success story (Was: DNS for home mail not working)
Mon, 26 Jun 2000 16:05:45 +0300
From: Alexandr Redko <[email protected]>
This page written and maintained by the Editor of the Linux Gazette.
Copyright © 2000, [email protected]
Published in Issue 55 of Linux Gazette, July 2000