Slashdot Mirror

Indeed - I was making an example with too much haste. I should just have posted a link to Google images.

http://www.lsi.upc.es/~valiente/knuth-1998-08-10.jpg
http://truetex.com/knuthchk.jpg
http://www.lsi.upc.es/~valiente/knuth-2002-08-24.jpg

etc...

The point Knuth makes in his post is that these things got framed and put on CompSci notice boards etc. Obtaining the details became trivial. The OP was suggesting that Knuth's accounts being targeted was in some way odd when in fact it was predictable if unfortunate.

Indeed - I was making an example with too much haste. I should just have posted a link to Google images.

http://www.lsi.upc.es/~valiente/knuth-1998-08-10.jpg
http://truetex.com/knuthchk.jpg
http://www.lsi.upc.es/~valiente/knuth-2002-08-24.jpg

etc...

The point Knuth makes in his post is that these things got framed and put on CompSci notice boards etc. Obtaining the details became trivial. The OP was suggesting that Knuth's accounts being targeted was in some way odd when in fact it was predictable if unfortunate.

Anyway, HP can complain as much as they want. I find that surprising. The Mare Nostrum is a result of many years of colaboration between the UPC and IBM in the form of the CIRI (CEPBA-IBM Research Institute), a center where research on parallel applications and tools is conducted. IBM had the intention to build a large supercomputer out of PowerPCs and blades and they were considering even places outside of the US. People at UPC and particularly the CIRI and the Computer Architecture department started talking with the government to bring the machine here, and along with it, start a new research institute on supercomputing (the BSC, btw my new employer). well that's at least what I've heard here at upc.

So HP would have wanted to compete??? As far as I know, all research that HP does in barcelona is dedicated to printers ...worse, it could be 4500 itaniums, can you imagine? ;-)

This story should be about the legal rights of instances of software processes rather than computer's per se + it we could speculate that we might have pretty autonomous entities well before they are legal. An example is this speculative paper [pdf tech report / UPC in spain]. for the metadata see here - the author speculates that it might be possible to build systems which can "feed themselves" (covering all their own hosting/server needs) by generating cash from on-line games for periods of month or years pretty soon.

Disclaimer - i do know the author - no doubt there are plenty similar papers out there.

This story should be about the legal rights of instances of software processes rather than computer's per se + it we could speculate that we might have pretty autonomous entities well before they are legal. An example is this speculative paper [pdf tech report / UPC in spain]. for the metadata see here - the author speculates that it might be possible to build systems which can "feed themselves" (covering all their own hosting/server needs) by generating cash from on-line games for periods of month or years pretty soon.

Disclaimer - i do know the author - no doubt there are plenty similar papers out there.

http://www.cis.upenn.edu/~sequence/ http://graphics.cs.brown.edu/research/telei/home.h tml

And Internet2 has this type of technology as one of its goals. See http://www-pagines.fib.upc.es/~si/treballs-SI2001/ e4024048/Tele-immersion.htm

Informative.

A GRID is a non-centralized distributed system, sharing storage, processing and connectivity with quality of service guarantees, over open protocolls. Is that about right?

Last summer, I was in Barcelona for a class trip. We visited the European Center for Parallellism of Barcelona (Like there are redundant arrays of Barcelonas. Well, there's the smaller town/city of Badelona right outside Barcelona.)

Anyway...

The CEPBA is a partnership with IBM. I talked to one of the IBM researchers there. They very much believed in the GRID as a distributed system that would hold all your personal data for you, and where you would buy your processsing power and storage from big vendors. Thus users wouldn't have to keep up with the hardware advances themselves.
I suggested that some of the less time-critical processing and storage resources could be provided by the nodes themselves. He did not buy into this idea.
This philosophy reminds me of the old time-sharing systems of yore. If GRIDs are really deployed to a vast number of users, I would predict that users with smaller processing power would team up and sell their (lower quality?) processing to other users, much as the F***** Article says. The only thing that could preclude this would be an enforced requirement that only reputable vendors provide services with QoS guarantees, and digital restrictions stop users from selling their cycles.
Why not have several layers/levels of quality and security? That's much of the point of QuS, isn't it -- telling what's your worst offer and the client deciding beforehand wether to accept your service level?

Oh, look: Now their saying that institutions really WILL be able to pool their resources What is GRID compiting
Looks like I was "getting with the program" better than that IBM guy was. Either he misunderstood or given wrong information (something I've done a few times and been ashamed of), or is a firm believer in that Those darn kids will never provide the computing power! Only me and my VAX!

You are confusing LEO (Low Earth Orbit) and GEO

Not at all. The problem, as I mentioned, is the complex application of CDMA in LEO systems. You are correct that in the physical layer, distance overcomes latencies inherent in GEO/MEOs. However, the time differential in high-velocity LEOs requires a multiplexing protocol like S-ALOHA CDMA (sorry, pdf).

To integrate these stat pattern multiplexing applications into the heavy traffic of a dense system creates its own latency.

The site, as well as the posters in this discussion fails to address another important hurdle in IPv6 deployment: applications!

It seems as most people seem to address the transport layer problems; such as migration and reconfiguration of network equipment (routers) as well as end-hosts, the more important application layer deployment is neglected.

Think, when all end-hosts and immediate routers are IPv6 ready; and hosts can one day communicate with each other natively over IPv6, what is the use if the pace of application development fails to follow?

I have worked with IPv6 in my final-year thesis; as well in an internship with NTT (a part of the KAME project sometime back), we can get FreeBSD up and running with IPv6 almost instantly, but what's keeping us back? Applications, of course.

The socket connection functions within the applications need to be upgraded (mainly to support a bigger address structure). For example, the sockaddr_in has to be upgraded to support sockaddr_in6, the address structure for IPv6. After that has been done, more changes in the User Interface might need to be done (for example, to allow users to enter IPv6 addresses directly in a textbox).

Fortunately, after a 4 years, the most important applications have already been ported. Apache now supports IPv6, same goes Mozilla and IE, and most importantly, BIND for DNS resolution.

However, there are still probably thousands, if not millions of other applications that need to be ported one by one (albeit simply).

The link from google to port your application:

Porting applications to IPv6 Howto

cheers

Bayesian filters for spam have extensively been studied and compared in the last few years.

• An evaluation of Naive Bayesian anti-spam filtering
• An Experimental Comparison of Naive Bayesian and Keyword-Based Anti-Spam Filtering with Personal E-mail Messages
• Learning to Filter Spam E-Mail: A Comparison of a Naive Bayesian and a Memory-Based Approach

Recently more filtering methods have been studied.

It's good to see someone implementing these techniques

According to this document, you're both wrong. The first known Mac virus was the "Peace" virus. This virus actually did spread through a HyperCard stack, but not via HyperTalk as the original poster suggested (e.g. the "Merry XMas" virus). Rather, an infected XCMD installed an infected INIT directly into the system. For people that knew HyperTalk, the Merry XMas virus was much easier to deal with, since the code is easy to get at - the virus functioned, as I recall, by trapping the "set" command.

Only some families of asynchronous hardware suffer from the problems of slow feedback. Typical bundled-data handshaking, as described above, generally does suffer from these problems; however, an approach developed at Adelaide University and known as FeFA manages to remove the bulk of the feedback. It is more similar to synchronous logic than most asynchronous styles, but the performance is generally slightly better (due to lower latency) and the noise and power consumption are both a lot lower.

[For the uninitiated: noise emissions are bad in synchronous circuits due to the switching of the clock - everything happens at once, so you get noise at the clock frequency and its harmonics]

In addition, speed-insensitive designs - for which software synthesis tools, notably the open-source petrify, now exist - do not have typical feedback paths, but each logic block provides its own indications of completion by a different data encoding. This offers the benefits of *no* timing constraints whatsoever, resulting in (theoretically) much easier design processes and a significantly higher level of tolerance to fabrication errors.

If you come with some science-fiction idea and you want to enter a contest, try the UPC Science Fiction Award, "the most important science fiction award in Europe" (Brian W. Aldiss).

Languages are EN, FR, ES and CT.
Prizes are up to 1,000,000 ESP (~= 6,010 EUR) and publishing. (Gimme 1% if you win ;) )

You have until September.
__