Slashdot Mirror

I believe that linux cdrecord has to run over scsi-ide, so make sure to use the scsi-ide module.

The following are some relevant docs:

cdrecord They mention something about dvd-r, so it seems that cdrecord can record dvds. They say it works on most unices.

The frontend i use

http://www.linuxdoc.org/HOWTO/CD-Writing-HOWTO.htm l
and the obligatory HOWTO.

Hope that helps

I have the Docuprint P8 Sigh... I have the worst luck at picking printers.

I looked around for info on your printer, hoping to be able to help. Unfortunetely, I found this... http://www.linuxdoc.org/HOWTO/Printing-HOWTO/print ers.html

Sorry.

Don't feel too bad, my first printer was a 0.05ppm colour Lexmark inkjet. I swear to you, this must be the slowest printer on the face of the earth! It's a Win printer also, thank God!

I take it you have never heard of the Linux Documentation Project?

Loopback encrypted filesystems

hmmm, well, for starters you might wish to look at www.linuxdoc.org/linuxfocus/Castellano which I would assume is a repository of Spanish-language documentation for Linux.
There is also the Debian translation repository at: www.debian.org/international/Spanish

And if you're interested in a Red-Hat based distribution that is supposed to have a fairly complete collection of spanish instructions, check out: conectiva.com. These guys also have a spanish-language publication that you might be interested in looking into. You might even want to sign up your new admin for a year or so.

hmmm, it's amazing what you can find in 15 seconds with Google, isn't it?

Once we looked at it more carefully, it actually turned out to be not even as bad as that. The last count I had was down to 91 non-free documents and 93 documents with no licence (which are arguable, but they probably come under the general LDP Licence which is free). I haven't had a lot of time recently so the database isn't up to date with this.

Just compile and install the new kernel, and keep your old one around. Put entries in LILO for both. For example I, running slack, might have an entry for "slack" being the default 2.4.16 which I most frequently use. I might then make and entry for "slacktest," being the most current 2.5.x kernel of the week. I simply direct one entry to vmlinuz (vmlinuz being my 2.4.16 kernel) and one to vmlinuz-2.5.1 (this being my newly compiled test binary).

If you wanna know where to find the FMs, www.linuxdoc.org is a good place to start.

"Any, and I mean any god dammit, attempt to restrict access to source code is evil according to GNU Values."

That is a pretty strong statement and smacks in the face of the "Magna Carta" of those GNU Values, ie the GPL. The GPL _does_ restrict access to source code! Albeit, in a way that turns the traditional role of copyright on it's face, but then you are condemining _all_ restrictions on source code right ;)

"Ximian is now evil. That they are now working with the Devil then should come as no surprise."

Please read this. Come on, how can you expect anyone to take you the least bit seriously. Haven't we all been more than reminded of what true evil is lately? Ximian is evil because they intend to sell a proprietary add-on to a product so that it can be used in conjunction with another proprietary product? Come on!

"Actually, it isn't possible to work with MS without selling your soul. By working with Microsoft you are explicitly telling the world that their licenses and policies and practicies should not be a reason to avoid doing business with MS."

What would you have us do O'Righteous One? Should we similarly brand IBM as evil? After all they do develop proprietary software... Do you suppose that we should not collaborate with IBM or refuse the fruits of there evil help in developing and promoting Linux?

I'm the maintainer of the Debian packages containing the English-language HOWTOs distributed by the Linux Documentation Project.

A few days ago, during a discussion we were having about other things, David Merrill brought it to my attention that many of the LDP documents didn't belong in our main distribution. With the evidence in front of me, it was hard for me not to agree, and, once I knew of the problem, I felt bound to do something about it.

The timing, of course, was unfortunate, coming as it did so close to the woody freeze. Yes, I should have noticed it earlier, but to be honest I've been kind of busy writing code and fixing bugs in the three months or so since I've been working on Debian's HOWTO packages. I certainly wouldn't have planned it this way; the situation now leaves me with less than three weeks to implement a bunch of code to parse the LDP database and to split the packages up, which is definitely not something I enjoy doing at the end of a release cycle, so we aren't doing this for our own amusement.

Personally, I am extremely disappointed that much of the doc-linux packages will have to become doc-linux-non-free-html and doc-linux-non-free-text. I didn't become the doc-linux maintainer with the intention of removing documentation from the standard installation! I'll be doing my best to ensure that any documents that we start being able to distribute in main are moved back into main as soon as possible, including submitting updates for point releases of woody and persuading the release manager to include them. I'll also be checking by hand as many of the documents in non-free as I can just in case they really are free. The two days mentioned in the story, incidentally, are when the relevant part of the freeze starts, not when it ends, so the notice that's been given to authors isn't quite so ridiculously short as it sounds. Any documents that get relicensed in the next month and a bit will be included in main for woody, and it wouldn't surprise me if that deadline could be allowed to slip a bit.

I find it fascinating that lots of people seem to think that Debian is somehow beating its chest, stirring trouble, or being generally obnoxious. This is simply not true. First of all, we're reacting to concerns from the LDP, and secondly all the conversations I've had with LDP people, especially David Merrill, have been very civil and friendly. (Incidentally, David, if you're reading this, I owe you a drink of your choice.)

If you'd like to see where this discussion started, try the thread about this on debian-legal. Although David's original mail to me wasn't sent to that mailing list, I think the linked article quotes everything important.

I wish David and the LDP volunteers all the best, and I dearly hope that the current situation will be temporary.

There is now a list of the documents which are not GFDL or OPL on the LDP website.

I know that some of these are free, not non-free, but I wanted to get the preliminary list up, especially now that this is a SlashDot story. This list is a list of all documents where the license isn't GFDL or OPL, or public domain (only a few LDP documents are under other free licenses).

Also, it doesn't show documents relicensed in the last few days.

Thanks again for the good idea.

David Merrill
LDP Collection Coordinator

That's a good idea, gmhowell. At this time we don't have such a list compiled, although I will get to work on compiling one. If you check on the LDP site, www.linuxdoc.org, I should have it up soon.

Thanks for the good idea.

Anyone who has an immediate concern can find us on #linuxdoc on irc.openprojects.net. I'd be happy to help you out any way I can.

David Merrill
LDP Collection Coordinator

Sure, sounds good. Shall I list you on the "documents in progress" list?

Seriously, though, we welcome contributors. Not only are there gaps in documentation, but there are documents needing new maintainers. Please read the announcement, or join our discussion list at lists.linuxdoc.org and help us out. We would all love for the LDP to be better than it is, but we rely on all of you to make it happen. We are a small coordinating group, and we need authors to help write the documentation.

David Merrill
LDP Collection Coordinator

I can see where this is confusing. What has happened is that there have been several versions of the LDP License, and also a sample "boilerplate" license listed in our manifesto.

Some of them are Free, some are Non-Free.

We are doing our best to get as many documents licensed to suit Debian guidelines as we can. However, the LDP is not a Free project, and we do not require a Free license. We DO want to keep our documents in Debian as much as we possibly can, so I am asking the LDP authors to consider seriously a relicensing in order to do that. I'm not forcing anyone to do anything. Allegations to the contrary just show you didn't bother to read the announcement.

Now if I may be permitted a micro-rant...

I'm a volunteer just like the other LDP volunteers, and I give lots of my time trying to create and improve the documentation you all count on. I'm doing my best to deal appropriately with a difficult situation, and I'd appreciate receiving some support for that rather than endless flames and gripes over things I'm not even doing.

And Flower, that isn't directed at you. :-)

David Merrill
LDP Collection Coordinator

Serial console... make sure you have Serial Console support in the kernel, add "console=ttySx" to the LILO append= line, and maybe fix the /dev/console device node. The Text-Terminal HOWTO has the details.

Even more important is this one. A linux DISTRO called BRLSpeak aimed at the visually impared. The creatror Osvaldo LaRosa is himself visually impared and also runs the AudioBraille.org/BLinux iniative website. You may also want to check out the LinuxAccesability-HowTo at linuxdoc.org. Linux is not just for the sighted. Also a note on the numbers of handicapped. Not all handicapped require special help in using a computer. I for one may have trouble with walking correctly but other than a pair of glasses I don't need any help with a comp. That's why the number may seem high to some of you .

There are a number of projects in the open source community that address different accessibility issues. The Gnome accessibility project (http://developer.gnome.org/projects/gap/ ) is probably the most widely known and most publicized. However, most of the Linux accessibility projects are, by necessity, focused on the command line interface instead of the graphical desktops.

In general, there are several areas that accessibility focuses on: visual, hearing, mobility, and cognitive or learning impairments. Currently, visual impairment is getting a lot of attention, as many visually impaired users require a screen reader and speech synthesizer (either hardware or software) for output. There are a number of screen readers (Emacspeak, Speakup, and Jupiter, to name a few) available which use either hardware or software synthesizers, but currently all of them work only in console mode (except Emacspeak, which works from within the Emacs environment). The Gnome accessibility project is working on a screen reader for Gnome, called Gnopernicus ( http://developer.gnome.org/projects/gap/AT/Gnopern icus/index.html). Linux figureheads like Alan Cox are helping to write requirements for an adapter-ready kernel ( http://www.speechinfo.org/fdawg/). SuSE Linux automatically detects braille devices during installation, making it possible for visually impaired users to install Linux without sighted assistance. For users who do not require audio output, screen magnifiers, larger fonts, icons, and mouse pointers are available in both KDE and Gnome, in addition to other accessibility features.

For hearing impaired users, the ability to have visual cues, such a visual bell, is crucial. For those with mobility impairments, features like Sticky Keys, Toggle Keys, and Bounce Keys, as well as on-screen keyboards, can make it easier to type. It is also possible to configure a standard keyboard to take one-handed input. Voice recognition systems, such as Open Mind Speech or ViaVoice Dictation may be a more viable option for some. Users with epilepsy, which might be triggered by on-screen animations, must be able to turn off features like window opening/closing animation. For more information on these options, as well as those mentioned for visual impairments above, refer to the Linux Accessibility HOWTO ( http://www.linuxdoc.org/HOWTO/Accessibility-HOWTO/ index.html).

In June 2001, the US government enacted Section 508 ( http://www.section508.gov/), which requires that all government IT tools and services be accessible. This means that the government won't buy and IT tool or service unless it is compliant with the criteria outlined in Section 508. Thus, from a purely business perspective, it makes sense for the Linux community to address the accessibility issue. From the user's point of view, it makes even more sense. For example, a visually impaired Windows user might choose JAWS for Windows (a commonly-used Windows screenreader), which is $795 US. Alternative Windows screen reading applications are less expensive, but some require a hardware synthesizer, which can cost in excess of $1600 US. Users must also purchase the Windows OS. However, a Linux user can get the Emacspeak screenreader and ViaVoice software synthesizer (not to mention Linux), for FREE. This is one of the reasons that many visually impaired users, at least, are making the move to Linux.

Also consider those of us who wear glasses and use lower resolution and/or larger fonts/icons so that we can see the screen better - these are accessibility features. Someone with a broken arm could take advantage of dictation apps or a one-handed keyboard - also accessibility features. What about the next time you're in a noisy airport working on your laptop, and you can't hear the audio bell that alerts you to a new email? You'd turn on the viusal bell instead - again, an accessibility feature. Making Linux doesn't just benefit those who are "handicapped," it benefits everyone.

As usual there is HOWTO that addresses this "ask slashdot" question. It is the Linux Accessability HOWTO sheesh

Freeing RAM is the main concern with removing unnecessary items, here is a link in the Kernel HOWTO pointing to this 8.2 Huge or slow kernels .

And yes, I did mix that up (dyslexia) in that compile as much as modules and not into kernel to free more memory of unused device drivers. I run a laptop, so SCSI is compiled as a module because I only use SCSI when I'm burning CD's which is maybe twice a month. And yes you get the side benefit of being able to restart devices, debug, recompile patches better if compiled as modules.

I think the only problem w/ Linux is that here arent enough programs, because Linux geeks expect everything for free. If we start to show that you can sell things for linux, then more stuff will be developed, and BAM!, there you go.

Nope! x86 architecture has exactly one address space. If you're talking about putting that geforce of yours into ppc or alpha then the address spaces might be physically different(not sure).

In x86, however, everything resides in one address space and you can access everything by it's address directly(highly unportable). That Geforce is going to get its 32mb(probably more) slice somewhere in the common space.

Yes.. I've written a driver for a videocard before..

For a linux side of the things look at address translation explanation by linus here. Specifically the part about pci-memory and the exception for x86.

I had a little trouble figuring out how to get the /boot partition ahead of the Windows one. I found a couple ways to do it. I originally did the Linux first and deleted everything except the /boot. I installed Windows then FreeBSD and finally Linux. The other way I tried was to install Windows first and move the partition with Partition Magic and then FreeBSD and Linux.

Using lilo to boot Linux and FreeBSD

Using Boot Easy to boot Linux and FreeBSD

One option you might look into rather than USB cameras would be to use video capture boards and bullet cameras as your capture device. Most small cameras will get you from 360 to 380 lines of resolution in colour and usually 420 lines in B/W. They're fairly cheap and really rugged. In fact almost any CCTV camera ought to work fine as most output a composite video signal. Most run on a 12v DC power supply so you can even run them off batteries if you really wanted or needed to. You can bet small CCTV cameras will give you a bit better of a video signal than USB cameras and most capture boards allow for uncompressed video that you can pipe into whatever streaming codec you are hip to use. A board and camera combo might cost you from 150 to 200$. Here's a link to compatible capture boards.

1. XP has a different (though open and standardised) bootloader removing the task from BIOS. Dualbooting is more difficult under XP.

Bullshit. XP uses the exact same bootloader as NT4, 2K, and even WinME (well, sure, with some minor cosmetic changes and performance enhancements, but for all intents and purposes it's the same loader written way back in 93/94-ish for NT4). As well, it's never been hard to dual-boot with the NT-Loader. There are two mini-howtos on LinuxDoc that outline two different ways of dual-booting Linux with NT (using LILO):

1. Using Lilo, either start linux, or start NT/ME/2K/XP, thus bringing you to the NT-Loader screen (in 2K, ME, and XP (and possibly NT4, though it's been a long time since I've played with that), if NT-Loader only has one entry, you won't get a menu and it'll just directly load that one entry)
2. Using NT-Loader, either start NT/ME/2K/XP, or start linux, thus bringing up the LILO prompt

2. The usual obscuring of office formats. While RTF is usable the new version bloats to about ten times the size when containing images - nice one, M$.

First off, what does this have to do with Windows XP? You've obviously confused Windows XP with Office XP. Second, this is not new, and it's unlikely it'll change (although with Microsoft moving more and more towards XML, don't be surprised if you start seeing XML-based Word documents that can thus be easily parsed by anything that understands XML).

Given all the above, I still don't see how these are anti-open source. Hell, even WPA isn't "anti-open source". It's anti-piracy, sure, but I don't see how it has anything to do with open source at all.

btw 2 years ago i took a generic laptop (Twinhead Slimnote) and installed RH 6.2 w/ no hardware problems i am sure the latest
RH versions support the hardware in the laptop of your choice.

roll your own laptop ? re-invent the wheel ?

eramm

Ximian has an answer for that: Red Carpet (usually) works great. Lately they've had some signature deficiencies, and there have been some dependencies that got missed WRT GIMP modules last night.

Beyond that Linux has much more comprehensive on-line documentation than Windows, in my estimation.

Case in point: I bought a Mitsume IDE CD-RW drive for my wife's school. I couldn't make any of the Windows software recognize it as a writer. I swapped it out for an older Mitsumi drive in my Linux box, and it worked just fine! Go figure. (I took the older drive to school, and *it* worked!)

I think a previous poster was right: Windows is thought to be easy because it's ubiquitous. People mistake familiarity for ease. Bruce Tognazzini talks about this idea.

Linux can natively be configured to enforce disk quotas and (with more difficulty) manage network bandwidth without any special virtual server software. Also the native unix process scheduling algorithm does reduce the priority of CPU bound tasks. The getrlimit(2) system call can be used to set various limits per process (not per virtual server unless the virtual server runs as one process I guess.) I know of no way to specifically limit disk bandwidth on Linux.

Freeware such as s_context and user mode linux provide no control over how much resources one virtual server gets over another besides disk usage. Other limited resources like CPU, disk and network bandwidth (RAM?) are shared just like they would be shared by separate processes under a single Linux system.

FreeVSD is not a virtual server, but a collection of scripts, binaries and multiple copies of hard-linked read-only filesystems for the common system environment. It is has the best chance for winning the total performance award but has no extra features for resource limits between systems.

True virtual machines. (E.g., vmware) provide very good isolation, but this leads to little sharing of excess unused resources between virtual servers I believe. They also have poorer performance in general because so much emulation is done.

The commercial, proprietary Private Server product from Ensim seems good from the marketing blurbs which say that they have "their own guaranteed share of the servers resources, including CPU, memory and bandwidth". I wonder what the performance penalty for this is and how much does it cost? Can anyone comment?

I was always interested in doing this type of work-technical writing. Where can you point me to explore this area of endeavor?

I can't offer much since it was never a great interest of mine, but I can offer a suggestion. Do something in the field! I don't have a degree in educational technology: I got my last two jobs by showing some of the software/web stuff I'd done in the field.

Write some documentation, perhaps for Linux, *BSD, or anything else that badly needs it. Visit the Linux Documentation Project ToDo list and see what needs doing. Perhaps you'd rather write a tutorial for some commercial Windows or Macintosh program- that works too. That documentation is your resume: if you can make some horribly hairy Linux system tool or the Curves command in Photoshop clear and understandable, people will take notice.

Eric

The original poster was suggesting that /bin, /usr/bin, and such are obsolescences in the same way that the 16-bit code (and non 64-bit clean code) in Windows is. I was explaining why that is not the case. You are being a unnecessarily insulting jerk.

Does that explain everything?

If you're talking about C:\Windows, you should also set up a Linux box and mount / over a network.

OK.

well link tags are commonly used to add style sheets. But this is not what we are talking about. The only real way to explain it is to get a new nightly (or 0.9.5) of mozilla, user the view menu select show/hide --> site navigation bar.
And select only as needed.
Then go to something like http://www.linuxdoc.org/HOWTO/mini/Outlook-to-Unix -Mailbox-2.html
and check out the bar that appears with the next previous buttons.

Consider the range 0x00-0xFF (inclusive). Randomly pick a number in that range. Set that to your file system and get amazing results.

Really, this is getting pathetic. We've a few too many pointless and irrelevant (come on, a story based entirely off a screenshot?!), or hopelessly outdated subject matter into the on /. the past couple days.

Yes I am being a troll and I apologize, but I want to know why intelligent stories (maybe a couple that I've sent in) get rejected, and this nonsense gets posted in the main column. Get real! EVERY Linux distro I have EVER used starting with Slackware 3.0 has always recommended using ext2 as the Linux Default. (You'll notice certain partitioning utilities make this clear.) How can anyone disagree that this is a newbie Linux question? Posted on /.'s front page! Easily answered if someone would simply visit a documentation resource and RTFM.

The Ask Slashdot forum has traditionally seen questions that are difficult to answer and need expert advice. They usually lend some insight into a problem or ask questions many of may not have considered.

This guy just asked a question regarding Linux installation. What the hell? Next thing we'll see is an Ask Slashdot question with the following:

"Hi, I wanted to ask the /. community. I'm installing WindowsXP on my server where I'm serving Samba and web pages for my friends. The installation program asked me if I want to use FAT or NTFS. WHICH ONE DO I USE!? I'm so confused about what partition type to use! I hope the /. community can lend some insight!"

Go ahead and mod me down. I don't care, but I think there aughta be another voice expressing irritation at the reduced quality for a service that may become subscription in the near future (or drown us in ads). I don't think that's major news or anything someone in #linuxhelp on the Undernet couldn't have answered with a flood of flames.

I don't know if you are serious are not, but I am going to assume you are.. I don't think I would have ever thought of that lol.. Do they really have that much of a voice?

I am serious, indeed.

And, yes, the librarians have that much voice. In fact, SunSite/Metalab/iBiblio (is the same thing; they change anmes every other year or so, because they change sponsors) is actually an on-line library. They host, for example the Linux Documentation Project (LDP) . and many more goodies.

And of course they have a big voice over the Congress. Where do you think the Congressman get their p0rn? At the Library of Congress, off course!

Well, maybe not. But it is a funny thought.

If you are new to installing your own kernel, or you want to get started on kernel programming, see http://www.kernelnewbies.org/ and join them on IRC in #kernelnewbies on the Open Projects Network.

Also helpful to newbies, or to convince you it's worthwhile to help with testing, is my other article Why We Should All Test the New Linux Kernel.

And finally there is the Kernel HOWTO.

If you'd like to program or debug the kernel, I recommend a couple of books:

• Kernel Projects for Linux by Gary Nutt, ISBN 0-201-61243-7 - this is a lab manual with hands-on kernel programming projects that address a variety of kernel components
• Understanding the Linux Kernel by Bovet, Cassetti, and Oram, ISBN 0596000022 - I bought a number of kernel programming books, and this seemed to be the best written of the books that covered recent kernels. It's mainly 2.2, with short addenda in each chapter for the changes that were expected at the time of writing for 2.4

I think systems like directFB are a step backwards. XFree86 already has shared memory and direct draw extentions (see vmware), designed for high speed local graphics. When running remotely, the X library falls back to it's normal protocol, and the apps slow way down, but still operate. The network transparency of X is far, far too usful to encourage a crop of apps that can't use it.

• 8mm video cassettes. Small, better video quality. But not good enough to make anybody switch from VHS.
• Every PDA ever invented, from the ancient WorkSlate to the latest "smart" phones. The idea isn't bad in itself, and there have even been a few successes. But there still isn't enough "added value" to make most people switch from paper-inscription technology.
• Spreadsheet software. The vendors have changed, but everybody still uses the klunky old macro language designed two decades ago for VisiCalc. Not even Microsoft could get people to accept a more elegant spreadsheet language.
• Desktop software. Yeah, I'd rather be using KDE or GNOME or even JavaStation. Anything but MS bloatware. But how to convince everybody to give up their Word/Excel/Powerpoint skill base?
• QWERTY keyboards. Yes, they're inefficient. (Although the inefficiency didn't actually come from a deliberate attempt to slow the machine down.) But who's going to learn typing from scratch?

the only question is how to "produce" one in less than 3 month...
I didn't found the HOWTO-make-a-sister-in-less-than-9month at linuxdoc.org...
maybe i should switch to debian so I can apt-get sister...
X

This piece made some interesting points about linux losing the desktop. It is certainly true that Outlook/Exchange Servers are awesome (though buggy and insecure) business applications, and the Linux world has no real equivalent. But the latest Star Office is adequate for most simple to intermediate documents. (The comment about Linux office apps not having a good spellchecker is not true for the latest Star Office. And besides, even if it were true, Spellcheck is hardly an important feature in the office environment---it never has been a particularly efficient way to correct mistakes). Linux now has many free components: a first class browser (Mozilla), an almost first class office app (Star Office), several decent mail programs, adobe acrobat, a free almost firstclass cdburn program, a first class windows interface (KDE), an almost first class graphics program (gimp), real player, several instant messenger programs (kyahoo, jabber), fairly good hardware detection (finally), a firstclass documentation project (which admittedly is not tightly integrated into linux--one needs to use search engines (my favorite link is Linux How-to Index .
The main weaknesses, as I see it are 1)poor font support (which I've been told has been fixed in the latest KDE release), difficulty installing things (although rpm's are not really that hard once you figure it out), and difficulty upgrading (there is no equivalent of windows update, although one could upgrade to a later distribution release). Also, Mozilla seems not to have default support for plugins (although Netscape 6.1 does include this support). Another significant problem is Windows/Linux compatibility issues. How do you dual boot? How do you share files? How do you set up samba permissions? Another basic problems has to do with the difficulty of setting up users and LDAP support. These things are not insurmountable. Basically, if a sys admin were to set up Linux and the network connections before handing it over to the user, I could teach any user to be productive in Linux in 2 hours or less. Guess what, guys? The same is true for Windows desktops as well. Robert Nagle, Austin Texas idiotprogrammer

Suppose you want to steal someone's identity, credit card info, bank statements, ad nauseum. Passport is the IDEAL way of doing this and one does not even have to involve directly attacking the servers. For instance see the following site:

http://www.passport.com@www%2elinuxdoc%2eorg...

Because that URI is standards compliant, it will work in any browser. Furthermore, any of the letters in the hostname can also be substituted using the %hex hex notation. So call me paranoid when I see this as being a great benefit to computer criminals...

Stop dreaming, no consumer ISP is going to let you send BGP annoucements into their network. Can't blame them though : BGP in novice hands is a very convenient way to fuck up spectacularily.

Go for proxy-based load balancing for the HTTP traffic, go for TEQL (loadsharing over multiple interfaces queuing in order to split the rest, use RIP to announce availability of outbound connections. Basically, you can do almost anything you want with outgoing connections, but you're pretty much stuck if you want inbound failover.

Give me a consumer DSL access provider that does BGP and I'll be a happy man ! Right now, no one gets it unless getting access through large-ish leased lines with lavish support and matching price tag.

http://www.linuxdoc.org/HOWTO/Unix-Hardware-Buyer- HOWTO/

Usually, when a new kernel is out, I download the patch, apply it, use the most recent config file, which I go through some, but not necessary through all umpteen options and this usually worked just fine...I don't really have the expertise to up/downgrade the compiler and the related libraries.

From the kernel Readme:

SOFTWARE REQUIREMENTS

Compiling and running the 2.4.xx kernels requires up-to-date versions of various software packages. Consult ./Documentation/Changes for the minimum version numbers required and how to get updates for these packages. Beware that using excessively old versions of these packages can cause indirect errors that are very difficult to track down, so don't assume that you can just update packages when obvious problems arise during build or operation.

Many sources recommend that if you don't have a critical reason to upgrade your kernel, don't. I will follow in this recommendation, as the old adage, "If it ain't broke, don't fix it," is especially true if you don't know how to fix it. Installing/uninstalling a program is far more mundane than upgrading a kernel. If you're not comfortable upgrading (downgrading) gcc, and your kernel is performing well as is (or was working fine, as the case may be), you aren't a strong candidate for a kernel upgrade. Learn the basics and fundamentals of the OS before diving headfirst into something as critical as kernel patches. Distribution providers usually do extensive testing on the kernel version included to ensure stability and compatibility.

If you're determined to go ahead with this, Linuxnewbie.org has a decent amount of information, linuxdoc.org and linuxnow.com have HOWTOs on virtually any subject (including the GCC HOWTO, although I can't say with any degree of certainty that gcc is at fault here), and the website of your distribution is probably another good source of info. If you still have problems, and turn to the net for answers, make sure to state specifically each step you took thus far and try to detail the problems you encountered, providing logs and diagnostic output when possible. In doing so, you or someone else may find you skipped a crucial step. Kernel upgrades are not to be taken lightly and, as you have experienced, can quite possibly be more trouble than they're worth.

http://www.linuxdoc.org
should get you started. A VERY good book on the subject, geared towards I want to do "X", but I don't know the command, is "Linux Essential Reference" by Ed Petron, published by New Riders.

Although, given that we usually don't read articles before going totally non-linear, it's probably unrealistic to expect people to read the howto.

Hi, and welcome to the club. I am glad that you are now considering the transition. Just to give some of my credentials: I am ungraduate at a fairly well known university, taking computer science. I also have about 3 years of summertime employment in ASP, VB, and minimal web server management.

Well now to the point. I have made the transition to linux environment about a year ago -- and I now consider myself an average user/admin. The main question in performing the transition is to ask yourself, how much unix/linux/BSD you already know. If the answer is none -- I recommend to not do an immediate transition, but instead get a separate computer, install a distro of linux, and just play with it, to get stuff figured out and working. This step will take a few weeks of devoted time. The main thing is DO NOT GIVE UP. Linux has all the features, but if you do not know where they are, stuff won't work. In which cases post questions to those who know. Or even better yet get a book. $50 will give you up front useful info on networking, and may tell you how to get the webserver running. I am using the book Using Linux, Sixth Edition SE. It has been a lifesaver, although it is oriented towards redhat, debian, and caldera versions.

Some usefel links:

RedHat Linux

Mandrake Linux

Debian

Linux Documantation Project

I recommend downloading (or purchasing) one of the distros above. The first two try to be really user friendly, and do a decent job at it. The third one is a bit more cryptic, but you will probably want that version for your real server, since it does not have a ton of annoying unnecessary flashy things, like graphical bootup. Besides the install the real diference is update management, which both redhat and mandrake do using rpm system. It is easy to figure graphical rpm. Once you get comfortable with that, consider using that book that yau bought, along with linuxdoc (the fourth link) to figure out how to get all that networking, like VPN, DNS, etc, using the configuration files -- the only good way of setting up the network.

After you figure out basic administartion, Try getting some simple pages to learn apache.

Apache web server
Perhaps a book on apache Perl and PHP programming might help. Do not actually know any specific titles. Basic idea is the same as in IIS. There is a public directory, similar to inetpub\wwwroot. where you can put the files. I believe that PHP is most similar to ASP. And since you did not use SQL server for database access, but Access, I assume that you do not need the speed of a full blown server. In this case MYSQL will do the trick. For something more significant you should check out Postgres db, or a commercial product such as db2. Learning these will take some time, but remember, these things have been written with an simplicity in mind. It just takes a little bit, to see where this simplicity is.

Well this msg is already too long. To sum it up, do not throw away your old system yet. Take time to learn linux, and in a little time you will possess the necessary skills to do transition. As for the tools that will make the transition for you, I have not heard of them, however they probably do exist. And starting somewhat anew is not always a bad thing. A lot of us hope that some version of windows will be written anew, but I doubt it will happen.

Well, good luck! The switch is not easy, but there are plenty of benefits in the long run. Do not give up, and you will see them soon.

One way to go might be an inexpensive, but not underpowered PC, with a PCI Firewir-- er, IEEE-1394 card.

Buy a bunch of cheap, identical IDE HDs, and put them in IEEE-1394 cases (~$150/ea.). Compile yourself some bleeding-edge Linux-1394 support, plug in your HDs, run XFS as the filesystem, and use software RAID. Because you said this is just for storage and media access, you probably don't need the currently limited FireWire hot-plug support and possibly still currently limited RAID hot-swap support.

For more on software RAID, IBM has a nice two-part article (1, 2) on it.

One way to go might be an inexpensive, but not underpowered PC, with a PCI Firewir-- er, IEEE-1394 card.

Buy a bunch of cheap, identical IDE HDs, and put them in IEEE-1394 cases (~$150/ea.). Compile yourself some bleeding-edge Linux-1394 support, plug in your HDs, run XFS as the filesystem, and use software RAID. Because you said this is just for storage and media access, you probably don't need the currently limited FireWire hot-plug support and possibly still currently limited RAID hot-swap support.

For more on software RAID, IBM has a nice two-part article (1, 2) on it.

I ran Token Ring on my personal desktop and a server at work for over two years without any incidents requiring sysadmin intervention.

Here's how I did it:

• check out the development site: http://www.linuxtr.net. This site is quite good about posting patches and information for the tr module.
• get a static IP! The Linux token ring driver was not at all happy with DHCP
• double-check your network settings--we had dire threats about setting our MTU right (yep, even in Windows), so I ensured that I knew what I was doing before plugging into the network
• get recent linux kernels! I used Red Hat, who didn't ship token ring support, so needing to recompile the kernel anyways, I always picked up the latest kernels. For a driver that few people apparently use, there have been a lot of patches that made their way into the kernel. I ran 2.2.19 on the server, and 2.4.8 on my desktop. I don't know what Debian gives you, but I would consider recompiling your kernel.
• read the docs! Unfortunately the Token Ring HOWTO appears to have forked down two paths: out of date (http://www.linuxtr.net), and further out of date (http://www.linuxdoc.org). I wrote the author of the newer version (Tom Gall), asking him to submit the updates to the LDP, but despite his assurances it never happened. Sigh.
• with IBM TR cards, you have to run some program that changes the firmware settings to get it to run in Turbo 16/4 mode, or some such arcana

Not letting go of what you have created is probably one reason: Software-prj-mgmt-HOWTO.

In the top-level directory of the SDK, there should be a simple text file named README or README.txt. If it isn't there the user has to go hunting around in a bunch of incomprehensible directories searching for documentation and gets annoyed. This README file should point to the location of the main documentation.

The main documentation should consist of, at minimum, a tutorial and a reference. One of the first things that should show up in the tutorial is a description of the directory hierarchy of the SDK (this could be in the README instead). It seems many SDK creators are so familiar with the structure of their own SDK that they forget to tell their users about it, leaving them to wander about in a sea of incomprehensibly named files and directories. You should describe the purpose of each directory (and possibly even the files inside). If you're developing for Unix or Java, it helps to use a conventional naming scheme for your directories -- bin/, lib/, src/, and so on. (For Windows or Macintosh you might want to use longer, descriptive names if you fear your users will be unfamiliar with terse Unix-style names.)

Some SDK writers just toss a bunch of code examples in a directory somewhere, with no explanation of the who, what, when, where, why and how of using them. (Sometimes they don't even have comments.) The tutorial should have a prose description of the code examples. You want to aim for a literate programming style. Make sure the tutorial is clear to newbies. Have someone read it over before you release it. I don't mean having one of your fellow SDK developers read it for typos (although you can do that as well); have someone unfamiliar with the product read it and make sure it is understandable.

The reference documentation should have complete, detailed explanations of every class/function call/XML element/whatever. If possible, use a standard format appropriate for your platform (e.g., man pages, Javadoc). In all cases you should try to use a format which is as non-proprietary as possible (e.g., HTML is good, PDF is okay, MS Word is pretty dubious).

Other documents may not be mandatory but can be nice to have: a FAQ, a rigorous specification, a style guide, a tool guide.

The user should not have to modify files in the SDK directory itself. I always like to keep a software package as pristine as possible, so I don't have to keep wondering whether I screwed up some configuration file or not. If you must have files modified in the SDK directory structure, keep it confined to as small a location as possible (a single configuration file, or at least a single conf/ or etc/ directory). Make sure it is easy for the user to compile/execute their own files/programs outside of the SDK directory.

If you plan on making releases (especially beta releases) often, it is nice if users can have multiple versions of the SDK installed at the same time. Also, try not to completely reorganize the SDK with every new release. Pick an organization and stick to it.