Slashdot Mirror

I mean, you can't say that all software patents are invalid because someone had already invented assembly language. Or that no mechanical devices can be patented because they all make use of the classical machines (lever, wheel, whatever, I forget, I'm a software guy).

raph's mention of Sprite seems to be getting close...the "main" system determines what and when the "remote" computers execute.
--

First, let me add my voice to those who say that Slashdot's patent stories could use a clue or two. These sensationalistic headlines don't help anybody. I'll be adding a patent section to Advogato soon, and it's my hope that this will become a good place for informed discussion of patents relating to free software.

When you analyze a patent, the most important thing to look at is the claims. The abstract has little or no legal force, it's just there to help people searching (it's on the front page of paper patents, which was important back in the days when people searched through stacks of them :). The language of the claims has to be read in the context of the disclosure of the patent, and to really do it right, you have to read the file history too.

That said, this is another example of the US Patent and Trademark Office screwing up royally. Claim 1 covers a pretty generic computation load-sharing system - a central computer keeping track of a bunch of tasks, sending a start message to a remote computer to ask it to take the task, and the remote computer sending a complete message back to the server.

The problem here is that there is prior art up the wazoo. I'm sure experts in the field could come up with more, but just about any operating system with process migration, such as Sprite should do. The main work on this project was all done in the early '90s, plenty of time to serve as prior art.

The disclosure doesn't help the case. It talks about the types of tasks to be distributed in extraordinarily vague terms, so much so as to not make much sense. Compressing MPEG's remotely? Are they on crack? Even a 320x200 at 30fps is over 5 megabytes per second of raw data. And of course serving up web pages is fraught with problems, such as latency, security, admin costs, reliability, and so on. The patent does not so much as mention these problems, let alone propose a reasonable method of dealing with them.

So what do you do when you have such a crappy patent? I think a reasonable thing for free software authors to do is ignore it. In theory, Intel could bring suit against a free software project for violating this patent. However, in that case it seems likely to me that we'd be able to get a good pro bono legal team together, and the patent would almost certainly be overturned.

In the meantime, I think our best option is to keep well informed about patents in general, and about specific patents that may be relevant. Shallow, "golly gee-whiz, look at the patent they just got on breathing" stories don't help much.

Set your proxy to nrl.onion-router.net:9200.

Read about AT&T Crowds, about TAZ-WWW, see the Proxy Mate, see the COTSE anonymizer or look what fravia has to say about anonymity.
© Copyright 1999 Kristian Köhntopp

The picture is available her e, and as you can see it is not a dual gated FET, but just has a gate that wraps around. Granted, I'm fairly sure that the picture is not to scale.

Comments? And thank you for an intelligent reply.

Pretty ballsy move. I expect some beancounters at the university must be just a weeeee bit choked right now.

No, nobody is choked right now. Any patent would belong to the University, not to the researchers. The decision to not patent was made by the university. Hell, IIRC, the very first paper I signed when I matriculated as an undergrad at UCB assigned all rights to any intelectual property I developed, while at the University, back to the school. And that was a long time ago.

Yes, It is an insightful move by the University not to patent this.

Go Bears!

Another big push to the Langland's Program is a connection between Elliptic Modular Forms and group theory. The Monster Group's character table consists of linear combinations of coefficients from the Jacobi expansion of the elliptic modular function - this property is called Moonshine.
Nobody has the faintest idea why.

A pointless coincidence - both links above point to a computer called 'shimura'.

SETI has always had trouble creating enough work units to keep up with user demand. The project is more popular than anyone had ever dreamed.

One of the patches cause the clients to run 30% faster (at least on my clients). I've heard some reports of clients running 50%-70% faster.

SETI just can't generate that much data to munch. If they did speed up all the clients and they ran out of blocks, users would be very upset. Solution... SETI would start sending out the same blocks to be rechecked while waiting for new blocks to be created. And users would be upset because they were doing the same blocks twice.

In either case, they lose.

As for the open source discussion, that is meaningless in terms of SETI. Their problem isn't that the client it too slow, but that it has the potential to be too fast.

InitZero

The insistence with which some people clamor for open sourcing everything really annoys me (and a lot of other people). There are very good reasons not everything is open sourced, and sometimes they're not even due to stupid licensing restrictions imposed by third-party code.

For something like SETI@home (or distributed.net or whatever else you like), there's a very good reason to keep the clients binary-only. Namely, there is no oracle for verifying that a block of search space was actually searched by the client that claims to have searched it. Abuse of this was seen by the DES challenge and distributed.net before; open-sourcing SETI@home would lead to even worse abuses. Unethical people would modify the code to claim they had searched oodles of key blocks, ruining the results of the search -- and only so they could show off how "studly" their computer system is.

Of course, maybe this concept is too hard for bgp4 to grasp. But for goodness's sake, it's in the SETI@home FAQ. Whining about their policies on Slashdot isn't likely to change their minds.

(Beyond the malicious introduction of false reports, it's very easy to "optimize" something like this and introduce numerical or algorithmic errors. Unless you are familiar with advanced theories of signal processing -- the sort of thing you'd find in graduate classes at a good university -- you would be well over your head in looking at how the algorithms work. And there are enough bright grad students working on the average project to know how to optimize for all sorts of cases without the help of a bunch of open source zealots who think that the GPL is some magic potion that can be applied to anything to make it better.)

Try Berkeley Extension, they have a good Comp/Sci program and offer quite a few distance learning courses over the web.

folks would be wanting to read this very fine text on the econ. of copyright, which msakes the same points as the article on copyright-as-monopoly, in a slightly more rigourous fashion.

jsm

I'm pretty sure the 386 (i386) didn't *HAVE* the SX/DX markings until much later in the production run (say, around the time that 486's got them).

Wrong. Just check the CPU Info Center listings. The 386 SX was introduced in 1988, while the 486 didn't show up until three years later in 1991.

Java interface (last time I checked) and I think the source is downloadable.

Probably not what you want, but cool none the less.

willis.

Contributions to non-commericial radio stations during pledge drives may be a good model here -- a percentage of consumers will pay for something they can get free, because they realize that if they don't pay, it may go away. Our local station KALX just had a successful fundraiser, and their audience is tough with a dollar -- college kids at a state school!

matthew

you should check out some of the stuff that has been done in my research group...
http://www.CS.Berkeley.EDU/~debevec/

matthew

you should check out some of the stuff that has been done in my research group...
http://www.CS.Berkeley.EDU/~debevec/

matthew

i think they might have derived it from cinema...

normally i wouldnt pick on a spelling error but when you are citing a source...i mean come on...

matthew

In fact current radial velocity surveys could detect Jupiter mass planets out to several AU (AU=distance fom Earth to Sun, Jupiter at 12AU, this planet orbits at 0.045 AU) . In fact some have been detected as far as 3 AU from their star (see Marcy & Butler's list

Forgive me if I'm missing the point, but why include an artist's rendition of the planet/star system on a page that otherwise contains scientific information? You can disclaim 'til you're blue in the face, yet someone is going to surf on over there and think, "man, those scientists sure can take clear pictures of faraway stuff these days!"

Seems to me that when you expect the unwashed masses to visit your site, you should consider that many folks really don't have a good grasp on the state of the technology. Monitoring the brightness of a star and noticing a 1.7% dip is a lot different from peering through an eyepiece and looking at Saturn's rings. I think in this case, the picture only obfuscates the situation.

But maybe I'm nitpicking...

• New this fall is Sun's MAJC
• Patriot shBoom (a 1996 relabelling of Chuck Moore's 32 bit FORTH chip)
• IBM's Java Chip - 1997 - apparently some extra logic hung off a PPC logic set
• Sun Scrapped their initial Java Chip
• UC Berkeley students designed one for a CS course
• Rockwell had one...

None of these have really gone anywhere in terms of influencing Java deployment.

The only way they would have been important is if:

• Network Computers had taken off, but they didn't.
• Java was getting deployed heavily in embedded systems. That factor is not evident.

The list only counts those systems where linpack has been run. I imagine that there are several beowulf (and other self-built)systems that are actually achieving more computational throughput, but aren't going to be noticed. Also, I'm sure the government doesn't release everything it has working on satellite images and what not. Overall, I'd imagine that a large subset of the people who are actually using huge machines for real work (rather than academic research) wouldn't take the time away from their work to even run linpack on their system.

As one example of such a computer, Professor John Koza has a 1000 node (Pentium II 350Mhz) beowulf machine for his Genetic Programming Inc. ( GPI's web site ) research group. He's running genetic programming applied to difficult problems on the machine (such as automatic analog circuit design), and is getting a nearly linear speedup because of the embarrasingly parallel nature of GP.

Cheers,

David Andre
my web site

disclaimer: I worked with Professor Koza for several years and helped him build some of his previous machines.

Isnt there something else out there that we all could be devoting our CPU time to?

Sure there is. Devote your idle cycles to SETI@Home (Search for Extraterrestrial Intelligence).

It has been talked about numerous times in the past on /.

Personally, I do not belive that searching outer space is more productive than making it known to the powers that be that the current encryption algorithms are inadequate and should be replaced by something stronger -- like rc5.

-d9

*sigh* Sadly, you perpetuated the invisibility of AMD. The AMD performs faster than the Pentium III in almost all tasks. You could've made your point even better that way.

Also, in the rather silly arena of benchmarking based on SETI@Home results, the alpha is the clear winner. There are no CPUs that come even close to the two alpha scores of 1:23 per data set, and 0:59 per data set.

Of course, I would MUCH rather run Linux on an Alpha, despite the fact that Tru64 has some interesting features (like a journaling FS, and an amazing level of parameter tunability (how relevant when you have the source?)) that Linux doesn't.

Just add the transistors and the dream of powerful (like ~286/386 powered, or at least dragonball(palm v)) smart dust will be a reality. (or smart cereal, just think, your daily internal diagnostic exam could happen over breakfast)

- Sam

Bruce's main site.
Information on Skipjack
Information on impossible-differential cryptanalysis
Information on attacks unknown to the NSA
About the Windows NSAKEY flap
Probable NSA backdoors
Information on the Blowfish algo
Information on the Twofish algo
Speed comparison of known algos
Speed comparison of the AES candidates
Summary of attacks on various algos
Breaking crypto isn't the best way to beat security. Article 1 Article 2
Information on the Solitare algo
Information on the Yarrow algo
Importance of peer-reviewed crypto
Comments on propriatary encryption
Dismissal of cracking contests
You say you can't break it; well, who the hell are you?"
Twofish team's published papers
David Wagner's published papers
So you wanna become a cryptographer?
Information on side-channel attacks
Information on power-analysis attacks
More information on side-channel attacks
Article on Quantum computing
The problems with the public-key infrastructure
The problem with longer keys
l0phtcrack
Biometrics as keys?

Check out these, which pre-dates you by over a month.

ttyl
Farrell

http://http.cs.berkeley.edu/~randy/ CLD/CLD.html

A look at the CPU info center charts here show that the Alpha is still almost twice as fast as the Pentium III and Athlon at SPEC INT. Benchmarks mean very little but its such a shame this wonderful processor isn't getting the headlines, machine architecture and recognition it deserves.

Okay, let's have a look at what a P3 overclocked to 1100 MHz would score in SPECint95 if it is as linear as it is from 450 to 600 MHz.

These are the highest scores these processors have gotten so far, according to the General Processor Information page at Berkeley, along with what they should've gotten if the score was linear with clock speed (l450 means linear to the CPU with 450 MHz clock speed):


MHz int95 l450 l500 l550 l600
450 18.7 18.7 18.5 18.2 18.0
500 20.6 20.8 20.6 20.2 20.0
550 22.2 22.9 22.7 22.2 22.0
600 24.0 24.9 24.7 24.2 24.0


As you can see, the 600 MHz version performs less than expected from the 450 MHz version by a margin of 3.7% (projected performance improvement if Deschutes scaled linearly from 450 MHz to 600 MHz). Similar margins are 0.9% for 500 MHz and 3.1% for 550 MHz.


Let's be nice and assume that the reduction won't be more than 4% for a clock speed of 1100 MHz compared to 600 MHz.

That would give us a SPECint95 performance of 42.2, slightly less than a 1100 MHz Willamette would do according to The Register, which is 43.

Without the 4% reduction, Deschutes might do 44, but I sincerely doubt that the architecture scales linearly when it didn't before, and a 2% reduction will bring you pretty close to the projected performance of Willamette.

I suspect, howere, that the reduction for Deschutes may be closer to 5%, and possibly greater, though I have no way of proving that now, of course. :)


As a side note, the projected linear performance (including a 4% reduction) of the 1000 MHz Athlon based on the 700 MHz Athlon would be 43.5, or 44.4 at 2%, or 45.3 at 0%. A 1100 MHz Athlon based on the 600 MHz Athlon would be 48.4% at 4%, 49.4 at 2% and 50.4 at 0%.

A 667 MHz Alpha 21264 processor (it's a pretty old thing now) performs at 44 already, BTW, which really shows how far behind both AMD and Intel still are in the high performance market (though not the bang for bucks market).

It looks like they have finally added the option to set up a TCP/IP connection using the standard cradle. Previously PalmOS would have only let you use a modem to connect to network; now IR and direct serial are possible..We're getting there, just wait until there is a nice Bluetooth add-on for Palm, or better, the Visor.

I bet a lot of Slashdot users(who were too lazy to set up a PPP server on their home Linux boxes just to connect their Palms to the Internet) will be installing this upgrade and fulfilling their filthiest, hidden fantasies of using PalmVNC to use their Linux boxes or surfing the Web on the Palm from an ADSL connection..I, for one, will be trying them...

• SETI@home : a neat, geek-friendly, worthy cause, but hardly practical, and they have plenty of CPU - they don't need mine. This project is currently running, and while they had growing pains a while ago, they have been solved. One problem remains (as far as I know); they client still slows to 1/3 speed if you have the visuals turned on.
• distributed.net encryption cracks : for a long time, the most practical distributed computing projects around, and certainly the most advanced, but I think that they (and others) have clearly proven the point re: encryption (i.e. that we need access to stronger encryption), and while we don't have perfect regulations, one more crack ain't gonna do it. These are also running, and have been for years now. They had some problems with stats a while ago, but they haven't had a problem of not sending out new work in a long time (if ever).
• d.net's OGR project : good scientific research, certainly, but really, just giving some grad student thesis fodder. You're not gonna solve world hunger or anything. Also, it isn't running yet.
• Casino-21 Project : wow, some practical application. Also very different from other projects, because it is devoted not to "solving a riddle", but to predicting a complex system. Of course, it's not running yet, either.

-Yoshi

The smart dust page had a link to a page with some really snazzy micro aircraft. Can you imagine using dust sensors/controllers to build a tiny self-guiding spy plane that can provide 20 minutes of flight time?

--

• Java for PalmOS
• More Java
• SSH and other crypto stuff for Palm Pilot
• There are free development tools for Linux
• One alternative to Grafitti (There are many)
• Tetris clone

- Sam

I think it's important to realize what Tim's point is here: that Linux versus Windows versus anybody else isn't the point here. It's all about building an open platform upon which to deploy the next generation of Internet applications.

In ten years, desktop operating systems will be an endangered species. We won't care about GNOME versus KDE, or even Linux versus Windows. We'll be far too busy connecting to the universal information applications with wireless appliances, handhelds, and other "pervasive" forms of computing. Everybody's going to have a different "net widget" in their hands or on their desks. We're already seeing this today -- can't everyone use the Web regardless of whether they use Linux, Windows, or an iMac?

The question is this: In such a heterogeneous computing landscape, how can we deploy services which are universally accessible?

Tim's point is a very good one: That we sure can't get there if everything's closed and proprietary. We need an open platform on which to base the next generation of networked information access. Windows ain't gonna do it. Linux (alone) ain't gonna do it, either. So it's important to chart out the space of platforms which will support the new applications. And Open Source is a fantastic way to ensure that the platform remains open itself.

For those who don't believe it, go read up on some technologies like Jini, Ninja, and e-Speak. The wave is coming.

Matt Welsh

Bandwidth isn't great, at 9600 or 14.4k depending on your carrier, but it's more than functional.

Once you're online, you can use ssh or vnc to work on a box. I've had only minor difficulty ssh'ing into a unix box and reading my mail with mutt. I still haven't really seen the usefulness of vnc in a 160x160 window, but it exists and it works.

Useful links:
Wireless Connections for Nokia 51x0/61x0
Top Gun ssh for PalmOS
VNC
And of course, ssh, because only morons use telnetd

...or start here at his web site

Anaconda kicks much tail.

Does anyone else notice a pattern here?

• Anaconda
• Asp and Asp 2
• Boa
• Bushmaster
• Caiman
• Cobra (Mk I and Mk III)
• Copperhead
• Coriolis
• Gecko
• Krait
• Mamba
• Python
• Sidewinder
• Viper 1 and 2
• Worm 1 and 2

Nominating companies or applications to match Hognose, Dodo, and Thargoid is left as an exercise to the reader.

How about, say, Sather? A clean, fast, free (libre and gratis), object-oriented, garbage-collected language, which (and this is the beauty) compiles into portable C, so you can bootstrap Perl without first bootstrapping Sather. You only need Sather if you want to tweak Perl.

If that's too much effort, then you've basically already made the decision that only C or C++ will do since that's the compiler that machines will already have, so there's not much point in talking about other languages you might have used were it not for that condition. But I think it would be a mistake for free software projects to mandate that only these languages will do - it's not a restriction that proprietary, binary-only releases labour under.
--

Star Trek has done so much to encourage the imagination of scientists, but it also destroys the scientific literacy of non-scientists. Dark matter is definitely one of the casualties.

"Dark Matter" is a loose term referring to mass in the universe that should exist but has not been accounted for yet. The last time I studied astronomy, two of the biggest theories were WIMPs (unknown subatomic particles) and MACHOs (planet-sized junk out in the void). An excellent essay on the subject is available at Berkeley.

Any astrophysicist who neglected the mass of asteroids, Oort, etc, would be a public laughingstock and unable to show their face in public for a long time. BTW, at reasonably large distances, the gravitation for any collection of objects (such as the asteroid belt, or the entire solar system for that matter) is identical to the sum of their masses located at their center of mass. The calculations are high school AP physics/calc, no big deal.

For those who want some background on the important issues, I highly recommend Gregory Pfister's book In Search of Clusters . Clustering is a lot harder than most people realize, and people should not ignore the work that's been done before in this area. The important question for LCC is what is fundamentally new in their design. I doubt that the lack of kernel locks is really it.

The thing that remains to be seen is what set of applications they target, and what tradeoffs they make to support those applications. The fundamental issues in clustering have been addressed by a large number of research projects and products, and I'd like to know what's new about LCC.

That being said, I'm happy that some smart people are going after this problem!

However. It is not all fine and dandy.

The "configuration problem" has not one issue, but several:

• The proliferation of "little languages" as formats.

  XML represents Yet Another Format; it is of value if it pushes out some of the existing formats. If it merely augments the population with another, there is no win here.

  Result: Ambiguous. XML might provide value.

• The Serialization/Locking Problem.

  The issue here is that you need to ensure that the configuration is written out correctly.

  This may require writing out the new config to a new file, validating that it is readable and correct. (Oops, made a mistake updating /etc/inet.d. Now the system won't reboot...)

  There is merit to having a "database form" ala IronDoc where the physical representation is a database system, which provides a somewhat different persistence model than the typical text file.

  (Before people start proposing that I be shot, I tend to favor the notion of, if using a binary format, synchronizing it carefully with a text format.)

  The merit of a "databased" scheme, which should provide a separate database for each facility, is that updates can be implemented "instantly" without needing to rewrite a whole file, and without a need to parse the file. Note that even in a situation where XML is used as an interchange format, there is still merit to storing the "tree" in database form. David McCusker, author of IronDoc and architect of the (regrettably failed) "Bento" database system that was part of OpenDoc, suggests this very use for IronDoc.

  For those that feel religious about using text files, a system like libPropList still has merit over the "let's do something with XML" idea since it has, already debugged, the locking, parsing, and config-file-rewriting code that let's use XML, it's k001 doesn't inherently provide.

  In short, deciding to use XML merely establishes a format; it does not resolve that:

  • Updates are managed well
  • The output from a particular program that manipulates a config file actually produces valid XML
• Federating Configuration.

  Michael Stonebraker (of fame with such developments as Ingres and Postgres) has most recently founded a company called Cohera based on the Mariposa Distributed Database Management System. This tool allows many databases to work together to process queries.

  The "obvious" implication of this with this thread is that a valuable thing to be able to do is to join together many "databases" that are configuration repositories, and provide a central way of getting at the data.

  The critical thing that is necessary is for configuration repositories to provide some sort of "metadata" so that they, in effect, publicize their existence.

  A "federation" tool like Linuxconf, Ganymede, or such, can then be used to join together the metadata and manage it all together.

  Unlike the situation with the infamous Windows Registry, this doesn't force all the configuration data into one fragile binary DB; it allows the data to stay wherever it was concluded that it should reside.

  The critical factor here is not that data files all have a common format; it is that there be some way of translating their data into a common format.

  XML has a lot to offer here in terms of providing a central "presentation" format. It could offer more if tools were available to make this a two-way street, where updates done to the central XML could be pushed back to the individual configuration data repositories.

  However. If someone writes some integration code to (say) connect Linuxconf to libPropList so that it could directly manipulate libPropList files, that would also represent a movement in the right direction.

Conclusion: XML may have value to offer in confederating config information.

That has to come along with a whole lot of coding effort to build robust configuration data repositories that may or may not use XML.

[...] "patent flooding," the practice of filing large numbers of patents with narrow claims and utility models to "surround" a rival's basic patent on a core technology. ( BRIE Working Paper 89)

In Japan, filing would expose them to patent piracy of their technology through "patent flooding," i.e., inundating the Japanese Patent Office with hundreds of unworthy patent applications using minuscule modifications of the American invention, followed by bullying tactics to get cross-licensing agreements. ( The Patent Fight Gets Ugly)

Just Another Patent System Stupidity, it seems.
--

xFS has a number of other advantages for locally distributed filesystems. In particular, it eliminates the need for a centralized server, which would otherwise limit performance scalability and reliability.

Of course, none of this matters much for the original poster. It sounds like he was *not* on a fast network with many other machines.

xFS is here (with source). An interesting project is Frangipa ni, but it is not available to the unwashed Linux masses. :-/

I'm crying foul on the moderations I've been given on this story. It's true that the government finds ways to mess things up, e.g. crypto laws, software patents, etc.

M2 has seemed to make moderations a bit more accurate, but I don't see it working out for me here. Unless somebody actually goes to the page and sees what I'm talking about -- "Alpha" in ten hours, and the EV series are cranking out units faster than LensCrafters...

I didn't make up those "CPU's". They are actually listed on the page! Please follow the link and see for yourself.

I'm crying foul on the moderations I've been given on this story. It's true that the government finds ways to mess things up, e.g. crypto laws, software patents, etc.

M2 has seemed to make moderations a bit more accurate, but I don't see it working out for me here. Unless somebody actually goes to the page and sees what I'm talking about -- "Alpha" in ten hours, and the EV series are cranking out units faster than LensCrafters...

I didn't make up those "CPU's". They are actually listed on the page! Please follow the link and see for yourself.

visit the SETI@home CPU type statistics page. -- Alpha EV6 and EV67's are rockin' ass^H^H^H, if not as much as the "Intel Puntium" or "PowderPC" chips...
--

General Processor Info.

Compare the SPECfp scores of high-end Intel and Alpha offerings. Take a look at a 600MHz PIII Xeon and a 667MHz Alpha 21264.

The reason to choose Alpha should be obvious.

And where are the breakthru languages?

You just aren't looking.

• Cecil

• Dylan

• Haskell

• Objective CAML

• Sather

• Self