Still, you could assign a random integer to how many mod points somebody gets each time he/she mods (say, a random integer from 1-10). Failing that, I think it would be interesting to see classes of mod points (say, be given a random number of +mod points and -mod points; the +mod points for modding stuff up and the -mod points for modding down). That would keep the rampant +5/karma runaway problem from growing much more than it already has by limiting the amount of karma that can be generated. There would have to be limitations on the random numbers for mod point allocation as a whole (preferably somewhat more +mod points than -mod points, otherwise/. would either stagnate or go into a karma sinkhole), but it would probably skim some of the overvalued posts from the top of the heap.
Hmmm. I'm gonna wind up reversing a troll mod by posting this, but oh well.
It would be a simple matter to have posts at, say, +5 be docked 1.5 mod points (staying in integers; it would have to be modded down twice from +5 to get the other -.5 which would bring it down another point). Or you could make it easier to mod a post down based on how the poster's other comments have been modded. Or have each +1 addition to a comment increase the poster's karma less if the poster already has higher karma. Something like that.
. . . that the best computer is only as good as its software. Can they guarantee that eLiza will be entirely invulnerable to script kiddie attacks? Probably not. It's statistically impossible (if the software is of any complexity at all, which it is).
I realize they're only claiming that it will aid in system administration, but I worry that this will give too many people a false sense of security (business executives, for example, who know little about security). I don't know about you, but, to me, a false sense of security is worse than bad (or no) security. At least with bad security, you know what to look for.
How can you tell what the server's been up to, anyway? Will it print out logs, or what? I'd rather administer my own box, to my own taste, than trust automated software to do it for me.
Finally, if the software is defective, could a company sue IBM . . . ? Or would this be more like firewalls (you've gotta maintain it yourself)?
Oh, yeah. *That's* why I was thinking 60 fps for NTSC and 50 fps for PAL. I usually use emulation software for my old video games (I'm too lazy to dig up my old systems and hook them up). The docs say that they run at 60 fps for NTSC games and 50 fps for PAL games. Just now, looking at the specs for NTSC and PAL on the Internet, I noticed that they are defined at roughly 30 and 25 fps.
I'm somewhat curious, though. How do they run things at twice the defined resolution without breaking something? Or are TVs designed for that?
PS2s are more powerful than people think. It is conceivable that a Beowulf cluster (or some other distributed processing scheme) of these things could, say, allow for remote control of a fighter jet. The problem is that they can be used for distributed computing. Currently, Iraq cannot buy consumer U.S. computing equipment. But they can buy toys. The PS2 qualifies as a toy. But, with Linux being released for it, it is no longer strictly a toy. It can be dangerous.
As far as the TV formats are concerned, Japan and the U.S. both use NTSC (60 fps, 512x384 resolution). It's Europe that uses a different format (PAL; 50 fps, 768x576 resolution).
They can fit it all on one disc. Some games have it already (an option for Japanese or English text/speech). Besides, the Japanese PS2s already have an option to display the interface in English (play DVDs, change settings, etc.) Besides, some people don't care if they can't understand the games. They'll buy them anyway.
You know, the DVD spec only calls for lockouts for movie DVDs. Not games. DVD-ROM is a different specification. (The PS2 probably uses a different disc format, but AFAIK, no region codes are defined for DVD-ROM.) The lockouts on the PSX didn't have anything to do with any CD-ROM spec, now did they? It was all internal within the Playstation fileformat spec (some kind of weird interleaved knockoff of the ISO9660 spec).
Not to dampen anyone's spirits (because this is really cool), but does anyone remember the stories about Saddam Houssein buying up a bunch of PS2 units? This could be dangerous, if someone sends him a copy of Linux for the PS2 . ..
Hmmm. Rereading my post, I guess I forgot something. I was thinking more along the lines of file compression before encrypting the message with a one-time pad. Have each element have a possible range of 00-FF, and loop back when it reaches the end (for instance, after adding 5 to, say, FC, it would loop to 01 and vice versa). That way you could be able to gain bits in each transfer. Typing this gave me another idea, though. If there's room left at the end of the pads after the message is sent, one could include part of another pad, and then continue it through the next messages. If each of the pads is the same length, it wouldn't need a terminating sequence after the end of the pad. Just at the end of the compressed message.
If you've been in contact with someone, just give them a set of decryption keys for one-time pads. Then, for the last one, send another batch. For the encryption/decryption for each one, you could use a true random number generator (at least one company makes them (I don't have a link, but maybe someone could post one . . . ?), but they're expensive (in the $15,000+ range, IIRC)) and feed the output into a key generator. Then you've got something that would probably be as useful as quantum crypto, as long as it's only used once. Of course, I'm not a crypto expert, but maybe someone could give me some insight on this?
A submission to the patent office has finally been cleared.
A Slashdot user known only as "Anonymous Coward" has pattented the process of posting a comment earning a rating of "Troll".
Explaining his/her application, he/she said: "I'm tired of other Slashdot users infringing on my intellectual property. Now, if other people want to post trolls, I'll at least be compensated for my hard work popularizing . . . I mean "inventing" . . . trolls."
OK. So what do you do if you get a cracker? Do you prosecute or do you just record data? If you do prosecute, does it depend on intent (just port sniffing (and maybe letting the sysadmin know of a security flaw), attempted breakin, successful breaking, 0wn1n9 the box, etc.)? I personally think that white hat crackers (say, just portsniffing letting the sysadmin know about security flaws) and some grey hats (maybe breaking in and then fixing some security flaws and then e-mailing the sysadmin) shouldn't be punished for just poking around (although the grey hat thing is iffy). Similarly, I think that black hats should be slapped down as quickly as possible. The best thing we can do is to stop the script kiddies as quickly as possible. If the honeynet data can be used for that, great. Otherwise, how is this any different than, say, reading a security bulletin?
So what? While it's cool that they're doing this (I love playing chess), I think it would have been better reported after it was over. Until then, there's nothing really to see here (unless you want to know what software will be competing). Just release the log of the games, including how long it took for each move. Then people can write progs to simulate the game.
All you would have to do would be to have a seperate switched LAN with an extra NIC in each box hooked up to it. That's basically all this is, I think (I can't seem to find exact specs on it, though, so I could be wrong).
using standard cat5 cabling connecting the output from the server to a special input box that, apparently, you just connect a monitor, keyboard, and mouse into. I'm not sure how far cat5 can be strung without noticable/significant signal degredation, but it seems to me that this wouldn't be necessary.
You could do this yourself by just setting up either SSH or VNC (depending on how you manage the server; command line or GUI) on the server and connecting to it over a network. It would be cheaper (read: free), and you wouldn't have to worry about proprietary hardware breaking.
I don't follow BSD too closely, so I'm somewhat curious (if someone doesn't mind indulging my ignorance): I'm getting the impression from the other posts that, up to this point, the x86 architecture was the only one that supported SMP under BSD. Is that how it stands with BSD (plus the Alpha architecture now), or are there other architechtures it supports SMP on?
Well, since the DMCA doesn't even require encryption (just "scrambling"), you could just swap every two letters for the filename.
Or, if you want to go with the encrypted filenames, modify an open-source Napster client to have an option to encrypt the filename search submission according to those guidelines before it's sent (maybe with a possible user-defined encryption scheme). Then the Napster servers could just use the existing search code.
So people can encrypt the MP3s with a decryption key of, say, their usernames. I doubt that encrypted binaries would be blocked by the filters. Could they really fingerprint *every* possible encryption of an MP3? I doubt it.
Uh, oh. I've got a 700 MHz Athlon in an SD11 (I hate that mobo). I'll try to get a copy of Mandrake 8.0 (final release) soon and post my results, but it would help if there were faster mirrors . . .:^(
> it notes all your hardware and creates a unique "id" that has to have a matching unique "password" to unlock the software
Yes, and (for the Windows student version, anyway), it's also tied to your partition table. I resized my Windows box (where my student copy of Mathematica resides) once with fips, so I could install a copy of Linux, and when I tried to run Mathematica again, it told me it had an invalid key, and that I had two weeks to get a valid one before it stopped working. I had to request another one (on the plus side, they were quite prompt about it).
AFAIK, that was never ratified/accepted by the U.N. (although I'm not entirely sure on that).
> Any threat or use of force or any other hostile act or threat of hostile act on the moon is prohibited. It is likewise prohibited to use the moon in order to commit any such act or to engage in any such threat in relation to the earth.
This will have one of two effects (unless I'm forgetting something). Sony will either:
1. Rewrite VGS so as to optimize the subroutines and maximize compatibility (which then would be something I'd pay for)
or
2. Kill it off after June 30 (per the acquisition agreement) and hope people forget about it.
Personally, I don't really see any benefit for Sony to kill off the emulation project. Sony can't be making much money, if any, on their console sales. Because they would be increasing the potential market for their real cash cow (software; i.e. games), they can only stand to gain from improving the software.
This does raise an interesting question, however. How will this affect other PSX emulation projects? Will Sony try to kill them off because then they *would* then be infringing on Sony's business, will they be acquired also, or will they be suffocated and die (the commercial ones, anyway; the others are labors of love)?
As far as I'm concerned, if you wrote the program yourself, you probably understand the principles behind the formula, so why not? Be careful, though. Some teachers are very picky about decimal approximations vs. the actual value. (1.41421 vs. Sqrt[2]) Frankly, though, I'd advise working them out. After you do enough, you don't need to work them out anymore. You can just do them in your head. It takes practice, true, but it's worth it if you use a formula a lot. I did that with the quadratic formula and your basic derrivatives and integrals. Now it takes me about 3-5 seconds to figure quadratic roots/etc. out. That vs. loading a program (I also wrote one to compute quadratic roots), which takes about 10-15 seconds or longer on my TI-83 (punching keys).
Slashdot Mirror
Hmmm. You're right. I missed the point.
/. would either stagnate or go into a karma sinkhole), but it would probably skim some of the overvalued posts from the top of the heap.
Still, you could assign a random integer to how many mod points somebody gets each time he/she mods (say, a random integer from 1-10). Failing that, I think it would be interesting to see classes of mod points (say, be given a random number of +mod points and -mod points; the +mod points for modding stuff up and the -mod points for modding down). That would keep the rampant +5/karma runaway problem from growing much more than it already has by limiting the amount of karma that can be generated. There would have to be limitations on the random numbers for mod point allocation as a whole (preferably somewhat more +mod points than -mod points, otherwise
Hmmm. I'm gonna wind up reversing a troll mod by posting this, but oh well.
It would be a simple matter to have posts at, say, +5 be docked 1.5 mod points (staying in integers; it would have to be modded down twice from +5 to get the other -.5 which would bring it down another point). Or you could make it easier to mod a post down based on how the poster's other comments have been modded. Or have each +1 addition to a comment increase the poster's karma less if the poster already has higher karma. Something like that.
. . . that the best computer is only as good as its software. Can they guarantee that eLiza will be entirely invulnerable to script kiddie attacks? Probably not. It's statistically impossible (if the software is of any complexity at all, which it is).
I realize they're only claiming that it will aid in system administration, but I worry that this will give too many people a false sense of security (business executives, for example, who know little about security). I don't know about you, but, to me, a false sense of security is worse than bad (or no) security. At least with bad security, you know what to look for.
How can you tell what the server's been up to, anyway? Will it print out logs, or what? I'd rather administer my own box, to my own taste, than trust automated software to do it for me.
Finally, if the software is defective, could a company sue IBM . . . ? Or would this be more like firewalls (you've gotta maintain it yourself)?
Oh, yeah. *That's* why I was thinking 60 fps for NTSC and 50 fps for PAL. I usually use emulation software for my old video games (I'm too lazy to dig up my old systems and hook them up). The docs say that they run at 60 fps for NTSC games and 50 fps for PAL games. Just now, looking at the specs for NTSC and PAL on the Internet, I noticed that they are defined at roughly 30 and 25 fps.
I'm somewhat curious, though. How do they run things at twice the defined resolution without breaking something? Or are TVs designed for that?
Hmmm. Rereading my post, I noticed that I also typed 50 fps for PAL. It's 25. Looks like I doubled the frequency of each.
PS2s are more powerful than people think. It is conceivable that a Beowulf cluster (or some other distributed processing scheme) of these things could, say, allow for remote control of a fighter jet. The problem is that they can be used for distributed computing. Currently, Iraq cannot buy consumer U.S. computing equipment. But they can buy toys. The PS2 qualifies as a toy. But, with Linux being released for it, it is no longer strictly a toy. It can be dangerous.
Err. Yeah. Oops. Dunno why I typed 60 fps.
As far as the TV formats are concerned, Japan and the U.S. both use NTSC (60 fps, 512x384 resolution). It's Europe that uses a different format (PAL; 50 fps, 768x576 resolution).
They can fit it all on one disc. Some games have it already (an option for Japanese or English text/speech). Besides, the Japanese PS2s already have an option to display the interface in English (play DVDs, change settings, etc.) Besides, some people don't care if they can't understand the games. They'll buy them anyway.
You know, the DVD spec only calls for lockouts for movie DVDs. Not games. DVD-ROM is a different specification. (The PS2 probably uses a different disc format, but AFAIK, no region codes are defined for DVD-ROM.) The lockouts on the PSX didn't have anything to do with any CD-ROM spec, now did they? It was all internal within the Playstation fileformat spec (some kind of weird interleaved knockoff of the ISO9660 spec).
Not to dampen anyone's spirits (because this is really cool), but does anyone remember the stories about Saddam Houssein buying up a bunch of PS2 units? This could be dangerous, if someone sends him a copy of Linux for the PS2 . . .
Hmmm. Rereading my post, I guess I forgot something. I was thinking more along the lines of file compression before encrypting the message with a one-time pad. Have each element have a possible range of 00-FF, and loop back when it reaches the end (for instance, after adding 5 to, say, FC, it would loop to 01 and vice versa). That way you could be able to gain bits in each transfer. Typing this gave me another idea, though. If there's room left at the end of the pads after the message is sent, one could include part of another pad, and then continue it through the next messages. If each of the pads is the same length, it wouldn't need a terminating sequence after the end of the pad. Just at the end of the compressed message.
If you've been in contact with someone, just give them a set of decryption keys for one-time pads. Then, for the last one, send another batch. For the encryption/decryption for each one, you could use a true random number generator (at least one company makes them (I don't have a link, but maybe someone could post one . . . ?), but they're expensive (in the $15,000+ range, IIRC)) and feed the output into a key generator. Then you've got something that would probably be as useful as quantum crypto, as long as it's only used once. Of course, I'm not a crypto expert, but maybe someone could give me some insight on this?
A submission to the patent office has finally been cleared.
A Slashdot user known only as "Anonymous Coward" has pattented the process of posting a comment earning a rating of "Troll".
Explaining his/her application, he/she said: "I'm tired of other Slashdot users infringing on my intellectual property. Now, if other people want to post trolls, I'll at least be compensated for my hard work popularizing . . . I mean "inventing" . . . trolls."
OK. So what do you do if you get a cracker? Do you prosecute or do you just record data? If you do prosecute, does it depend on intent (just port sniffing (and maybe letting the sysadmin know of a security flaw), attempted breakin, successful breaking, 0wn1n9 the box, etc.)? I personally think that white hat crackers (say, just portsniffing letting the sysadmin know about security flaws) and some grey hats (maybe breaking in and then fixing some security flaws and then e-mailing the sysadmin) shouldn't be punished for just poking around (although the grey hat thing is iffy). Similarly, I think that black hats should be slapped down as quickly as possible. The best thing we can do is to stop the script kiddies as quickly as possible. If the honeynet data can be used for that, great. Otherwise, how is this any different than, say, reading a security bulletin?
So what? While it's cool that they're doing this (I love playing chess), I think it would have been better reported after it was over. Until then, there's nothing really to see here (unless you want to know what software will be competing). Just release the log of the games, including how long it took for each move. Then people can write progs to simulate the game.
Post the link to your web site. You'll get a good idea of how expensive it will be if it's ever successful. You'll know how much funding you'll need.
All you would have to do would be to have a seperate switched LAN with an extra NIC in each box hooked up to it. That's basically all this is, I think (I can't seem to find exact specs on it, though, so I could be wrong).
using standard cat5 cabling connecting the output from the server to a special input box that, apparently, you just connect a monitor, keyboard, and mouse into. I'm not sure how far cat5 can be strung without noticable/significant signal degredation, but it seems to me that this wouldn't be necessary.
You could do this yourself by just setting up either SSH or VNC (depending on how you manage the server; command line or GUI) on the server and connecting to it over a network. It would be cheaper (read: free), and you wouldn't have to worry about proprietary hardware breaking.
I don't follow BSD too closely, so I'm somewhat curious (if someone doesn't mind indulging my ignorance): I'm getting the impression from the other posts that, up to this point, the x86 architecture was the only one that supported SMP under BSD. Is that how it stands with BSD (plus the Alpha architecture now), or are there other architechtures it supports SMP on?
Well, since the DMCA doesn't even require encryption (just "scrambling"), you could just swap every two letters for the filename.
Or, if you want to go with the encrypted filenames, modify an open-source Napster client to have an option to encrypt the filename search submission according to those guidelines before it's sent (maybe with a possible user-defined encryption scheme). Then the Napster servers could just use the existing search code.
So people can encrypt the MP3s with a decryption key of, say, their usernames. I doubt that encrypted binaries would be blocked by the filters. Could they really fingerprint *every* possible encryption of an MP3? I doubt it.
Uh, oh. I've got a 700 MHz Athlon in an SD11 (I hate that mobo). I'll try to get a copy of Mandrake 8.0 (final release) soon and post my results, but it would help if there were faster mirrors . . . :^(
> it notes all your hardware and creates a unique "id" that has to have a matching unique "password" to unlock the software
Yes, and (for the Windows student version, anyway), it's also tied to your partition table. I resized my Windows box (where my student copy of Mathematica resides) once with fips, so I could install a copy of Linux, and when I tried to run Mathematica again, it told me it had an invalid key, and that I had two weeks to get a valid one before it stopped working. I had to request another one (on the plus side, they were quite prompt about it).
AFAIK, that was never ratified/accepted by the U.N. (although I'm not entirely sure on that).
> Any threat or use of force or any other hostile act or threat of hostile act on the moon is prohibited. It is likewise prohibited to use the moon in order to commit any such act or to engage in any such threat in relation to the earth.
Hmmm. Glad they thought of everything.
BTW, the moon is owned by the Lunar Embassy.
This will have one of two effects (unless I'm forgetting something). Sony will either:
1. Rewrite VGS so as to optimize the subroutines and maximize compatibility (which then would be something I'd pay for)
or
2. Kill it off after June 30 (per the acquisition agreement) and hope people forget about it.
Personally, I don't really see any benefit for Sony to kill off the emulation project. Sony can't be making much money, if any, on their console sales. Because they would be increasing the potential market for their real cash cow (software; i.e. games), they can only stand to gain from improving the software.
This does raise an interesting question, however. How will this affect other PSX emulation projects? Will Sony try to kill them off because then they *would* then be infringing on Sony's business, will they be acquired also, or will they be suffocated and die (the commercial ones, anyway; the others are labors of love)?
As far as I'm concerned, if you wrote the program yourself, you probably understand the principles behind the formula, so why not? Be careful, though. Some teachers are very picky about decimal approximations vs. the actual value. (1.41421 vs. Sqrt[2]) Frankly, though, I'd advise working them out. After you do enough, you don't need to work them out anymore. You can just do them in your head. It takes practice, true, but it's worth it if you use a formula a lot. I did that with the quadratic formula and your basic derrivatives and integrals. Now it takes me about 3-5 seconds to figure quadratic roots/etc. out. That vs. loading a program (I also wrote one to compute quadratic roots), which takes about 10-15 seconds or longer on my TI-83 (punching keys).