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:0L@0.7(8.in,-0.1in)+1L@0.7(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
[Forwarded from The Answer Guy column. -Ed.]
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.
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)
(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.
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%
(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.
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.
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.
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.
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:
display=:0
Replace it with:
let DISP=0 while ls -a /tmp/ | grep -q ".X$DISP-lock" ; do let DISP+=1 done echo "Using Display:$DISP.0" display=:$DISP
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:
Option "DontZoom"
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.