Slashdot Mirror

you could get one of uPenn's ENIAC on a chip samples and start porting - not sure how Linux will make use of the "square rooter" but that's a good start on a math-coprocessor.

Chuck

Found this link a while ago... some interesting historical info, too:
Eniac on a chip

John W. Mauchly and the Development of the ENIAC Computer

http://www.ee.upenn.edu/~jan/eniacproj.html

In Philadelphia, Pennsylvania. In the University of Pennsylvania School of Engineering and Applied Sciences. (I know someone who work there, and visited him a few times. Apparently, they do tours from time to time.)

You can look at the stuff about it at The Birth Of The Information Age exhibit. For something deeeeeply funky, I suggest looking through the programming manual. You can, in fact write PROGRAMS for ENIAC, even today.

I find this highly amusing.

In Philadelphia, Pennsylvania. In the University of Pennsylvania School of Engineering and Applied Sciences. (I know someone who work there, and visited him a few times. Apparently, they do tours from time to time.)

You can look at the stuff about it at The Birth Of The Information Age exhibit. For something deeeeeply funky, I suggest looking through the programming manual. You can, in fact write PROGRAMS for ENIAC, even today.

I find this highly amusing.

See this for the full (889k) 1999 draft text.

http://www.law.upenn.edu/lib rary/ulc/ucita/citam99.htm

http://dept.physics.upenn.edu/nine planets/titan.html

--ac

One of the difficulties in working through all the hype on both sides, is that the shift from UCC2B to UCITA leaves us without a specific draft to criticize. Critics are free to exaggerate supposed defects, and of course, advocates can do the same. Anyway, before taking the article's word for it, look at the last drafts of UCC2B, ask yourself why critics aren't really citing its language, and consider well whether you are being completely and honestly informed by critics or advocates alike.

UCC2B is not all bad, and not all good, IMHO. However, some of the comments in the subject article strain credulity and, regrettably, much of it is demagoguery from various special interest groups trying to stir up dissent.

For example, shrinkwraps. Shrinkwraps are not the enemy of open source -- to the contrary, they are part of what makes the open source license "virus"es work. Some here have argued that this law can somehow have retroactive effect on already existing contracts and past reverse engineering -- Not so, indeed, a law that changed existing contract rights would be unconstitutional. In short, while I understand why the software defect plaintiff's lobby is all in a huff about greater certainty in enforcing shrinkwraps, I'm not sure that the OSS community shouldn't be planting itself squarely on the fence on the issue.

Some other points made in the article:

prevent the transfer of licenses from one party to another without vendor permission;

Of course, this can be (and often is) accomplished under the status quo with a commonly used contract provision. I actually prefer the common law default to the language of UCC2B, but I don't see this as either new or particularly egregious.

allow vendors to disclaim warrantees; and

Vendors can presently disclaim warrantees.

outlaw reverse engineering.

I believe you can review the last draft in vain to find a provision outlawing reverse engineering. Still further, it is doubtful that a state law could do so under present law without violating the Supremacy Clause of the Constitution. Indeed, the last draft of the UCC2B has an express example in the commentary expressly noting circumstances where unconsented reverse engineering is not a breach!

Why are they exaggerating if their case is so strong? Think about it. Its not.

I find great flaws in the UCC2B as do others. However, while flawed, it is not the unmitigated disaster it is held out to be by its critics (although it is certainly special interest legislation). As is often the case, the truth is more interesting.

I do believe slashdotters should educate themselves about this bill, study its provisions (the real ones, not the straw men) and judge for themselves what should be the law. But UCITA is not suprise legislation -- these proposals have been brewing now for years. Consider them carefully, and use what power you have, particularly now that it is no longer UCC, to help your legislators to separate the wheat from the chaff.

So, RTF Bill, read the commentary on both sides, and judge for yourselves.

Maybe he has an ENIAC-on-a-chip.

David Farber, while being very well respected in his field, is also on the board of directors of Democrats Online, which apparently no longer is actually online. I don't think that you could consider him as "unbiased".

If you want to look at a really new OS, check out the Extremely Reliable Operating System (a.k.a. the EROS project). It's not ready for users yet, but if want to hack on a new OS, the pre-release might be just what you're looking for.
-----

If you want to look at a really new OS, check out the Extremely Reliable Operating System (a.k.a. the EROS project). It's not ready for users yet, but if want to hack on a new OS, the pre-release might be just what you're looking for.
-----

Not only are disk-writes faster on journeled file-systems, there are also such things as journeled operating systems.

That is, if you turn the power off and turn it on, the entire OS comes back on to a state within a few minutes of where it was. One example that looks interesting is EROS.

I have not seen this one in operation, but there are theoretical arguments for their speed claims, and (as they say) it is theoretically impossible for *any* OS based on access lists (such as Unix) to achieve the same level of security that a capability based system can. (Note, I said "can", not "does".)

Regards,
Ben Tilly