Or perhaps the lead (only?) programmer for Braid: http://braid-game.com/news/?p=364 (I think there was another post saying "Screw this, it's not coming out for Linux," but that might just be at the end of the comments)
Can we all laugh in Ubisoft's face yet? Too soon? Too late?
Companies put all this time and money into DRM. Have they yet shown that the money they spend outweighs the money they lose from piracy? It seems like this DRM scheme is particularly bad as it actually INCREASES the piracy and DECREASES the legitimate customers--the exact opposite of the intent. Sure, if there's no DRM, it might have even worse actual sales, but then again, it might not. Even if it does have worse sales...are they losing more money than they would have spent on the DRM? It's hard to say, or even to do a study on this.
I commend StarDock for their anti-DRM attitude and manifesto, although I have seen their stuff on pirate sites. I have a friend who pirated an indie game a few weeks back, and I really hate that more than pirating a game by a large company (say, EA or Ubisoft). His reasoning was "I'll play it once for not very much time. It's not worth that money." I've seen other arguments, "Well I wouldn't buy it anyway, so they're not losing money." Is this really the selfish culture we've become? If it costs money and you're not going to pay for it, you shouldn't get to use it. That's kind of the way capitalism works. It's not about your impact on their sales, it's about exchange of goods. I'm not 100% pure, myself, having a fair amount of pirated music, and some pirated video games (all of which are pretty old and no longer published at this point), but at least I don't regard the idea of piracy as justifiable a lot of the time...
I find the way Steam handles DRM the least draconic of any DRM and am actually fairly okay with it. You can buy it and link it up to Steam. Steam needs to be online, sure, although there is an offline mode. I'm fairly certain that Valve has stated that if they were to bring Steam offline forever, they would provide a way of unlocking the games, and I don't really doubt this. This is a sane way to provide DRM, so long as you follow through with your promise.
AMD released on Monday its 12-core chip code-named Magny-Cours
Very clever, AMD. Naming your chip after a location in Europe as usual, but this time making it able to be read as "Many-Cores" (or possibly more accurately "Many-Core", I don't really know how to pronounce French words). Very clever indeed...
I'd make a joke about how the internet can now handle the flow of porn through it, but I'm sure that with one of these routers, I've already been beaten to the punch!
LZW isn't that bad. And mostly, I just needed to know what it did WRONG, not how to do it RIGHT. I'd already learned how LZSS worked the previous year...for an also ambitious project that never really saw the light of day. Reverse engineering a compression format through raw tinkering and seeing how outputs changed was a lot of fun^H^H^Htedium. It helped that I had a lead that it was probably some derivative of LZ77.
Okay yeah I might have spent a lot of time on nothing substantial during this, but it did yield a security patch, which is a good thing. And besides, I was on winter break from college. It's a good time for doing nothing substantial.
Actually, I personally found and patched the TIFF bug. In January. Of last year. http://bugzilla.maptools.org/show_bug.cgi?id=1985 Feeding random data (aka fuzzing) might work, but 99% of the time, I'd imagine it'd just give you a corrupted image and bail out. You have to be clever about how you search for it. I found a known vulnerability patch posted by, of all people, an Apple employee, and tried to reverse engineer what he'd fixed. I found that the patch hadn't been applied on old version of the PSP system software, which is what I was targeting. After messing with this specific attack vector, I noticed that I could still crash system software version that did have the patch. After reading up on LZW compression (which is what part of LibTIFF had the vulnerability) and the TIFF specification of how they implemented LZW, I realized that the Apple patch was incomplete--it only tested for one value you could give it that was erroneous. By simply changing the equality they used (in two places) to an inequality, I tested for all erroneous values. Meanwhile, I tried to exploit the new unpatched vector on the PSP so that I could inject code. Failing this, I decided the best course of action was to submit a bug report to LibTIFF. It might seem a tad unethical to try and exploit the bug before reporting it, but I wasn't trying to exploit in for malicious purposes, and not on a desktop operating system. Regardless, I failed to make it do more than crash the PSP. Surely the best course of action here would be to patch it upstream before anyone else found it. (Incidentally, this "arbitrary execution" this is blown out of proportion. In its current state, it is extremely unlikely that it could provide ANY code execution. Just crashing. Although I don't know if it's IMPOSSIBLE for it to execute code with this vulnerability, it would take a lot of work to get anything valuable out of this. Mostly it's a DoS. They usually just attach "arbitrary execution" when there's even the vaguest possibility for code to be executed, regardless of whether or not such an exploit has been demonstrated.)
It, um, took a while for anyone to notice the patch. In fact, the only reason anyone did notice was because someone found some of the fruit of my research into this bug and then posted a link to the research in a new bug report. Funnily, they created a different patch, which, instead of preventing the infinite loop caused by the erroneous data, just tested to see if the loop was writing out of bounds. Perhaps both approaches should be used together. Defensive programming and all that. Regardless, I noticed this new bug report shortly afterward it was posted and pointed them back to the inexplicably ignored old bug report. Most Linux vendors applied the patch shortly after the new bug report was filed, but Apple lagged by a number of months, until 10.6.2 came out. This update backports the fix into 10.5.x. However, I've found that some projects (such as Qt) are still using ancient versions of LibTIFF that have had numerous bug and security fixes since they were last updated in the projects' trees. While Qt does try to use the system's version of Qt if it can, it's still kind of scary to think about what could happen if it falls back on its own version, as I've seen it do before when I try my "corrupted" TIFF on things like Arora.
Incidentally, I am TAing a computer security course this semester. I guess previous experience helps.
I never said it was right. They just did it. I'm on a Mac right now, and I switched it so that the F* keys are the F* keys again because the other way bothers me.
I also notice the Scroll Lock and Pause/Break keys are missing. I know you can use the Scroll Lock key in conjunction with Excel, but I'm not sure anyone else ever does. Although I have actually used it on the command line to, shock and awe, lock the screen from scrolling while it was booting up so I could see error messages before they disappeared into the dust.
Also, switching the F keys with the functionality usually relegated to Fn-F*, as mentioned in TFA, is nothing new. Apple has been doing that on their laptops for years.
That's basically what the Wii's Virtual Console is. Only caveat is that you have to have a Wii to play them. And, well, you're not SUPPOSED to be able to copy them, but there are hacks that let you.
This is my point. Ridiculously minute is a relative thing here. Sure, 100 billion is a big number. Sure, Avogadro's number is a LOT bigger. However, I don't imagine they'd be needing quite that many particles for what they're doing. But really, I don't know. I'm not a physicist, I'm just speculating. 100 billion seems like a lot of particles to be smashing together in a linear accelerator, though.
Re:Interesting Background Material
on
Robotic Mold
·
· Score: 5, Interesting
The plasmodium behind malaria is not the same kind of plasmodium. IIRC, malaria is caused by a sporozoan, which is completely different from a slime mould. In fact, plasmodium is not even a kind of slime mould. In reference to slime moulds, plasmodium is just the macroscopic form of any slime mould.
Judging from the labeling, those parts are from the first replica, which is in London. This is the second replica. I saw them operate this one, so I'd hope it's functional.
Although these photos don't include the functional replica of Babbage's Difference Engine #2 that's currently at the museum, and leaves in a few months. I was just at the museum two weeks ago. It was pretty interesting. There's also an exhibit about the history of chess computation. Apart from those two things though, most of the museum is a big room full of old computers. I wish there were more to see there, but what is there is pretty interesting. I recommend going before the Babbage Engine leaves in a few months if one gets a chance.
I hate to be the pedantic one to point this out, but this isn't ASCII. It might even be pushing it to call it ANSI, but it's certainly a closer classification. Looks more like CP 437 than anything else.
Golden Sun DS (not mentioned in TFS) is really what I'm most excited about. Golden Sun and its sequel for GBA were possibly my favorite RPG series for a long time. What a brilliant mixture of RPG gameplay with puzzle solving it was, with great graphics (for GBA) to boot! I've been waiting for a third for ages, as the second had a somewhat open ending.
Slashdot Mirror
Or perhaps the lead (only?) programmer for Braid: http://braid-game.com/news/?p=364
(I think there was another post saying "Screw this, it's not coming out for Linux," but that might just be at the end of the comments)
Can we all laugh in Ubisoft's face yet? Too soon? Too late?
Companies put all this time and money into DRM. Have they yet shown that the money they spend outweighs the money they lose from piracy? It seems like this DRM scheme is particularly bad as it actually INCREASES the piracy and DECREASES the legitimate customers--the exact opposite of the intent. Sure, if there's no DRM, it might have even worse actual sales, but then again, it might not. Even if it does have worse sales...are they losing more money than they would have spent on the DRM? It's hard to say, or even to do a study on this.
I commend StarDock for their anti-DRM attitude and manifesto, although I have seen their stuff on pirate sites. I have a friend who pirated an indie game a few weeks back, and I really hate that more than pirating a game by a large company (say, EA or Ubisoft). His reasoning was "I'll play it once for not very much time. It's not worth that money." I've seen other arguments, "Well I wouldn't buy it anyway, so they're not losing money." Is this really the selfish culture we've become? If it costs money and you're not going to pay for it, you shouldn't get to use it. That's kind of the way capitalism works. It's not about your impact on their sales, it's about exchange of goods. I'm not 100% pure, myself, having a fair amount of pirated music, and some pirated video games (all of which are pretty old and no longer published at this point), but at least I don't regard the idea of piracy as justifiable a lot of the time...
I find the way Steam handles DRM the least draconic of any DRM and am actually fairly okay with it. You can buy it and link it up to Steam. Steam needs to be online, sure, although there is an offline mode. I'm fairly certain that Valve has stated that if they were to bring Steam offline forever, they would provide a way of unlocking the games, and I don't really doubt this. This is a sane way to provide DRM, so long as you follow through with your promise.
Guess I was confusing it with Intel's naming scheme then. It seemed to fit anyway. The point about the "many-core" name stands, though.
It is occasions like this that I wish I could mod replies to one's comments +1, Informative.
Very clever, AMD. Naming your chip after a location in Europe as usual, but this time making it able to be read as "Many-Cores" (or possibly more accurately "Many-Core", I don't really know how to pronounce French words). Very clever indeed...
I look forward to the successor of the Nintendo 3DS: the Nintendo 3DS Max.
I'd make a joke about how the internet can now handle the flow of porn through it, but I'm sure that with one of these routers, I've already been beaten to the punch!
Cool, now Copernicus has an element named after him.
LZW isn't that bad. And mostly, I just needed to know what it did WRONG, not how to do it RIGHT. I'd already learned how LZSS worked the previous year...for an also ambitious project that never really saw the light of day. Reverse engineering a compression format through raw tinkering and seeing how outputs changed was a lot of fun^H^H^Htedium. It helped that I had a lead that it was probably some derivative of LZ77.
Okay yeah I might have spent a lot of time on nothing substantial during this, but it did yield a security patch, which is a good thing. And besides, I was on winter break from college. It's a good time for doing nothing substantial.
Actually, I personally found and patched the TIFF bug. In January. Of last year. http://bugzilla.maptools.org/show_bug.cgi?id=1985
Feeding random data (aka fuzzing) might work, but 99% of the time, I'd imagine it'd just give you a corrupted image and bail out. You have to be clever about how you search for it. I found a known vulnerability patch posted by, of all people, an Apple employee, and tried to reverse engineer what he'd fixed. I found that the patch hadn't been applied on old version of the PSP system software, which is what I was targeting. After messing with this specific attack vector, I noticed that I could still crash system software version that did have the patch. After reading up on LZW compression (which is what part of LibTIFF had the vulnerability) and the TIFF specification of how they implemented LZW, I realized that the Apple patch was incomplete--it only tested for one value you could give it that was erroneous. By simply changing the equality they used (in two places) to an inequality, I tested for all erroneous values. Meanwhile, I tried to exploit the new unpatched vector on the PSP so that I could inject code. Failing this, I decided the best course of action was to submit a bug report to LibTIFF. It might seem a tad unethical to try and exploit the bug before reporting it, but I wasn't trying to exploit in for malicious purposes, and not on a desktop operating system. Regardless, I failed to make it do more than crash the PSP. Surely the best course of action here would be to patch it upstream before anyone else found it. (Incidentally, this "arbitrary execution" this is blown out of proportion. In its current state, it is extremely unlikely that it could provide ANY code execution. Just crashing. Although I don't know if it's IMPOSSIBLE for it to execute code with this vulnerability, it would take a lot of work to get anything valuable out of this. Mostly it's a DoS. They usually just attach "arbitrary execution" when there's even the vaguest possibility for code to be executed, regardless of whether or not such an exploit has been demonstrated.)
It, um, took a while for anyone to notice the patch. In fact, the only reason anyone did notice was because someone found some of the fruit of my research into this bug and then posted a link to the research in a new bug report. Funnily, they created a different patch, which, instead of preventing the infinite loop caused by the erroneous data, just tested to see if the loop was writing out of bounds. Perhaps both approaches should be used together. Defensive programming and all that. Regardless, I noticed this new bug report shortly afterward it was posted and pointed them back to the inexplicably ignored old bug report. Most Linux vendors applied the patch shortly after the new bug report was filed, but Apple lagged by a number of months, until 10.6.2 came out. This update backports the fix into 10.5.x. However, I've found that some projects (such as Qt) are still using ancient versions of LibTIFF that have had numerous bug and security fixes since they were last updated in the projects' trees. While Qt does try to use the system's version of Qt if it can, it's still kind of scary to think about what could happen if it falls back on its own version, as I've seen it do before when I try my "corrupted" TIFF on things like Arora.
Incidentally, I am TAing a computer security course this semester. I guess previous experience helps.
I don't think you understand. If this is a 12, Disaster Area is somewhere hovering around a 400 or so.
Yeah, I use scroll-scroll with KVMs, but remember, this is a laptop. KVMs...are not typically used with laptops.
I never said it was right. They just did it. I'm on a Mac right now, and I switched it so that the F* keys are the F* keys again because the other way bothers me.
I also notice the Scroll Lock and Pause/Break keys are missing. I know you can use the Scroll Lock key in conjunction with Excel, but I'm not sure anyone else ever does. Although I have actually used it on the command line to, shock and awe, lock the screen from scrolling while it was booting up so I could see error messages before they disappeared into the dust.
Also, switching the F keys with the functionality usually relegated to Fn-F*, as mentioned in TFA, is nothing new. Apple has been doing that on their laptops for years.
That's basically what the Wii's Virtual Console is. Only caveat is that you have to have a Wii to play them. And, well, you're not SUPPOSED to be able to copy them, but there are hacks that let you.
Disregard the "Copyright Shogmaster 2007" and you still get a hoax that doesn't look believable.
This is my point. Ridiculously minute is a relative thing here. Sure, 100 billion is a big number. Sure, Avogadro's number is a LOT bigger. However, I don't imagine they'd be needing quite that many particles for what they're doing. But really, I don't know. I'm not a physicist, I'm just speculating. 100 billion seems like a lot of particles to be smashing together in a linear accelerator, though.
If you call hundreds of billions ridiculously minute, then maybe.
With a username like "celibate for life", they don't really have to invent anything to tell you're a virgin.
We won't: http://kerneltrap.org/mailarchive/linux-kernel/2008/7/15/2497614
The plasmodium behind malaria is not the same kind of plasmodium. IIRC, malaria is caused by a sporozoan, which is completely different from a slime mould. In fact, plasmodium is not even a kind of slime mould. In reference to slime moulds, plasmodium is just the macroscopic form of any slime mould.
Judging from the labeling, those parts are from the first replica, which is in London. This is the second replica. I saw them operate this one, so I'd hope it's functional.
Er, sorry, scratch that. There are a few photos of it. There was a repeat photo in the gallery and thought I had gone through all of the photos.
Although these photos don't include the functional replica of Babbage's Difference Engine #2 that's currently at the museum, and leaves in a few months. I was just at the museum two weeks ago. It was pretty interesting. There's also an exhibit about the history of chess computation. Apart from those two things though, most of the museum is a big room full of old computers. I wish there were more to see there, but what is there is pretty interesting. I recommend going before the Babbage Engine leaves in a few months if one gets a chance.
I hate to be the pedantic one to point this out, but this isn't ASCII. It might even be pushing it to call it ANSI, but it's certainly a closer classification. Looks more like CP 437 than anything else.
...anyone else remember ZZT? I do.
Golden Sun DS (not mentioned in TFS) is really what I'm most excited about. Golden Sun and its sequel for GBA were possibly my favorite RPG series for a long time. What a brilliant mixture of RPG gameplay with puzzle solving it was, with great graphics (for GBA) to boot! I've been waiting for a third for ages, as the second had a somewhat open ending.