Slashdot Mirror

http://elbitz.net/home.php is good, but they only open up registering every now and then (I remember I waited like 2 months to get my user). In general, though I just use the same popular torrent sites for everything else I get for books, too and I've gotten 6.28GB that way. Also, appear to have just found a .pdf with a huge list of ebook sites (and one for how to swear in all languages!). Haven't tried any of them, but go for it:
O'Reilly online http://www.oreilly.com/openbook/ | http://sysadmin.oreilly.com/ Computer books and manuals http://www.hoganbooks.com/freebook/webbooks.html | http://www.informit.com/itlibrary/ | http://www.fore.com/support/manuals/home/home.htm | http://www.adobe.com/products/acrobat/webbuy/freebooks.html The Network Book http://www.cs.columbia.edu/netbook/ Some #bookwarez.efnet.irc links http://www.extrema.net/books/links.shtml Some #bookwarez.efnet.irc fiction http://194.58.154.90:4431/enscifi/ Pimpas online books (Indonesia) http://202.159.16.55/~pimpa2000 | http://202.159.15.46/~om-pimpa/buku Security, privacy and cryptography http://theory.lcs.mit.edu/~rivest/crypto-security.html | http://www.oberlin.edu/~brchkind/cyphernomicon/ My own misc online reading material http://www.eastcoastfx.com/docs/admin-guides/ | http://www.eastcoastfx.com/~jorn/reading/ Computer books http://solaris.inorg.chem.msu.ru/cs-books/ | http://sweetrude.net/~cab/books/ | http://alaska.mine.nu/books/ | http://poprocks.dyn.ns.ca/dave/books/ | http://58-160.skarland.uaf.edu/books/ | http://202.186.247.194/~ebook/ | http://hooligans.org/reference/ Linux documentation http://www.linuxdoc.org/docs.html FreeBSD documentation http://www.freebsd.org/tutorials/ Sun documentation http://osiris.imw.tu-clausthal.de:8888/ | http://uran.vvsu.ru:8888/ SGI documentation http://newton.unicc.chalmers.se/ebt-bin/nph-dweb/dynaweb;td=2 | http://techpubs.sgi.com/library/tpl/cgi-bin/init.cgi IBM Online Redbooks http://www.redbooks.ibm.com/ Digital Unix documentation http://www.unix.digital.com/faqs/publications/base_doc/DOCUMENTATION/V40D_HTML/V40D_HTML/LIBRARY.HTM Filesystem Hierarchy Standard http://www.pathname.com/fhs/2.0/fhs-toc.html | http://www.linuxbase.com/ UNIX stuff http://ww

I just purchased a Radeon X1300 for a silent system (Sapphire uses a large heat sink, no fan).

I am very disappointed that there is no ATI Linux driver for it. It works with Vesa but that is far from satisfactory (no Xv for instance). I asked ATI when a driver may be available and got the following non-answer:

The Linux drivers available from ATI are provide are "as is". You may be able to get further assistance from the Linux community at the links below:

http://www.linux.org/help/index.html
http://www.linuxdoc.org/
http://www.xfree86.org/

It sure looks to me like ATI is not interested in Linux business.

First the setup: it is a Pentium 233 MMX (P1, not P2) with 64 MB of ram. It was first setup with Slack 9.1 a year ago. I did a clean install when Slack 10 came out and all Slack kernels have software RAID enabled by default, so it was recognised automatically. The two drives are quite different: one Maxtor 7200 rpm drive and a WD 5400 rpm drive that have ~ 1 GB difference in size. This computer does not even have a monitor connected to it.

Now the recommendations:
-Read ALL How-To's related to RAID, you can all get them at http://www.linuxdoc.org/ and either print them or have them quickly available on another computer.
-Be sure you have raidtools installed, it's a standard slack package.
-All partitions have to be the exact same size and of the "Linux raid autodetect" type. The software RAID on Linux is partition based, not disk based, which makes it more flexible.
-All drives have to be Master on an IDE channel, no slave drives (or else it will very slow), so 8 drives = 8 IDE channels = 3 additional controllers (or 2 if you have an onboard RAID controller). At this price, it could be interresting to get a 3ware hardware based raid card.
-NEVER, EVER run a hardware RAID array on cheap Promise RAID controllers (but software RAID on regular IDE Promise controllers, OK).

As for drive failure: once, when moving my server, a power cable got unplugged from the master drive on the first IDE port, the server booted without any problem from the second drive which is master on the secondary IDE port. The CDROM drive which is slave on the first IDE port was even detected correctly. I noticed it when I did the lsraid command. I then shutdown the server, plugged the cable back and did the raidhotadd command to rebuild the drive, a little less than an hour later, everything was ok.

It's pretty much what I can think of now...

Maybe not "average", but certainly this works with Linux.

No Java, no JSP man. Simply use PHP for web development.
Forget Java man and go to PHP!

PHP is 4 times faster than Java technology 'JSP' (Java server pages).
This tallies because compiled "C" program is 4 times faster than Java.

Moreover, PHP is getting the object oriented features of Java language.

The real usefulness of Java is 'Java applets' which run on client browsers but on the server side you simply use PHP.

PHP is a very lightening fast object oriented scripting language. PHP is 100% written in "C" and there is no virtual machine as in Java. Nothing can beat "C" language ("C" is a language which never dies!!)

(Java is just another language. The PHP project needs millions of Java programmers who can add the Java's language features like inner classes, static, private, protected and others to PHP. PHP already has some of java' features).
Java programmers will really "LOVE" PHP as PHP class is identical to Java's class keyword.

Read the benchmars of Java JSP and PHP. PHP tops in the speed!!

Read the doc here and mirrors at [1], [2], [3], [4].

No Java, no JSP man. Simply use PHP for web development.
Forget Java man and go to PHP!

PHP is 4 times faster than Java technology 'JSP' (Java server pages).
This tallies because compiled "C" program is 4 times faster than Java.

Moreover, PHP is getting the object oriented features of Java language.

The real usefulness of Java is 'Java applets' which run on client browsers but on the server side you simply use PHP.

PHP is a very lightening fast object oriented scripting language. PHP is 100% written in "C" and there is no virtual machine as in Java. Nothing can beat "C" language ("C" is a language which never dies!!)

(Java is just another language. The PHP project needs millions of Java programmers who can add the Java's language features like inner classes, static, private, protected and others to PHP. PHP already has some of java' features).
Java programmers will really "LOVE" PHP as PHP class is identical to Java's class keyword.

Read the benchmars of Java JSP and PHP. PHP tops in the speed!!

Read the doc here and mirrors at [1], [2], [3], [4].

PHP is 4 times faster than Java technology 'JSP' (Java server pages).

This tallies because compiled "C" program is 4 times faster than Java.

Moreover, PHP is getting the object oriented features of Java language.

The real usefulness of Java is 'Java applets' which run on client browsers but on the server side you simply use PHP.

PHP is a very lightening fast object oriented scripting language. PHP is 100% written in "C" and there is no virtual machine as in Java. Nothing can beat "C" language ("C" is a language which never dies!!)

(Java is just another language. The PHP project needs millions of Java programmers who can add the Java's language features like inner classes, static, private, protected and others to PHP. PHP already has some of java' features).
Java programmers will really "LOVE" PHP as PHP class is identical to Java's class keyword.

Read the benchmars of Java JSP and PHP. PHP tops in the speed!!

Read the doc here and mirrors at [1], [2], [3], [4].

I myself was thinking of using Debian, but I never heard of Festival... I'll definately look it up though.

Festival is a speech synthesis system. Under Debian, just type "apt-get install festival festival-doc" (and festival-dev if you want to use it in your own programs). It has a nice built-in Scheme-based command interpreter.

I think Debian is a great choice for vision impaired users. Take a look at the Debian Accessibility Project and Accessibility HOWTO. There are even speakup enabled boot floppies for Woody (Debian 3.0, the current stable version).

Also, take a look at BrlSpeak, a Braille and Speech Mini-Distribution of GNU/Linux. It is based on Debian, developed by Osvaldo La Rosa, visually impaired Debian user. Let me quote the website:

Objective:
BrlSpeak is here to make life easier for blind people who wish to install a GNU/Linux distribution on their computer WITHOUT ANY assistance from a sighted person. The objective is to create and develop a blindfriendly GNU/Linux distribution enabling a blind user:
a) To preconfigure the braille driver config file before running GNU/Linux
b) To compile the braille driver without having to see (or to hear)
c) To have the braille display immediately operational when booting GNU/Linux for the first time

BrlSpeak can be installed on a FAT partition. There's a 36MB .zip file or CD ISO9660 image for download.

There's also Free(b)deb, a Free(b)soft's specialized linux distribution based on Debian GNU/Linux. From the website:

The goal of the Free(b)deb project is to provide a specialized distribution of complete Debian GNU/Linux operating system including specialized software, which enables blind and visually impaired users to work with computer.

However I'm not sure how to install it and where to download it from.

(I don't talk about Blinux, as it has already been mentioned in the story.)

Good luck.

Good points, but I'd try them in a different (reversed) order.. You'd be surprised how informative some Fine (that's what the F in RTFM is for, by the way) manuals are. If you don't buy boxed distros or don't download the documantation cd's, you can still browse most manuals at the website of your favourite distributions. As many have pointed out, LDP is a fine resource as well.

Just my 0.02 of course...

No Java, no JSP man. Simply use PHP for web development.
Forget Java man and go to PHP!

PHP is 4 times faster than Java technology 'JSP' (Java server pages).
This tallies because compiled "C" program is 4 times faster than Java.

Moreover, PHP is getting the object oriented features of Java language.

The real usefulness of Java is 'Java applets' which run on client browsers but on the server side you simply use PHP.

PHP is a very lightening fast object oriented scripting language. PHP is 100% written in "C" and there is no virtual machine as in Java. Nothing can beat "C" language ("C" is a language which never dies!!)

(Java is just another language. The PHP project needs millions of Java programmers who can add the Java's language features like inner classes, static, private, protected and others to PHP. PHP already has some of java' features).
Java programmers will really "LOVE" PHP as PHP class is identical to Java's class keyword.

Read the benchmars of Java JSP and PHP. PHP tops in the speed!!

Read the doc here and mirrors at [1], [2], [3], [4].

No Java, no JSP man. Simply use PHP for web development.
Forget Java man and go to PHP!

PHP is 4 times faster than Java technology 'JSP' (Java server pages).
This tallies because compiled "C" program is 4 times faster than Java.

Moreover, PHP is getting the object oriented features of Java language.

The real usefulness of Java is 'Java applets' which run on client browsers but on the server side you simply use PHP.

PHP is a very lightening fast object oriented scripting language. PHP is 100% written in "C" and there is no virtual machine as in Java. Nothing can beat "C" language ("C" is a language which never dies!!)

(Java is just another language. The PHP project needs millions of Java programmers who can add the Java's language features like inner classes, static, private, protected and others to PHP. PHP already has some of java' features).
Java programmers will really "LOVE" PHP as PHP class is identical to Java's class keyword.

Read the benchmars of Java JSP and PHP. PHP tops in the speed!!

Read the doc here and mirrors at [1], [2], [3], [4].

...linuxdoc.org ??

I dunno what exactly I'd do if someone DID start leaching, since I have no real contract, but then again, I have the switch in my condo, so all I need to do is pull the plug.

The Linux traffic control stuff is amazing! See Advanced Routing and Traffic Control HOWTO for details on how to make a router that is good about prioritizing traffic. If you have a leech, you could just put his traffic as lowest priority; he could suck all the bits he wants with minimal problems for others.

Also, the social solution can work pretty well. put together some MRTGgraphs of who's using what; then when people gripe, show them where to check who's using what. That way, you aren't the bad cop.

The ``physical source lines of code'' (physical SLOC) measure was used as the primary measure of SLOC in this paper. Less formally, a physical SLOC in this paper is a line with something other than comments and whitespace (tabs and spaces). More specifically, physical SLOC is defined as follows: ``a physical source line of code is a line ending in a newline or end-of-file marker, and which contains at least one non-whitespace non-comment character.'' Comment delimiters (characters other than newlines starting and ending a comment) were considered comment characters. Data lines only including whitespace (e.g., lines with only tabs and spaces in multiline strings) were not included.

Note that the ``logical'' SLOC is not the primary measure used here; one example of a logical SLOC measure would be the ``count of all terminating semicolons in a C file.'' The ``physical'' SLOC was chosen instead of the ``logical'' SLOC because there were so many different languages that needed to be measured. I had trouble getting freely-available tools to work on this scale, and the non-free tools were too expensive for my budget (nor is it certain that they would have fared any better). Since I had to develop my own tools, I chose a measure that is much easier to implement. Park [1992] actually recommends the use of the physical SLOC measure (as a minimum), for this and other reasons. There are disadvantages to the ``physical'' SLOC measure. In particular, physical SLOC measures are sensitive to how the code is formatted. However, logical SLOC measures have problems too. First, as noted, implementing tools to measure logical SLOC is more difficult, requiring more sophisticated analysis of the code. Also, there are many different possible logical SLOC measures, requiring even more careful definition. Finally, a logical SLOC measure must be redefined for every language being measured, making inter-language comparisons more difficult. For more information on measuring software size, including the issues and decisions that must be made, see Kalb [1990], Kalb [1996], and Park [1992].

Note that this required that every file be categorized by language type (so that the correct syntax for comments, strings, and so on could be applied). Also, automatically generated files had to be detected and ignored. Thankfully, my tool ``sloccount'' does this automatically. 2.3 Estimation Models

This decision to use physical SLOC also implied that for an effort estimator I needed to use the original COCOMO cost and effort estimation model (see Boehm [1981]), rather than the newer ``COCOMO II'' model. This is simply because COCOMO II requires logical SLOC as an input instead of physical SLOC.

Basic COCOMO is designed to estimate the time from product design (after plans and requirements have been developed) through detailed design, code, unit test, and integration testing. Note that plans and requirement development are not included. COCOMO is designed to include management overhead and the creation of documentation (e.g., user manuals) as well as the code itself. Again, see Boehm [1981] for a more detailed description of the model's assumptions. Of particular note, basic COCOMO does not include the time to develop translations to other human languages (of documentation, data, and program messages) nor fonts.

There is reason to believe that these models, while imperfect, are still valid for estimating effort in open source / free software projects. Although many open source programs don't need management of human resources, they still require technical management, infrastructure maintenance, and so on. Design documentation is captured less formally in open source projects, but it's often captured by necessity because open source projects tend to have many developers separated geographically. Clearly, the systems must still be programmed. Testing is still done, although as with many of today's proprietary programs, a good deal of testing is done through alpha and beta releases. In addition, quality is enhanced in many open source projects through peer review of submitted code. The estimates may be lower than the actual values because they don't include estimates of human language translations and fonts.

Each software source code package, once uncompressed, produced zero or more ``build directories'' of source code. Some packages do not actually contain source code (e.g., they only contain configuration information), and some packages are collections of multiple separate pieces (each in different build directories), but in most cases each package uncompresses into a single build directory containing the source code for that package. Each build directory had its effort estimation computed separately; the efforts of each were then totalled. This approach assumes that each build directory was developed essentially separately from the others, which in nearly all cases is quite accurate. This approach slightly underestimates the actual effort in the rare cases where the development of the code in separate build directories are actually highly interrelated; this effect is not expected to invalidate the overall results.

For programmer salary averages, I used a salary survey from the September 4, 2000 issue of ComputerWorld; their survey claimed that this annual programmer salary averaged $56,286 in the United States. I was unable to find a publicly-backed average value for overhead, also called the ``wrap rate.'' This value is necessary to estimate the costs of office space, equipment, overhead staff, and so on. I talked to two cost analysts, who suggested that 2.4 would be a reasonable overhead (wrap) rate. Some Defense Systems Management College (DSMC) training material gives examples of 2.3 (125.95%+100%) not including general and administrative (G&A) overhead, and 2.81 when including G&A (125% engineering overhead, plus 25% on top of that amount for G&A) [DSMC]. This at least suggests that 2.4 is a plausible estimate. Clearly, these values vary widely by company and region; the information provided in this paper is enough to use different numbers if desired. These are the same values as used in my last report. 2.4 Determining Software Licenses A software license determines how that software can be used and reused, and open source software licensing has been a subject of great debate. The Software Release Practice HOWTO [Raymond 2001] discusses briefly why license choices are so important to open source / free software projects:

The license you choose defines the social contract you wish to set up among your co-developers and users ...

Who counts as an author can be very complicated, especially for software that has been worked on by many hands. This is why licenses are important. By setting out the terms under which material can be used, they grant rights to the users that protect them from arbitrary actions by the copyright holders.

In proprietary software, the license terms are designed to protect the copyright. They're a way of granting a few rights to users while reserving as much legal territory is possible for the owner (the copyright holder). The copyright holder is very important, and the license logic so restrictive that the exact technicalities of the license terms are usually unimportant.

In open-source software, the situation is usually the exact opposite; the copyright exists to protect the license. The only rights the copyright holder always keeps are to enforce the license. Otherwise, only a few rights are reserved and most choices pass to the user. In particular, the copyright holder cannot change the terms on a copy you already have. Therefore, in open-source software the copyright holder is almost irrelevant -- but the license terms are very important.

Well-known open source licenses include the GNU General Public License (GPL), the GNU Library/Lesser General Public License (LGPL), the MIT (X) license, the BSD license, and the Artistic license. The GPL and LGPL are termed ``copylefting'' licenses, that is, the license is designed to prevent the code from becoming proprietary. See Perens [1999] for more information comparing these licenses. Obvious questions include ``what license(s) are developers choosing when they release their software'' and ``how much code has been released under the various licenses?''

An approximation of the amount of software using various licenses can be found for this particular distribution. Red Hat Linux uses the Red Hat Package Manager (RPM), and RPM supports capturing license data for each package (these are the ``Copyright'' and ``License'' fields in the specification file). I used this information to determine how much code was covered by each license. Since this field is simply a string of text, there were some variances in the data that I had to clean up, for example, some entries said ``GNU'' while most said ``GPL''. In some cases Red Hat did not include licensing information with a package. In that case, I wrote a program to attempt to determine the license by looking for certain conventional filenames and contents.

This is an imperfect approach. Some packages contain different pieces of code with difference licenses applying to different pieces. Some packages are ``dual licensed'', that is, they are released under more than one license. Sometimes these other licenses are noted, while at other times they aren't. There are actually two BSD licenses (the ``old'' and ``new'' licenses), but the specification files don't distinguish between them. Also, if the license wasn't one of a small set of common licenses, Red Hat tended to assigned nondescriptive phrases such as ``distributable''. My automated techniques were limited too, in particular, while some licenses (e.g., the GPL and LGPL) are easy to recognize automatically, BSD-like and MIT-like licenses vary the license text and so are more difficult to recognize automatically (and some changes to the license would render them non-open source, non-free software). Thus, when Red Hat did not identify a package's license, a program dual licensed under both the BSD and GPL license might only be labelled as having the GPL using these techniques. Nevertheless, this approach is sufficient to give some insight into the amount of software using various licenses. Future research could examine each license in turn and categorize them; such research might require several lawyers to determine when two licenses in certain circumstances are ``equal.''

One program worth mentioning in this context is Python, which has had several different licenses. Version 1.6 and later (through 2.1) had more complex licenses that the Free Software Foundation (FSF) believes were incompatible with the GPL. Recently this was resolved by another change to the Python license to make Python fully compatible with the GPL. Red Hat Linux 7.1 includes an older version of Python (1.5.2), presumably because of these licensing issues. It can't be because Red Hat is unaware of later versions of Python; Red Hat uses Python in its installation program (which it developed and maintains). Hopefully, the recent resolution of license incompatibilities with the GPL license will enable Red Hat to include the latest versions of Python in the future. In any case, there are several different Python-specific licenses, all of which can legitimately be called the ``Python'' license. Red Hat has labelled Python itself as having a ``Distributable'' license, and package Distutils-1.0.1 is labelled with the ``Python'' license; these labels are kept in this paper.

Where do I download clues?

Here.

Try using some current Apple products on a daily basis and then get back to me.

Oh, so you're saying they've put a real power switch and manual eject floppies/cdroms onto their computers? That's funny, nearly all the other computer manufacturers seem to be going in the opposite direction...

That sounds a lot to me like the MS fanatics that insist Windows XP/2000 is a lot better than the previous versions (and Linux as well), and I should give their newest version a chance. I've used MS operating systems from DOS 5 to Win98, and all of them have been crappy. DOS was mostly stable just because of the fact that it was mostly only a filesystem driver. If you made a DOS program, you'd have to access the BIOS or hardware directly for graphics/sound/whatever.

BTW six years ago, Apple was cranking out those Beige blocks of cheese that Sculley thought he was going to sell against PCs into Corporate America.

Yeah, yeah, and the goatse.cx guy was living peacefully among a herd of goats. You still haven't specified any reason for me to think that the current Macs are of better design than the ones I used at work 6 years ago. Here, I'll help out: OS X. ;-)

And floppies...we don't need no stinking floppies.

Six years ago I doubt you would have said that....unless you were rich enough to crank out thousands of dollars for a CD burner. ;-) Although that still wouldn't solve my problems with motor eject type drives versus manual.

Oh yeah, how about providing the make/model of your PC *notebook* with the CPU idling features...

It's not a laptop of any kind, it's a desktop, and I'm certain any power mangement features in a desktop are going to be in a laptop too. The motherboard is a Soyo SY-5EMA+ V1.1 (Based on the crappy VIA Apollo MVP3+ chipset--bought it used, so I didn't know what I was getting) with a 500 MHz K6-2.

I think you are somewhat of a new Apple fan--Personal computer (PC) is the term Apple coined for their Apple IIe (IIRC, it was one of their early 8-bit computers anyway...) Really zealous Apple people will flame anyone who uses that term. ;-) --however it's hard to know what to call them... IBM-compatible doesn't really seem to apply anymore.

Before you label me anti-Apple, I'm not really. I just have some issues with their hardware design and the things the main article said. I just had to point out some inconsistencies with your post. I bet if Apple would just sell competitively priced Mac boards and OS X, Macintosh computers would probably have as much market share as Microsoft/IA32 computers. I played around with assembly programming for the 68000 on my Atari ST--much better than Intel's instruction set. Although I guess now the new Macs are all based on some RISC processor...

I talked to some of these folks at LinuxWorld Expo, and it looked like they had things working. Somebody was even selling NICs and boot PROMs. They would be the logical starting point.

Unfortunately, I don't have my bag 'o swag with me here at work, or I might even be able to find the docs.

Also look at the Linux Journal article on LinuxBIOS

http://linuxjournal.com/article.php?sid=4888


http://ltsp.org Linux Terminal Server Project who were using NetBoot, if I remember correctly.


http://sourceforge.net/projects/netboot/

and not sure if you got the netboot howto

http://www.linuxdoc.org/HOWTO/DisklessHOWTO.html
(netboot is linux based, etherboot is bsd based)

Here are the correct links. (Note to self: Drink more coffee, less vodka.)
Jumpstart Design Notes
Redhat Kickstart
Kickstart How-to

Most of the questions you need to be asking at this point (especially "how do I boot a PC over the network?") are answered in this section of the Diskless-HOWTO. It discusses TFTP, BOOTP, and network boot ROM's.

rpm/deb isn't really a problem (you can go other way, too)

First on the block with Sun/Mandrake merger

/opt is in FHS 2.2 at secton 3.12. It begins:

3.12.1 Purpose

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package.

Doesn't look very depricated to me. I think the problem is your FHS link isn't really the FHS; it is the SAG (Systems Administrator Guide), which in section 4.1 clearly says it is loosely based on the FHS.

As for /usr/local, I do agree it should be off-limits to the distribution (besides setting it up if not already present). And packages in the package format of the distribution (e.g. RPM for Redhat, Mandrake, SuSE, etc ... DEB for Debian and any like it ... TGZ for Slackware ... and so on) really should stay out of /usr/local. What /usr/local should be is whatever is local policy (FHS doesn't say it this way). Packages that the administrator really wants to be separate from the package management system, stuff compiled from source, stuff locally developed, all is eligible to be in /usr/local. My guess is the author of the article has no experience doing system administration combined with a decision making role where he might have to choose to do something slightly different than what everone else does.

/opt is in FHS 2.2 at secton 3.12. It begins:

3.12.1 Purpose

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> directory tree, where <package> is a name that describes the software package.

Doesn't look very depricated to me. I think the problem is your FHS link isn't really the FHS; it is the SAG (Systems Administrator Guide), which in section 4.1 clearly says it is loosely based on the FHS.

As for /usr/local, I do agree it should be off-limits to the distribution (besides setting it up if not already present). And packages in the package format of the distribution (e.g. RPM for Redhat, Mandrake, SuSE, etc ... DEB for Debian and any like it ... TGZ for Slackware ... and so on) really should stay out of /usr/local. What /usr/local should be is whatever is local policy (FHS doesn't say it this way). Packages that the administrator really wants to be separate from the package management system, stuff compiled from source, stuff locally developed, all is eligible to be in /usr/local. My guess is the author of the article has no experience doing system administration combined with a decision making role where he might have to choose to do something slightly different than what everone else does.

I understand that this is directly from the FHS.

Not true. This is what the FHS says about /usr/local:

The place for locally installed software and other files. Distributions may not install anything in here. It is reserved solely for the use of the local administrator. This way he can be absolutely certain that no updates or upgrades to his distribution will overwrite any extra software he has installed locally.

/opt is not mentioned as far as I can see. I remember reading that it was deprecated.

/usr/local is not obsolete, and won't be. The only rule is that a package manager (dpkg, rpm,...) should never touch that directory (beyond creating it on a new install).

It depends on the xinerama support for the chipset. For my ATI Rage128 Mobility, there is no support, though I think that other chipsets fare better. Check www.xfree86.org and http://www.linuxdoc.org/HOWTO/Xinerama-HOWTO.html.

The nice part of cracking these days is that you don't really need any skill. A few downloads, and a script kiddie is you!

Hotmail probably isn't that much of a concern, but your email isn't what people are going to go after. Your linux box is a *very* lucrative target, not because of anything that you yourself might have on the hard drive, but because further attacks can be launched from you machine. In the United States, at least, you would be liable for damages from your machine, as you failed to take proper precautions to secure it.

Moreover, it's meaningless that you don't know anyone with the know-how or patience to compromise your system. As a former grey-hat in the industry, I can safely assert that more than 75% of the cases I dealt with weren't instances where someone known to the victim carried out the cracking.

Take thirty minutes, read over the Security Quickstart Howto, and prevent yourself a *lot* of future hassle.

First of all, I would recommend trying the preemptible kernel patch and even the low-latency patch. It seems like an obvious enough suggestion, but some will tell you that these patches should not be used in servers where throughput is important, and that is correct... in some cases. It has been shown, however, that in most cases the preemptible patch increases performance and throughput. I have not heard of any such testing on the low-latency patch, as I am new to it.

In my testing, these two patches have been a big help, especially on my P166 system with 48MB RAM.

Also, you say "faster drives" and repartitioning are not feasible ATM, but how about multiple small drives? As shown in this howto, the linux kernel has support for striping data to swap disks, just by specifying multiple swap entries in fstab.

Then again, if you're not on SCSI, trying to stripe to the swap drives won't be much help anyway, as RAID over IDE for _speed_ usually is just crap.

That last suggestion may not be for you, but definitely try the two patches. It should also be noted that preempt is a compile-time option, and there is also a compile-time option to control the low-latency patch through /proc/sys/kernel/lowlatency. An additional patch may be required to allow these two to work together, but I am unable to locate it currently.

This is already happening. For example, the Linux Documentation Project (LDP) recently added support for Plucker; the LDP now automatically generates Plucker format for all HOWTO, mini-HOWTO, and FAQ documents. The LDP also automatically regenerates the files when the documents are updated. Pluckerbooks has over a thousand pregenerated books and they have links to other sources of Plucker documents.

In fact, I've recently added support for Plucker to my own website. My paper Why Open Source Software / Free Software? Look at the Numbers! also has a Plucker version available. I also generate a Plucker version of my book on writing secure programs. So I'm speaking from experience here.. Plucker works well for at least some content providers!

Downloading the tools and then generating the Plucker format is easy if you can use a command line interface. Plucker's format is essentially compressed HTML, so for most websites it's easy to support. Plucker is GPL'ed, so its components (the generator and reader) can't be "taken away"... and they are free for any use. This combination of free reader, free creator, and no risk (because it can't be taken away) makes Plucker much more appropriate for many content providers. The Plucker viewer itself is quite capable, for example, it supports larger fonts for headings, bold text, italics, hypertext links, images, horizontal rules, and tables (formatted as one cell per line). If you click on a hypertext link to a page not included in the file, Plucker will show you the URL so you can look it up later.

Installing just the viewer is actually quite easy for end-users; you can download just the viewer from the Plucker website, and Plucker users can beam the program to other users of Palm-compatible PDAs. Generating Plucker files is pretty easy from the command line, but I do agree that currently grandma may have trouble generating documents on her own. It's also true that getting "new" versions of Plucker documents isn't automatic; you have to do something to get an update. The Plucker folks are actively working on solving these problems, e.g., creating GUI interfaces. Since Plucker is already a really nice viewer, and other work is already ongoing, I think that the Plucker developers will quickly succeed in making it easier for naive users to generate their own documents.

This is already happening. For example, the Linux Documentation Project (LDP) recently added support for Plucker; the LDP now automatically generates Plucker format for all HOWTO, mini-HOWTO, and FAQ documents. The LDP also automatically regenerates the files when the documents are updated. Pluckerbooks has over a thousand pregenerated books and they have links to other sources of Plucker documents.

In fact, I've recently added support for Plucker to my own website. My paper Why Open Source Software / Free Software? Look at the Numbers! also has a Plucker version available. I also generate a Plucker version of my book on writing secure programs. So I'm speaking from experience here.. Plucker works well for at least some content providers!

Downloading the tools and then generating the Plucker format is easy if you can use a command line interface. Plucker's format is essentially compressed HTML, so for most websites it's easy to support. Plucker is GPL'ed, so its components (the generator and reader) can't be "taken away"... and they are free for any use. This combination of free reader, free creator, and no risk (because it can't be taken away) makes Plucker much more appropriate for many content providers. The Plucker viewer itself is quite capable, for example, it supports larger fonts for headings, bold text, italics, hypertext links, images, horizontal rules, and tables (formatted as one cell per line). If you click on a hypertext link to a page not included in the file, Plucker will show you the URL so you can look it up later.

Installing just the viewer is actually quite easy for end-users; you can download just the viewer from the Plucker website, and Plucker users can beam the program to other users of Palm-compatible PDAs. Generating Plucker files is pretty easy from the command line, but I do agree that currently grandma may have trouble generating documents on her own. It's also true that getting "new" versions of Plucker documents isn't automatic; you have to do something to get an update. The Plucker folks are actively working on solving these problems, e.g., creating GUI interfaces. Since Plucker is already a really nice viewer, and other work is already ongoing, I think that the Plucker developers will quickly succeed in making it easier for naive users to generate their own documents.

You mean you want to build a linux-based kiosk?

Check out the XFree86 Font De-uglification HOWTO.

It has a lot of information on font rendering in X11 and following its advice can really make a big difference in improving the look of the fonts, (especially in Netscape I found).

-Bruce

You can just copy an existing system. (I.e. keep a hard-drive around with your base config).
If you've never done this before, the disk-upgrade howto gives you all the info you need.
You can also have several configs TAR'd up all nice and neat and just pull down whatever you need with a 'nix boot disk (or have 'em on CD).

K12linux.org is a great site for info and their Red Hat Distro. I have meet Eric and Paul a few times, really great people. They have developed quite a following because they are making implimenting a thin client setup really easy.

K12ltsp is based on www.ltsp.org which is in version 3.0 right now. I use this software to set up computer labs in non-profits in and around Portland. We are a NP ourselves) It is gaining maturity, system administration is barely more work than working on a box running programs locally. You need to have DHCP running on the server, TFTP setup, and allow it to serve applications to remote X-Clients, and that is about it.

Here are some links for further reading on what others have done.
umn
olinux
solucorp
askslashdot
gbdirect
tucows
XDM

The obvious anser is right here. That is assuming of course that linux is a viable answer. If you're talking Windows thin client (I hope you're not, since you did post this to /.) Citrix is your only real option.

I'd just put the spy code in the Bios. What else is distributed on every computer, and run every time they boot?

Ya, but it's never used after boot, so would it still be useful?

-yb

Kernel HOW-TO
CD Burning HOW-TO
ZIP Drive Mini HOW-TO

Now my first impression after reading your post, what benig so open minded about things, is that these HOW-TO's are most likely not for you. Much in the same way that Windows based OS'es are not for all of us (Read: Choice!).

However, you're not limited by that, wanna try Linux? Buy a distro, Redhat, Suse and Mandrake are all quite mature, quite *graphically* configurable and meant for end-users (Read: Binary Updates). Additionally if you spend the few bucks, (certainly not nearly as much as XP), you get something in the realm of 30 days technical, live installation support - I know many people who have used these services and been quite happy.

So as to maintain the topic thread, I would also suggest that you're miles off topic as MS releasing the source to a fellow such as yourself would make no difference whatsoever. Additionally, there is a huge difference between configuring a kernel, which is what you need to do and kernel hacking which is most certainly something you could never do

As for your final comment, agreed Linux should be easier for everyone, admittedly the community is not there yet. However, the above mentioned distributions have come a long way in the last year, patience. If you want easy and *NIX then don't be cheap, buy a Mac.

God, I can't believe I just did all that for such a trollish comment...

Kernel HOW-TO
CD Burning HOW-TO
ZIP Drive Mini HOW-TO

Now my first impression after reading your post, what benig so open minded about things, is that these HOW-TO's are most likely not for you. Much in the same way that Windows based OS'es are not for all of us (Read: Choice!).

However, you're not limited by that, wanna try Linux? Buy a distro, Redhat, Suse and Mandrake are all quite mature, quite *graphically* configurable and meant for end-users (Read: Binary Updates). Additionally if you spend the few bucks, (certainly not nearly as much as XP), you get something in the realm of 30 days technical, live installation support - I know many people who have used these services and been quite happy.

So as to maintain the topic thread, I would also suggest that you're miles off topic as MS releasing the source to a fellow such as yourself would make no difference whatsoever. Additionally, there is a huge difference between configuring a kernel, which is what you need to do and kernel hacking which is most certainly something you could never do

As for your final comment, agreed Linux should be easier for everyone, admittedly the community is not there yet. However, the above mentioned distributions have come a long way in the last year, patience. If you want easy and *NIX then don't be cheap, buy a Mac.

God, I can't believe I just did all that for such a trollish comment...

Kernel HOW-TO
CD Burning HOW-TO
ZIP Drive Mini HOW-TO

Now my first impression after reading your post, what benig so open minded about things, is that these HOW-TO's are most likely not for you. Much in the same way that Windows based OS'es are not for all of us (Read: Choice!).

However, you're not limited by that, wanna try Linux? Buy a distro, Redhat, Suse and Mandrake are all quite mature, quite *graphically* configurable and meant for end-users (Read: Binary Updates). Additionally if you spend the few bucks, (certainly not nearly as much as XP), you get something in the realm of 30 days technical, live installation support - I know many people who have used these services and been quite happy.

So as to maintain the topic thread, I would also suggest that you're miles off topic as MS releasing the source to a fellow such as yourself would make no difference whatsoever. Additionally, there is a huge difference between configuring a kernel, which is what you need to do and kernel hacking which is most certainly something you could never do

As for your final comment, agreed Linux should be easier for everyone, admittedly the community is not there yet. However, the above mentioned distributions have come a long way in the last year, patience. If you want easy and *NIX then don't be cheap, buy a Mac.

God, I can't believe I just did all that for such a trollish comment...

For instance, I learned way back in the day on slackware. I had a friend help me out, and in a month I was runnin' it exclusively. Very little was automatic; there was a utility to change your network settings, and pkgtool, but that's about it. Want to install software? Download the tarball and compile it. Something went wrong? RTFM. Still can't figure it out? Jump on IRC and see if someone will help you.

Needless to say, not everyone learns best that way.

Mandrake's easy to get running and use, but you won't learn much about linux doin' it. I knew a guy who ran caldera for over a year and didn't know how to compile a program. Having GUI utilities around won't really teach you much unless you try to learn.

Debian's a good median I think - if you have someone experienced around to point you in the right direction, you won't have too much of a problem. Apt takes away the pain of package management without hiding it all from you, but you'll find very few GUI admin tools. The nice thing is that with Debian, it's standardized enough that almost all the documents at the LDP are relevant - to change something, you edit files in /etc or whatnot.

As for the distro lockin you mention, debian's not a bad distro to be locked into. Stable's great for servers, sid's great for desktops, and there's even a multimedia-oriented distro around for people that work with that.

I know I looked for something like this before:

Font How-To

I know it isn't everything you might be looking for, but it does answer some of the questions.

For general programmer-level stuff, a good place to start would be Eric Raymond's Software Release Practice HOWTO. The GNU coding standards and maintainer information provide guidance for practices on the GNU project; although other open source projects will not follow all of these practices, they give you a good idea of how things are generally organized. Sourceforge itself has pretty good documentation. There are various guides to sending patches (the diff manual is also good reading for this). There is a book on autoconf. There are several documents on CVS; an interesting one is the CVS best practices HOWTO. It's fairly new (November 20, 2001) and still pretty sketchy, but perhaps it will evolve into a more complete best practices guide (the author is soliciting input, so this is a chance to contribute).

And, of course, nearly every Open Source software package comes with some sort of manual. (This contrasts with proprietary Windows applications, which seem to expect you to buy some sort of proprietary book on the side, in addition to the proprietary application you have already bought.) E.g., the the GCC manual, the GNU Make manual, the Perl manual, the Python tutorial, and so on. Although these are not always ideal for the beginner they will certainly be a useful reference to keep handy.

If you are going to mirror, at least give credit where credit is due.

Cost of upgrading what? Did you even read the article? This is a CLUSTER, not your run-of-the-mill desktop or workstation.

I could get linux to easily run on an old 486 motherboard that is somewhere in the bottom of my closet.

I could have ipchains up and running fast

" Theres a core group in charge of what goes and what stays."
Actually, in Linux it's the same (f.e. Torvalds, Cox, Tosatti).

So, where the BSD team is some 10-20 people who can all get in a room and hash out details and come out with a coherent ports system, or a standard place to put software (apache goes in /var/www? Wtf patrick?), the Linux world is far too big to do that. Hell, we can't even document stuf coherently -- everything has its own man page, readme, manual, plus linux documentation project. Compare to FreeBSD's Handbook.

This is a weakness in the Linux system of cooperation. It's also a strength. Just as no one can take control of the whole thing and fix it, also nobody can break the whole thing. Even if Linux and Cox between them decided to sabotage Linux, they couldn't, whereas one guy with cvs commit privileges on cvsup.freebsd.org could give himself a root shell on every BSD box on the planet. (Okay I exaggerate -- he'd get caught, probably, but that's only because most of the people working on BSD are good guys.)

The X Window System began development in 1984 and first commercially released in 1986.

Now, given that X is descended from Paul Asente's W Windowing System, which already existed in 1984, tell me, which Window(s|ing) has the longer history?

Moreover, neither "X" nor "the X Window System" can easily be confused with "Windows".

But I digress: the Windows system can indeed be confused with any glass-plated hole in the wall which isn't actually a door. The X Windowing System is a little more difficult to confuse with the glassed hole, but still easy to confuse with the Windows system.

...the hell is wrong with xconfig?

I think a small script to detect obvious hardware configurations should be available (is there one available now?) as a separate package, but this "feature" shouldn't be included in the kernel source.

Besides, don't you think people are better off *learning* anyhow?

First, how to make a bootable Linux disk. Check out The BBLCD Toolkit, Bernhard's Bootable Linux CD or Build your own Bootable Linux CD, and of course the CD-Writing HOWTO. Do some searches on your favorite search engines for more information on making bootable Linux CDs.

Second, how to start X-windows and run a dedicated application on start up. Check out the Kiosk HOWTO for information on which scripts need to be modified (they talk about booting up netscape, but you'll get the idea). You should also become familiar with Linux and X-windows boot up sequence to find out which scripts need to be modified.

To be honest: I don't see the parallel...

The first is an example of wasting resources detailing new regulation which looks like it was written by a male secretary who only uses TeX and drinks Jolt cola, and has serious problems identifying the priorities in life.

The second is a government docket from the USDA detailing in what seems to be the streamlining of the inspection and labeling system. The context is unfamiliar for most of us (food inspection + labeling), and he may not have don't the greatest job trying to be clear and concise.
However, He makes an honest attempt to be precise, probably because it is a docket.

Oh yeah, one of these affects the quality of our food supply.

Here's some more examples to what seems to look like stupid and complicated excerpts. (Atleast by your standard...)

Subsection 1201(b)(1) is similar to subsection 1201(a)(2), except that subsection 1201(a)(2) covers those who traffic in technology that can circumvent "a technological measure that effectively controls access to a work protected under" Title 17, whereas subsection 1201(b)(1) covers those who traffic in technology that can circumvent "protection afforded by a technological measure that effectively protects a right of a copyright owner under" Title 17. Id. 1201(a)(2), (b)(1) (emphases added). In other words, although both subsections prohibit trafficking in a circumvention technology, the focus of subsection 1201(a)(2) is circumvention of technologies designed to prevent access to a work, and the focus of subsection 1201(b)(1) is circumvention of technologies designed to permit access to a work but prevent copying of the work or some other act that infringes a copyright. See S. Rep. No. 105-190, at 11-12 (1998). Subsection 1201(a)(1) differs from both of these anti-trafficking subsections in that it targets the use of a circumvention technology, not the trafficking in such a technology.

Source

Wow... That looks stupid and frivilous too!!! Why can't they just make these things simple.

How about this example:

The WRR qdisc distributes bandwidth between its classes using the weighted round robin scheme. That is, like the CBQ qdisc it contains classes into which arbitrary qdiscs can be plugged. All classes which have sufficient demand will get bandwidth proportional to the weights associated with the classes. The weights can be set manually using the tc program. But they can also be made automatically decreasing for classes transferring much data.

The qdisc has a built-in classifier which assigns packets coming from or sent to different machines to different classes. Either the MAC or IP and either source or destination addresses can be used. The MAC address can only be used when the Linux box is acting as an ethernet bridge, however. The classes are automatically assigned to machines based on the packets seen.


The Source

Then of course there is TeX and any number of WYSIWY-won't-G word processors. I haven't used TeX much, I only tried my luck in writing a few letters (and found out that it is not suitable for this).

The benefit of using
LyX is that it can do both LaTeX and DocBook
output. That means it can basically export to any
useful format you might need (although MS-Word
.doc output might be a little awkward).

Don't discount DocBook just because it's a pig to
install and set up, it is a professional and pretty
well-designed documentation solution. Talk to the
LinuxDoc people if you don't believe me (who,
incidentally, are still considering making LyX the semi-official
application for editing their HOWTOs).

But then, I'm biased.

--

I've been keeping an eye out for one of these at a decent price...

The IBM Network Station 1000 Model 8362 is a PowerPC-603-based thin client with support for VT emulation, X, ICA/Citrix, local Java apps, 1600x1280x8bit graphics, sound.

The complicated part is that they were designed to be slaved off of a Win2k/NT or AIX box, but people have figured out ways around that for the most part.

Best of all, they're silent, too.

They seem to go on E-Bay for around 300Eur (These guys have them for 450Eur with a 1yr warranty. [for those not in Europe, that's $270 and $400 US, respectively]