What do you think it is? Beautiful artwork? Lovely poetry? pics of the goatse guy?
All of the above. I mean that literally. (Well, OK, "Beautiful" and "Lovely" are subjective.)
Re:Okay, hate to be the first "help me post"...
on
Freenet 0.5 Released
·
· Score: 3, Informative
The docs refer to fcp.allowedHosts, fproxy.allowedHosts, and fproxy.bindAddress.
The docs are out of date. The "fproxy" service was renamed to "mainport" about a month ago.
mainport.port=8888 mainport.bindAddress=* main port.allowedHosts=127.0.0.1,209.142.155.49,192.168.2.1,192.168.2.2,192.168.2.4,192.168.2.20 mai nport.params.servlet.1.params.tempDir=/home/fre enet/tmp/
Also note that "nodeinfo" is gone. It got merged with fproxy into mainport. For more details, please read The Freenet Wiki FAQ.
I'm having a very hard time imagining any nontrivial legitimate use for this technology.
Free hosting for your daily web comic. You could even have normal World Wide Web URLs embedded in the Freenet page, pointing back to your web-store for merchandise, etc.
Free hosting for your own music, that you composed and recorded yourself. See above for merchandising. ("If you like these lossily-compressed songs and want to buy a better-sounding copy on CD, click here....")
Free hosting for a personal web log.
I hope you see the pattern here. In addition to this pattern, we have:
Uncensorable criticism of your employer, the Church of Scientology, the government of your country, etc.
Uncensorable expression of unpopular opinions (hate speech, underage erotica, racism, sexism, negative religious speech of all flavors). Publishing these forms of expression on the traditional Web could lead to unpleasant repercussions.
That's just "shooting from the hip". I'm sure someone with different needs and perspectives can come up with even more legitimate uses for this application. Use your imagination.
The Freenet gateway page (or "web interface") has three Freenet URLs: The Freedom Engine, and a couple others. (Currently "Freenet Forever" and "Cruft". I'm glad Cruft made it, finally -- the author deserves it.)
The Freedom Engine (TFE) is published by (or claims to be published by) the same person who did "Content of Evil" in the older days. It's essentially Freenet's version of Yahoo! (the old one, before they added a bunch of services) -- a portal to other sites within Freenet. Go there. Be amazed by the variety, both good and bad.
Porn (Was Re:A quick description)
on
Freenet 0.5 Released
·
· Score: 3, Informative
It is NOT designed for swapping MP3s or porn for those who have got the wrong idea,
Before anyone gets misled, let me state for the record that Freenet does have porn and MP3s in it. In fact, it's quite a good platform for publishing collections of pornographic images. (It's not quite as good for MP3s and Oggs because they're much larger files. But it has been successfully used for that purpose. It may even have been used successfully for the next order of magnitude (ISO images, movies), but I can't confirm or deny that.)
So if you're reading this wondering if Freenet is going to have any pr0n -- yes, it does. But you may be somewhat disappointed if you're looking for huge MP3 collections.
Another problem was that because nothing can ever be deleted from the FreeNet once published, it was hard to do news/blog style sites: at the time they used JavaScript date based redirects, I think that shows how long ago I used it.
Wow, you're right -- that does show how long ago you last tried it!;-)
Suffice to say, the Javascript method is no longer used. In fact, fproxy (err, I think they still call it fproxy even though it's called "mainport" in the config file now) will object vehemently if it encounters any Javascript in a Freenet document.
There are several popular sites (and some less popular ones, like mine) that do a quasi-daily blog style. It's been working quite well for a couple weeks now (ever since Matthew's really excellent debugging job got into high gear). If you saw what Freenet 0.3 and earlier were like, you're going to be stunned when you try 0.5. Seriously.
(Those who missed the early Freenet days may not be stunned. You don't have the point of reference that IamTheRealMike has, and you may be spoiled by services that are much faster than Freenet -- of course, none of those services has Freenet's anonymity.)
Either say what the problem is, or keep reading. C'mon, you didn't even say what operating system you're running! (Must be a Windows user.)
In general, the procedure is as follows:
0) Download Java. 1) Download Freenet software. 2) Configure it (generate freenet.ini or freenet.conf). 3) Start the node. 4) Wait for it to initialize (usually takes less than a minute). 5) Go to http://127.0.0.1:8888/.
Now, you can go yell at the Freenet developers if you wish, but all of the documentation linked to from freenetproject.org is badly out of date and incomplete. There is a much better Freenet user FAQ at The Freenet Wiki. It's not perfect, either, but it's much closer.
If for instance, my node is used for storing some part of some kiddy pr0n and the authorities decide for whatever reason to inspect my PCs, how am I to prove that I didn't source the file myself.
Your question should be modded up. It's one of the most important ones.
The idea behind Freenet's anonymity is plausible deniability. But before I can go into what that means, I need to describe how Freenet works in a little more detail.
There are two different types of Freenet nodes: permanent and transient. If you run a permanent node, it means that you're a full participant in the Freenet network. Your node acts as storage and as a router for requests and inserts. Data moves through Freenet in the form of keys, which are basically the same as files (or in some cases, segments of files) but with cryptic names. Your node caches all the keys that it sees (with least recently used keys being deleted when the node's data store is full, with "full" being defined by the amount of space you choose to let it consume).
Let's say Alice inserts two files into Freenet: the text of Mein Kampf and a picture of Adolf Hitler. She does this using her Freenet node, specifying a hops to live value on the insert. This HTL value is usually around 10 to 15, and is the number of other Freenet nodes that must be talked to. Each node that processes Alice's request decreases the HTL and passes it on to another node. When the last node to get the request sees that HTL is 1, and it still hasn't found Alice's file (because she's the first person to insert it), it returns Data Not Found to the previous node, which passes it to the previous node, etc., all the way back to Alice.
Alice's node gets the "failure" message back, and then sends actual copies of the data files back down the chain. Thus, the files are inserted into Freenet.
Now, this is where the plausible deniability comes in: the data coming from Alice's node looks just like the data coming from all the other nodes she talked to during the request/insert process. There's no way to distinguish between the node that originated the request and a node that's simply passing the request along on someone else's behalf. So if someone were to sniff the traffic coming from Alice's machine and decrypt it and discover that her machine was inserting Mein Kampf, then she could claim that she had no knowledge of it; that her machine was simply routing an insert by someone else.
The same goes for requests. Suppose Bob stumbles upon a key which claims to be an ISO image of Windows 2000 Professional and requests a copy of it. His node generates a request with a certain HTL (generally 15 or more for requests), and it's passed along to other nodes until one of them either finds the key, or runs out of hops. The final result (either an error condition or the key he requested) is sent back to Bob's node.
But Bob could claim that he wasn't the person who originally requested that key -- he could say that his node was simply routing someone else's request, and he had no knowledge of it.
The same thing goes for files inside the local node's data store. Just because your node is storing a copy of a nude photo of Ronald Reagan doesn't necessarily mean that you either inserted or requested that file. Your node might simply have acted as a router for someone else's activity, and cached a copy of the key.
Now, all of this protection goes straight out the window if you run a transient node. Transient nodes don't ever act as routers for other nodes -- they're pure leeches. Anything on a transient node is there because you, the node operator, requested or inserted it there. You have no plausible deniability any more.
This explanation is a bit vague, and for that I apologize. The actual routing algorithms and encryption ciphers are a bit beyond my understanding at this time. If you have more detailed questions about how Freenet works, please check the Freenet mailing lists.
Re:Which Network gear manufacturer?
on
Ask Donald Becker
·
· Score: 2
The problem is that not all "Tulip" chipsets are created equal. The tulip.c driver covers a lot of different hardware from a lot of different vendors.
If your "Tulip" card is actually a Linksys 10/100 , then it's not actually a DEC Tulip chipset at all. Mine is reported as an ADMtek Centaur-P rev 17 in dmesg (and a Linksys Network Everywhere Fast Ethernet 10/100 model NC100 in lspci). And yes, I had trouble with this card, although it seems to be much better in Linux 2.2.21 than in previous Linux kernels. (I haven't tried 2.2.22 on that machine yet.) (Linux 2.4? Puh-lease! Maybe when it's stable.)
I have worked with Linux servers since 1998 and I have never seen one crash.
I have.
I started with Linux in May 1993 running kernel 0.99 pl 14. That one had a bug in the keyboard driver, which caused the system console to lock up if I typed too quickly. But that hardly counts, because the kernel hadn't hit 1.0 yet.
I just updated one of our production servers from 2.0.36 to 2.0.39 two weeks ago because I kept getting total system lockups accompanied by kernel error messages on the console and I was tired of hitting reset and watching it fsck while users kept asking why the database didn't work.
I had a boatload of problems with the tulip driver and Linux's NFS client code in late-series 2.2.x kernels (2.2.19 and 2.2.20). This appears to be mostly fixed in 2.2.21.
I won't even begin to describe all the horror stories I've heard about the 2.4.x kernel series; instead, I'll just tell you the one I've actually lived through. I have a machine which was until recently a server, but now I wanted to make it a desktop. It's an HP Pavilion that has an i810 integrated video thing in it (I can't call it a "video card"). In order to run X on this thing, with Linux, I needed kernel 2.4.x for agpgart support. Well, when I run X on this thing under 2.4.18, everything's fine -- except that the NFS client suddenly stops working. Any access to the NFS-mounted file system goes into kernel wait and is completely unkillable (even with -9). The system has to be rebooted -- but the reboot also hangs. Meaning I have to sit through a 45-minute-or-more fsck. (No, I am not exaggerating. One of the disks in this thing is either not properly recognized or is physically defective. If I attempt to turn on DMA mode, the system locks hard.) Anyway, my workaround for this is not to mount any NFS file systems on it -- it can serve as a dumb web browser and Freenet node using local storage only.
Ridiculous claim since Linux binaries are supported at the kernel level.
DISCLAIMER: My experience is with OpenBSD, not FreeBSD. (However, FreeBSD users have confirmed my findings in considerable detail.)
DISCLAIMER: I hate Java's bloated reeking guts. Java's only purpose in life is to run Freenet until someone rewrites the Freenet reference node into a portable language like C.
My experience with Java and Freenet on OpenBSD is that the Linux native JDK does not work. Freenet will appear to start up and run, but once you actually start using it, it fails miserably. Specifically, the Freenet node listens for connections on two or more TCP/IP sockets. Connections made to any port that Freenet is listening to will be silently dropped if no data are waiting on the socket (e.g., if you telnet localhost 8888 it will drop the connection after accepting it). However, if data are actually waiting in the buffer, the connection may work, at least sometimes (e.g., if you echo -e "GET / HTTP/1.0\n" | nc localhost 8888 it will work most of the time).
As you can imagine, this makes running the software a fool's mission. Things just break and there's no rhyme or reason to it, because there's at least one case where the behavior is nondeterministically broken. And that's just the case that I happened to discover -- who knows what else is lurking in those murky proprietary-Sun-code depths?
Fortunately, Kaffe 1.0.7 seems to work at least acceptably for running Freenet on OpenBSD. (Don't use Kaffe from the ports tree, which is 1.0.6. Kaffe 1.0.6 has serious bugs, at least one of which is in big number handling, which is essential to many of Freenet's encryption algorithms.) Kaffe 1.0.7 has some bugs of its own -- for example, it tended to crash and core dump on me, at least until I commented out one assertion that the Kaffe mailing list said was probably spurious. (And you don't want to see how big a Kaffe/Freenet core file is.)
"Sorry, we see you've broken the terms of our agreement, so we can no longer keep your credit card interest below our maximum rate."
You have this backwards. I think what you really meant to say was, "Sorry, we see you've revealed yourself to be a pathetic little dying bank grasping at pennies in an effort to stay solvent just a few more months, so we can no longer keep your credit card. Please give us all our money back, so we can put it in your competitor."
The ideal solution would be for the reviewers to not review them at all. See what that does to sales.
I can't speak for Pearl Jam, but in the case of Tori Amos, it won't do a damn thing. She's got a solid core of fans who will buy this album, unheard, unreviewed, period. I should know; I'm one of them.
An honest double-blind listening test is extremely difficult to arrange, and there is no evidence whatsoever on such on the site.
This is how the test was conducted.
The test required access to a Windows machine (probably Win95 and up, didn't try with Win3.1) with a sound card. Users were required to download the ABC/HR "practice" Zip file, which includes the ABC/HR program, the Ogg Vorbis 1.0 command-line encoder and decoder, a LAME command-line encoder/decoder (I forget which version), a FLAC command-line decoder program, and a.flac sample file (the instrumental introduction to The Eagles' "New Kid in Town").
After unzipping this, the user had to run a batch file (encdec_foobar.bat) which un-FLACced the sample file, then encoded it with Ogg Vorbis and LAME, then decoded both of the resulting files back to.wav.
Then the user executed the ABC/HR program, which is a Win32 GUI application. After loading the sample into the application (pull-down menu and file selector dialog), the interface became a row of double-slider pairs. Below each slider was a "Play" button. Below each slider pair was a "Play Ref" button. Below that was a "Stop" button. There was a pair of sliders for each decoded sample -- so for the practice run, there were two pairs of sliders: one for file #1, and one for file #2. The user did not know which file was Ogg Vorbis, and which was LAME MP3.
The user then listened to the Reference file by clicking any of the "Play Ref" buttons. After hearing the Reference, the user could then click any of the normal "Play" buttons. The first task was to determine, for each pair of sliders, which one was the original and which one was the encoded file. Having determined that, the user used the slider (which went from 1.0 to 5.0 in increments of 0.1) to "score" the sample on the subjective quality of the result. There were also text labels on the slider: 4.0 was "perceptible but not annoying", 3.0 was "slightly annoying", 2.0 was "annoying" and 1.0 was "very annoying".
Finally, there was an ABX button, which launched a different window. In the ABX window, the user could select "Original", "Sample 1", or "Sample 2" for the "A" and "B" samples. Normal ABX testing proceeded from that point. (If you don't know what ABX is, go to pcabx.com.) I found that the ABX window sometimes helped me to focus on a specific sample so that I could find its flaws; armed with that knowledge, I was able to make a determination of which of the two sliders, right or left, was the encoded version.
Once a slider was pulled down from the default 5.0 position, another button became active above that slider. Clicking on it opened a new window with a text box, into which comments could be typed. When the user was finished with the test, the slider positions, the comments, and the ABX results (if any) were written to a plain text file (DOS CR/LF format), which was to be mailed to the test administrator. (Though, of course, you weren't supposed to mail the practice results.)
Now, that was just the practice session, which was a prerequisite for participation in the actual test. For the actual test, the process was similar, but differed in a few details.
The actual test samples included copyrighted, patented codecs for which there are no freely distributable decoders. Therefore, the WMA, AAC and MP3Pro samples were distributed as FLAC files, and decoded by the batch file. Since MP3 did not participate in the listening test, the LAME encoder was not used during the actual test. The Vorbis encoder, of course, was used twice: first with -q 0, and then with -b 64 --managed.
With 5 encodings per audio sample in the actual test, there were 5 pairs of active sliders instead of only 2 pairs. But otherwise, the actual test was exactly like the practice session.
(Personal note: I did 10 of the 12 samples, skipping the two classical ones. Out of 50 encoded versions of the 10 samples, there was only one case where I couldn't tell right from left -- "The Source", encoded with MP3Pro.)
Twice the capacity of normal players and it STILL sounds better (or same capacity truly indistinguishable from CD -- at only 128k).
Vorbis 1.0 does sound amazingly good at ca. 128 kbps (VBR -q 4). That's what I've been using lately for CDs that I rip. But it's not "indistinguishable from CD" in all cases. On at least one song ("Feed My Hungry Soul" by the Lords of Acid), I can differentiate Vorbis -q 4 from the original in ABX testing. And I'm not a trained listener, and not using high-end equipment.
I urge everyone to encode for themselves, using their favorite music CDs, and decide what works best for them. Some people are very sensitive to the lossy stereo separation that Vorbis RC3 and 1.0 employ at low-to-mid-bitrate settings. I was able to hear this clearly on several of the samples in the 64kbps test, though I'd never noticed it at higher quality levels.
It's been several years since I read Firefly, but if I remember correctly, the scene in question is something like this:
A very young girl has suffered sexual abuse, and is looking for solace. Specifically, she needs to reach a point of understanding that sex can be healing as well as harmful; and to do this, she has to have a positive sexual experience. She meets a grown man who is mentally retarded. She seduces him, despite his intial objections -- he does not have the mental capacity to understand the danger she is placing him into. (If she were slightly more sophisticated, one might say that she used him. But she was naive enough, and he was simple-minded enough, that the relationship was somewhat balanced.)
Later, their activities become known, and the man is placed on trial. The girl doesn't understand, at first, why he is in trouble; when she does, she tries to protect him, but it's too late. And so, for helping her, he goes to jail.
So, only MP3s are currently being bogofied? (And, I would assume, primarily the Windows-only networks?) That's good, actually. Those of us who prefer to share and download Ogg Vorbis files on predominantlyUnix-basednetworks will remain largely unaffected.
No, KaZaA used to have a Linux client, but they went out of their way to break compatibility with their own network protocol -- multiple times -- so the official KaZaA Linux client no longer works.
If you're looking for a Linux-based file sharing system, you have three basic choices:
That's not historic. I do something very similar to that, today, using Apache and ipchains. I ban users who use those fucking multi-threading download manglers. You can see the idiot list du jour at greycat.yi.org.
I've said this before, but a quick glance through the first few comments at threshold 2 didn't reveal anyone else having said it yet, so....
TURN OFF JAVASCRIPT, YOU IDIOTS!
Javascript is the Incarnation of Evil on this plane. It is the Scion of Satan. It is the Bastard of Beelzebub. Javascript blew up the Twin Towers on September 11. Javascript is what killed your goldfish when you were a kid.
(We now return you to your regularly scheduled "my browser is better than your brower" war.)
Slashdot Mirror
What do you think it is? Beautiful artwork? Lovely poetry? pics of the goatse guy?
All of the above. I mean that literally. (Well, OK, "Beautiful" and "Lovely" are subjective.)
The docs refer to fcp.allowedHosts, fproxy.allowedHosts, and fproxy.bindAddress.
The docs are out of date. The "fproxy" service was renamed to "mainport" about a month ago.
mainport.port=8888
mainport.bindAddress=*
mai
ma
Also note that "nodeinfo" is gone. It got merged with fproxy into mainport. For more details, please read The Freenet Wiki FAQ.
I'm having a very hard time imagining any nontrivial legitimate use for this technology.
Free hosting for your daily web comic. You could even have normal World Wide Web URLs embedded in the Freenet page, pointing back to your web-store for merchandise, etc.
Free hosting for your own music, that you composed and recorded yourself. See above for merchandising. ("If you like these lossily-compressed songs and want to buy a better-sounding copy on CD, click here....")
Free hosting for a personal web log.
I hope you see the pattern here. In addition to this pattern, we have:
Uncensorable criticism of your employer, the Church of Scientology, the government of your country, etc.
Uncensorable expression of unpopular opinions (hate speech, underage erotica, racism, sexism, negative religious speech of all flavors). Publishing these forms of expression on the traditional Web could lead to unpleasant repercussions.
That's just "shooting from the hip". I'm sure someone with different needs and perspectives can come up with even more legitimate uses for this application. Use your imagination.
The Freenet gateway page (or "web interface") has three Freenet URLs: The Freedom Engine, and a couple others. (Currently "Freenet Forever" and "Cruft". I'm glad Cruft made it, finally -- the author deserves it.)
The Freedom Engine (TFE) is published by (or claims to be published by) the same person who did "Content of Evil" in the older days. It's essentially Freenet's version of Yahoo! (the old one, before they added a bunch of services) -- a portal to other sites within Freenet. Go there. Be amazed by the variety, both good and bad.
It is NOT designed for swapping MP3s or porn for those who have got the wrong idea,
Before anyone gets misled, let me state for the record that Freenet does have porn and MP3s in it. In fact, it's quite a good platform for publishing collections of pornographic images. (It's not quite as good for MP3s and Oggs because they're much larger files. But it has been successfully used for that purpose. It may even have been used successfully for the next order of magnitude (ISO images, movies), but I can't confirm or deny that.)
So if you're reading this wondering if Freenet is going to have any pr0n -- yes, it does. But you may be somewhat disappointed if you're looking for huge MP3 collections.
Another problem was that because nothing can ever be deleted from the FreeNet once published, it was hard to do news/blog style sites: at the time they used JavaScript date based redirects, I think that shows how long ago I used it.
Wow, you're right -- that does show how long ago you last tried it! ;-)
Suffice to say, the Javascript method is no longer used. In fact, fproxy (err, I think they still call it fproxy even though it's called "mainport" in the config file now) will object vehemently if it encounters any Javascript in a Freenet document.
There are several popular sites (and some less popular ones, like mine) that do a quasi-daily blog style. It's been working quite well for a couple weeks now (ever since Matthew's really excellent debugging job got into high gear). If you saw what Freenet 0.3 and earlier were like, you're going to be stunned when you try 0.5. Seriously.
(Those who missed the early Freenet days may not be stunned. You don't have the point of reference that IamTheRealMike has, and you may be spoiled by services that are much faster than Freenet -- of course, none of those services has Freenet's anonymity.)
Either say what the problem is, or keep reading. C'mon, you didn't even say what operating system you're running! (Must be a Windows user.)
In general, the procedure is as follows:
0) Download Java.
1) Download Freenet software.
2) Configure it (generate freenet.ini or freenet.conf).
3) Start the node.
4) Wait for it to initialize (usually takes less than a minute).
5) Go to http://127.0.0.1:8888/.
Now, you can go yell at the Freenet developers if you wish, but all of the documentation linked to from freenetproject.org is badly out of date and incomplete. There is a much better Freenet user FAQ at The Freenet Wiki. It's not perfect, either, but it's much closer.
If for instance, my node is used for storing some part of some kiddy pr0n and the authorities decide for whatever reason to inspect my PCs, how am I to prove that I didn't source the file myself.
Your question should be modded up. It's one of the most important ones.
The idea behind Freenet's anonymity is plausible deniability. But before I can go into what that means, I need to describe how Freenet works in a little more detail.
There are two different types of Freenet nodes: permanent and transient. If you run a permanent node, it means that you're a full participant in the Freenet network. Your node acts as storage and as a router for requests and inserts. Data moves through Freenet in the form of keys, which are basically the same as files (or in some cases, segments of files) but with cryptic names. Your node caches all the keys that it sees (with least recently used keys being deleted when the node's data store is full, with "full" being defined by the amount of space you choose to let it consume).
Let's say Alice inserts two files into Freenet: the text of Mein Kampf and a picture of Adolf Hitler. She does this using her Freenet node, specifying a hops to live value on the insert. This HTL value is usually around 10 to 15, and is the number of other Freenet nodes that must be talked to. Each node that processes Alice's request decreases the HTL and passes it on to another node. When the last node to get the request sees that HTL is 1, and it still hasn't found Alice's file (because she's the first person to insert it), it returns Data Not Found to the previous node, which passes it to the previous node, etc., all the way back to Alice.
Alice's node gets the "failure" message back, and then sends actual copies of the data files back down the chain. Thus, the files are inserted into Freenet.
Now, this is where the plausible deniability comes in: the data coming from Alice's node looks just like the data coming from all the other nodes she talked to during the request/insert process. There's no way to distinguish between the node that originated the request and a node that's simply passing the request along on someone else's behalf. So if someone were to sniff the traffic coming from Alice's machine and decrypt it and discover that her machine was inserting Mein Kampf, then she could claim that she had no knowledge of it; that her machine was simply routing an insert by someone else.
The same goes for requests. Suppose Bob stumbles upon a key which claims to be an ISO image of Windows 2000 Professional and requests a copy of it. His node generates a request with a certain HTL (generally 15 or more for requests), and it's passed along to other nodes until one of them either finds the key, or runs out of hops. The final result (either an error condition or the key he requested) is sent back to Bob's node.
But Bob could claim that he wasn't the person who originally requested that key -- he could say that his node was simply routing someone else's request, and he had no knowledge of it.
The same thing goes for files inside the local node's data store. Just because your node is storing a copy of a nude photo of Ronald Reagan doesn't necessarily mean that you either inserted or requested that file. Your node might simply have acted as a router for someone else's activity, and cached a copy of the key.
Now, all of this protection goes straight out the window if you run a transient node. Transient nodes don't ever act as routers for other nodes -- they're pure leeches. Anything on a transient node is there because you, the node operator, requested or inserted it there. You have no plausible deniability any more.
This explanation is a bit vague, and for that I apologize. The actual routing algorithms and encryption ciphers are a bit beyond my understanding at this time. If you have more detailed questions about how Freenet works, please check the Freenet mailing lists.
The problem is that not all "Tulip" chipsets are created equal. The tulip.c driver covers a lot of different hardware from a lot of different vendors.
If your "Tulip" card is actually a Linksys 10/100 , then it's not actually a DEC Tulip chipset at all. Mine is reported as an ADMtek Centaur-P rev 17 in dmesg (and a Linksys Network Everywhere Fast Ethernet 10/100 model NC100 in lspci). And yes, I had trouble with this card, although it seems to be much better in Linux 2.2.21 than in previous Linux kernels. (I haven't tried 2.2.22 on that machine yet.) (Linux 2.4? Puh-lease! Maybe when it's stable.)
I have worked with Linux servers since 1998 and I have never seen one crash.
I have.
I started with Linux in May 1993 running kernel 0.99 pl 14. That one had a bug in the keyboard driver, which caused the system console to lock up if I typed too quickly. But that hardly counts, because the kernel hadn't hit 1.0 yet.
I just updated one of our production servers from 2.0.36 to 2.0.39 two weeks ago because I kept getting total system lockups accompanied by kernel error messages on the console and I was tired of hitting reset and watching it fsck while users kept asking why the database didn't work.
I had a boatload of problems with the tulip driver and Linux's NFS client code in late-series 2.2.x kernels (2.2.19 and 2.2.20). This appears to be mostly fixed in 2.2.21.
I won't even begin to describe all the horror stories I've heard about the 2.4.x kernel series; instead, I'll just tell you the one I've actually lived through. I have a machine which was until recently a server, but now I wanted to make it a
desktop. It's an HP Pavilion that has an i810 integrated video thing in it (I can't call it a "video card"). In order to run X on this thing, with Linux, I needed kernel 2.4.x for agpgart support. Well, when I run X on this thing under 2.4.18, everything's fine -- except that the NFS client suddenly stops working. Any access to the NFS-mounted file system goes into kernel wait and is completely unkillable (even with -9). The system has to be rebooted -- but the reboot also hangs. Meaning I have to sit through a 45-minute-or-more fsck. (No, I am not exaggerating. One of the disks in this thing is either not properly recognized or is physically defective. If I attempt to turn on DMA mode, the system locks hard.) Anyway, my workaround for this is not to mount any NFS file systems on it -- it can serve as a dumb web browser and Freenet node using local storage only.
#
# Delay in seconds before being allowed another attempt after a login failure
#
FAIL_DELAY 3
That's in /etc/login.defs on Debian 3.0.
No native JDK 1.4.
Ridiculous claim since Linux binaries are supported at the kernel level.
DISCLAIMER: My experience is with OpenBSD, not FreeBSD. (However, FreeBSD users have confirmed my findings in considerable detail.)
DISCLAIMER: I hate Java's bloated reeking guts. Java's only purpose in life is to run Freenet until someone rewrites the Freenet reference node into a portable language like C.
My experience with Java and Freenet on OpenBSD is that the Linux native JDK does not work. Freenet will appear to start up and run, but once you actually start using it, it fails miserably. Specifically, the Freenet node listens for connections on two or more TCP/IP sockets. Connections made to any port that Freenet is listening to will be silently dropped if no data are waiting on the socket (e.g., if you telnet localhost 8888 it will drop the connection after accepting it). However, if data are actually waiting in the buffer, the connection may work, at least sometimes (e.g., if you echo -e "GET / HTTP/1.0\n" | nc localhost 8888 it will work most of the time).
As you can imagine, this makes running the software a fool's mission. Things just break and there's no rhyme or reason to it, because there's at least one case where the behavior is nondeterministically broken. And that's just the case that I happened to discover -- who knows what else is lurking in those murky proprietary-Sun-code depths?
Fortunately, Kaffe 1.0.7 seems to work at least acceptably for running Freenet on OpenBSD. (Don't use Kaffe from the ports tree, which is 1.0.6. Kaffe 1.0.6 has serious bugs, at least one of which is in big number handling, which is essential to many of Freenet's encryption algorithms.) Kaffe 1.0.7 has some bugs of its own -- for example, it tended to crash and core dump on me, at least until I commented out one assertion that the Kaffe mailing list said was probably spurious. (And you don't want to see how big a Kaffe/Freenet core file is.)
"Sorry, we see you've broken the terms of our agreement, so we can no longer keep your credit card interest below our maximum rate."
You have this backwards. I think what you really meant to say was, "Sorry, we see you've revealed yourself to be a pathetic little dying bank grasping at pennies in an effort to stay solvent just a few more months, so we can no longer keep your credit card. Please give us all our money back, so we can put it in your competitor."
The ideal solution would be for the reviewers to not review them at all. See what that does to sales.
I can't speak for Pearl Jam, but in the case of Tori Amos, it won't do a damn thing. She's got a solid core of fans who will buy this album, unheard, unreviewed, period. I should know; I'm one of them.
Listen to "A man with a gun".
Obligatory nitpick: "Me and a Gun", from her first album Little Earthquakes.
I am Karma Man, hear me Whore.
An honest double-blind listening test is extremely difficult to arrange, and there is no evidence whatsoever on such on the site.
This is how the test was conducted.
The test required access to a Windows machine (probably Win95 and up, didn't try with Win3.1) with a sound card. Users were required to download the ABC/HR "practice" Zip file, which includes the ABC/HR program, the Ogg Vorbis 1.0 command-line encoder and decoder, a LAME command-line encoder/decoder (I forget which version), a FLAC command-line decoder program, and a .flac sample file (the instrumental introduction to The Eagles' "New Kid in Town").
After unzipping this, the user had to run a batch file (encdec_foobar.bat) which un-FLACced the sample file, then encoded it with Ogg Vorbis and LAME, then decoded both of the resulting files back to .wav.
Then the user executed the ABC/HR program, which is a Win32 GUI application. After loading the sample into the application (pull-down menu and file selector dialog), the interface became a row of double-slider pairs. Below each slider was a "Play" button. Below each slider pair was a "Play Ref" button. Below that was a "Stop" button. There was a pair of sliders for each decoded sample -- so for the practice run, there were two pairs of sliders: one for file #1, and one for file #2. The user did not know which file was Ogg Vorbis, and which was LAME MP3.
The user then listened to the Reference file by clicking any of the "Play Ref" buttons. After hearing the Reference, the user could then click any of the normal "Play" buttons. The first task was to determine, for each pair of sliders, which one was the original and which one was the encoded file. Having determined that, the user used the slider (which went from 1.0 to 5.0 in increments of 0.1) to "score" the sample on the subjective quality of the result. There were also text labels on the slider: 4.0 was "perceptible but not annoying", 3.0 was "slightly annoying", 2.0 was "annoying" and 1.0 was "very annoying".
Finally, there was an ABX button, which launched a different window. In the ABX window, the user could select "Original", "Sample 1", or "Sample 2" for the "A" and "B" samples. Normal ABX testing proceeded from that point. (If you don't know what ABX is, go to pcabx.com.) I found that the ABX window sometimes helped me to focus on a specific sample so that I could find its flaws; armed with that knowledge, I was able to make a determination of which of the two sliders, right or left, was the encoded version.
Once a slider was pulled down from the default 5.0 position, another button became active above that slider. Clicking on it opened a new window with a text box, into which comments could be typed. When the user was finished with the test, the slider positions, the comments, and the ABX results (if any) were written to a plain text file (DOS CR/LF format), which was to be mailed to the test administrator. (Though, of course, you weren't supposed to mail the practice results.)
Now, that was just the practice session, which was a prerequisite for participation in the actual test. For the actual test, the process was similar, but differed in a few details.
The actual test samples included copyrighted, patented codecs for which there are no freely distributable decoders. Therefore, the WMA, AAC and MP3Pro samples were distributed as FLAC files, and decoded by the batch file. Since MP3 did not participate in the listening test, the LAME encoder was not used during the actual test. The Vorbis encoder, of course, was used twice: first with -q 0, and then with -b 64 --managed.
With 5 encodings per audio sample in the actual test, there were 5 pairs of active sliders instead of only 2 pairs. But otherwise, the actual test was exactly like the practice session.
(Personal note: I did 10 of the 12 samples, skipping the two classical ones. Out of 50 encoded versions of the 10 samples, there was only one case where I couldn't tell right from left -- "The Source", encoded with MP3Pro.)
AAC's performance at 64 kbps is not necessarily indicative of its performance at 128 kbps.
Twice the capacity of normal players and it STILL sounds better (or same capacity truly indistinguishable from CD -- at only 128k).
Vorbis 1.0 does sound amazingly good at ca. 128 kbps (VBR -q 4). That's what I've been using lately for CDs that I rip. But it's not "indistinguishable from CD" in all cases. On at least one song ("Feed My Hungry Soul" by the Lords of Acid), I can differentiate Vorbis -q 4 from the original in ABX testing. And I'm not a trained listener, and not using high-end equipment.I urge everyone to encode for themselves, using their favorite music CDs, and decide what works best for them. Some people are very sensitive to the lossy stereo separation that Vorbis RC3 and 1.0 employ at low-to-mid-bitrate settings. I was able to hear this clearly on several of the samples in the 64kbps test, though I'd never noticed it at higher quality levels.
It's been several years since I read Firefly, but if I remember correctly, the scene in question is something like this:
A very young girl has suffered sexual abuse, and is looking for solace. Specifically, she needs to reach a point of understanding that sex can be healing as well as harmful; and to do this, she has to have a positive sexual experience. She meets a grown man who is mentally retarded. She seduces him, despite his intial objections -- he does not have the mental capacity to understand the danger she is placing him into. (If she were slightly more sophisticated, one might say that she used him. But she was naive enough, and he was simple-minded enough, that the relationship was somewhat balanced.)
Later, their activities become known, and the man is placed on trial. The girl doesn't understand, at first, why he is in trouble; when she does, she tries to protect him, but it's too late. And so, for helping her, he goes to jail.
So, only MP3s are currently being bogofied? (And, I would assume, primarily the Windows-only networks?) That's good, actually. Those of us who prefer to share and download Ogg Vorbis files on predominantly Unix-based networks will remain largely unaffected.
No, KaZaA used to have a Linux client, but they went out of their way to break compatibility with their own network protocol -- multiple times -- so the official KaZaA Linux client no longer works.
If you're looking for a Linux-based file sharing system, you have three basic choices:
I don't count Freenet here because it's too unreliable.
That's not historic. I do something very similar to that, today, using Apache and ipchains. I ban users who use those fucking multi-threading download manglers. You can see the idiot list du jour at greycat.yi.org.
evilviper, I would mod you up if I had mod points.
http://www.discover.com/may_02/feattech.html
The link supplied in the slashdot write-up requires Javascript. Javascript is bad. 'K?
I've said this before, but a quick glance through the first few comments at threshold 2 didn't reveal anyone else having said it yet, so....
TURN OFF JAVASCRIPT, YOU IDIOTS!
Javascript is the Incarnation of Evil on this plane. It is the Scion of Satan. It is the Bastard of Beelzebub. Javascript blew up the Twin Towers on September 11. Javascript is what killed your goldfish when you were a kid.
(We now return you to your regularly scheduled "my browser is better than your brower" war.)