Slashdot Mirror

No, this is different. In the case of the colliding webpages, bit level inspection immediately reveals what's going on: both "good" and "bad" version are included in the webpages, with an if-statement to choose which one to display.

When you inspect these binaries at bit level, they contain only the "good" or the "bad" version, and some random data appended to it to make the MD5 hash of the files collide. This technique thus also works for file formats which don't have control statements such as "if" or "file starts at offset". See also: http://www.win.tue.nl/hashclash/Nostradamus/, scroll down to: "Didn't Daum and Lucks do something like this in 2005?"

Marc Stevens already constructed these "chosen-prefix" collisions for X.509 Certificates, see the HashClash project page. What's new in these results, is that it did not require massively distributed computing efforts, only one Playstation 3 and less than two days of computation. There is no paper available yet as to how he achieved this major optimization, but his MSc thesis gives a clue: see "future work" at the end of section 7.4.

Isn't it kinda hard for MS to detect OS'es on other partitions without supporting their file systems?

If it is sufficient just to identify the filesystem type and infer the OS type from this, then it's really easy to do without supporting or understanding the filesystem. You just consult the single byte partition type indicator in the relevant partition table entry (a byte that MS must presumably be checking to distinguish its own FS types).
Table of partition identifiers: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html

Note that the presence of partition types 82 and/or 83 is a pretty reliable indicator that Linux is installed.

wire your own computer out out of logic gates!

MiniDisc uses SCMS (Serial Copy Management System), and it's relatively trivial to defeat. It's not encryption, it's just an extra bit set in the S/PDIF stream. See http://en.wikipedia.org/wiki/Serial_Copy_Managemen t_System and http://www.esrac.ele.tue.nl/~leon/scms/ (or Google for SCMS killer) for more information.

Many teams lost untold time on J because the judge data did not meet the input specification.

ICPC has had this problem before. Four times in my direct experience, most notably ICPC World Finals 2000 at which they refused to acknowledge their error until weeks later.

This year the data for problem J was wrong, so teams got "run time error" instead of "wrong answer;" many spent vast amounts of time trying to find the source of their crash when in fact it was the judges' fault. All submissions were rejudged at the eleventh hour, when it was too late to fix the problem or to move on to another question.

There is really no excuse for this sort of error. Published guidelines make it clear that input checkers should be written for all problems, yet the finals judges don't bother, and the finals organization imposes no standard on them to do so. Furthermore, the organizers refuse to release any information about the test sets, so we have no idea how many screwups have been covered up.

Here is a list of data errors for which I have first-hand knowledge. I'm sure there are many more.

Finals '97 -- Problem C has ambigous output but the
                            judges rejected some correct solutions
                            (all but their expected one?) Complaints
                            were responded to with "no response."

Finals '98 -- Problem D had empty lines in the input,
                            contrary to the specification.

Finals '00 -- The infamous graph that was not connected,
                            contrary to the problem spec (Problem F)

Finals '07 -- Problem J was supposed to have maximum size
                            64, but was 100. Rejudged in the last hour
                            of contest. Many submissions changed from
                            run-time or time limit to wrong answer.

I am at a loss to understand why the organizers fail to implement better quality control, and why they refuse to release the data and solutions. Bad calls will happen, but the lack of quality control and the lack of transparency exacerbates the problem considerably. These failures, in my opinion, detracts substantially from the contest.

Gordon Cormack
Coach, Waterloo ACM Team

How you got modded insightful is beyond me. This shit is real, very real, not just some propaganda from the Chinese. The attack on MD5 has been demonstrated by generating a couple of forged X.509 certificates based on the MD5 hash. It has long been suspected that MD5 harbored significant weaknesses, but it was confirmed in 2005 when Wang and her team demonstrated in a 2005 paper (warning PDF link) that it is possible to generate MD5 collisions with only about 2^39 hash computations (approx. 500 billion), a level of computational work which is doable in a matter of a few days even on the computer which I am using to type this post, and a very long way from the 2^64 computations required by a brute force attack. MD5 is well and truly broken, and not just in the academic sense, and anyone who says that the break doesn't affect the vast majority of its uses is either hopelessly uninformed or willfully ignorant. Checksums and digital signatures based on MD5 are now all suspect, and the only major application of the algorithm that remains unaffected is its use as a message authentication code, and the fact that the algorithm shown significant weakness in so many other areas should make anyone think twice before using it even for that. The biggest names in cryptography have been watching her work and that of her team with the keenest of interest, and there was an announcement (also here) that SHA-1 collisions could be found in 2^63 operations, which, while not feasible on my humble little PC, is within the realm of feasibility of today's fastest supercomputers and distributed computation clusters. Meaning that the NSA could probably generate SHA-1 collisions if they wanted to. Her most recent peer-reviewed paper on the subject gave a work factor of 2^69 for generating collisions, which while quite high, is quite a ways from the 2^80 required by true brute force, and that would make any serious cryptographer worried about using the algorithm.

The abstract also mentions "In the presence of the colloidal PVA-Pt as a catalyst and triethanolamine (TEOA) as a sacrificial electron donor, the photosensitized reduction of water to H2 takes place." This basically means that electron fro TEOA is being used to reduce water to hydrogen. This chemical (TEOA) is oxidized and has to be replenished to maintain the H2 production rate. I am not disparaging their results (they are valuable, otherwise it would not be published in such a reputed journal), but trying to put things in perspective. Compare this to the reports of water splitting using titanium dioxide and other ceramics ( http://adsabs.harvard.edu/abs/2006ApPhL..89p3106P, http://edu.chem.tue.nl/6KM11/files/Project%20repor ts%202003%202004/Photocatalytic%20water%20splittin g.pdf ) where water is split to yield hydrogen and oxygen without the need for any "sacrificial electron donor".

Ever wondered why your hard disk is full? Or what directory is taking up most of the space? When using conventional disk browsing tools, such as Windows Explorer, these questions may be hard to answer. With SequoiaView however, they can be answered almost immediately. SequoiaView uses a visualization technique called cushion treemaps to provide you with a single picture of the entire contents of your hard drive. You can use it to locate those large files that you haven't accessed in one year, or to quickly locate the largest picture files on your drive. http://www.win.tue.nl/sequoiaview/

Something along similar lines is Frank van Ham's work on visualizing large state spaces. He's generated some neat visualizations of complex transition systems associated with various protocols.

When my company, a very small software house, looked into integrating with workflow systems, we quickly came across this site:

http://is.tm.tue.nl/research/patterns/

Which contains a list of workflow patterns which they use to compare the expressiveness of different workflow solutions. Finding many of them lacking, they have now gone on to produce YAWL http://www.yawl.fit.qut.edu.au/ which aims to address the shortfalls of the systems they looked at. I found it quite a nice academic approach to a problem which the rest of the industry seems to approach with a lot less rigour.

The solution we ended up going with however was Object Connections Common Knowledge http://objectconnections.com/products/CommonKnowle dge.asp, which is similar to YAWL in many ways.

http://physicsweb.org/articles/news/7/11/15/1#need le

Ok, so its not slicing through his fingers but it's a step right.

* Scanner--shows hard drive usage as stacked pie graph of files/folders

Here's a vote for Sequoiaview, which does a similar thing in a different way.

Rik

That's nice. I've been researching repurposed game engines and there are some very interesting things out there. From architecture and geovisualization to interface with libraries. Even the blind are being helped

I've found this useful: http://is.tm.tue.nl/research/patterns/

My master's thesis can be found in the university's library, and the documentation I talked about is provided with the software to the clients.

The parent comment, which I wrote, was based on a severe misunderstanding of the extent of the capability of the attack. In particular, I didn't realize that the attack could find collisions even with arbitrary, attacker-specified IVs. What that means is that it is indeed possible to generate x.509 certificates containing different keys but the same MD5 hash (and therefore the same signature). In fact, it's been done.

The main problem with MD5 as it's used today comes when MD5 is used as a component of a digital signature scheme. Most digital signature schemes based on public key crypto work like this:

1. Generate hash of document to be signed
2. Encrypt hash of document using signer's private key (this is the signature)
3. Send document along with signed hash to whoever cares

To verify a digital signature, the following is performed:

1. Recompute hash of signed document
2. Decrypt signature using signer's public key, producing calculated hash
3. Compare computed hash and signed hash--if they match, signature is authentic

Now, it's easy to see why this spate of collision attacks on hashing algorithms is so deadly. If, given some signed document, you can produce another document that verifies to the same signature, well, I guess you're in a world of hurt. If these documents happen to be public key certificates, well, the whole PKI more or less collapses. And well, here's a bit of news: someone has done just that with X.509 certificates based on MD5.

http://web.phys.tue.nl/nl/people_pages/?script=sho wemp.php&pid=130 prof.dr.ir. G.M.W. Kroesen (Elementary Processes of Gas discharges)from the Technical University of Eindhoven has reproduced the experiment with succes. In his words (Dutch) "Je blijft zitten met het feit dat je een plasma kunt opwekt onder condities waaronder je niet verwacht dat je een plasma kunt opwekken. je vingers jueken dan als fysicus. Ik ben gewoon nieuwsgierig: wat is hier in godsnaam aan de hand?"

Translation
You continue sit with the fact that you can a plasma arouses under conditions among which you do not expect that you can arouse a plasma. that's when your fingers start to itch then as a physicist. I am simply curious: whatin gods name is happening?

What about seqoiaview

Personally, I like SequoiaView. Colorful 2-dimensional structures give me a great representation of file usage.

Check out this free utility. You might be surprised how much stuff you DON'T want is lurking on your system. This will help you track it down.

Could become a representative for Great Britian to the International Olympiad of Informatics next summer, to be held in Mexico.

If you're in northern Ireland, you'd compete in the Irish Schools' Programming Competition.

You can also compete in online contests such as USA Computer Olympiad (operated in the USA, but open to everyone), or a quick google search will yield more.

Oh, nonsense.

Here's a collection of proofs that P=NP.

http://www.win.tue.nl/~gwoegi/P-versus-NP.htm

Ooops, it seems that there are proofs that P!=NP in that collection as well. Maybe you're on to something.

I think we probably agree more than disagree - any turbofan for high speed applications will be a low bypass setup. At the moment though, I don't know of any flying aircraft that cruise at Mach 2+, turbojet or turbofan. I think the noise issues from a "pure" turbojet tend to push it out of the running (for civillian applications).

This isn't something I've looked into much lately, but did some reading - interestingly enough NASA was (is?) pushing a mixed-flow turbofan for supersonic (Mach 2+) cruise.

Some good diagrams for recent ideas on supersonic airliner propulsion can be found in [PDF file]. Most of these are centered around a low-bypass turbofan, although tweaked around to deal with the issues of high-speed flight and low-speed noise.

Personally, I don't think the engine type is the main issue to this type of aircraft - I suspect the environmental issues will be more critical (not just talking about sonic booms, but the exhaust products from the engines and the takeoff noise).

[1]
[LdW] A. Lenstra, B. de Weger: On the possibility of constructing meaningful hash collisions for public keys
http://www.win.tue.nl/~bdeweger/CollidingCertifica tes/ddl-full.pdf

[2]
Using the length extension property present in MD5 and all other hash functions following the (almost omnipresent) Merkle-Damgaard design principle, we constructed a pair of documents to display either the letter or the order.

"Earlier this morning I posted a very serious "Ask Slashdot" regarding getting advice on requirements for a remote "store and forward" system I'm trying to design for physicians in very remote areas of third world countries."

And yours get's modded "funny" while someone else with the same sentiment gets a "troll". Consistency isn't a slashdot strong point. Anyway grab a book on queue theory. The rest relates to physical environment, the nature of the communications links, as well as what's being communicated.

Without a restricted bootloader, you essentially guarantee that someone is going to open up the system, and that leads to the loss of a fixed hardware platform. You may, for example, upgrade your console's memory only to find that most games on the market are designed to handle exactly the number of bits necessary to cover the console's address range. As soon as something gets loaded outside that range, these games can't figure out how to access it, and instead access whatever garbage is addressed by the lower-order bits.

If it's important enough that the hardware remains fixed that the manufacturer thinks it has to monopolize the bootloader, I'd imagine fixed hardware that can be upgradable, but for which a switch can turn off the upgrades. For instance, that's why there's an A20 gate on the PC.

I want one of... whatever this thing is!

http://phys9901.campus.tue.nl:50080/remote6/

The 286 added protected mode, though not as nice as 386+. You could access up to 16MB of memory in 80286 Protected Mode. oh, baby!

The 386 finally added the ability for the control program to switch back to real mode. With that it carried a bug that allowed the user to set a segment limit of 4GB while in protected mode and then quickly switch back to real mode, giving the user access to a 4GB address space in real mode (where only a 1MB address space should be available). Many games and demos circa 1992-1993 exploited this "Unreal-mode" feature like Ultima 7 and Zone 66, and were known to be the nastiest, most incompatible programs ever to exist, never getting along with any memory manager or multitasking operating system. If only game programmers had used something sane like DPMI back then!

IIRC the 486 added something related to cache, I forget if it was on-chip cache

With an 80% average, you probably went somewhere middling for college (not that there's anything wrong with that...), which means that your competition in your classes (most of which I presume were graded on a curve) was less severe (than it would be at a top university, generally speaking).

It's important for us to have a realistic view of our abilities. It's also important to realize that the difference between a "B" and an "A" is usually pretty significant (more folks can get a B than could get an A, for starters). So "being close" doesn't buy you much.

I am saying that there is something more difficult in excelling at hard subjects than excelling in soft subjects (where for "soft" subjects, grading is often much more subjective).

You know, this question really doesn't have anything to do with Apple. It's a hypothetical question based on a processor architecture, and not necessarily Macintosh-based computers. Both IBM and Freescale sell Power PC microprocessors, and technically any motherboard manufacturer can design a board for a PowerPC, and buy the CPUs from either manufacturer, much as how they currently design boards for either Intel or AMD processors.

Why? Well, because the Power PC architecture doesn't have all of the nasty cruft that Intel-based systems have. Like IRQ nastiness that people keep designing around. Or the fact that they boot up in real mode, and need to be switched into protected mode as part of the boot process. Or all of the various BIOS limitations, like the fact you can't address beyond the first 1023 cylinders of a hard drive during IPL. Of the . Or the x86 instruction set and registers.

The cost of this cruft is both cost and power. As cheap as Intel-based hardware is (due to the economies of scale), it could be cheaper if it didn't have to contain hardware and code to work around the many limitations of the architecture. It would also be quite a bit faster than it currently is.

Windows on Power PC would be a boon for users, if either (or both) IBM and Freescale could ramp up production sufficiently, and if every Intel Windows user were willing to give up their current software investments (or if such a Windows system run Intel binaries).

Of course, Windows itself would still suck :).

The things keeping people from making such a move aren't technical -- they're economic and social.

Myself, I'm composing this on a PowerBook G4 running Mac OS X. I have little or no desire to run Windows on any architecture. I doubt if you'd find too many existing Power PC users who wish they could run Windows as their core OS -- it's Windows users who should want to run to run their OS of choice on an affordable Power PC architecture.

Yaz.

It took me a week only to get familar with the very basics; how to install the damn thing, where to put stuff so latex finds it, which commands must be called in what order to get anything out of it, basic LaTex-syntax, how to decipher LaTeX error messages to navigate through dependency-hell, which classes to use, how to set options and in what order and by which method (different classes use different styles), how to get proper pdf output without crippling the fonts, how to position images at least close to where i want them etc. etc.

Sure it's complex if you need to meddle, and definitely it can be hard to learn, but that doesn't really contradict my point. My point was that, once I'd done a few hard yards (learning LaTeX, writing my own document classes) everything I needed to do was simple, and it was very usable. I wasn't saying that LaTeX in all is simple and usable, I was saying that, for doing what i wanted to do LaTeX let me create a system that was simple and usable. What I mean is this: I'm sure you could do, in Word and Powerpoint, exactly what i described in LaTeX - a mixed report/presentation format. In Word and Powerpoint though, you would be getting your hands very dirty hand hacking binary .doc files so that Powerpoint would accept them, and ignore all the bits you wanted it to. Compared to anything like that the LaTeX solution I created is both simple and usable.

With all that knowledge I'm still far from being able to do something supposedly simple as, say, design a custom letter head or footer.

I'll give you a hand on that one - what you want is the fancyhdr package. You can find some documentation here. It will at nleast give you an idea of what you can do - rememberign of course that you can include graphics in the headers and footers provided if you like.

Jedidiah.

Actually, the International Biology Olympics are just over yesterday... And other sciences, like Informatics, Physics and Chemistry have them too...

While there are a lot of History olympiads there doesn't appear to be an international competition. And as for latin, there is a country which hosts a "National Greek and Latin Olympiad"

Infer from that what you will...

Hate to rain on your parade, but the Linux kernel itself is between 1.8M and 3.3M LOC (I say "between" because I'm not sure what kernel version the Zaurus has). So any way you look at it, when you add up all the source for the Zaurus's components and the Linux kernel you're getting up to or above the 2.5M LOC figure that you seem to think is unacceptable for an embedded device.

Some Linux kernel developers may disagree with you.

maybe something like this blog treemap, or this one that represents file sizes

I couldn't agree more. A month ago I started serious kernel programming and my code wouldn't have been what it is if I hadn't found out about the free, online version of the second edition.

Some other useful sites :
the Linux kernel API reference

Linux cross reference, especially the `identifier search'.

the driver porting series over at LWN.net (which Rufus211 alreay pointed out).

the module init tools FAQ

this document, aptly titled `the linux kernel'

apart from these there are many more interesting links, but mostly those have to do with specialty domains, such as networking or memory management. I pasted my bookmarks.html to my personal website.

And lastly, if you want to do cross-version /dev (mknod and devfs), mmap, module or networking development, please take a look at our project's cvs server through our website (webcvs) at ffpf.sourceforge.net. The directory ffpf/srv/v1.1/generic contains some files I created that work on both 2.4.24 and 2.6.1 and which I'll test on a 2.3.99 system shortly.

Argh!
This is very bad news for a computing purist.
We get to live with the ugliest hack ever, for
yet another 20 years.

Please burn all CPU designs that contain the
A20 gate.

RELEASE
The Linux man page maintainer proudly announces. . .

man-pages-1.65.tar.gz - man pages for Linux

POSIX
This release is the first to contain the POSIX 1003.1-2003 man pages. The directories man0p, man1p, man3p contain descriptions of the headers, the utilities, and the functions documented in that standard.

Permission to distribute these POSIX man pages has just been obtained, and the pages in man0p, man1p, man3p were derived from the POSIX html pages by some silly conversion script. No doubt the result is still full of flaws, and all of this can be much improved. Corrections, scripts, etc. are welcome - aeb@<snip>.

In order to use this, put in {/usr/share/misc/}man.conf{ig} or so your favourite order of looking at these pages, for example,
MANSECT 1p:1:8:0p:3p:2:3:4:5:6:7:9:tcl:n:l:p:o
or set the MANSECT environment variable.

OTHER PAGES
The remaining pages are most of the section 2, 3, 4, 5, 7 man pages for Linux, and in addition section 1 man pages for the fileutils-4.0 utilities, and section 5 and 8 man pages for the timezone utilities.

[The latter were taken from ftp://elsie.nci.nih.gov/pub/tzcode2001a.tar.gz.] [The section 3 man pages for the db routines have been taken from ftp://ftp.terra.net/pub/sleepycat/db.1.86.tar.gz.] [The rpc man pages were taken from the 4.4BSD-Lite CDROM.]

Differences from version 1.64:

POSIX pages were added

The man pages

chroot.2 clone.2 intro.2 mkdir.2 remap_file_pages.2

errno.3

sk98lin.4

elf.5 protocols.5 raw.7

are new or have been updated. Typographical or grammatical errors have been corrected in several other places.

Here is a breakdown of what this distribution contains:

Section 0p = POSIX headers
Section 1p = POSIX utilities
Section 3p = POSIX functions

Section 1 = user commands (intro, and pages not maintained by FSF)
Section 2 = system calls
Section 3 = libc calls
Section 4 = devices (e.g., hd, sd)
Section 5 = file formats and protocols (e.g., wtmp, /etc/passwd, nfs)
Section 6 = games (intro only)
Section 7 = conventions, macro packages, etc.
Section 8 = system administration (intro only)

Usually, there are no section 1, 6 and 8 man pages because these should be distributed with the binaries they are written for. Sometimes Section 9 is used for man pages describing parts of the kernel.

Note that only Section 2 is rather complete, but Section 3 contains several hundred man pages. If you want to write some man pages, please do so and mail them to aeb@<snip>.

The following people (listed in alphabetical order by first name) wrote, edited, or otherwise contributed to this project:

<snip>

Copyright information:

For the POSIX pages permission to distribute was given by IEEE and the Open Group, see POSIX-COPYRIGHT.

For the remaining pages, please note that these man pages are distributed under a variety of copyright licenses. Although these licenses permit free distribution of the nroff sources contained in this package, commercial distribution may impose other requirements (e.g., acknowledgement of copyright or inclusion of the raw nroff sources with the commercial distribution).
If you distribute these man pages commercially, it is your responsibility to figure out your obligations. (For many man pages, these obligations require you to distribute nroff sources with any pre-formatted man pages that you provide.) Each file that contains nroff source for a man page also contains the author(s) name, email address, and copyright notice.

RELEASE
The Linux man page maintainer proudly announces. . .

man-pages-1.65.tar.gz - man pages for Linux

POSIX
This release is the first to contain the POSIX 1003.1-2003 man pages. The directories man0p, man1p, man3p contain descriptions of the headers, the utilities, and the functions documented in that standard.

Permission to distribute these POSIX man pages has just been obtained, and the pages in man0p, man1p, man3p were derived from the POSIX html pages by some silly conversion script. No doubt the result is still full of flaws, and all of this can be much improved. Corrections, scripts, etc. are welcome - aeb@<snip>.

In order to use this, put in {/usr/share/misc/}man.conf{ig} or so your favourite order of looking at these pages, for example,
MANSECT 1p:1:8:0p:3p:2:3:4:5:6:7:9:tcl:n:l:p:o
or set the MANSECT environment variable.

OTHER PAGES
The remaining pages are most of the section 2, 3, 4, 5, 7 man pages for Linux, and in addition section 1 man pages for the fileutils-4.0 utilities, and section 5 and 8 man pages for the timezone utilities.

[The latter were taken from ftp://elsie.nci.nih.gov/pub/tzcode2001a.tar.gz.] [The section 3 man pages for the db routines have been taken from ftp://ftp.terra.net/pub/sleepycat/db.1.86.tar.gz.] [The rpc man pages were taken from the 4.4BSD-Lite CDROM.]

Differences from version 1.64:

POSIX pages were added

The man pages

chroot.2 clone.2 intro.2 mkdir.2 remap_file_pages.2

errno.3

sk98lin.4

elf.5 protocols.5 raw.7

are new or have been updated. Typographical or grammatical errors have been corrected in several other places.

Here is a breakdown of what this distribution contains:

Section 0p = POSIX headers
Section 1p = POSIX utilities
Section 3p = POSIX functions

Section 1 = user commands (intro, and pages not maintained by FSF)
Section 2 = system calls
Section 3 = libc calls
Section 4 = devices (e.g., hd, sd)
Section 5 = file formats and protocols (e.g., wtmp, /etc/passwd, nfs)
Section 6 = games (intro only)
Section 7 = conventions, macro packages, etc.
Section 8 = system administration (intro only)

Usually, there are no section 1, 6 and 8 man pages because these should be distributed with the binaries they are written for. Sometimes Section 9 is used for man pages describing parts of the kernel.

Note that only Section 2 is rather complete, but Section 3 contains several hundred man pages. If you want to write some man pages, please do so and mail them to aeb@<snip>.

The following people (listed in alphabetical order by first name) wrote, edited, or otherwise contributed to this project:

<snip>

Copyright information:

For the POSIX pages permission to distribute was given by IEEE and the Open Group, see POSIX-COPYRIGHT.

For the remaining pages, please note that these man pages are distributed under a variety of copyright licenses. Although these licenses permit free distribution of the nroff sources contained in this package, commercial distribution may impose other requirements (e.g., acknowledgement of copyright or inclusion of the raw nroff sources with the commercial distribution).
If you distribute these man pages commercially, it is your responsibility to figure out your obligations. (For many man pages, these obligations require you to distribute nroff sources with any pre-formatted man pages that you provide.) Each file that contains nroff source for a man page also contains the author(s) name, email address, and copyright notice.

I happened to be in Berlin last Saturday. Here's a photo of the Humboldt university on Unter den Linden as it looks now, during the protests.

Linux 0.01 (Sep 1991) is 10239 lines of code, 0.2 MB.
Linux 0.10 (Dec 1991) is 17750 lines of code, 0.4 MB.
Linux 0.99 (Dec 1992) is 81091 lines of code, 2.2 MB.
Linux 1.0.0 (Mar 1994) is 176250 lines of code, 4.7 MB.
Linux 1.2.0 (Mar 1995) is 310950 lines of code, 8.4 MB.
Linux 2.0.0 (Jun 1996) is 777956 lines of code, 22 MB.
Linux 2.2.0 (Jan 1999) is 1800847 lines of code, 52 MB.
Linux 2.4.0 (Jan 2001) is 3377902 lines of code, 100 MB.
Linux 2.5.37 (Sep 2002) is 5100081 lines of code, 152 MB.
Linux 2.6.0-test9 (Oct 2003) is 5928160 lines of code, 212 MB.

http://www.win.tue.nl/~aeb/linux/lk/lk-1.html

or did anybody else notice that Jupiter's north pole is pointing down in these photos. Oh, yeah, and look at this page for some photos of dark spots caused by comet Shoemaker-Levi 9.

Here's a list...there are some other interesting ones on there too, like that weird Fn key on laptops.

You wanna see a plasma lamp?

If your at work, look up.

Those florescent lights are plasma lights with a phosphorus coating that absorbs the UV light emitted by the plasma and emits visible light. The plasma is created by applying high voltage to the electrodes.

Did you know that there is no such thing as a white fluorescent light?

The lights are shifted ever so slightly towards either the red green or blue spectrum. Thats why if you go into a older office building and look up you will likely notice that some of the lamps just don't look the same - look at it closely relative to the other lights and you can tell what color shift it has.

Neon lamps (I believe any noble gas will do), cold cathode lamps (the ones people install in their windowed computer cases), those cheesy globes that when you touch them lightning shaped light appears to be reaching for your finger - all plasma.

Read about plasma here:

http://www.prl.dcu.ie/expl.html


Here are the different ways to create plasma:

http://www.phys.tue.nl/EPG/epghome/polylab/sourc es .htm


Or if you can find them - some of you probably remember these:

http://bulbmuseum.net/bulbs/figuralargon.htm


Noble gases:

http://www.theodoregray.com/PeriodicTable/Elemen ts /NobleGases/index.s7.html


Anyway the real story here is the tools that they used to capture the data in the instant that is takes to turn on the lamps. I see nothing of intrest here esp. regarding 'life'.

The crap about life is garbage. Plasma is the fourth state of matter (solid, liquid, gas, plasma). They are not "reproducing" thereby mimicking life. Rather, they are merely converting an element from one physical state to another.

Quick theory:

Gas can not pass an electrical current because if the electrons (- charge) in the atom move then the rest of the atom goes along with including the + charged protons.

The electrical potential (voltage) has to be high enough such that the electrons begin to be ripped away from the atom itself. This exchange of energy causes the gas matter to change from a gas state to a plasma state and is called ionization. The emission of light (photons) is caused by the change in energy states. As you can see here..

http://zebu.uoregon.edu/~js/ast123/images/bohr_a to m.gif


When an electron jumps from one orbit to another energy must be released by the atom this energy is released in a form of a proton at a fixed wavelength relative to the distance of the state change (atom specific). If the wavelength falls into the visible range of the EM spectrum you'll be able to see it.

I don't have WinXP, I use Windows 2000. It currently takes about 1Gb. Here is a picture of the contents made using Sequoia.

http://www.lut.fi/~medvedev/misc/winnt.jpg

As you can see, most of it is code in system DLLs. Of course, it has been shown in the past that MS code is bloat. We can safely assume that 90-95% of the typical DLL is never used. Some useless resources, uncompressed bitmaps and crap like that. A lot of space is occupied by dll cache, a completely stupid feature made to solve a completely stupid problem. The rest of the WINNT directory is bloat as well, the problem is that it's distributed bloat and you can't easily pinpoint it and say "remove this file" (although that was done for Win95 recently very successfully). All files are bloated and all look like they serve some function. But they are bloated, oh yes, they are.

As of 2.4 it looks like there were approximately 3.4 Million lines of code in the kernel See Here.

So roughly 1/3 of linux is directly copied from unix? Gimme a break.

Google does. According to this site:

Linux 2.5.37 (Sep 2002) is 5100081 lines of code, 152 MB.

So according to SCO, almost 20% of Linux is copied directly from their code. I can't believe they're even seriously trying any more, what with this and their blatant misreading of copyright law claiming that licenses allowing multiple copies to be made are invalid.

According to here:

Linux 0.01 (Sep 1991) is 10239 lines of code, 0.2 MB.
Linux 0.10 (Dec 1991) is 17750 lines of code, 0.4 MB.
Linux 0.99 (Dec 1992) is 81091 lines of code, 2.2 MB.
Linux 1.0.0 (Mar 1994) is 176250 lines of code, 4.7 MB.
Linux 1.2.0 (Mar 1995) is 310950 lines of code, 8.4 MB.
Linux 2.0.0 (Jun 1996) is 777956 lines of code, 22 MB.
Linux 2.2.0 (Jan 1999) is 1800847 lines of code, 52 MB.
Linux 2.4.0 (Jan 2001) is 3377902 lines of code, 100 MB.
Linux 2.5.37 (Sep 2002) is 5100081 lines of code, 152 MB.