If YOU were the copyright holder why would YOU need to abide by these terms?
You wouldn't, as long as you don't mind having to do all the development work yourself, rather than working with a community of developers. As soon as you merge other people's patches, you're bound by the terms of the license.
In GPLv2 (perhaps not GPLv3) you can have the program open source, but keep the build scripts to yourself.
I'm glad you took the time to read the GPL before commenting:
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.
Embedded in the virus is an encrypted IP address belonging to a server in China which is believed to be a C+C server.
Not only does it misuse the term "virus", as you mentioned, but it also misuses the term "encrypted". The correct term here is "obfuscated". The obfuscation code might happen to contain something that looks very similar to AES, but it isn't encryption (and it certainly isn't AES) if the "key" can just be recovered from the executable.
It's been mentioned several times in discussions, but I don't have a great citation (probably because it's in Swedish and I don't understand Swedish). There's some mention of it in the Wikipedia article about Remand (Häktning).
Maybe the prices charged by doctors/hospitals/etc will go down (or at least not go up as quickly). Every time there's a medical bankruptcy, they don't get fully paid, so they have to factor that into their prices.
Not being familiar with the Amiga OS at all, could you explain what made it so good?
It was a bit like having a Pentium machine running Windows 95, with hardware-accelerated video and sound, but it was elegant and---probably most importantly---it was released 10 years earlier. It also happened to be able to be synchronized to an incoming NTSC/PAL signal, so it gave you a lot of interesting video production features an order of magnitude cheaper than the alternatives.
Imagine what it would be like if you had an iPad when the original BlackBerry was first released. That's what it was like to have an Amiga back then.
I'm guessing the only software fix here would be that if the software in question can detect that it's running on Intel, rather than AMD CPUs, it needs to substitute SYSENTER for SYSCALL and SYSEXIT for SYSRET, and run, until Intel fixes it in its next CPU spin.
The only software fix? That's rather complicated. All you need to do is to check if rcx is non-canonical and invoke IRET instead of SYSEXIT if it isn't, which is what Linux already does. Of course, you shouldn't *have* to do this, which is why it's a bug.
It is arguable whether it is a CPU bug or an OS/hypervisor bug. The CPU should not run the fault code with privileges, but on the other hand the OS should prevent the fault code from being called in the first place.
I think it's only arguable inside Intel's reality-distortion field. The whole point of SYSCALL/SYSRET is to create a *fast* syscall path. Requiring extra code before *every* SYSRET in order to prevent it from overwriting arbitrary memory is pretty clearly a design flaw in Intel's specification, especially since (as TFA notes) that specification was intended to be compatible with AMD's specification.
It's totally different.// Doesn't actually know if it's different
Heh. It's the same thing, as far as I can tell. The title of the 2005 paper linked by the old Slashdot article was: "Totally Secure Classical Communication Utilizing Johnson (-like) Noise and Kirchoff's Law".
I think all of these physical "crypto"systems are snake oil. They claim to be unbreakable, but in reality, they're physical systems subject to the same engineering challenges (such as manufacturing tolerances) as any other system. I would never use one of these systems instead of, say, a point-to-point SSH tunnel, and I'm not sure that the added security (if any) justifies the cost, when a simple, authenticated Diffie-Hellman key exchange would do quite nicely.
The ITU shouldn't even be involved. X.500, ASN.1, OSI, and the rest of their ilk are proof enough that telco organizations are simply not capable of engineering good networks.
This is a matter of priorities -- do we want to protect dissidents, or do we want to make futile attempts to prevent child abuse images from being shared?
I'm not fond of the GPL in the context of GPLv3, since v3 tries to assert rights that make it legally impossible to use in a business.
Untrue.
The grey area comes from GPL programs that create content (eg the GCC compiler, Gimp, Inkscape, and various other content creation tools) since in a legal context there is no difference between source code and content when it comes to copyright.
Untrue.
So oddly, enough the reason you can't get people to use the Gimp, or Inkscape over photoshop and illustrator.
Untrue.
the GPL licence requires them to release their original files if it was created in the program.
Is that the same kind of oxymoron as the 'relative stability' of bitcoins?
Bitcoins *have* had an unprecedentedly stable price of approximately $5 since March 2012. This is more-or-less what we should expect, given that they've followed the standard Gartner hype cycle for emerging technologies pretty closely so far.
Stable...and much, much lower. That is why most of these people will be unhappy: they bought into the Bitcoin system late in the game, and are going to see the value of their Bitcoins decline substantially.
The speculators who hoarded Bitcoins will be, but it won't make a difference for most people. If you want to send me $100 using Bitcoins, it doesn't matter whether they're worth $5, $0.05, or $500 apiece. As long as the price doesn't fluctuate too much between the time you buy $100 worth of bitcoins, and the time I convert them into about $100 worth of my local currency, then Bitcoin remains useful, and I haven't had to deal with PayPal, Western Union, or long bank transfer delays.
Way to destroy the pace of innovation in that area, then. Pretty much everyone who used Bitcoinica knew it was risky, especially after the first break-in. Heck, the nature of Bitcoinica involved the possibility of losing all your money if the USD price of Bitcoins moved too much against your position.
Slashdot Mirror
If YOU were the copyright holder why would YOU need to abide by these terms?
You wouldn't, as long as you don't mind having to do all the development work yourself, rather than working with a community of developers. As soon as you merge other people's patches, you're bound by the terms of the license.
In GPLv2 (perhaps not GPLv3) you can have the program open source, but keep the build scripts to yourself.
I'm glad you took the time to read the GPL before commenting:
the /. editor is not doing his job, which makes the site a worse place to visit.
You must be new here.
Embedded in the virus is an encrypted IP address belonging to a server in China which is believed to be a C+C server.
Not only does it misuse the term "virus", as you mentioned, but it also misuses the term "encrypted". The correct term here is "obfuscated". The obfuscation code might happen to contain something that looks very similar to AES, but it isn't encryption (and it certainly isn't AES) if the "key" can just be recovered from the executable.
It's been mentioned several times in discussions, but I don't have a great citation (probably because it's in Swedish and I don't understand Swedish). There's some mention of it in the Wikipedia article about Remand (Häktning).
In Sweden, you can't be charged until you've been questioned. So he's not really wanted for questioning, he's wanted for "questioning".
Health insurance isn't a scarce resource.
Maybe the prices charged by doctors/hospitals/etc will go down (or at least not go up as quickly). Every time there's a medical bankruptcy, they don't get fully paid, so they have to factor that into their prices.
Not being familiar with the Amiga OS at all, could you explain what made it so good?
It was a bit like having a Pentium machine running Windows 95, with hardware-accelerated video and sound, but it was elegant and---probably most importantly---it was released 10 years earlier. It also happened to be able to be synchronized to an incoming NTSC/PAL signal, so it gave you a lot of interesting video production features an order of magnitude cheaper than the alternatives.
Imagine what it would be like if you had an iPad when the original BlackBerry was first released. That's what it was like to have an Amiga back then.
I'm guessing the only software fix here would be that if the software in question can detect that it's running on Intel, rather than AMD CPUs, it needs to substitute SYSENTER for SYSCALL and SYSEXIT for SYSRET, and run, until Intel fixes it in its next CPU spin.
The only software fix? That's rather complicated. All you need to do is to check if rcx is non-canonical and invoke IRET instead of SYSEXIT if it isn't, which is what Linux already does. Of course, you shouldn't *have* to do this, which is why it's a bug.
It is arguable whether it is a CPU bug or an OS/hypervisor bug. The CPU should not run the fault code with privileges, but on the other hand the OS should prevent the fault code from being called in the first place.
I think it's only arguable inside Intel's reality-distortion field. The whole point of SYSCALL/SYSRET is to create a *fast* syscall path. Requiring extra code before *every* SYSRET in order to prevent it from overwriting arbitrary memory is pretty clearly a design flaw in Intel's specification, especially since (as TFA notes) that specification was intended to be compatible with AMD's specification.
It's not a dupe, that one was based on Kichoffs's Law. This one is based on Johnson-Nyquist noise.
It's totally different. // Doesn't actually know if it's different
Heh. It's the same thing, as far as I can tell. The title of the 2005 paper linked by the old Slashdot article was: "Totally Secure Classical Communication Utilizing Johnson (-like) Noise and Kirchoff's Law".
I think all of these physical "crypto"systems are snake oil. They claim to be unbreakable, but in reality, they're physical systems subject to the same engineering challenges (such as manufacturing tolerances) as any other system. I would never use one of these systems instead of, say, a point-to-point SSH tunnel, and I'm not sure that the added security (if any) justifies the cost, when a simple, authenticated Diffie-Hellman key exchange would do quite nicely.
I remember when this was posted on Slashdot 7 years ago.
I'm a rightsholder, too. Copyrights, even. It's not to my chagrin.
Shush now.
...
The predominant use of freenet was untraceable child porn last time I looked.
Really? How did you determine that? Do you think the dissidents using it make their Freenet URLs public?
And crime is not the issue. Unlike you, I don't confuse morality and legality.
What are you talking about?
The ITU shouldn't even be involved. X.500, ASN.1, OSI, and the rest of their ilk are proof enough that telco organizations are simply not capable of engineering good networks.
This is a matter of priorities -- do we want to protect dissidents, or do we want to make futile attempts to prevent child abuse images from being shared?
FTFY.
Child porn is the reason I can't in good conscience run a telephone network.
Child porn is the reason I can't in good conscience run an ISP.
Child porn is the reason I can't in good conscience run a shipping company.
Child porn is the reason I can't in good conscience run a camera company.
Your conscience needs adjustment. Every sufficiently useful and/or popular tool will be used for crime at some point.
Maybe it's something that Ubuntu did to it, but I ran Kubuntu Netbook Edition on my netbook, and it was unusably slow.
I'm not fond of the GPL in the context of GPLv3, since v3 tries to assert rights that make it legally impossible to use in a business.
Untrue.
The grey area comes from GPL programs that create content (eg the GCC compiler, Gimp, Inkscape, and various other content creation tools) since in a legal context there is no difference between source code and content when it comes to copyright.
Untrue.
So oddly, enough the reason you can't get people to use the Gimp, or Inkscape over photoshop and illustrator.
Untrue.
the GPL licence requires them to release their original files if it was created in the program.
Untrue.
Maybe Chinese is his native language.
Is that the same kind of oxymoron as the 'relative stability' of bitcoins?
Bitcoins *have* had an unprecedentedly stable price of approximately $5 since March 2012. This is more-or-less what we should expect, given that they've followed the standard Gartner hype cycle for emerging technologies pretty closely so far.
Stable...and much, much lower. That is why most of these people will be unhappy: they bought into the Bitcoin system late in the game, and are going to see the value of their Bitcoins decline substantially.
The speculators who hoarded Bitcoins will be, but it won't make a difference for most people. If you want to send me $100 using Bitcoins, it doesn't matter whether they're worth $5, $0.05, or $500 apiece. As long as the price doesn't fluctuate too much between the time you buy $100 worth of bitcoins, and the time I convert them into about $100 worth of my local currency, then Bitcoin remains useful, and I haven't had to deal with PayPal, Western Union, or long bank transfer delays.
How is this not already handled by tort law?
Way to destroy the pace of innovation in that area, then. Pretty much everyone who used Bitcoinica knew it was risky, especially after the first break-in. Heck, the nature of Bitcoinica involved the possibility of losing all your money if the USD price of Bitcoins moved too much against your position.