Slashdot Mirror

See http://uw.physics.wisc.edu/~himpsel/nano.html, or this and Feynman's talk on the subject.

See http://uw.physics.wisc.edu/~himpsel/nano.html, or this and Feynman's talk on the subject.

See http://uw.physics.wisc.edu/~himpsel/nano.html, or this and Feynman's talk on the subject.

Seeing as I currently attend UW-Madtown, this holds a special place in my heart... oh yeah, I'm in the Engineering Mechanics and Astronautics program, so that might have something to do with it too. Anyways, because I tend to remember cool stuff like this going on here at UW, I remembered another press release by us concerning Quantum computers. Yummy!

Seeing as I currently attend UW-Madtown, this holds a special place in my heart... oh yeah, I'm in the Engineering Mechanics and Astronautics program, so that might have something to do with it too. Anyways, because I tend to remember cool stuff like this going on here at UW, I remembered another press release by us concerning Quantum computers. Yummy!

Although the article doesn't mention his first name, "Himpsel" is Franz Himpsel. Check out his homepage here.

That program was called fuzz. A pretty cool idea, maybe someone should send the link to Mcafee.

Australia

ftp://ftp.planetmirror.com/pub/Mandrake/8.2/i586/ (Brisbane)
Austria

ftp://ftp.univie.ac.at/systems/linux/Mandrake/8.2/ i586/ (Vienna)

ftp://gd.tuwien.ac.at/pub/linux/Mandrake/8.2/i586/ (Vienna)
Belgium

ftp://ftp.belnet.be/packages/mandrake/8.2/i586/
Costa Rica

ftp://ftp.ucr.ac.cr/pub/Unix/linux/mandrake/Mandra ke/8.2/i586/
Czech Republic

ftp://ftp.cesnet.cz/OS/Linux/Mandrake/mandrake/8.2 /i586/ (Brno)

ftp://ftp.fi.muni.cz/pub/linux/mandrake/8.2/i586/ (Brno)

ftp://klobouk.fsv.cvut.cz/pub/linux-mandrake/Mandr ake/8.2/i586/ (Prague)

ftp://mandrake.redbox.cz/Mandrake/8.2/i586/

ftp://sunsite.mff.cuni.cz/OS/Linux/Dist/Mandrake/m andrake/8.2/i586/ (Prague)

http://ftp.fi.muni.cz/pub/linux/mandrake/8.2/i586/ (Brno)
Denmark

ftp://ftp.dkuug.dk/pub/mandrake/8.2/i586/ (Koebenhavn)

ftp://ftp.sunsite.dk/mirrors/mandrake/8.2/i586/ (Aalborg)
Estonia

ftp://ftp.aso.ee/pub/os/Linux/distributions/mandra ke/8.2/i586/
Finland

ftp://ftp.song.fi/pub/linux/Mandrake/8.2/i586/ (Espoo)
France

ftp://ftp.ciril.fr/pub/linux/mandrake/8.2/i586/ (Nancy)

ftp://ftp.club-internet.fr/pub/unix/linux/distribu tions/Mandrake/8.2/i586/ (Paris)

ftp://ftp.info.univ-angers.fr/pub/linux/distributi ons/mandrake/8.2/i586/ (Angers)

ftp://ftp.lip6.fr/pub/linux/distributions/mandrake /8.2/i586/ (Paris)

ftp://ftp.proxad.net/pub/Distributions_Linux/Mandr ake/8.2/i586/ (Paris)

ftp://ftp.u-strasbg.fr/pub/linux/distributions/man drake/8.2/i586/ (Strasbourg)

ftp://linux.ups-tlse.fr/Mandrake/8.2/i586/ (Toulouse)
Germany

ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/Mandra ke/8.2/i586/ (Esslingen)

ftp://ftp.de.uu.net/pub/linux/mandrake/8.2/i586/

ftp://ftp.fh-giessen.de/pub/linux/mandrake/8.2/i58 6/ (Giessen)

ftp://ftp.fh-wolfenbuettel.de/pub/os/linux/mandrak e/dist/8.2/i586/ (Wolfenbuettel)

ftp://ftp.gwdg.de/pub/linux/mandrake/8.2/i586/ (Goettingen)

ftp://ftp.join.uni-muenster.de/pub/linux/distribut ions/mandrake/8.2/i586/ (Muenster)

ftp://ftp.leo.org/pub/comp/os/unix/linux/Mandrake/ Mandrake/8.2/i586/ (Munchen)

ftp://ftp.tu-chemnitz.de/pub/linux/mandrake/8.2/i5 86/ (Chemnitz)

ftp://ftp.tu-clausthal.de/pub/linux/mandrake/8.2/i 586/ (Clausthal)

ftp://ftp.uasw.edu/pub/os/linux/mandrake/dist/8.2/ i586/ (Wolfenbuettel)

ftp://ftp.uni-bayreuth.de/pub/linux/Mandrake/8.2/i 586/ (bayreuth)

ftp://ftp.uni-kassel.de/pub/linux/mandrake/8.2/i58 6/ (Kassel)

ftp://ftp.uni-mannheim.de/systems/linux/mandrake/8 .2/i586/ (Mannheim)

ftp://ftp.vat.tu-dresden.de/pub/Mandrake/8.2/i586/ (Dresden)

ftp://ramses.wh2.tu-dresden.de/pub/mirrors/mandrak e/8.2/i586/ (Dresden)

ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/ mandrake/8.2/i586/ (Aachen)
Greece

ftp://ftp.duth.gr/pub/Mandrake/8.2/i586/ (Thrace)

ftp://ftp.ntua.gr/pub/linux/mandrake/8.2/i586/ (Athens)
Hong Kong

ftp://ftp.wisr.eie.polyu.edu.hk/linux/mandrake/8.2 /i586/
Hungary

ftp://ftp.linuxforum.hu/mirror/Mandrake/8.2/i586/
Ireland

ftp://ftp.esat.net/pub/linux/mandrake/8.2/i586/
Italy

ftp://bo.mirror.garr.it/mirrors/Mandrake/8.2/i586/ (Bologna)

ftp://ftp.edisontel.it/pub/Mandrake_Mirror/Mandrak e/8.2/i586/
Latvia

ftp://ftp.latnet.lv/linux/mandrake/8.2/i586/
Netherlands

ftp://ftp.nl.uu.net/pub/linux/mandrake/8.2/i586/

ftp://ftp.nluug.nl/pub/os/Linux/distr/Mandrake/Man drake/8.2/i586/

ftp://ftp.surfnet.nl/pub/os/Linux/distr/Mandrake/M andrake/8.2/i586/

ftp://ftp.wau.nl/pub/Mandrake/8.2/i586/ (Wageningen)
Poland

ftp://ftp.ps.pl/mirrors/mandrake/8.2/i586/ (Szczecin)

ftp://ftp.task.gda.pl/pub/linux/Mandrake/8.2/i586/ (Gdansk)
Portugal

ftp://ftp.dei.uc.pt/pub/linux/Mandrake/Mandrake/8. 2/i586/ (Coimbra)

ftp://tux.cprm.net/pub/Mandrake/8.2/i586/
Russia

ftp://ftp.chg.ru/pub/Linux/mandrake/8.2/i586/ (Chernogolovka)
Singapore

ftp://ftp.singnet.com.sg/opensource/linux/Mandrake /8.2/i586/
Slovakia

ftp://spirit.profinet.sk/mirrors/Mandrake/8.2/i586 / (Bratislava)
Spain

ftp://ftp.cesga.es/pub/linux/Mandrake/8.2/i586/ (Galicia)

ftp://ftp.cica.es/pub/Linux/Mandrake/8.2/i586/ (Sevilla)

ftp://ftp.rediris.es/pub/linux/distributions/mandr ake/8.2/i586/
Sweden

ftp://ftp.chello.se/pub/Linux/Mandrake/8.2/i586/

ftp://ftp.chl.chalmers.se/pub/Linux/distributions/ Mandrake/8.2/i586/ (Gothenburg)

ftp://ftp.du.se/pub/os/mandrake/8.2/i586/ (Dalarma)
Switzerland

ftp://ftp.pcds.ch/pub/Mandrake/8.2/i586/ (Neuhausen)

ftp://sunsite.cnlab-switch.ch/mirror/mandrake/8.2/ i586/ (Zurich)
Taiwan

ftp://linux.cdpa.nsysu.edu.tw/pub/Mandrake/mandrak e/8.2/i586/

ftp://linux.csie.nctu.edu.tw/distributions/mandrak e/Mandrake/8.2/i586/

ftp://mdk.linux.org.tw/pub/mandrake/8.2/i586/
Turkey

ftp://ftp.ankara.edu.tr/pub/linux/dagitimlar/Mandr ake/8.2/i586/ (Ankara)
United Kingdom

ftp://ftp.mirror.ac.uk/sites/sunsite.uio.no/pub/un ix/Linux/Mandrake/Mandrake/8.2/i586/ (Canterbury)
United States

ftp://ftp-linux.cc.gatech.edu/pub/linux/distributi ons/mandrake/8.2/i586/ (Georgia)

ftp://ftp.cise.ufl.edu/pub/mirrors/mandrake/Mandra ke/8.2/i586/ (Florida)

ftp://ftp.cse.buffalo.edu/pub/Linux/Mandrake/mandr ake/8.2/i586/ (NY)

ftp://ftp.nmt.edu/pub/linux/mandrake/8.2/i586/ (New Mexico)

ftp://ftp.orst.edu/pub/mandrake/8.2/i586/ (Oregon)

ftp://ftp.tux.org/pub/distributions/mandrake/8.2/i 586/ (Virginia)

ftp://ftp.umr.edu/pub/linux/mandrake/Mandrake/8.2/ i586/ (Missouri)

ftp://ftp.uwsg.indiana.edu/linux/mandrake/8.2/i586 / (Indiana)

ftp://linux-cs.tccw.wku.edu/pub/linux/distribution s/Mandrake/8.2/i586/ (WKU-Linux, Western Kentucky University)

ftp://mirror.aca.oakland.edu/linux/mandrake/8.2/i5 86/ (Michigan)

ftp://mirror.cs.wisc.edu/pub/mirrors/linux/Mandrak e/8.2/i586/ (Wisconsin)

ftp://mirror.mcs.anl.gov/pub/Mandrake/8.2/i586/ (Illinois)

ftp://mirrors.ptd.net/mandrake/8.2/i586/ (Pensylvania)

ftp://mirrors.secsup.org/pub/linux/mandrake/Mandra ke/8.2/i586/

ftp://uml-pub.ists.dartmouth.edu/mirrors/ftp.mandr akesoft.com/pub/Mandrake/mandrake/8.2/i586/ (New Hampshire)

ftp://videl.ics.hawaii.edu/mirrors/mandrake/Mandra ke/8.2/i586/ (Hawaii)

http://mandrake.dsi.internet2.edu/Mandrake/8.2/i58 6/ (For Internet2 academic institutions only)

There is also a 3d game construction set available from a small company, saw it in a gaming magazine- I ordered it and it seemed okay, but was more than I wanted to commit to at the time :)

As for the mod issue, the one thing that mods of course don't afford you is the ability to send your mod as a standalone application to someone else - they have to own Morrowind or Quake or whatever. This GCS gets around that - the catch being all the bad stuff (lack of graphics, etc.) it brings with it, which wouldn't be bad were it not for the $70 price tag. An alternative is the Torque engine by GarageGames. I've got it - it's damn good. Not only does it have what most systems lack (online play, top of the line graphics, multiplatform) but the price is right - for $100 you can make what you want with it and give it to whomever you want. If you want to sell what you make its a different affair (games have to be sold through the GG.com site) but for free games you can do what you want with it. GCS lets you sell it however you like - provided you can get someone to pay for it.

A lot of ISPs use hardware that is NetFlow capable.

NetFlow records the source IP, source port, destination IP, and dest port, bytes sent, start and stop times of the transaction. Using packages such as FlowScan, admins can profile users traffic.

This makes it very easy to look at what your users are doing.

[...] you're going to need to express temporal ideas.

But nobody is going to go to the trouble of synthesyzing an Ebola virus because it's too much trouble and there's a better way to turn it into a Weapon of Mass Destruction (WMD). Ebola has just seven genes and only one of these produces the substance that causes the 90% fatality rate - Ebola glycoprotein. The gene for this protein has already been isolated and put in a common cold virus!!!

"...Nabel's team worked with intact blood vessels taken from people and animals. The researchers infected those cells with a cold virus they had engineered to carry the Ebola glycoprotein gene. Within 48 hours, massive numbers of endothelial cells began to die and the blood vessels became leaky. Such effects could lead to the internal and external bleeding caused by Ebola...."

Kinda makes you wonder where ol' Nabel's virus is now, huh? Hope it's safely in the bottom of his lab freezer. But inserting the Ebola glycoprotein in a bacterium (as opposed to a virus) is basically a science fair project these days, so ANYBODY can get in on the fun. Who knows, the next Jack in the Box E Coli scare may very well be a version with an Ebola gene in it. The basic data you need for such a project is onlione at the SWISS-PROT database in Switzerland; just enter ebola in their search engine and see for yourself. The specific data for Ebola glycoprotein is here, and in case that gets slashdotted, the relevant sequence data info is as follows:

MGVTGILQLP RDRFKRTSFF LWVIILFQRT FSIPLGVIHN STLQVSDVDK LVCRDKLSST NQLRSVGLNL EGNGVATDVP SATKRWGFRS GVPPKVVNYE AGEWAENCYN LEIKKPDGSE CLPAAPDGIR GFPRCRYVHK VSGTGPCAGD FAFHKEGAFF LYDRLASTVI YRGTTFAEGV VAFLILPQAK KDFFSSHPLR EPVNATEDPS SGYYSTTIRY QATGFGTNET EYLFEVDNLT YVQLESRFTP QFLLQLNETI YTSGKRSNTT GKLIWKVNPE IDTTIGEWAF WETKKTSLEK FAVKSCLSQL YQTEPKTSVV RVRRELLPTQ GPTQQLKTTK SMASENSSAM VQVHSQGREA AVSHLTTLAT ISTSPQSLTT KPGPDNSTHN TPVYKLDISE ATQVEQHHRR TDNDSTASDT PSATTAAGPP KAENTNTSKS TDFLDPATTT SPQNHSETAG NNNTHHQDTG EESASSGKLG LITNTIAGVA GLITGGRRTR REAIVNAQPK CNPNLHYWTT QDEGAAIGLA WIPYFGPAAE GIYIEGLMHN QDGLICGLRQ LANETTQALQ LFLRATTELR TFSILNRKAI DFLLQRWGGT CHILGPDCCI EPHDWTKNIT DKIDQIIHDF VDKTLPDQGD NDNWWTGWRQ WIPAGIGVTG VIIAVIALFC ICKFVF

Any genetic engineer worth her salt should be able to take this data and create a Ebola / E Coli hybrid plasmid with the help of this data and a friendly mail order supplier of synthetic DNA...

But nobody is going to go to the trouble of synthesyzing an Ebola virus because it's too much trouble and there's a better way to turn it into a Weapon of Mass Destruction (WMD). Ebola has just seven genes and only one of these produces the substance that causes the 90% fatality rate - Ebola glycoprotein. The gene for this protein has already been isolated and put in a common cold virus!!!

"...Nabel's team worked with intact blood vessels taken from people and animals. The researchers infected those cells with a cold virus they had engineered to carry the Ebola glycoprotein gene. Within 48 hours, massive numbers of endothelial cells began to die and the blood vessels became leaky. Such effects could lead to the internal and external bleeding caused by Ebola...."

Kinda makes you wonder where ol' Nabel's virus is now, huh? Hope it's safely in the bottom of his lab freezer. But inserting the Ebola glycoprotein in a bacterium (as opposed to a virus) is basically a science fair project these days, so ANYBODY can get in on the fun. Who knows, the next Jack in the Box E Coli scare may very well be a version with an Ebola gene in it. The basic data you need for such a project is onlione at the SWISS-PROT database in Switzerland; just enter ebola in their search engine and see for yourself. The specific data for Ebola glycoprotein is here, and in case that gets slashdotted, the relevant sequence data info is as follows:

MGVTGILQLP RDRFKRTSFF LWVIILFQRT FSIPLGVIHN STLQVSDVDK LVCRDKLSST NQLRSVGLNL EGNGVATDVP SATKRWGFRS GVPPKVVNYE AGEWAENCYN LEIKKPDGSE CLPAAPDGIR GFPRCRYVHK VSGTGPCAGD FAFHKEGAFF LYDRLASTVI YRGTTFAEGV VAFLILPQAK KDFFSSHPLR EPVNATEDPS SGYYSTTIRY QATGFGTNET EYLFEVDNLT YVQLESRFTP QFLLQLNETI YTSGKRSNTT GKLIWKVNPE IDTTIGEWAF WETKKTSLEK FAVKSCLSQL YQTEPKTSVV RVRRELLPTQ GPTQQLKTTK SMASENSSAM VQVHSQGREA AVSHLTTLAT ISTSPQSLTT KPGPDNSTHN TPVYKLDISE ATQVEQHHRR TDNDSTASDT PSATTAAGPP KAENTNTSKS TDFLDPATTT SPQNHSETAG NNNTHHQDTG EESASSGKLG LITNTIAGVA GLITGGRRTR REAIVNAQPK CNPNLHYWTT QDEGAAIGLA WIPYFGPAAE GIYIEGLMHN QDGLICGLRQ LANETTQALQ LFLRATTELR TFSILNRKAI DFLLQRWGGT CHILGPDCCI EPHDWTKNIT DKIDQIIHDF VDKTLPDQGD NDNWWTGWRQ WIPAGIGVTG VIIAVIALFC ICKFVF

Any genetic engineer worth her salt should be able to take this data and create a Ebola / E Coli hybrid plasmid with the help of this data and a friendly mail order supplier of synthetic DNA...

Not entirely true. If you look into the active research in the area of fusion reactions, you'll find that there are what they call DT, DD, D3He and He3-He3 reactions. In that order, they contain about 75%, 35%, 5% and 0% total energy released in neutron form. The Holy Grail of nuclear energy is to make He3-He3 reactions economically viable. These reactions produce NO neutrons and He3 is actually very plentiful... on the lunar surface (verified by Apollo missions).

If you want more info, do a google search for "fusion he3 fti wisconsin". One article in particular:

http://fti.neep.wisc.edu/FTI/pdf/fdm1131.pdf

This link talks about glass. I was not referring to the technical definition of crystalline vs amorphous. To be a crystalline solid it would need long-range order. That does not mean that glass does not have short-range cyrstalline like fragments. Glass does not have the odd shaped, interlocking fragments to which I was referring to. Graphite would be a better example in that it is structured in the form of sheets, making it very brittle.This link has pictures and explanations.

On Windows I just use Ghostscript/Ghostview, either the AFPL one , or the GNU GPL one to view and print *.ps files.

On Windows I just use Ghostscript/Ghostview, either the AFPL one , or the GNU GPL one to view and print *.ps files.

This works great.

I would suggest rather getting ghostscript for Windows, the free PostScript interpreter, and also GSview, a viewer (the latter requires the former).

Ghostscript is free as in speech, with a GNU release and a release under AFPL, a slightly different license (the GNU code is older than the AFPL code). GSview is available, as far as I can tell, under the AFPL only, which is still free but not GPL.

With both of these properly installed on Windows, one click on the link provided by Slashdot will launch the viewer. (It must gunzip on-the-fly.)

I would suggest rather getting ghostscript for Windows, the free PostScript interpreter, and also GSview, a viewer (the latter requires the former).

Ghostscript is free as in speech, with a GNU release and a release under AFPL, a slightly different license (the GNU code is older than the AFPL code). GSview is available, as far as I can tell, under the AFPL only, which is still free but not GPL.

With both of these properly installed on Windows, one click on the link provided by Slashdot will launch the viewer. (It must gunzip on-the-fly.)

You can read PostScript files on Windows, Mac, Linux, OS/2, and VMS with GhostScript.

I don't know whether select() would scale; apparently it scales linearly, which is fine when n=20 but not when n=10000. I think if you are going to go with select() you need an implementation that scales logarithmically.

Anyway, to answer my own initial question, there is a paper which I found with a google query and seems interesting.

This paper analyzes the amount of source code in GNU/Linux, using Red Hat Linux 7.1 as a representative GNU/Linux distribution, and presents what I believe are interesting results.

In particular, it would cost over $1 billion ($1,000 million - a Gigabuck) to develop this GNU/Linux distribution by conventional proprietary means in the U.S. (in year 2000 U.S. dollars). Compare this to the $600 million estimate for Red Hat Linux version 6.2 (which had been released about one year earlier). Also, Red Hat Linux 7.1 includes over 30 million physical source lines of code (SLOC), compared to well over 17 million SLOC in version 6.2. Using the COCOMO cost model, this system is estimated to have required about 8,000 person-years of development time (as compared to 4,500 person-years to develop version 6.2). Thus, Red Hat Linux 7.1 represents over a 60% increase in size, effort, and traditional development costs over Red Hat Linux 6.2. This is due to an increased number of mature and maturing open source / free software programs available worldwide.

Many other interesting statistics emerge. The largest components (in order) were the Linux kernel (including device drivers), Mozilla (Netscape's open source web system including a web browser, email client, and HTML editor), the X Window system (the infrastructure for the graphical user interface), gcc (a compilation system), gdb (for debugging), basic binary tools, emacs (a text editor and far more), LAPACK (a large Fortran library for numerical linear algebra), the Gimp (a bitmapped graphics editor), and MySQL (a relational database system). The languages used, sorted by the most lines of code, were C (71% - was 81%), C++ (15% - was 8%), shell (including ksh), Lisp, assembly, Perl, Fortran, Python, tcl, Java, yacc/bison, expect, lex/flex, awk, Objective-C, Ada, C shell, Pascal, and sed.

The predominant software license is the GNU GPL. Slightly over half of the software is simply licensed using the GPL, and the software packages using the copylefting licenses (the GPL and LGPL), at least in part or as an alternative, accounted for 63% of the code. In all ways, the copylefting licenses (GPL and LGPL) are the dominant licenses in this GNU/Linux distribution. In contrast, only 0.2% of the software is public domain.

This paper is an update of my previous paper on estimating GNU/Linux's size, which measured Red Hat Linux 6.2 [Wheeler 2001]. Since Red Hat Linux 6.2 was released in March 2000, and Red Hat Linux 7.1 was released in April 2001, this paper shows what's changed over approximately one year. More information is available at http://www.dwheeler.com/sloc. 1. Introduction The GNU/Linux operating system has gone from an unknown to a powerful market force. Netcraft found that, of the systems running web servers on June 2001, GNU/Linux was now the second most popular operating system (with 29.6%, versus Windows' 49.6%) [Netcraft 2001]. Another survey, of primarily European and educational sites, found that GNU/Linux was used more than any other operating system (of the sites it surveyed) [Zoebelein 1999]. IDC found that 25% of all server operating systems purchased in 1999 were GNU/Linux, making it second only to Windows NT's 38% [Shankland 2000a].

There appear to be many reasons for this, and not simply because GNU/Linux can be obtained at no or low cost. For example, experiments suggest that GNU/Linux is highly reliable. A 1995 study of a set of individual components found that the GNU and GNU/Linux components had a significantly higher reliability than their proprietary Unix competitors (6% to 9% failure rate with GNU and Linux, versus an average 23% failure rate with the proprietary software using their measurement technique) [Miller 1995]. A ten-month experiment in 1999 by ZDnet found that, while Microsoft's Windows NT crashed every six weeks under a ``typical'' intranet load, using the same load and request set the GNU/Linux systems (from two different distributors) never crashed [Vaughan-Nichols 1999].

However, possibly the most important reason for GNU/Linux's popularity among many developers and users is that its source code is generally ``open source software'' and/or ``free software''. A program that is ``open source software'' or ``free software'' is essentially a program whose source code can be obtained, viewed, changed, and redistributed without royalties or other limitations of these actions. A more formal definition of ``open source software'' is available from the Open Source Initiative [OSI 1999], a more formal definition of ``free software'' (as the term is used in this paper) is available from the Free Software Foundation [FSF 2000], and other general information about these topics is available at Wheeler [2000a]. Quantitative rationales for using open source / free software is given in Wheeler [2000b]. The GNU/Linux operating system is actually a suite of components, including the Linux kernel on which it is based, and it is packaged, sold, and supported by a variety of distributors. The Linux kernel is ``open source software''/``free software'', and this is also true for all (or nearly all) other components of a typical GNU/Linux distribution. Open source software/free software frees users from being captives of a particular vendor, since it permits users to fix any problems immediately, tailor their system, and analyze their software in arbitrary ways.

Surprisingly, although anyone can analyze GNU/Linux for arbitrary properties, I have found little published analysis of the amount of source lines of code (SLOC) contained in a GNU/Linux distribution. Microsoft unintentionally published some analysis data in the documents usually called ``Halloween I'' and ``Halloween II'' [Halloween I] [Halloween II]. Another study focused on the Linux kernel and its growth over time is by Godfrey [2000]; this is an interesting study but it focuses solely on the Linux kernel (not the entire operating system). Paul G. Allen posted some results from running Scientific Toolworks, Inc.'s tools on the Linux kernel, but this analysis only considered C code (including headers) - ignoring the many other languages used in constructing the Linux kernel (e.g., assembly language), and only concentrating on the kernel. The Free Code Graphing Project at http://fcgp.sourceforge.net generates a graphical representation of a program (currently, the Linux kernel), but only of the C code. In a previous paper, I examined Red Hat Linux 6.2 and the numbers from the Halloween papers [Wheeler 2001].

This paper updates my previous paper, showing estimates of the size of one of today's GNU/Linux distributions, and it estimates how much it would cost to rebuild this typical GNU/Linux distribution using traditional software development techniques. Various definitions and assumptions are included, so that others can understand exactly what these numbers mean. I have intentionally written this paper so that you do not need to read the previous version of this paper first.

For my purposes, I have selected as my ``representative'' GNU/Linux distribution Red Hat Linux version 7.1. I believe this distribution is reasonably representative for several reasons:

1. Red Hat Linux is the most popular Linux distribution sold in 1999 according to IDC [Shankland 2000b]. Red Hat sold 48% of all copies in 1999; the next largest distribution in market share sales was SuSE (a German distributor) at 15%. Not all GNU/Linux copies are ``sold'' in a way that this study would count, but the study at least shows that Red Hat's distribution is a popular one.
2. Many distributions (such as Mandrake) are based on, or were originally developed from, a version of Red Hat Linux. This doesn't mean the other distributions are less capable, but it suggests that these other distributions are likely to have a similar set of components.
3. All major general-purpose distributions support (at least) the kind of functionality supported by Red Hat Linux, if for no other reason than to compete with Red Hat.
4. All distributors start with the same set of open source software projects from which to choose components to integrate. Therefore, other distributions are likely to choose the same components or similar kinds of components with often similar size for the same kind of functionality.

Different distributions and versions would produce different size figures, but I hope that this paper will be enlightening even though it doesn't try to evaluate ``all'' distributions. Note that some distributions (such as SuSE) may decide to add many more applications, but also note this would only create larger (not smaller) sizes and estimated levels of effort. At the time that I began this project, version 7.1 was the latest version of Red Hat Linux available, so I selected that version for analysis.

Note that Red Hat Linux 6.2 was released on March 2000, Red Hat Linux 7 was released on September 2000 (I have not counted its code), and Red Hat Linux 7.1 was released on April 2001. Thus, the differences between Red Hat Linux 7.1 and 6.2 show differences accrued over 13 months (approximately one year).

Clearly there is far more open source / free software available worldwide than is counted in this paper. However, the job of a distributor is to examine these various options and select software that they believe is both sufficiently mature and useful to their target market. Thus, examining a particular distribution results in a selective analysis of such software.

Section 2 briefly describes the approach used to estimate the ``size'' of this distribution (more details are in Appendix A). Section 3 discusses some of the results. Section 4 presents conclusions, followed by an appendix. GNU/Linux is often called simply ``Linux'', but technically Linux is only the name of the operating system kernel; to eliminate ambiguity this paper uses the term ``GNU/Linux'' as the general name for the whole system and ``Linux kernel'' for just this inner kernel. 2. Approach My basic approach was to:

1. install the source code files in uncompressed format; this requires carefully selecting the source code to be analyzed.
2. count the number of source lines of code (SLOC); this requires a careful definition of SLOC.
3. use an estimation model to estimate the effort and cost of developing the same system in a proprietary manner; this requires an estimation model.
4. determine the software licenses of each component and develop statistics based on these categories.

More detail on this approach is described in Appendix A. A few summary points are worth mentioning here, however. 2.1 Selecting Source Code

I included all software provided in the Red Hat distribution, but note that Red Hat no longer includes software packages that only apply to other CPU architectures (and thus packages not applying to the x86 family were excluded). I did not include ``old'' versions of software, or ``beta'' software where non-beta was available. I did include ``beta'' software where there was no alternative, because some developers don't remove the ``beta'' label even when it's widely used and perceived to be reliable.

I used md5 checksums to identify and ignore duplicate files, so if the same file contents appeared in more than one file, it was only counted once (as a tie-breaker, such files are assigned to the first build package it applies to in alphabetic order).

The code in makefiles and Red Hat Package Manager (RPM) specifications was not included. Various heuristics were used to detect automatically generated code, and any such code was also excluded from the count. A number of other heuristics were used to determine if a language was a source program file, and if so, what its language was.

Since different languages have different syntaxes, I could only measure the SLOC for the languages that my tool (sloccount) could detect and handle. The languages sloccount could detect and handle are Ada, Assembly, awk, Bourne shell and variants, C, C++, C shell, Expect, Fortran, Java, lex/flex, LISP/Scheme, Makefile, Objective-C, Pascal, Perl, Python, sed, SQL, TCL, and Yacc/bison. Other languages are not counted; these include XUL (used in Mozilla), Javascript (also in Mozilla), PHP, and Objective Caml (an OO dialect of ML). Also code embedded in data is not counted (e.g., code embedded in HTML files). Some systems use their own built-in languages; in general code in these languages is not counted.

Can all these changes be implemented by the auto manufacturers?

These trucks must be inexpensive enough to produce to be inexpensive enough for the average consumer.

And aluminum as safe as an all-steel frame?

You are right about air quality, but I think that if we aren't willing to shoot for a doubling of fuel economy in our vehicles (and quite a bit more in the rest of the economy via co-generation), frankly we are being lazy pikers. We can double economy with technologies which are student playthings; when you consider the kind of advances which are currently in the real labs, and how they could come to the car dealerships and merchandise racks at Home Depot and Lowe's over the next 20 years, you have to wonder what excuse there is for doing nothing. I sure don't see one.

I had to look at C Class - Arrays, String Constants and Pointers to learn all the differences (I only got 1 out of the 4).

many scientists consider mining the moon for He-3 to be the key to unlocking the secrets of fusion energy.

it's only a possibility certainly, but not exactly a sure "dead end" either

Sea temperature is measured by satellite, not by inferring from coral growth. A correllation may be seen between coral growth and sea surface temperature, but the temperature is not measured by looking at the growth. See this NOAA site

2) Which "theory" are you referring to when you talk about global warming? As far as I know, the only theories are:
1) CO2 increases cause warming (trivial physics, but not a real hypothesis to test man-made global warming in this complex system).
2) Computer simulations show warming, and with enough tuning can sort-of match the past since temperature records were kept.

Number 2 (computer simulations) Isnt a hypothesis, or a theory, it is an attempt to verify the global warming hypothisis that you state in 1. A computer simulation is not a hypothesis in any case.

So really were only arguing about 1. Does an increase in Co2 decrease the rate of heat radiated by the planet. Thats the question. Does CO2 trap heat? Your alternative hypothesies, solar irradiation etc, may or may not be true. If solar variability is true, then that will contribute to an overall warming effect. Regardless we know one simple fact that cannot be disputed: CO2 traps heat. If it werent for some CO2 wed be living in an icebox. CO2 allows for liquid water, which then takes over as the dominant greenhouse gas. An increase in CO2 can therefore be assumed to increase the amount of heat trapped by the earths atmosphere, since CO2 has been doing that since the beginning of time. Regardless of any other causes to global warming, increasing CO2=Increasing trapped heat. So you may be right and solar variability may be a factor, granted, but this does not negate the effect of CO2 on the atmosphere. In fact it makes controlling CO2 even more vital, since we have to compensate for solar variations as well as human caused effects.

There's been a long-recognized phenomenon discovered among people who have sight restored after long periods of blindness: Motivation Crisis

http://psych.wisc.edu/vision/courses/recovery.html

http://216.239.35.100/search?q=cache:ZD8gWmH2aEYC: www.wfu.edu/Academic-departments/Art/art111/files/ 12_tosee.pdf+

Notes on this phenomenon go back to at least 1771, with the publishing of the book "L'Aveugle Qui Refiise deVoir." By 1932, there was a book "Space and Sight" that concluded that "every newly sighted adult sooner or later comes to a 'motivation crisis', and that not every patient gets through it." Fortunately for this guy though, this problem seems to be more linked to people who lost their sight early, and then regained it much later, having to radically change their lives down to the tiniest mannerisms. It might have something to do with the time limitation they are putting on him, and the scientists choice of Jans, for his positive attitude.

Definetly an interesting topic on human psychology though. Hopefully with future inventions along this line, no one will be forceably blind long enough for such depression to occur along these lines. It makes one wonder though - will more distant technology create a new sort of "Motivation Crisis" in us if perception enchancements become widely available and used.

Ryan Fenton

I've been using Ghostscript with RedMon to print direct to pdf from WinNT/Win2K apps for 3 years. Works great.

You should probably start here. It has been a while since I used the Windows version of Ghostscript, but it seemed to be pretty complete. There is even special documentation on ps2pdf.

If I remember correctly I used a setup with a special printer that printed the Postscript output to a file. I would then run ps2pdf on the file and I would have a PDF file.

Good luck.

You should probably start here. It has been a while since I used the Windows version of Ghostscript, but it seemed to be pretty complete. There is even special documentation on ps2pdf.

If I remember correctly I used a setup with a special printer that printed the Postscript output to a file. I would then run ps2pdf on the file and I would have a PDF file.

Good luck.

pdf and postscript were released as open standards as a result we have many tools which can read and write these formats. the only problem i can see with pdf and ps is that they are not really ment for editing. while you can edit a pdf, i wouldnt really recommend it. i think xml would be better for long term storage.

I am pretty sure it is going to be tough reading (and I don't even have any degrees from MIT)

Actually, once you get through the first chapter, things aren't so bad.

If you make it a point to follow along, it's not so hard - the pictures/diagrams (of which there are many) get the salient points across, and do a pretty decent job of showing what's going on. Not many equations, and the ones there are are pretty easily followed. (and this from a biology grad from Illinois Tech - I'm definitely a resident of the foothills of mathematical academia).

This guy has some -serious- ego, though - the first chapter seemed to be nothing but (as yet unsubstantiated, but then I'm only on the 4th chapter) blowhard hubris promise-the-world-in-a-simple-program promises.

Nevertheless ...

I work with computers these days, and have gotten used to the idea that people with huge egos not only exist, but often have the results to back them up. So I'm trying to reserve judgement about his revolutionizing the world of science until I read a bit more.

But cellular automata are much better observed in action than in the static pictures he provides. A quick search on the web yielded this fine program that has given me a lot to play with over the last few days too.

A fun book, overall. Not expensive. Worth poking around in, once you get past Wolfram's ego.

Lautier: Are computers a threat for Shogi ?

Habu: In mating problems, called Tsume Shogi, the computer is already superior to the best players. In normal games, however, the computer is still far from the professional level. Its level can be compared to a 4-dan among amateurs [approximately 2300 strength in chess Elo terms. The first dan among professionals starts after the amateur 6-dan. To get a rough idea, the best Shogi players in the world, including Mr Habu, have a ranking of professional 9-dan - JL].

This is one example of the prevailing sad state of affairs of the performance of AI in games. The best chessplaying programs are those which use brute force search and little else. The fact that they can beat world champions tells us little except that the effective branching factor in chess is small. In games like go and shogi where the branching factor is much higher, long-term strategy counts much more, and brute-force is relatively useless, computers are nowhere near the best humans.

Another example: As early as 1962 Samuels wrote a checker playing program which could learn from its previous games and beat reasonably strong humans. After that there has been virtually no progress in game strategy; all the improvement has been in hardware speed. Indeed, it wasn't until 1994 that the first wold-champion-beating checker player, "Chinook" was written. This is an amazingly slow rate of progress compared to other areas of computer science/technology.

Its a shame, considering that game playing is thought to be one of the easiest problem domains for AI.

UW-Madison has the Condor Project, which you could say is related.

The plural of "virus" isn't "virii." There is no such word. The plural of "virus" is "viruses."

Here's a good explanation from cdknow.com, quoted here in its entirety because the people who most need to read this won't click on a link.

The correct English plural of virus is viruses. Please consult any good dictionary before making up words.

For the purists, in Latin, there is a rarely-used plural form:

virus, viri (neuter)

(Forms: almost always restricted to nominative and accusative singular; generally singular in Lucretius, ablative singular in Lucretius)

The point of this is that even in Latin the form "viri" is rarely used. The singular form is used in most every instance. (This is from the Oxford Latin Dictionary.)

So, when considering the Latin: "virii" is incorrect and "viri" was almost never used.

Despite the fact there was little use for the plural form, there is another reason why "viri" was rarely used. The most common Latin word for "man" is "vir" with "viri" being its plural in the form used as the subject of a sentence. Thus, since "men" as the subject of a sentence would be used far more often than "venoms" (virus means venom) the "viri" word was most commonly seen as the plural of "man."

Bottom line: Don't try to make up words using a false Latin plural form. Since the word virus in its English form is now used then the English plural (viruses) should be used.

More plural-of-virus resources:

perl.com, the canonical and exhaustive source
The alt.comp.virus FAQ
Jonathan de Boyne Pollard's Frequently Given Answer
Merriam-Webster's "Word for the Wise," January 20, 2000.

is that there is actually an MLA standard for citing online articles, yet once your prof gets it the material may have changed or be completely gone. During the 2000 election crap I actually tried linking to a couple of CNN articles that promptly disappeared - you couldn't even find them in searches! Thankfully I had printed each source as I used it (which added up) and I was able to give those to the prof for proof.

This is a print medium, like it or not, so versioning and archiving must be done or using such materials for sources will quickly die and we'll all be back to researching the old fashioned way. Which does at least get you better results usually, it just takes forever to find all of your sources, many of which may be 5 years out of date. With the Internet, the sources can be up to date.

is that there is actually an MLA standard for citing online articles, yet once your prof gets it the material may have changed or be completely gone. During the 2000 election crap I actually tried linking to a couple of CNN articles that promptly disappeared - you couldn't even find them in searches! Thankfully I had printed each source as I used it (which added up) and I was able to give those to the prof for proof.

This is a print medium, like it or not, so versioning and archiving must be done or using such materials for sources will quickly die and we'll all be back to researching the old fashioned way. Which does at least get you better results usually, it just takes forever to find all of your sources, many of which may be 5 years out of date. With the Internet, the sources can be up to date.

The plural of "virus" isn't "virii." There is no such word. The plural of "virus" is "viruses."

Here's a good explanation from cdknow.com, quoted here in its entirety because the people who most need to read this won't click on a link.

The correct English plural of virus is viruses. Please consult any good dictionary before making up words.

For the purists, in Latin, there is a rarely-used plural form:

virus, viri (neuter)

(Forms: almost always restricted to nominative and accusative singular; generally singular in Lucretius, ablative singular in Lucretius)

The point of this is that even in Latin the form "viri" is rarely used. The singular form is used in most every instance. (This is from the Oxford Latin Dictionary.)

So, when considering the Latin: "virii" is incorrect and "viri" was almost never used.

Despite the fact there was little use for the plural form, there is another reason why "viri" was rarely used. The most common Latin word for "man" is "vir" with "viri" being its plural in the form used as the subject of a sentence. Thus, since "men" as the subject of a sentence would be used far more often than "venoms" (virus means venom) the "viri" word was most commonly seen as the plural of "man."

Bottom line: Don't try to make up words using a false Latin plural form. Since the word virus in its English form is now used then the English plural (viruses) should be used.

More plural-of-virus resources:

perl.com, the canonical and exhaustive source
The alt.comp.virus FAQ
Jonathan de Boyne Pollard's Frequently Given Answer
Merriam-Webster's "Word for the Wise," January 20, 2000.

You can read PDF without Acrobat.

http://www.cs.wisc.edu/~ghost/

Also, http://directory.google.com/Top/Computers/Software / ord_Processors/PDF/?tc=1

For terran bacteria withstanding vacuum is clearly more difficult than an atmosphere of carbon dioxide (Hmm we have that here), and inert gases. There is in fact an excess of material to feed upon. Not to mention that the lack of atmosphere on the moon results in an exposure to high levels of hard radiation.

I hope it's not too difficult for you to consider the possibilities of martian bacteria here on Earth.

6 hours of that convinced me that it is most likely Millikan's grad students we have to thanks for the thousands of data points needed for the accurate measurement of elementary charge.

Not knowing enough about the subject to want to jump into the actual debate, I just want to say that the way you describe it reminded me of this guy's paper on the "Electron Band Structure In Germanium". See Figure 1.

For it being the 'holy grail' in software development, it seems like the poster could have dug up some sort of linkage for those not hip with exactly what STL truly is all about...

For the ill-informed, please see the following links concern the C++ Standard Template Library (STL):

*** Mumit's STL Newbie guide

*** Standard Template Library Online Reference Home Page

*** Another Informational Link

There, I feel much better.... and hopefully you do, as well!!!

Why are there so many people complaining about a PS link? The answer is simple: ./ is news for nerds, not for geeks.

So while the average geek keeps his favorite postscript viewer handy, the standart nerd wonders about such an ancient format and does not know how to feed his acrobat viewer with it...

Here is the solution for those irritated ones: try this piece of ancient software on the ancient adobe format, and you can miracously view it's contents!

Have fun and keep your google handy!

Basically, boils down to this: we need highly renewable clean nuclear fusion power. The solution? He3-He3 fusion reactors (probably another 30-50 years off, but the potential is HUGE). The lunar surface is FULL of He3 (confirmed by Apollo missions). He3-He3 reactions produce NO Class A or Class C nulcear waste. And 1 ton of He3 would be able to produce 10,000 MWe-years of electricity. All you need to make this work is to perfect the reactor technology and find a cheap way of mining He3 off the lunar surface.

Best part is: mining for He3 through the surface can be done with robots and put in canisters sent back to earth. This can be done for MUCH MUCH less $$ than a lunar solar panel. Plus the power output is magnitudes more per unit of lunar surface area.

The presentation I got this material from is listed here:
http://fti.neep.wisc.edu/FTI/POSTERS/glk_amsterd am . df

Basically, boils down to this: we need highly renewable clean nuclear fusion power. The solution? He3-He3 fusion reactors (probably another 30-50 years off, but the potential is HUGE). The lunar surface is FULL of He3 (confirmed by Apollo missions). He3-He3 reactions produce NO Class A or Class C nulcear waste. And 1 ton of He3 would be able to produce 10,000 MWe-years of electricity. All you need to make this work is to perfect the reactor technology and find a cheap way of mining He3 off the lunar surface.

Best part is: mining for He3 through the surface can be done with robots and put in canisters sent back to earth. This can be done for MUCH MUCH less $$ than a lunar solar panel. Plus the power output is magnitudes more per unit of lunar surface area.

The presentation I got this material from is listed here:
http://fti.neep.wisc.edu/FTI/POSTERS/glk_amsterd am . df

I know it isn't kosher to reply to your own reply, but I thought about the original posting. Basic research can lead to good things, but applied research is not good in and of itself. For example, check out the work of Jean-Marc Vanden-Broeck and his pursuit of the drip free teapot. He has been richly rewarded.

Too late. Voyager is currently running on Nuclear Power, that 20 year life estimate mentioned in the article is actualy when they figure the juice will run out.

I never grokked why this stay-up-for-hours mentality became such a powerful meme with college students. I *always* did better by getting a reasonable amount of sleep than by staying up to cram. Give yourself a few extra days lead time for in-depth studying. Get proper sleep sleep for the period just before and during exams. Watch your performance soar.

Under some workloads, I can go along with the assertion that a MOSIX cluster is just like having a big machine with a lot of CPU's. It seems to be great for those workloads and I would love to try it out. Those loads tend to be multiple long running (more than a few seconds) and not multithreaded. For MOSIX to be most efficient, there also needs to be fewer jobs than there are CPUs to run them.

Other workloads, however, will not benefit from MOSIX. These statements are based on reading the docs a couple weeks back, not on actual experience.

Under the MOSIX model, when a process forks, the child may run on the current machine or it may migrate somewhere else. If the job is short lived (ls, echo whatever | sed s/blah/baz, you get the point) MOSIX will perform poorly because it will spend more time trying to figure out where the process should run than would have if it had just run the program on the local host.

If you need more CPU time than one CPU can provide and your program is multi-threaded, a single multiprocessor machine will also work better. This is because MOSIX does not yet support threads running on different machines. A 128-node cluster of 386's is going to run Netscape slower than a single 486 because you will only be using one 386 CPU.

For cases where you just have too many jobs for the resources available (CPU or memory), you may be better off with something like Condor. It is great for submitting batch jobs, migrating those jobs around, and only running the number of jobs that the system can handle.