Even if this craft can reach speeds of 10% the speed of light we would still be limited to interplanetary exploration and exploitation (human nature dictates this). As far as interstellar travel goes it would still take about 45 years to send a spacecraft to the nearest star, not to mention the 4.5 year transmission delay.
That's not am impossible obstacle. If the will was there, we could colonize the galaxy with current technology.
This was -2G; I should have clarified that I meant linux-the-kernel. With 3G I find it doesn't break, but it does frequently refuse to write - when I'm trying to copy a 26 episode series over to windows I end up scattering episodes all over the filesystem.
Truecrypt is cross-platform, Truecrypt volumes work in both Linux and Windows. Truecrypt is pretty much the ONLY encryption tool I've found that is cross-platform. In Linux it's a bit of a PITA, but it's worth it (for me anyway).
I use LUKS partitions and use FreeOTFE to mount them in windows.
I made my Truecrypt volumes truly cross-platform by installing NTFS support in the kernel. I can take my data drives and move them completely unchanged between my Linux and Windows boxes which is teh awesome.
The NTFS write support in linux is unreliable (I've had it break a partition before); you're better off using ext2 and installing an ext2 driver for windows (though fscking after a crash is a pain). Or, if it's small enough for windows scandisk to work, fat32.
Please, tell me how you can lob a piece of material through a target at 100 yards more efficiently? And no, you can't use uber coil gun designs which haven't been invented yet either. Crossbows, perhaps?
Sure, crossbow is a perfectly good example - it's an equally or if anything more skilled sport. Or, yes, lasers, or rubber pellet guns. Sure, it would be a different sport - with the different projectile weapons you have less range and more effect from wind, while the opposite is true when using lasers. But there's no objective reason to prefer actual guns to any of the others, and guns were not designed to make target shooting interesting - rather the other way around.
What if I were to declare that PGP's primary purpose is to hide criminal activity? It certainly can be used for such. Many people in law enforcement would agree. Maybe you simply use PGP to secure your personal or business data, but that's just you.
Your declaring doesn't make it so; look at who invented it (PRZ is not notably a criminal, nor known to be working for any criminal organization), why it was developed, what the first things it were used for were, and what its featureset suggests its uses are (e.g. ADKs wouldn't be useful for criminals).
I don't see how anything can be dubbed as having it's "primary purpose" as "killing eople" when the vast majority of this item is NEVER used to do so (nor are many marketed to do so
While it's not what it's primarily used for, it's what it's designed for, and what makes it useful rather than other things. Animals I'll give you, but the target-type stuff could all be done just as well with any number of other weapon designs - it's designed so that you can use guns for it, rather than the other way around.
This is completely ignoring the fact that defensive use, though it DOES necessitate incapacitating someone (normally through killing), is hard to argue against being a legitimate use.
The defensive use is not a distinct use of the gun - it's impossible to design a gun that's going to be more or less effective when being used defensively. Defensive use (by which I mean "defence through killing your opponent", rather than e.g. parrying with a sword) of any weapon is a legitimate use for a generally illegitimate action. Sure, there are times when it's legitimate to kill someone, but for any generally illegitimate action one can contrive a situation where it would be justified.
Really? I own tons of guns. I use them all the time. I do nothing illegal with them. I know many other people who own guns, and again, they do nothing illegal with them. The primary purpose of guns for everyone I know is hunting, with target shooting being secondary.
That may be what those particular people use them for, but the primary purpose of guns remains killing people.
Just as with PGP, the VAST majority of gun owners are users are law abiding citizens doing NOTHING wrong. For something with no "legitimate use" they certainly do get legitimately used a lot.
I never said they had no legitimate use, just that their primary purpose is not legitimate.
Of course one loses something; the question is whether it's worthwhile. As I see it it's worth keeping PGP legal because PGP's primary purpose is a legitimate one, wheras that of guns is not.
To put it into Slashdot terms: it would be like the government outlawing encryption to prevent terrorists from communicating. If they're talking about blowing up a building do you really think they are afraid to have a copy of PGP installed on their computer? Nope. All outlawing encryption does is take it away from the people who were originally using it for non-illegal purposes, or make criminals out of those who refuse to give it up even if their original actions were perfectly legal. Same applies to guns.
Look at China. Sure, the terrorists aren't be afraid to have PGP installed - but it means they'll be dragged off to the gulags before they get anywhere. Making guns illegal does prevent crime, because anyone with a gun can be arrested for that before they do anything with it.
In a year's time, DDR3 will have totally supplanted DDR2.
Well yes, but who cares right now? My system still uses AGP - even though I knew it was "obsolete" when I built the system (2 years ago), it had the right price/performance at the time, and by the time I need a better video card I will also need a new CPU, a new motherboard to accommodate it, and much more memory - so it's going to be easier to build a new system. It was the right decision at the time, and I don't regret it one bit. It's the same situation here - sure, the future may be DDR3, but if you're building a system *now*, is it worth it? It's a reasonable question to ask, and I can well believe that the answer might be "no".
You have a super-server that validates the servers. You don't give out the source code to the server, and the server contains internal checks to assure it has not been tampered with.
If you're not open-sourcing the server, how will GPLv3ing the client prevent you from doing this anyway?
Not true. You can encrypt the packets and bury the encryption algorithm in your client, whose source code you do not give out.
Which will fail, because there's no such thing as a secure closed-source encryption algorithm. And again, if you're not open sourcing the client, GPLv3 is utterly irrelevant.
Of course, these techniques don't always work, but unfortunately, that's all we have for now. There are games that use untrusted servers and client encryption in just this way, and they are the best solution we have.
I agree that it would be better if we had a better solution, but we don't. If you know, one, please share it with the class.
A better solution would be to accept that there will be cheaters, as there have been in every popular online FPS, and devote the saved effort to your "social" rankings and matchmaking system so that an ID is valuable and people don't want to risk being found out as cheaters. Trying to stop the cheaters through technical measures is a losing proposition, because it's never going to be possible to do effectively - the data *has* to go to the client, and the client *has* to be able to decode it - which means with enough effort the player can, too - and once one person's worked out how to do it, anyone who wants to can find out.
1) Who says there's a server? Are you just going to reject peer-to-peer gaming?
In a peer-to-peer mechanism, either there is a server behind the scenes, or all the clients run the sim; in the latter case, if one disagrees with the rest, it can be "outvoted" by the others.
Who says the server is trusted?
It's pretty damn hard to avoid having to trust the server; how would you do so?
2) For poker, you can make the client just the user's agent, but for almost any other game, it's impractical to design a client this way. For one thing, it means the client always has to go to the server before it can present the user with any information that becomes available to the user as a result of a decision the user makes. This increases latency dramatically and would make most first-person shooters unplayable across the Internet.
Imagine if you're turning (or even walking forward) in an FPS -- every frame contains new information you are not supposed to have until that frame is rendered. Are you suggesting a 60 frame per second game should be receiving 60 packets per second with the new data in each frame?
No, but if you don't do that, the players can still use a network sniffer to find out the information that the server has sent but they shouldn't be seeing yet, so you're not actually any better off with your "verified" client.
I mean, the Linux kernel is *STILL* released under GPL V2, or during my trip to Mars something changed, and now it has a Microsoft EULA attached?
Yes, but Linus has demonstrated that he doesn't particularly care about the freedom part, and if and when he thinks an MS EULA is the right thing to do from a technical/uptake standpoint he will go for it.
Until last (boreal) spring, GPL V2 wasn't the best, "freest" license around, according to RMS and FSF themselves?
Actually, no. They said repeatedly and publicly that they thought the patent provisions in the APL, CDDL and EPL were a good idea and something they were going to add to the next version of the GPL.
but also means that the replacement must be able to appear on the gaming network exactly as unmodified software would. The user running modified software can't even be flagged as such,
Of course you can flag them, in the same way that Red Hat don't have to allow you to sign your own RPMs with their keys, they just have to let you allow it to accept your own keys. Use some public-key scheme whereby the builds are digitally signed, and ship the clients with your own public keys for "Gaming, Inc." You don't have to turn over the private key; what you do is make sure I can generate my own keys for "m50d's builds for OpenVMS" or whatever, and server owners can add those keys if they're happy that those clients are legitimate. You could even resign such builds with your own keys if you've happy with them. This would work better, because it would mean legitimate modified clients would still be allowed.
Of course, such methods can't prevent cheating because you're always relying on the client self-reporting, but GPLv3 doesn't stop you from trying.
Is this not contrary to ODF proponents' claim that ODF is equally suitable for all word processors and spreadsheets to implement? That it doesn't favor any particular spreadsheet implementation (i.e. OO.o) over any other? That it was built from the ground up to be app-neutral, and that this is app-neutrality is a virtue that OOXML lacks (since OOXML of course favors MS Office)?
That claim is bollocks, and always will be for a standard written as the standard for a single application; look at the trouble KSpread has had with ODF as well. However, it is at least *possible* to implement ODF completely in applications other than OOo, which doesn't look to be the case for OOXML.
Second, if you've computed all possible hash values for all possible character combinations, then it really doesn't matter what your password is, since you only have to have the input hash to the correct hash value. Since an infinite number of character strings map to a finite number of hash values, it is only a matter of building the tables before you can hack any system.
If passwords are salted, then you need to build tables for all possible salts as well as all character combinations, i.e. 2^128 times as much data, or more than 10^39 bytes.
Slashdot Mirror
The manufacturer saves money by only offering the one OS configuration
Erm, what? Because it's impossible for a woman to rape a man? (Hint: it's not)
That's not am impossible obstacle. If the will was there, we could colonize the galaxy with current technology.
This was -2G; I should have clarified that I meant linux-the-kernel. With 3G I find it doesn't break, but it does frequently refuse to write - when I'm trying to copy a 26 episode series over to windows I end up scattering episodes all over the filesystem.
I use LUKS partitions and use FreeOTFE to mount them in windows.
I made my Truecrypt volumes truly cross-platform by installing NTFS support in the kernel. I can take my data drives and move them completely unchanged between my Linux and Windows boxes which is teh awesome.
The NTFS write support in linux is unreliable (I've had it break a partition before); you're better off using ext2 and installing an ext2 driver for windows (though fscking after a crash is a pain). Or, if it's small enough for windows scandisk to work, fat32.
Sure, crossbow is a perfectly good example - it's an equally or if anything more skilled sport. Or, yes, lasers, or rubber pellet guns. Sure, it would be a different sport - with the different projectile weapons you have less range and more effect from wind, while the opposite is true when using lasers. But there's no objective reason to prefer actual guns to any of the others, and guns were not designed to make target shooting interesting - rather the other way around.
Your declaring doesn't make it so; look at who invented it (PRZ is not notably a criminal, nor known to be working for any criminal organization), why it was developed, what the first things it were used for were, and what its featureset suggests its uses are (e.g. ADKs wouldn't be useful for criminals).
While it's not what it's primarily used for, it's what it's designed for, and what makes it useful rather than other things. Animals I'll give you, but the target-type stuff could all be done just as well with any number of other weapon designs - it's designed so that you can use guns for it, rather than the other way around.
This is completely ignoring the fact that defensive use, though it DOES necessitate incapacitating someone (normally through killing), is hard to argue against being a legitimate use.
The defensive use is not a distinct use of the gun - it's impossible to design a gun that's going to be more or less effective when being used defensively. Defensive use (by which I mean "defence through killing your opponent", rather than e.g. parrying with a sword) of any weapon is a legitimate use for a generally illegitimate action. Sure, there are times when it's legitimate to kill someone, but for any generally illegitimate action one can contrive a situation where it would be justified.
That may be what those particular people use them for, but the primary purpose of guns remains killing people.
Just as with PGP, the VAST majority of gun owners are users are law abiding citizens doing NOTHING wrong. For something with no "legitimate use" they certainly do get legitimately used a lot.
I never said they had no legitimate use, just that their primary purpose is not legitimate.
Of course one loses something; the question is whether it's worthwhile. As I see it it's worth keeping PGP legal because PGP's primary purpose is a legitimate one, wheras that of guns is not.
Searches of people who are acting suspiciously, like we already have.
I never claimed it could be; I just said that the linux kernel is not a good or fair test of a C compiler. Are you disputing that?
Look at China. Sure, the terrorists aren't be afraid to have PGP installed - but it means they'll be dragged off to the gulags before they get anywhere. Making guns illegal does prevent crime, because anyone with a gun can be arrested for that before they do anything with it.
Then run GNU/kFreeBSD. Or, as others have said, opensolaris.
That's not a good test, given that Linux depends on gcc-isms. It's not written in any standardised form of C, which would be a far fairer test.
If you think that you've clearly never tried to get specs out of a hardware manufacturer.
Well yes, but who cares right now? My system still uses AGP - even though I knew it was "obsolete" when I built the system (2 years ago), it had the right price/performance at the time, and by the time I need a better video card I will also need a new CPU, a new motherboard to accommodate it, and much more memory - so it's going to be easier to build a new system. It was the right decision at the time, and I don't regret it one bit. It's the same situation here - sure, the future may be DDR3, but if you're building a system *now*, is it worth it? It's a reasonable question to ask, and I can well believe that the answer might be "no".
The same reason as windows: hardware support.
If you're not open-sourcing the server, how will GPLv3ing the client prevent you from doing this anyway?
Not true. You can encrypt the packets and bury the encryption algorithm in your client, whose source code you do not give out.
Which will fail, because there's no such thing as a secure closed-source encryption algorithm. And again, if you're not open sourcing the client, GPLv3 is utterly irrelevant.
Of course, these techniques don't always work, but unfortunately, that's all we have for now. There are games that use untrusted servers and client encryption in just this way, and they are the best solution we have.
I agree that it would be better if we had a better solution, but we don't. If you know, one, please share it with the class.
A better solution would be to accept that there will be cheaters, as there have been in every popular online FPS, and devote the saved effort to your "social" rankings and matchmaking system so that an ID is valuable and people don't want to risk being found out as cheaters. Trying to stop the cheaters through technical measures is a losing proposition, because it's never going to be possible to do effectively - the data *has* to go to the client, and the client *has* to be able to decode it - which means with enough effort the player can, too - and once one person's worked out how to do it, anyone who wants to can find out.
In a peer-to-peer mechanism, either there is a server behind the scenes, or all the clients run the sim; in the latter case, if one disagrees with the rest, it can be "outvoted" by the others.
Who says the server is trusted?
It's pretty damn hard to avoid having to trust the server; how would you do so?
2) For poker, you can make the client just the user's agent, but for almost any other game, it's impractical to design a client this way. For one thing, it means the client always has to go to the server before it can present the user with any information that becomes available to the user as a result of a decision the user makes. This increases latency dramatically and would make most first-person shooters unplayable across the Internet.
Imagine if you're turning (or even walking forward) in an FPS -- every frame contains new information you are not supposed to have until that frame is rendered. Are you suggesting a 60 frame per second game should be receiving 60 packets per second with the new data in each frame?
No, but if you don't do that, the players can still use a network sniffer to find out the information that the server has sent but they shouldn't be seeing yet, so you're not actually any better off with your "verified" client.
Yes, but Linus has demonstrated that he doesn't particularly care about the freedom part, and if and when he thinks an MS EULA is the right thing to do from a technical/uptake standpoint he will go for it.
Until last (boreal) spring, GPL V2 wasn't the best, "freest" license around, according to RMS and FSF themselves?
Actually, no. They said repeatedly and publicly that they thought the patent provisions in the APL, CDDL and EPL were a good idea and something they were going to add to the next version of the GPL.
Of course you can flag them, in the same way that Red Hat don't have to allow you to sign your own RPMs with their keys, they just have to let you allow it to accept your own keys. Use some public-key scheme whereby the builds are digitally signed, and ship the clients with your own public keys for "Gaming, Inc." You don't have to turn over the private key; what you do is make sure I can generate my own keys for "m50d's builds for OpenVMS" or whatever, and server owners can add those keys if they're happy that those clients are legitimate. You could even resign such builds with your own keys if you've happy with them. This would work better, because it would mean legitimate modified clients would still be allowed.
Of course, such methods can't prevent cheating because you're always relying on the client self-reporting, but GPLv3 doesn't stop you from trying.
Surely most of the potential switchers from firefox to safari would have already switched to opera, no?
That claim is bollocks, and always will be for a standard written as the standard for a single application; look at the trouble KSpread has had with ODF as well. However, it is at least *possible* to implement ODF completely in applications other than OOo, which doesn't look to be the case for OOXML.
If passwords are salted, then you need to build tables for all possible salts as well as all character combinations, i.e. 2^128 times as much data, or more than 10^39 bytes.