Slashdot Mirror

RDRAM has significant advantages to SDRAM. In overall latency and performance, it is true that RDRAM is only about as good as SDRAM. And true, RDRAM is more expensive now because of those outrageous royalties paid to Rambus, and the low volume.

But in overall production costs, ignoring the price premiums tacked on the price by companies, RDRAM is more cost-effective. That is, RDRAM is actually cheaper to produce.This alone makes it attractive in the long run.

There are several good papers about comparisons of modern DRAM architectures, which highlight this point. The more technically oriented among you might want to take a look at the following:

A Performance Comparison of Contemporary DRAM Architectures

Here is a live cam from Miami Beach, several North Florida cams and a link to a whole page of weather cams for the US.

Don't kill them all at once! Spread it around.

Mean hop distance is relatively easy to measure, as IP addresses are nicely arranged. Measuring clicks takes a bit more work, I feel. A somewhat cryptic document by another guy at caida.org puts the average hop at 14-15. A great link with more info is the
Internet Distance Maps Project.

For more pretty pictures, check out the Internet Mapping Project.

Mean hop distance is relatively easy to measure, as IP addresses are nicely arranged. Measuring clicks takes a bit more work, I feel. A somewhat cryptic document by another guy at caida.org puts the average hop at 14-15. A great link with more info is the
Internet Distance Maps Project.

For more pretty pictures, check out the Internet Mapping Project.

A scan of the mirrors in the com/net/edu/gov/ca domains revealed that a handful have the Lorax release. Here's the list I compiled. Others might also have it, but are overloaded right now, so I can't check.

ftp://ftp.aklug.org/pub/redhat/mirror/ lorax/
ftp://cwrulug.cwru.edu/pub/ftp.red hat.com/lorax/
ftp://ftp.eecs.umic h.edu/pub/linux/redhat/ftp.redhat.com/lorax/
ftp://metalab.unc.edu/p ub/Linux/distributions/redhat/lorax/
ftp://csociety-ftp.ecn.purdue.e du/pub/redhat/lorax/
ftp://ftp.snoopy.net/pub/mirrors/red hat/lorax/

Obviously algorithms are subject to patents.

This was not obvious, as a previous poster noted, until court decisions in the past few decades ruled that it was.

In any case, I am perfectly aware that patents have been awarded on purely mathematical processes. My assertion was that this should never have been possible, and constitutes a betrayal of the original intent (as well as court precedent) regarding patents. Which would have been clear had you thought for half a second before replying.

It's true that my opinion doesn't matter, mostly because I don't have a lot of money with which to influence the government. But I'm still entitled to my opinion.

It's not the math - it's not the process that's patented - it's the utility arising from the math and process that's patented.

This is one of the silliest things I have ever read. "Utility" is a vague, abstract economic quantity and cannot be patented. Specific inventions are patented. Utility is what people gain from these inventions, and the idea is that some of this utility should funnel back, in the from of money, to those inventors. But it is not utility that is patented. Lots of people generate nonpatentable utility all day long by, for example, cutting up meat.

BTW: I was mistaken about the processes thing. This link explains the different kinds of patents. Processes can be patented. Oops.

However, the original intention was to allow inventors to patent specifically mechanical (i.e., physical) processes. The US patent office site writes:

Interpretations of the statute by the courts have defined the limits of the field of subject matter which can be patented, thus it has been held that the laws of nature, physical phenomena and abstract ideas are not patentable subject matter.

-- http://www.uspto.gov/web/ offices/pac/doc/general/what.htm

Many people, myself included, assert that an algorithm, as an abstract mathematical process, is much more like an idea than a machine or a technique for manufacturing doughnuts. A closer software analogue of a patentable "mechanical process" is an implementation of an algorithm in software. That is, RSA should have been awarded a patent, not on an algorithm for public key encryption, but on the piece of software that they wrote.

The patenting of algorithms veers very close to the patenting of ideas or laws of nature. The quicksort algorithm (to take a bland example) is no less a pure idea than Pythagoras's theorem or Newton's axioms of motion. That this is not clear to you and every programmer in the nation is a testament to the sorry state of CS education in America.

~k.lee

To everyone who enjoyed it--thanks for the appreciation. To everyone who did not--well, you can't please everybody.

To everyone who enjoyed it--thanks for the appreciation. To everyone who did not--well, you can't please everybody.

Last I heard, John Koza (at Stanford) was in the process of building a 1,000-Pentium Beowulf-Style Cluster Computer for Genetic Programming.

Koza has been doing very cool things with GP for a long time, ever since he was at Michigan working with John Holland.

The 'small efficient government' that you fantasize of only ruled 13 colonies and probably less than 100,000 people (anyone know an actual number here?).

Please stop spreading this myth.

Plutonium is a mildly radioactive metal that is also chemically toxic. A short article can be found here. There are many chemicals that are far more toxic than plutonium.

Anti-nuclear activists would get more respect if they made scientifically sound arguments. Most of the anti-Cassini material appears to be written by people who flunked high school physics and chemistry.

It seems to me that you are not helping make slashdot any better with that post. After reading it I can pretty much agree with you. That last line especially convinces me. Yes, that parody page didn't live up to my expectations, but if you're not willing to post at least constructive criticism, please go start your own "news for nerds" site.

As far as slashdot being dead, I have to contend that you're just plain wrong.

About midnight eastern time last night, I learned that the ATI Rage Pro LT chipset, which comes standard in the laptop I recieve from my college, is not fully supported by XFree86. I had two options, spend $150 on a commercial software from Xi Graphics, or live with console only.

After reading the devasting information, I followed a link from this page to a thread on Ask Slashdot. The first post, from theMissingLink, had a link to this page, where I found multiple ways to get XFree86 up and running on my laptop.

Those who only complain without offering solutions may be trying to kill it, but no, slashdot is not dead. It won't be dead any time soon.

"Capital letters are a good thing." -- anonymous

This article is the major reference for the RFC and is written by the same guy as the RFC. It also has a lot of tough criticism of other systems, including Solaris and several BSD-dervived stacks. Windows gets a fairly clean bill, and they are very critical of Trumpet Winsock.

I tried to check Dawson's paper, but his server seems to be down.

For the other problems in the RFC they were either clearly marked as BSD problems, or I couldn't follow up the references. (Either because there weren't any, or because they were paper and not online.) The RFC doesn't name names, so it's impossible to say which of the others Linux has been guilty of, or is guilty of.

I think Holger Kruse should tell us what his 4 workarounds are, that he has been forced to put in to work around Linux. Linux has plenty of stuff put in to work around other people's mistakes of course. I guess having to put that sort of thing in your code can make you arrogant.

You don't need power, just high voltage -- which you can get from a static generator like a van de Graaf machine.

Well, it takes power to establish the high voltage in the first place. Actually the power required goes like the square of the voltage.

Also, if you are using the HV to accelerate something, you will have to supply power, because the battery or whatever it is that's creating the electric field is doing work on the particles it accelerates, and that energy has to come from somewhere. Otherwise, if what you say is true, your powerless accelerator would make a nice engine for a perpetual motion machine...

BTW, I work in the physics dept. at the Univ. of Michigan, and Fred Niell, one of the students who built the reactor, is coming to graduate school here in the fall. I am gonna treat that guy with respect!

(I wanted someone to comment on KOffice before I said anything)

On the Gnome side of things, progress is being made. Bonobo (the CORBA-ized component model) is nearing an initial (developer) release.

A Guppi Bonobo component is being added to Gnumeric (which is looking nice these days) to enable charts. This might also make it into Genius.

Go is being Bonobo-ized also, and (I hear) is pretty usable.

And work is being done on a nice mailer too.

Sure, 2.2.2 was listed as "stable", but common sense dictates that a shake-down period is likely to take place before it is really stable. Some bugs are subtle enough that it takes a lot of installations to bring them to light. However, many sites won't try to seriously use the new kernel versions until they are listed as "stable".

It's a chicken-and-egg problem; the kernel has to be listed as "stable" before many sites will risk it for heavy production use, and the more subtle bugs will evade detection until placed in heavy production use. Therefore, at some point, they just have to decide it's "good enough" and declare it a "stable" release, and fix whatever comes up.

Given that we don't even have a 2.3.x series yet, it should be fairly obvious that the early 2.2.x "stable" versions should still be taken with a grain of salt, for now. Yes, they're pretty stable and improving all the time. However, to expect them to be just as stable as 2.0.36, which has been in maintenance mode for years, is a bit unrealistic.

After 2.3.x kernels are rolling, and 2.2.x updates have stopped coming out for a few months, then the truly cautious sites will start to rely on 2.2.x kernels for mission-critical applications. The paranoid will stick with stable 2.0.x kernels and let the majority volunteer themselves as guinea pigs to debug the early 2.2.x kernels. (The less paranoid who can afford a small amount of instability are crucial to ironing out the little wrinkles to make a very stable kernel, as people have come to expect of Linux.)

That said, I think some mistakes were made in the 2.1.x -> 2.2.x transition. For example, major changes were introduced in the 2.2.0 "pre" series, which ought to have been strictly limited to fixing bugs. The changes to the VM system were a particular case in point here; a major overhaul of the VM system was applied in the 2.2.0 "pre" series, when it really belonged in an experimental kernel series.

The new VM code is significantly improved in general, but the bforget() bug slipped into the final 2.2.0 release and remained for several more releases until it was finally isolated and fixed. From the description of the bug and the comments in the Usenet News article attributed to Mindcraft, it seems quite clear that the Mindcraft people unknowingly crippled their Linux machine by using the 2.2.2 kernel with a serious performance bug that was yet undiscovered. No wonder the NT machine managed to win for once!

[...]
We have Redhat 5.2 installed and compiled an SMP version of the 2.2.2 Linux kernel.
[...]
The problem: the server performs well, delivering in excess of 1300 HTTP GET requests per second. But then performance drops WAAAY off, like down to 70 connections per second. We're not swapping, the network isn't saturated (4 x 100Mbit nets), disks are hardly used, but the system is just crawling. If it were saturated then performance should level off, not drop like this. Neither vmstat nor top show anything unusual. No error messages in the web server. Its puzzling.

As pointed out by an astute poster elsewhere under this article, Linux 2.2.2 (which Mindcraft used) had a kernel bug in the buffer cache that would cause a significant loss of performance just as described above. Using a 2.2.x kernel was a little premature in this case, it seems. (Why didn't they also test 2.0.36?)

No doubt a repeat test with 2.2.5 and a proper Samba configuration would give more accurate results...

According to reliable Public Interest Research Groups, this scientist was locked out of his lab for months after he went public with this information. Apparently the British government was very embarassed at him biting the hand that feeds him.This I hear from a person who works at Consumer's Union (the parent company of Consumer's reports) who came to speak at my campus. There's an interesting paper by the guy, Mike Hansen, here, at http://www.consunion.org/food/whywenny798.htm.

Try this.
And be sure to check the "Other FINE Works by Simon..."-Link!

He was once involved with one Doctress Neutopia, and was a candidate for the position of Gaia Messiah. For more information, see this page.

Posted by hackerzarus:

ftp://phyppro1.phy.bnl. gov/pub/mirror/redhat-main/starbuck/
ftp://ftp.eecs.umich.edu /pub/linux/redhat/redhat/starbuck/
ftp://ftp.wtfo.com/pub /linux/redhat/ftp.redhat.com/starbuck/
and of course, ftp://ftp.redhat.com/pub/starbuck/

Posted by hackerzarus:

ftp://phyppro1.phy.bnl. gov/pub/mirror/redhat-main/starbuck/
ftp://ftp.eecs.umich.edu /pub/linux/redhat/redhat/starbuck/
ftp://ftp.wtfo.com/pub /linux/redhat/ftp.redhat.com/starbuck/
and of course, ftp://ftp.redhat.com/pub/starbuck/

-jeremie

-jeremie

-jeremie

There IS a web based version. It is at http://neylonpc.engin.umich.edu/mst3k/mistings.sht ml

No, I think you're splitting hairs on this one.

"You have got mail in your mailbox and you need to check it." is perfectly OK.
"You have mail" would be perfectly fine, too.

For more on "have" and "got" and American "gotten", see John Lawler