Slashdot Mirror

A scan of the mirrors in the com/net/edu/gov/ca domains revealed that a handful have the Lorax release. Here's the list I compiled. Others might also have it, but are overloaded right now, so I can't check.

ftp://ftp.aklug.org/pub/redhat/mirror/ lorax/
ftp://cwrulug.cwru.edu/pub/ftp.red hat.com/lorax/
ftp://ftp.eecs.umic h.edu/pub/linux/redhat/ftp.redhat.com/lorax/
ftp://metalab.unc.edu/p ub/Linux/distributions/redhat/lorax/
ftp://csociety-ftp.ecn.purdue.e du/pub/redhat/lorax/
ftp://ftp.snoopy.net/pub/mirrors/red hat/lorax/

OK, another boring JK-bashing post: ...$1,599 for a Mac with a 400-megahertz processor; $2,499 for 450 MH available in September, and $3,499 for 500 MH...
Those are pretty large coils, I bet! Free link for Jon Katz' continued education: SI Derived Units. I recommend looking at the first one. It's frequently very useful when talking about processor speeds. :)

I can't believe I used ul instead of u for underline.

Anyway: check out RMS's "Right to Read" as 'published' by PG at Metalab

Nice starting point if you are on a budget:

Software RAID mini-HOWTO

Also take a look at:

Linux High-Availability HOWTO

Check out the nanoManipulator at UNC.

Tanner Lovelace
Ph.D. Student
University of North Carolina

Check out the nanoManipulator at UNC.

Tanner Lovelace
Ph.D. Student
University of North Carolina

If you're interested in computer graphics, especially real-time computer graphics (read Virtual Reality), seriously consider the University of North Carolina. Besides the fact that we have been studying this field for almost 30 years and we're ranked very high, we also have an SGI Reality Monster all to ourselves :-). Seriously, though, take a look at any year's SIGGRAPH proceedings and you'll see a large number of papers from UNC. So, when you think graphics, think North Carolina.

Tanner Lovelace
Ph.D. Student
University of North Carolina at Chapel Hill

If you're interested in computer graphics, especially real-time computer graphics (read Virtual Reality), seriously consider the University of North Carolina. Besides the fact that we have been studying this field for almost 30 years and we're ranked very high, we also have an SGI Reality Monster all to ourselves :-). Seriously, though, take a look at any year's SIGGRAPH proceedings and you'll see a large number of papers from UNC. So, when you think graphics, think North Carolina.

Tanner Lovelace
Ph.D. Student
University of North Carolina at Chapel Hill

Being a graduate student in computer science is an ascetic experience. In order to succeed, you will be called upon by the elders of your order (professors) to forsake the temptations of big IT salaries and stock options, to labor and toil as a peon with virtually no status whatsoever. In the end, you are supposed to emerge as an enwizened practitioner. That's the theory at least.

Seriously though, if you decide to go to graduate school, you will help yourself greatly by doing the following:

1) Talk to graduate students from any of the schools that you are considering attending. They will be able to tell you the real deal about their school. You might also be able to judge how bright a department's grads are when you talk to them. A lot of smart grads is usually a good sign.

2) Find out something about the school's location. Even though you will be involved with classes and research most of the time, you want to make sure that when you actually have free time, that there's something to do.

3) Make sure that the school's aid package is enough to pay the rent and eat. That is, unless you are your parents are rich. Make sure that you know exactly what your expenses are, e.g., tuition, fees and health insurance. Any good Ph.D. program will pay most of these for you. Don't be shy asking about the size of stipends or fellowships. And make sure that you'll be funded throughout your tenure as a student.

4) Know exactly why you're going to graduate school. You will get depressed and start doubting your decision to go to graduate school. Especially when your friend's make $10,000,000 when their stock vests. It's good to be able to reassure yourself that you made the right choice when this happens.

5) Visit Ron Azuma's guide to being a PhD student.

Hope this helps.

EvilKevin

Love and Linux,
Paul

It's been folded into the Ethernet HOWTO. Check out "Using More than one Ethernet Card per Machine"


--Phil (Not that I even have a cable modem; I'm still stuck in 56K-land.)

It's been folded into the Ethernet HOWTO. Check out "Using More than one Ethernet Card per Machine"


--Phil (Not that I even have a cable modem; I'm still stuck in 56K-land.)

you can try out http://www.linuxkb.com/ (not up yet, coming soon) and http://linuxkb.cheek.com/ which are two Linux Knowledge Base projects.

For more info see the Linux Documentation Project. I personally like to access the LDP through http://howto.linuxberg.com/ because I find it easier to navigate.

Here's how I did it:

1. Grab a copy of the FreeType font server here (for linux/x86 w/glibc2), h ere (for solaris/SPARC) or here (patch to XFree sources -- not for the faint of heart).
2. Put the xfsft executable somewhere in your $PATH.
3. Get a directory full of TT fonts. I have a directory on my Linux partition full of symlinks to /dosc/windows/fonts/*.ttf, for example. /usr/X11R6/lib/fonts/tt is not a bad place.
4. Run the ttinst script in that directory; this will create a fonts.scale file.
5. ln -s fonts.scale fonts.dir
6. echo "catalogue=/usr/X11R6/lib/fonts/tt" > /usr/X11R6/lib/fonts/tt/xfsft.conf
7. Add the following to your .xinitrc:

   xfsft -port 7100 -config /usr/X11R6/lib/fonts/tt/xfsft.conf
   sleep 1 # Give xfsft a chance to start up
   xset +fp tcp/127.0.0.1:7100
   xset fp rehash
   

Steve 'Nephtes' Freeland | Okay, so maybe I'm a tiny itty

Here's how I did it:

1. Grab a copy of the FreeType font server here (for linux/x86 w/glibc2), h ere (for solaris/SPARC) or here (patch to XFree sources -- not for the faint of heart).
2. Put the xfsft executable somewhere in your $PATH.
3. Get a directory full of TT fonts. I have a directory on my Linux partition full of symlinks to /dosc/windows/fonts/*.ttf, for example. /usr/X11R6/lib/fonts/tt is not a bad place.
4. Run the ttinst script in that directory; this will create a fonts.scale file.
5. ln -s fonts.scale fonts.dir
6. echo "catalogue=/usr/X11R6/lib/fonts/tt" > /usr/X11R6/lib/fonts/tt/xfsft.conf
7. Add the following to your .xinitrc:

   xfsft -port 7100 -config /usr/X11R6/lib/fonts/tt/xfsft.conf
   sleep 1 # Give xfsft a chance to start up
   xset +fp tcp/127.0.0.1:7100
   xset fp rehash
   

Steve 'Nephtes' Freeland | Okay, so maybe I'm a tiny itty

Here's how I did it:

1. Grab a copy of the FreeType font server here (for linux/x86 w/glibc2), h ere (for solaris/SPARC) or here (patch to XFree sources -- not for the faint of heart).
2. Put the xfsft executable somewhere in your $PATH.
3. Get a directory full of TT fonts. I have a directory on my Linux partition full of symlinks to /dosc/windows/fonts/*.ttf, for example. /usr/X11R6/lib/fonts/tt is not a bad place.
4. Run the ttinst script in that directory; this will create a fonts.scale file.
5. ln -s fonts.scale fonts.dir
6. echo "catalogue=/usr/X11R6/lib/fonts/tt" > /usr/X11R6/lib/fonts/tt/xfsft.conf
7. Add the following to your .xinitrc:

   xfsft -port 7100 -config /usr/X11R6/lib/fonts/tt/xfsft.conf
   sleep 1 # Give xfsft a chance to start up
   xset +fp tcp/127.0.0.1:7100
   xset fp rehash
   

Steve 'Nephtes' Freeland | Okay, so maybe I'm a tiny itty

Download the current copy of the wine source from http://metalab.unc.edu/pub /Linux/ALPHA/wine/development/, gunzip and untar it, and run:

grep corel ChangeLog

from the base directory (wineYYYYMMDD) and see how many contributions Corel has made. They've made less than I personally hoped, but they've made quite a few. To be fair, I've poked in that code some, this is not a trivial project. In many ways it is much more complicated than the Linux kernel (I guess that shouldn't surprise any of us!). Corel's team may well be still finding their way around. They may also be concentrating on those things that affect their applications primarily.

They are there and they are doing things...

I doubt this news will do anything but improve Wine's situation. A guy who has done much of the lead work on Wine in his spare time will now be working on it full time and being paid to do so. I can't see how this can do anything but help.

I've hand many chances to play with machines with redundant power supplies. In two words, THEY SUCK! Failure rate on redundant power supplies is ENORMOUS. In most cases (double entendre intended) two power supplies must occupy the space normally inhabited by a single power supply. They fail an order of magnitude more often than large single power supplies. IMHO, your overall best bet is redundant servers. Linux doesn't have many built-in high-availability features but the High-Availability HOWTO is a great place to start. But redundant power supplies -- PHEW! They stink!

We've been hosting many various open source projects for a long time now and would be glad to host more. So if you are homeless--or if you are starting an OS project--drop a note to me or to Donald Sizemore dsl@metalab.unc.edu

You will find the file in HOWTO/mini/Hard-Disk-Upgrade.html. Remember to use the mirrors folks, hence no direct link.

For everything you ever wanted to know about this topic, visit the BogoMIPS mini-HOWTO

The dates, memos, address book, and all that are handy, but the ability to read hypertext documents anywhere has been a great asset.

The dates, memos, address book, and all that are handy, but the ability to read hypertext documents anywhere has been a great asset.

The dates, memos, address book, and all that are handy, but the ability to read hypertext documents anywhere has been a great asset.

The dates, memos, address book, and all that are handy, but the ability to read hypertext documents anywhere has been a great asset.

Second, you may have felt overwhelmed by all the HOWTOs available at the Linux Documentation Project, and you might have missed a few of the handier ones. Well, <FONT FACE="large, friendly letters">DON'T PANIC!</FONT> :-) As a former "dos junkie", you'd probably get the most initial mileage out of the From DOS/Windows to Linux HOWTO. I also recommend the Linux Gazette, which seems aimed at new Linux users and often contains a whole lot of handy tips and tricks that will sometimes make your life simpler.

As a former DOS junkie myself (who still occasionally amazes Win95 users with my knowledge of CONFIG.SYS and "DOS=HIGH,UMB" and so on) I'll predict that once you get used to Linux's quirks (and yes, it does have a few), you'll feel right at home. It may take a year or two (it did for me), but after a couple of years, you'll wonder how you could have used anything else.

Have fun, and feel free to E-mail me if you have any questions.
-----

Second, you may have felt overwhelmed by all the HOWTOs available at the Linux Documentation Project, and you might have missed a few of the handier ones. Well, <FONT FACE="large, friendly letters">DON'T PANIC!</FONT> :-) As a former "dos junkie", you'd probably get the most initial mileage out of the From DOS/Windows to Linux HOWTO. I also recommend the Linux Gazette, which seems aimed at new Linux users and often contains a whole lot of handy tips and tricks that will sometimes make your life simpler.

As a former DOS junkie myself (who still occasionally amazes Win95 users with my knowledge of CONFIG.SYS and "DOS=HIGH,UMB" and so on) I'll predict that once you get used to Linux's quirks (and yes, it does have a few), you'll feel right at home. It may take a year or two (it did for me), but after a couple of years, you'll wonder how you could have used anything else.

Have fun, and feel free to E-mail me if you have any questions.
-----

Second, you may have felt overwhelmed by all the HOWTOs available at the Linux Documentation Project, and you might have missed a few of the handier ones. Well, <FONT FACE="large, friendly letters">DON'T PANIC!</FONT> :-) As a former "dos junkie", you'd probably get the most initial mileage out of the From DOS/Windows to Linux HOWTO. I also recommend the Linux Gazette, which seems aimed at new Linux users and often contains a whole lot of handy tips and tricks that will sometimes make your life simpler.

As a former DOS junkie myself (who still occasionally amazes Win95 users with my knowledge of CONFIG.SYS and "DOS=HIGH,UMB" and so on) I'll predict that once you get used to Linux's quirks (and yes, it does have a few), you'll feel right at home. It may take a year or two (it did for me), but after a couple of years, you'll wonder how you could have used anything else.

Have fun, and feel free to E-mail me if you have any questions.
-----

They had an excellent TUI complete with buttons, windows, pop down menus, radio and check boxes, text editing, etc. It was extremely well thought out and unbeatable for C++ development/learning in text mode. Worked both with mouse and keyboard.

They now distribute it freely. I couldn't find a complete license agreement but you should be able to develop BSD style licensed programs with it blazingly fast (at least the UI when you become acquainted). It is now ported to Linux though I haven't had a chance or trying it but you can download it here:

Even in DOS days when I bought BC++ 3.10, TVision came with its complete source code. I made a database program combining it with Paradox Engine. The whole thing worked flawlessly without a memory manager, i.e. with less than 640 kB. I plan to do the same thing with some free SQL in Linux one day.

From ESR, I would add The Jargon File. The Cathedral And the Bazaar is more about Software than the Internet, but if that's there, than RMS's Why Software Should Be Free should also be there.

Another critically important RMS piece (and one more relevant to the internet) is The Right to Read.

Also there's The Declaration of Independence [of the USA], not as a document in its own right, but as the first entry into Project Gutenberg.

Getting more internetty, you've got RFC Number 1, the description of the tentative IMP protocol to be used between the four systems on the brand spanking new ARPA network.

Going to distant history (in computer terms) there is the 1945 paper by Vandemaar Bush, As We May Think, one of the inspirations for the ARPA project.

There's the 1989 whitepaper from CERN's Tim Berners-Lee, Information Management: A Proposal, the paper that started the WWW.

If you chop [per-copy royalties], then you aren't being adequately compensated...

1. Documentation of software is a part of the software package itself. Therefore, if the software is free, why shouldn't the documentation be free? If the software is of high quality, why should I skimp on documentation?
2. If I'm just downloading the documentation with free software, then the money lost by any one due to my having the documentation in front of me is close to nil. The difference between the money lost from letting me download software, or letting me download software and documentation, is nil. The cost difference between writing software for free, and writing documentation concurrently with the software, is not generally measurable, so again the difference is nil.

1. Hey! I wrote those docs, I should be compensated! (see Why Software Should Not Have Owners)
2. The difficulty of producing quality hardcopy documentation(i.e., going through a publisher) require a more conventional (non-free) way of doing things.

Check out this link:
X video timings HOWTO

Yeah, since 1994 about 2 drivers a year. (And I know, if you look at the kernel source it's a lot different, but it's so much easier to follow a link.)

At least one gives a rather in depth description of the issue, the Multi Disk HOWTO which is very much about tuning in general. It is way to big to quote here so I' rather suggest the interested readers look at the following chapters listed below (straight from the Multi Disk HOWTO homepage):

• disk drives and speed
• File System Features which even starts off discussing swap. Pay special attention to interleaving issues.
• Terms which gives more info on speed limitations and what speed really is
• Physical track positioningan old but still good technique
• Disk layout for general layout issues
• The need for swap
• An example setting using 4 interleaved swap partitions.
• Single drive swap positioning optimisation

Note that the swap partiotn limit in old kernels depends on the architecture of the processor, namely if it is a 32- or 64-bits processor.

If you have any comments to the HOWTO I hope you can take direct contact with the author so more people can benefit from your insight.

I too, a Prodigy customer, had trouble setting up Linux to connect, the people on the newsgroups were no help, and as for the people in the chat help... don't even get me started on them. However, eventually I came across this one program, called PPPSetup, which can be found here at ftp://metalab.unc.edu/pu b/Linux/system/network/serial/ppp/ as the file "pppsetup-2.16.tar.gz". It's a simple bash script, but it was really easy to use.

Btw, FSSTD stands for FileSystem STanDard. You can find the document on Metalab.

True, LotusXSL is slow. The documentation even says the focus was on completeness and stability. Funny, that's how Apache started...but I'll leave that alone. There's other XSL processors available. But taken as a whole, XSL is very, very bleeding edge. So what is an early adopter to do?

Unless your pages are changing constantly, use a caching mechanism. If your site is very static, only generated dynamically occasionally, then spider your site. Otherwise, reverse proxies like SQUID do nicely

Let's say your pages do change every second, or your pages are personalized to such a degree (like slashboxes) that only just in time creation works. You could:

• Write XSL transformations that almost completely transform the document to HTML, leaving a handfull of XML tags that must be tranformed at the last minute. Expand those last minute tags with XSL or something homegrown. This would work nicely with my personalized slashdot page. The content of my article list and my slashboxes changes, but the location and ordering of my slashboxes changes infrequently.
• skip XSL entirely. XML parsers are more mature than XSL processors. IBM's xml4j API has hooks for inserting your own element handlers. You would be coding the tranformation instead of writing in a tranformation language, but it would be fast

My preference is to use XSL, or more acurately, XSL:T or XTL or whatever the part of XSL that just deals with tranformations. However, the more important part is getting your content represented as XML. That's the most important. Here, this person said it better than I can:

When you sit down to implement an XML system the last thing you think about is CSS, XSL, or the DOM. The first thing you think about is the needs of the data. If you have any volume of textual data, you will probably not get another opportunity to re-encode all of it until CSS and XSL are historical artifacts, Microsoft is a division of Red Hat, and the Web has more users than the telephone.

So you *must* concentrate on the needs of the data. You must make richly semantic markup that captures the structure of the data. And you must have human authors start to add this semantic markup to the data as soon as possible. You must minimize the cost of this markup effort. --Paul Prescod on the xml-dev mailing list

heh, well, you certainly gave up too easily... desktop sucks? take a look at this screenshot and tell me that's crap. btw, if u want to use TTF fonts in Linux, you need to compile and install freetype. Any idiot knows to go to http://metalab.unc.edu/LDP/ for HOWTO's and whatnot.. that's how you get Linux help.. anyone that reads slashdot knows that, and if they don't, then they are an arrogant bafoon. well gee, there ya go.. i just gave 2 urls that prove that you're just not a hard core computer user.

Get xfstt from Metalab.
Copy whatever TrueType fonts you want into /usr/ttfonts.
Run /usr/X11R6/bin/xfstt --sync
Run /usr/X11R6/bin/xfstt &
Problem solved.
And try KDE.
--

At home I've been running an old Digital 386DX/16 workstation, as a server for a while. It initially came with an Adaptec SCSI controller and a 40MB Scsi hard drive. It used the SCSI BIOS to boot the HD. The system bios itself could only select a floppy and the SCSI drive as an option to boot. Right now, I don't have any scsi hard drives in it at all. It has 2 small IDE drives and a Hardcard, with a copy of the kernel in the floppy drive. It boots off the floppy, and then uses the IDE drives, despite the fact that the BIOS doesn't support them.

This only thing IMHO that could prevent you from having eight IDE controllers is a lack of IRQ's or some other possible limitation, that I don't know of, placed by the PCI bus.

This is explained in more detail in the Large-Disk mini-HOWTO

FYI: Lilo version 21 has support for /dev/hde and higher. You can get lilo v21 from metalab.

- intrep

FYI: Lilo version 21 has support for /dev/hde and higher. You can get lilo v21 from metalab.

- intrep

• is there, in fact, and GPL'd code?
• was it modified? If not, then links could be provided to the original source upon request, and the GPL would be intact.
• if there is GPL'd code, will they be providing source for those GPL'd apps?

Jumping on this too quickly, and too harshly, could do more harm than good. Even if, when this does come out, a GPL violation is found, remember that it may be accidental -- and respond first with a tactful notice. If the programmers are typical, they will immediately take steps to correct the violation... if not, then legal action might be explored by the community.

Either way, the community as a whole will get a lot farther using dignity and tact than sending off flame. Think about it: how would you respond to a literal flame? Extinguish it... is that what we want? I thought not.

Please, please, read the Advocacy HOWTO.

Posted by the Proteus

I did this once on a 10BaseT network. It works fine but if you don't want to wait a second for every 'ls' I suggest you use 100 Mbit NICs. If your network holds 10+ machines a 10BaseT infrastructure is not recommended. Consult the mini HOWTOs at LDP for more info.

What is Bob Young going to do other than put his foot in his mouth. Macmillan is a publisher of *documentation*. They pride themselves on their documentation being right while RedHat just prides itself on declairing soul ownership of it's documentation (right or wrong). While RedHat web hosts Marc Ewing's statements on why the Linux Community should not be accepting of the Qt license (for modifablity reasons), they sneaked the Donnie Barnes non-modifiablity license into the LDP while the majority of the LDP is covered (and usually assumed to be covered) by the LDP license. And, anyone who has provided patches to both Troll Tech and Donnie Barnes knows that if the patch is sound that Troll Tech accepts the modification into the offical package and that keeping RH documentation maintained is done at Donnie Barnes whim. So, lets not be accepting of non-modifablity licensing just as Mr. Ewing suggested. Hence, lets not be accepting of RedHat! If Macmillan thinks it can publish (and document) a distribution better than the RedHat closed documentation distribution, then more power to them! Go Macmillan, down with the Donnie Barnes/RedHat license which is under conditions that even RedHat's Ewing wouldn't support!

What is Bob Young going to do other than put his foot in his mouth. Macmillan is a publisher of *documentation*. They pride themselves on their documentation being right while RedHat just prides itself on declairing soul ownership of it's documentation (right or wrong). While RedHat web hosts Marc Ewing's statements on why the Linux Community should not be accepting of the Qt license (for modifablity reasons), they sneaked the Donnie Barnes non-modifiablity license into the LDP while the majority of the LDP is covered (and usually assumed to be covered) by the LDP license. And, anyone who has provided patches to both Troll Tech and Donnie Barnes knows that if the patch is sound that Troll Tech accepts the modification into the offical package and that keeping RH documentation maintained is done at Donnie Barnes whim. So, lets not be accepting of non-modifablity licensing just as Mr. Ewing suggested. Hence, lets not be accepting of RedHat! If Macmillan thinks it can publish (and document) a distribution better than the RedHat closed documentation distribution, then more power to them! Go Macmillan, down with the Donnie Barnes/RedHat license which is under conditions that even RedHat's Ewing wouldn't support!

What is Bob Young going to do other than put his foot in his mouth. Macmillan is a publisher of *documentation*. They pride themselves on their documentation being right while RedHat just prides itself on declairing soul ownership of it's documentation (right or wrong). While RedHat web hosts Marc Ewing's statements on why the Linux Community should not be accepting of the Qt license (for modifablity reasons), they sneaked the Donnie Barnes non-modifiablity license into the LDP while the majority of the LDP is covered (and usually assumed to be covered) by the LDP license. And, anyone who has provided patches to both Troll Tech and Donnie Barnes knows that if the patch is sound that Troll Tech accepts the modification into the offical package and that keeping RH documentation maintained is done at Donnie Barnes whim. So, lets not be accepting of non-modifablity licensing just as Mr. Ewing suggested. Hence, lets not be accepting of RedHat! If Macmillan thinks it can publish (and document) a distribution better than the RedHat closed documentation distribution, then more power to them! Go Macmillan, down with the Donnie Barnes/RedHat license which is under conditions that even RedHat's Ewing wouldn't support!

"This document and its contents are copyright protected. Redistribution of this document is permitted as long as the content remains completely intact and unchanged. In other words, you may reformat and reprint or redistribute only."

While the RPM package itself is modifable, the documentation MUST be complettely rewritten as an independant work so that the documentation can provide information that reflects the latest changes/version.

I have talked with members of my local LUG about this issue. I had discovered some fellow members who have also made patches which found their way into the offical RedHat distribution. Also, with each of the resulting derivative works, RedHat took advantage of the licensing conditions of the GPL and published binaries which resulted from their modifications. However, while RedHat was free to modify our work, we each had come to relize that RedHat does not extend the same licensing considitions back for their documentation. As a result, we are forced to email Donnie Barnes to request modifications but for every member of my local LUG that contacted Mr. Barnes, he declaired that he did not have time to update the documentation.

Btw, the LUG is working to put together a petition to request that Greg Hankins remove "HOWTOs" like this which are under more restrictive licensing terms than that of the LDP license. It is our feeling that it compromises the reliabilty of the LDP when any one person or company controls certain LDP content. This also becomes a legal trap just waiting to be sprung. At any point, someone may attempt to assist in maintaining LDP documentation without take care to notice that some LDP material is not under LDP license and may find themselves sued by RedHat as a result. It is the LUG's belief that ever step should be taken to *ENCOURAGE* modification/updates to LDP and that leaving the RPM HOWTO trap as part of the LDP can only serve to discourage this goal.

It is also licensing issues like this which encourage forking of distributions. How can we truely trust a company like RedHat which sucks off of the work of the Linux community and then deploys the Donnie Barnes documentation license trap back upon that same community?

I would also like to applaud Macmillan for their steps to fork from RedHat. Since RedHat is getting so much commerical recognization right now (despite trying to snare the Linux community with it's licensing considitions), the easy thing for Macmillan to have done is to try to associate itself with RedHat as best it could. Instead, it appears that Macmillan (a publisher, anotherwords, documentation company) clearly saw that RedHat wasn't worth publishing on until they could correct what they publish. Hopefully, after Macmillan takes the time to rewrite documentation from the ground up, they make sure to screw RH over with licensing conditions the same way the Donnie Barnes' attack was used on the Linux community.

Rather than acting like an elementary school student and going around using gratuitous pejoratives, perhaps you could've actually pointed out a URL of the HOWTO.

Rather than acting like an elementary school teacher and going around patronizing random strangers, perhaps you could have posted such a URL yourself.

From section 6.6 of the NET-3-HOWTO, available to Internet users worldwide:

The EQL device name is `eql'. With the standard kernel source you may have only one EQL device per machine. EQL provides a means of utilizing multiple point to point lines such as PPP, slip or plip as a single logical link to carry tcp/ip. Often it is cheaper to use multiple lower speed lines than to have one high speed line installed.

Kernel Compile Options:
Network device support --->
[*] Network device support
EQL (serial line load balancing) support

To support this mechanism the machine at the other end of the lines must also support EQL. Linux, Livingstone Portmasters and newer dial-in servers support compatible facilities.

To configure EQL you will need the eql tools which are available from:
sunsite.unc.edu
ftp://sunsite.unc.edu/ pub/linux/system/Serial/eql-1.2.tar.gz.

There, see how easy that was?

--

Just for fun, I went to Yahoo! and did a search on "+gre +vpn +linux" and came up with tons o' useful links.

Always check the LDP and specifically the VPN Mini-HOWTO.

I shouldn't have to tell you this.