Unfortunately, a peer-to-peer network with a centralized authority is not peer to peer! This creates a single point of failure and a stronger legal liability...
The easy way to get around blacklists based on "nick"s that the user invents is to simply invent a new nick for each crappy file you put on the network. Unless you expect that users will know most of the others around and have already developed trust for them, people will simply see a lot of hits coming from seemingly good users.
Here's one solution to that problem: http://www-2.cs.cmu.edu/~tom7/papers/peer.pdf
I thought a bit about these issues (in a different context) and wrote a paper on a method for assigning identities to network participants in a fully peer-to-peer way using cryptographic techniques. The basic idea is to make identity generation computationally expensive and independently verifiable, so that you know without having to trust any third party that the user in question spent a significant amount of resources to create their identity. Though these identities are pseudonymous (they won't say "RIAA", unfortunately), they are associated with the user's behavior through message signing, so it becomes easy to build a blacklist of users that you don't like. In certain situations, you can even share unforgeable evidence of misdeed with others. With this as a start, I don't believe it's infeasible to do things like you describe...
These days instruction-level efficiency simply isn't important outside of a few niche areas (embedded systems, games, multimedia, certain kinds of low-level systems work). To imply that knowing what's happening on the silicon is "what really counts" is nonsense. Using appropriate data structures and algorithms counts, and making correct software counts even more, but worrying about how many cycles one instruction takes versus another is a serious misdirection of effort on modern machines!
It's folks like you who are the reason people still write their SSH daemons in C, and why we live in a mixed up world where we have neither stability NOR speed!
You guys might remember the DMCA Threats I received over my program embed (for TrueType fonts). I think this case has some interesting consequences for my fight, because I published my program in 1997 and haven't modified the page since. 1997 was before the DMCA became law. If in fact that publishing was found to be the only act of "trafficking", then they would not be able to sue me because of the ban on ex post facto laws in the constitution.
Of course, that defense is much weaker than the dozens of other reasons why their threats are totally stupid.;)
I don't think you want SIMMs. Those were popular in 1996, but these days everybody uses DIMMs or SODIMMs (laptops).
By the way: Ask slashdot questions generally need more context, or else we're all just speculating! What are you going to do with these things? Can it be done by networking your terminals to one large machine in the back room?
Yeah, the new Wilco is pretty good. But there are not just a "few bands" that allow fans to tape shows -- almost none of the independent artists we had when I used to arrance concerts for my school had any problem with it either. It's mainly just the Big Label career "artists" who don't like it.
My friend has an iBook and I found it to be pretty slow. I didn't run any benchmarks or anything, but it definitely "felt" slower than my 400mhz celeron vaio in OSX, and that thing cost only $1200 three years ago!
Also, ask around to see what the actual battery life of any laptop you buy is. The advertised times are sometimes measured under pretty unlikely circumstances..
This happens frequently when forgetting the semicolon at the end of a class or struct definition in your header file. Since it's pasted into the source file you compile, and the parse error doesn't happen until *after* that file has ended, it reports the error in the source file, not the header file. I had this one on a job interview once.;)
When comments are more than comments...
on
Pet Bugs?
·
· Score: 4, Funny
Back in the day when I used to program in C++, I was also really into making little ascii-art comments in my code. One time I had some code that looked like this:
#include <stdio.h>
// tom 7 was here - 1998 \\
typedef unsigned char uchar;
int something(uchar c);
...
(In actuality, the code was longer and more complicated, so it wasn't so easy to figure out...). Can you see the bug?
Uh, duh, this is slashdot!
on
Is Linux Dead?
·
· Score: 1
Unfortunately the prolog program (as usual) is extremely inefficient. It'll work for a few people, but for hundreds, exhaustive backtracking search is really slow. Matching solves it (at least the problem you describe, which may be different from the "timetabling" problem) in polynomial time.
Huh? They have a workaround that doesn't work on many systems, not a patch. From what I understand, this vulnerability has been known for at least a week already... (though it has not been "announced").
Again, OpenSSH has another remote exploit! It is climbing my list of insecure software on my machine, which is pretty scary. Can't someone write secure software??
But even finding the optimal solution for a bipartite matching problem is polynomial time. This is just matching, right? (His description is sort of vague...)
I thought bipartite matching with integral weights (probably no weights in this case, actually) was polynomial time. Am I missing something that makes this NP-complete, or did you just make that up?
Genetic algorithms? Really? It sounds to me like a straight up bipartite matching problem, and though there are doubtlessly genetic algorithms for tackling matching, there are also plenty of simple algorithms too (like using max flow... polynomial time!). It sounds like you don't have weights and you probably don't even require the optimum solution, so what's the big deal? Just implement it as a nice abstract package, and hopefully nobody will need to "maintain" your working matching library.
> A high speed x86 cpu wastes 90% of its power on operations who's result is thrown away.
This figure sounds pretty fishy. I know there's a lot of speculative execution going on in a superscalar chip, but 90% sounds way too high. Where'd you get this?
> You are resisting _real, tangible, and easy improvement_ because of _tradition_ and > because you are unwilling to change what you grew up with, "It works swell now dammit, I > don't need no hard disk, floppies do all I need!". That is what this boils down to.
No, I'm resisting a minor improvement to something that's already easy. Would I like it if my keyboard was also color-coded to make typing easier? The arms of my t-shirt color-coded to make it easier to tell front from back? There are plenty of easy things that can be made easier, but if they mean making the things ugly too, then I am probably not for it. If they do want to make a *real* difference, like dispensing with cash to make way for electronic money, getting rid of the penny, etc. then I am all for it. It's just a matter of weighing the pros versus the cons.
Also, as others have pointed out, this is not necessarily "easy"; consider for instance the tens of thousands of automatic bill changers around the US.
Of course it's true that adding color makes it *easier* to distinguish bills, I have to contend with your statement that american bills are "difficult" to distinguish between. I have never, ever, squinted or got out my magnifying glass to try to tell them apart, or asked for help from the cashier. I've never asked for someone to wait up while I compare all the bills in my wallet to see if I can find the twenty. That, to me, means it is not "difficult". In fact, I'd say it is easy to simply look at the big numbers in the corner or the new big portraits to tell what denomination it is. Yes, it could be somewhat easier with colors, but that comes at a cost of altering tradition (and you know how Americans love their money!). As an actual American, I do prefer the tradition over the minor convenience.
Slashdot Mirror
Unfortunately, a peer-to-peer network with a centralized authority is not peer to peer! This creates a single point of failure and a stronger legal liability...
Nitpick:
The easy way to get around blacklists based on "nick"s that the user invents is to simply invent a new nick for each crappy file you put on the network. Unless you expect that users will know most of the others around and have already developed trust for them, people will simply see a lot of hits coming from seemingly good users.
Here's one solution to that problem: http://www-2.cs.cmu.edu/~tom7/papers/peer.pdf
I thought a bit about these issues (in a different context) and wrote a paper on a method for assigning identities to network participants in a fully peer-to-peer way using cryptographic techniques. The basic idea is to make identity generation computationally expensive and independently verifiable, so that you know without having to trust any third party that the user in question spent a significant amount of resources to create their identity. Though these identities are pseudonymous (they won't say "RIAA", unfortunately), they are associated with the user's behavior through message signing, so it becomes easy to build a blacklist of users that you don't like. In certain situations, you can even share unforgeable evidence of misdeed with others. With this as a start, I don't believe it's infeasible to do things like you describe...
Check it out:
http://www-2.cs.cmu.edu/~tom7/papers/peer.pdf
Sweeeeeeeeeeeet.
These days instruction-level efficiency simply isn't important outside of a few niche areas (embedded systems, games, multimedia, certain kinds of low-level systems work). To imply that knowing what's happening on the silicon is "what really counts" is nonsense. Using appropriate data structures and algorithms counts, and making correct software counts even more, but worrying about how many cycles one instruction takes versus another is a serious misdirection of effort on modern machines!
It's folks like you who are the reason people still write their SSH daemons in C, and why we live in a mixed up world where we have neither stability NOR speed!
You guys might remember the DMCA Threats I received over my program embed (for TrueType fonts). I think this case has some interesting consequences for my fight, because I published my program in 1997 and haven't modified the page since. 1997 was before the DMCA became law. If in fact that publishing was found to be the only act of "trafficking", then they would not be able to sue me because of the ban on ex post facto laws in the constitution.
Of course, that defense is much weaker than the dozens of other reasons why their threats are totally stupid. ;)
I don't think you want SIMMs. Those were popular in 1996, but these days everybody uses DIMMs or SODIMMs (laptops).
By the way: Ask slashdot questions generally need more context, or else we're all just speculating! What are you going to do with these things? Can it be done by networking your terminals to one large machine in the back room?
Actually, I have seen this "Buffy the Vampire Slayer" on TV and it was pretty bad. Maybe that's the reason?
I dunno, but my second son is gonna be called Skeletor.
Yeah, the new Wilco is pretty good. But there are not just a "few bands" that allow fans to tape shows -- almost none of the independent artists we had when I used to arrance concerts for my school had any problem with it either. It's mainly just the Big Label career "artists" who don't like it.
The slow one is the OSX laptop! I dunno how to replace windows with linux there. ;)
My friend has an iBook and I found it to be pretty slow. I didn't run any benchmarks or anything, but it definitely "felt" slower than my 400mhz celeron vaio in OSX, and that thing cost only $1200 three years ago!
Also, ask around to see what the actual battery life of any laptop you buy is. The advertised times are sometimes measured under pretty unlikely circumstances..
This happens frequently when forgetting the semicolon at the end of a class or struct definition in your header file. Since it's pasted into the source file you compile, and the parse error doesn't happen until *after* that file has ended, it reports the error in the source file, not the header file. I had this one on a job interview once. ;)
Back in the day when I used to program in C++, I was also really into making little ascii-art comments in my code. One time I had some code that looked like this:
#include <stdio.h>
// tom 7 was here - 1998 \\
typedef unsigned char uchar;
int something(uchar c);
...
(In actuality, the code was longer and more complicated, so it wasn't so easy to figure out...). Can you see the bug?
Read the article? Why? This is slashdot!
;)
Have you subscribed yet?
Unfortunately the prolog program (as usual) is extremely inefficient. It'll work for a few people, but for hundreds, exhaustive backtracking search is really slow. Matching solves it (at least the problem you describe, which may be different from the "timetabling" problem) in polynomial time.
I'm a copyright holder, in fact I distribute my works for free on P2P networks. AND NOW I WILL BE ABLE TO DOS THEM LEGALLY!
Huh?
They have a workaround that doesn't work on many systems, not a patch. From what I understand, this vulnerability has been known for at least a week already... (though it has not been "announced").
Again, OpenSSH has another remote exploit! It is climbing my list of insecure software on my machine, which is pretty scary. Can't someone write secure software??
But even finding the optimal solution for a bipartite matching problem is polynomial time. This is just matching, right? (His description is sort of vague...)
I thought bipartite matching with integral weights (probably no weights in this case, actually) was polynomial time. Am I missing something that makes this NP-complete, or did you just make that up?
Genetic algorithms? Really? It sounds to me like a straight up bipartite matching problem, and though there are doubtlessly genetic algorithms for tackling matching, there are also plenty of simple algorithms too (like using max flow ... polynomial time!). It sounds like you don't have weights and you probably don't even require the optimum solution, so what's the big deal? Just implement it as a nice abstract package, and hopefully nobody will need to "maintain" your working matching library.
> A high speed x86 cpu wastes 90% of its power on operations who's result is thrown away.
This figure sounds pretty fishy. I know there's a lot of speculative execution going on in a superscalar chip, but 90% sounds way too high. Where'd you get this?
> You are resisting _real, tangible, and easy improvement_ because of _tradition_ and
> because you are unwilling to change what you grew up with, "It works swell now dammit, I
> don't need no hard disk, floppies do all I need!". That is what this boils down to.
No, I'm resisting a minor improvement to something that's already easy. Would I like it if my keyboard was also color-coded to make typing easier? The arms of my t-shirt color-coded to make it easier to tell front from back? There are plenty of easy things that can be made easier, but if they mean making the things ugly too, then I am probably not for it. If they do want to make a *real* difference, like dispensing with cash to make way for electronic money, getting rid of the penny, etc. then I am all for it. It's just a matter of weighing the pros versus the cons.
Also, as others have pointed out, this is not necessarily "easy"; consider for instance the tens of thousands of automatic bill changers around the US.
Of course it's true that adding color makes it *easier* to distinguish bills, I have to contend with your statement that american bills are "difficult" to distinguish between. I have never, ever, squinted or got out my magnifying glass to try to tell them apart, or asked for help from the cashier. I've never asked for someone to wait up while I compare all the bills in my wallet to see if I can find the twenty. That, to me, means it is not "difficult". In fact, I'd say it is easy to simply look at the big numbers in the corner or the new big portraits to tell what denomination it is. Yes, it could be somewhat easier with colors, but that comes at a cost of altering tradition (and you know how Americans love their money!). As an actual American, I do prefer the tradition over the minor convenience.