I just wanted to say that it's also an interesting case from a security standpoint. Their method of having a hardcoded and difficult to change BIOS protecting the system via hard crypto was basically unbeatable for a while. But when one exploit was found in one version of their signed code, then the system was basically broken open then, and forever more. I think it showcases an important flaw with using public key type signatures on executable code when you have absolutely no way to revoke that signature. One mistake, and your security is history or can be made to be history. All the hacker must have is one way to get in, and then the company can't undo that way in, even when they fix the flaw.
There are people who've successfully hacked the Series 2 TiVos by replacing the BIOS with one that has the signature-check edited out, but that requires soldering, which is more than most TiVophiles are comfortable with.
If you really want to do it, then there is a way without soldering. It ain't exactly legal, but it works.
A quick explanation of the Tivo's protection methodology: -The hardcoded BIOS boots up and checks the kernel. It's looking for a signature on the kernel. Since we don't have Tivo's private key, we can't fake or recreate the kernel's signature. If the kernel signature is valid, it boots the kernel. -The kernel has a chunk of code that checks every file on the root partition. If it doesn't match, then the kernel replaces that file with the right one before continuing on. This pretty much eliminates changing any files on the drive.
And that's how it works. The BIOS protects the kernel, the kernel protects everything else.
The trick to fixing this is, ah ha, an exploit that they accidentally left in one particular BETA kernel which then made it out into the wild. The exploit was removed, but the kernel was already out there.
I believe it was the U5 kernel. Anyway, the exploit is that a BASH environment variable could be set in the boot options and the kernel didn't clear it before booting up the shell. So what you do to get in and actually trick out the kernel is as follows: - Use the BETA kernel. This kernel has protections, and so you have to have a correct filesystem for it to see. - Create the BASH env variable such that, when the shell starts, it mounts a new partition with a modified, and therefore unsigned, kernel on it, swaps the root partition out with another, and does a two card monte trick with the kernel. The two card monte trick is where the running kernel loads a module that actually replaces the entire kernel with another one and starts it up. Neat trick, actually. This swaps the unsigned kernel into the kernel space, and bypasses the BIOS check, because the BIOS check is already finished and done.
Then all you do is use a copy of the latest kernel, and modify it slightly to eliminate the initd check of the partition. Two card monte swaps the unsigned kernel in and it runs just fine now that the BIOS check isn't stopping it dead in it's tracks.
The beauty of this hack is that Tivo can't fix the problem without changing the code in the BIOS/PROM chip. The U5 kernel that actually has the flaw is signed. They can't unsign it. The boot code there has the public side of the keyset and will read that kernel as signed forever and ever and ever. The new kernel can't detect that it's been two card monte'd into memory. It could check it's own signature, but that's as easily disabled as the initd part of the kernel is disabled. So once you have a two card monte set up and running, you just need a few good partitions to set it up in and then you have to slightly reconfigure it whenever they release new code for the box (basically disabling the initd in the new kernel and setting the boot params back to the U5 kernel on your other partition), but other than that it's wide, wide open.
Now, this ain't exactly legal, as the U5 kernel is Tivo's code, not yours. Or maybe it is, as the thing is the linux kernel. It's GPL'd. I'm not sure about that, as they never released U5 to the public that I'm aware of. In any case, it works. Search around dealdatabase.com and you'll find it.
Well, from what they're saying on the page, it can take 1 to several minutes to transmit the data over. So I'm just going by that. In theory, with a hard drive and a 100mbit ethernet, then you're probably right. All I know is that the load time on my GC is very, very low for most things.
1. This exploit uses a bug in Phantasy Star Online and a GC ethernet adapter to load the games both to and from the GC. Thus using Nintendo's non-standard drive to read the game itself, and loading the game back in via ethernet instead of from a burned disc (basically by remapping the calls to read from the disc to read from another PC on the network instead).
2. A mod chip is coming out soon, according to fairly good rumors. It will have some means to connect it to an external DVD drive which will then be able to read normal DVD formats instead of N's reversed track format. People have already been able to grab images using the PSO exploit, with this modchip you should be able to burn an image onto a normal DVD or mini-DVD and then play them from the external DVD drive. Or if you have the capability to read them already using the exploit, now you have the capability to write them to the GC's memory and play them without a modchip.
Short version: Using a GC and a GC ethernet network adapter, along with a copy of Phantasy Star Online, one can upload code to the Cube which the cube then runs.
Longer version: Combined with the ability to read in a GC disc over the broadband adapter, and write it back similarly, this makes GC Game piracy possible, although it also makes possible other things like writing a version of Linux for the Cube. There exists a GCC cross compiler for the Cube, and people have been using this write their own homebrew demos and such already. This trick makes it possible to run those more easily, if you happen to have a copy of PSO and a GC ethernet adapter.
Even longer: A mod chip is rumored to be coming out for the GC soon. The trick to the GC is that it uses non-standard discs. They are basically just mini-DVD's which hold 1.5 gig, but they swapped the direction of the tracks. Instead of reading from the inside edge to the outside edge, as all CD's and DVD's do, the GC discs go from the outside edge to the inside edge. They spin the same direction, but the track is reversed. So no existing DVD writer or reader can read them. With the PSO bug exploit and the broadband adapter, one can read the disk via ethernet instead, and now write the disk contents back into RAM on the cube to run the contents and such.
I know what you're thinking, the disk is too large to hold all in the GC's RAM. And you're right. I think the way this works is that it exploits the PSO bug to load a small program into the GC's memory which then remaps the calls to read from the disk into calls to read from the ethernet. So the disc image is sitting on the PC and being read by the GC if and when the GC needs to load data. Then it simply loads the boot block from the image file over and starts 'er up. Voila, it's now playing, and you only have a delay in load times as the network transaction occurs. There's a program running on the PC which handles the disk image to be sent back to the GC as well. It probably must be running all the time the game is playing, or at least whenever the game needs to load something into memory from the disc. Not all games do. Notably, Animal Crossing does all its disc access right at load time, then the disc is idle until you shut the thing down. This program is known to work with Animal Crossing and Luigi's Mansion (which does do loads from the disc on new levels and such).
Delta V isn't a rocket, it's a shorthand term for "change in velocity".
Spaceships don't measure fuel in terms of tons or pounds or gallons.. Well, they could, I suppose, but a more sensible way to measure how much fuel you have left, when in space, is by how much change in velocity you've got left. Once you run out of the ability to change your velocity anymore, you're stuck at whatever speed and direction you happened to be going when you ran out.
This is why spaceships don't make right turns, much less reverse their course. They'd have to burn fuel to eliminate their current velocity (eating up some of their delta V) and then burn more fuel in order to get a new velocity going elsewhere. It's wasteful. If you want to turn around, then it's best to find a handy planet to swing around using its gravitational pull. Get your change in direction for free that way.
Anyway, if you could accelerate at something like 1 G for a pretty much unlimited time, then you could achieve tremendous speeds. In this particular example, you'd be doing 739,214 meters per second at the turnaround point, which is roughly 1.6 million miles per hour.
But, of course, no chemical rocket could achieve that kind of delta V. It's utterly impossible. The problem with a chemical rocket is that you have to carry all the fuel you're going to burn, and you have to push it too. At a certain point, your rocket gets so big that the amount of fuel you've got actually means you lose delta V, because you've got all this fuel to shove around. It's the same reason that it take 2,500 tons of fuel for us to shove a 100 ton shuttle into orbit. All that fuel has to push all the other fuel a good portion of the way up.
In order to get an acceleration for anything remotely like a day and a half, you'd have to have something that didn't weigh so much or use so much fuel. Ion drives can produce fantastic speeds of the particles coming out, and use very little fuel, but the acceleration they produce ain't much. Enough to move a satellite around, I grant you, but it's a long way from what exists now to shoving around ships. And high accelerations with ion drives is just a fantasy. Nuclear power could possibly do it, if someone could come up with a way of harnessing that power and putting it to work. Current tech is woefully poor at extracting the vast amount of power locked up in the atom.
But it's quite possible for it to be done. Just not for a while.:)
I suppose you mean 'propulsion allowing a higher terminal speed'. Todays chemical rockets are basicly 'burn, then coast'. You accelerate a lot for a while, then glide towards the target. A ion-engine or a nucular rocket will let you accelerate less but for a much longer time, meaning you'll get a higher terminal velocity. The providial Holy Grail for interplanitary missions would be an engine which would let you accelerate forever. Just think about it; you blast off into orbit, then turns on the flightengine. That gently accelerates you to one G.. and keeps that accelatation all the time. Halfway to the target, you simply turns around and deacceleate with one G, leaving you with zero relative speed as you enter orbit around Mars (or wherever you want to go). The speeds you'll reach are way higher than any chemical rocket can provide, the flighttime shortens and we don't have to worry about the determinal effects of living in zero G for years on end. I havn't got my notes and calculator here right now, but maybe someone could punch up some numbers on this?
This is an easy one.. Okay, Mars was at it's closest a few months ago, right? A quick google tells me that it was 55.76 million kilometers away at the time.
So, since we're accelerating to there and then slowing down halfway, basically we divide the problem into two parts. How long will it take to get halfway there? Then we simply double it to get the reverse, how long it'll take to slow down.
-Half of 55,760,000,000 meters is 27,880,000,000 meters. -One G is 9.8 m/s^2
Solve for time, and you get 75430.73589... seconds. But that's only halfway to Mars, so double it to get the slowdown part too and you have 150861.4717... seconds. Divide by 60 for minutes, divide by 60 for hours, and you come up with roughly 41 hours, or about a 1 and 3/4 days total.
So yeah, if you had all the delta V you could handle, you could be there in under a couple days.
I have cable. I also run my own mail server. If that's implemented, then no mail server will receive my mail because my residential cable IP won't be allowed to send mail from my ISP's netblock. Thus we all need to pay just to run our mail domains, which is too expensive.
No, but if it's widely implemented, you won't be able to run your own mail server to forge your From: domain name anymore.
Look at it like this.. You have a mail server setup. It's sending email as if it was a domain that you don't actually own. It may be your email address, granted, but you don't have any right to use that address, or that domain, without the leave of your ISP. That's what you're paying them for. They're perfectly able to dictate that you go thru their mail servers to send mail from that domain.
If your ISP isn't blocking outgoing on port 25 (which many are nowadays anyway.. mine started a few weeks ago, using "to help stop stupid email viruses" as an excuse), then you could very easily get your own domain name and either run your own DNS server or use one of the cheap or even free DNS server services out there. Once you're running a DNS, you can stick an MX line in there and voila, main to your named domain goes *directly* to your mail server.
Problem solved. You're already running a mail server. A domain name can be had for $10-15 a year.
Hey, then you can even implement SPF yourself, if you like, so that nobody but you can send mail from your new domain name. You'd no longer need your ISP's email account. And if you moved to a new ISP or new IP address in any way, a few minutes of changing the DNS record would set your email right back up to point to the new address, and your email address *never changes*, ever again. Not as long as you own the domain.
Sorry, but I have a PC. 4 pin firewire built right into my couple year old laptop. I find it much nicer than USB, in general. Have it hooked to a drive bay, an MP3 player, and occasionally to other computers via firewire. Works very well.
If you need to attach a device that can use the high speed connection, like a hard drive or an MP3 player or something, then stick with firewire. It's easier to deal with. Of course, USB is fine for your mouse or keyboard or what have you, but trying to sort out the differences there is just too much of a pain. Firewire has various speeds too, but I've yet to see a firewire device that really needs a high speed work at a lower one.
The one thing that it hasn't supplanted, and I doubt that it will for a while, are long writings. If I want to read a book, rather than use it as a reference, far better to have it in print form where I can carry it with me anywhere and read it on something other than a computer screen. In short, the Internet is probably the best/random-access/ media yet developed, but is lacking for long serial accesses.
I agree, although progress is being made. I'm not too happy with the e-book type stuff available at the moment, but I acquired a handheld computer (a Progear, actually), and have been using it more and more for normal book type stuff. Oh, my dead-tree medium exceeds my e-book medium by a 1000 to 1 now, by far, but that's still better than the 1000000 to 1 a couple of years ago, or the infinity to zero ratio five years ago.:)
It's all about the devices, methinks. When someone creates a lightweight device with network access, using a display method that's easy on the eyes (I have high hopes of digital ink type stuff), then e-books might come into their own, finally.
The rumors of a thousand ill-informed people do not add up to the knowledge of a single well-informed person.
Perhaps, but when looking for factual information, the internet is a great source to find a thousand well informed people on any given topic.
There's a difference between opinion and fact, and the internet is only useful as a research tool when you learn to distinguish someone who knows what he's talking about from someone who doesn't. In the realm of verifable, factual, knowledge, I find that it's rare that someone will put up something that is provably complete nonsense, unless they're a wacko. And most people's wacko-meter works pretty well.
In the realm of opinion, you're absolutely 100% correct. You can find thousands of conflicting opinions on the internet.
So be careful to verify what you read before accepting it as Truth.
Probably a good idea to do the same in libraries too.;)
The real problem with MapQuest is not that it's maps are incorrect or that it's directions are wrong. It's that stupid people take them literally instead of actually looking at the damn map themselves. I use MapQuest all the time, because I travel a lot. I never have once followed the sheet of directions it gives me, because I know it's taking the way that a computer thought up. In other words, it's probably the shortest or quickest or easiest, in theory, but reality is far different from theory.
You can't program a computer to know that while this street is shorter, that one is more likely to have less traffic at this particular time of day. Well, you can program it to know that, I suppose, but is it? I doubt it.
I think MapQuest is a great tool, but people read those directions, which seem extremely detailed, and their brain shuts off. When the reality deviates from the expected course, they don't usually bother to turn the brain back on.
Use MapQuest to get a map and find approximate locations. But plot your own course. That's the way to use it properly.
Relevant quotes: To prevent consumers from identifying partially-filled Coke cans as winners by discerning differences in weight or listening for sloshing sounds, Coca-Cola added a chamber of chlorinated water to these special cans. This special water was doctored with the addition of ammonium sulfate, a foul-smelling yet harmless substance placed there to prevent anyone from mistaking the chlorinated water for Coca-Cola. It also served to alert the lucky consumers that they were holding winning cans, not just misfilled ones, if they somehow failed to notice their prizes and managed to gain access to the sealed-off liquid in the cans' bottoms. ... In May 1990, 11-year-old Zachary Gendron of North Andover drank from one of the defective cans. His parents took a whiff of the clear, bad-smelling liquid and felt a foreign object inside the can. "Knowing nothing about the promotion, we thought it might be a case of product tampering," said Robin Gendron, Zachary's mother. The Gendrons handed the can over to the local police, who dissected the can back at the station and contacted state health officials.
Young Zachary had gotten a winning can that misfired. His prize, a soggy five-dollar bill, was duly retrieved and presented to the him (although his mother threatened to have it framed), and Coca-Cola also sent along coupons good for free product. Despite the confusion over his find, the boy had never been in any danger -- the potential harm from drinking the doctored water was limited to possible nausea.
It wasn't the chlorinated water. It was the ammonium sulfate that caused the nausea.
Does this mean that the first person who hacks the transmitter's signal to track down the winning can gets to claim the prize? I don't think this will ever work because most cans are stored in places that don't get good GPS reception (buildings, steel machines, trucks, etc...) and the transmit out (presumably a cell connection?) is another matter entirely. You got problems, we got answers:
a) Hacking: Build the device so that it doesn't activate until someone opens the can. Then you won't receive any signals from it until it's been bought, or at least, opened. Weight difference could be fixed with hunks of lead filler, or whatever. It's possible to make it indistinguishable from a normal can anyway, unless you have a portable xray scanner or some such thing.
b) Indoors, etc: Simple coding problem. If you don't get a signal from a GPS, wait until you do and then transmit the cell phone message to home base saying where you are. To prevent the guy throwing the can away (which is already unlikely, as he's got an empty can full of electronics and he's going to wonder WTF is up with that), you could stick a speaker in the thing and play a tune with a voice that says "Hey, you just won a prize! Go outside and the prize patrol will meet you there in a few minutes, or dial this number to contact them immediately!" and there you go.
Reverse Polish Notation?!?!? Why exactly is it "Polish"?
Because a Polish man came up with the idea?
Prefix and Postfix notation were developed in the 1920's by Jan Lukasiewicz (who was, in fact, Polish). Prefix notation was often called Polish Notation in honor of Lukasiewicz.
Postfix turned out to be useful for computer operations, if you made it into a stack and then did operations upon that stack. It was called Reverse Polish Notation, since postfix is the opposite of prefix, and prefix was called Polish Notation.
however, what happens when i want to have two machines inside the network both serving content?
well, i could have the NAT box forward all connections to port 80 to 10.0.0.2:80 and port 81 to 10.0.0.3:81. however, this mythical protocol that uses port 80 has a lot of clients implementing it that are stupid and always assume port 80 is the one to connect to. all of a sudden, binding a forward to port 81 isn't an option. As I see it, this is a problem that solves itself, over time. I mean, when there's a problem, solutions are created.
For example, in NAT, there's the problem of user stupidity. Not knowing how to forward ports, for example. uPnP is only the most obvious solution to this, and while it's not very widespread, it *is* a solution that will take hold over time. Most home level NAt boxes support uPnP pretty well now, and several client programs now are starting to support it. Microsoft's various clients are the most obvious of these, I grant you, but uPnP does work to solve the problem. It lets the application forward ports on it's own, without help from the end-user.
The problem you address is one of multiple similar services behind a NAT box. Given that you have one external IP, clients that take the port for granted don't have the easy option of choosing which service they're talking to. This has two possible solutions: a) Get someone in the network administrator position who has a freakin' clue and won't be using a cheap and simple NAT box for all their internet access to the company, but will instead use a real firewall and router and will therefore give those boxes external IP's of their own, or at least route different IP's to those boxes. b) Make smarter client applicatons.
Solution A is the one most usually implemented. In a company I used to be at, we had this exact problem. We wanted to run a new webserver for our section of the organization ourselves. So we convinced the network admins that we had a need for it, and eventually they pulled a real IP address out of their uplink's block of IP's and set up rules in the firewall to route those connections to our internal IP'd webserver. Problem solved. Of course, we had to secure that server and convince them of the fact in order to get them to do it, but then that's the way it's supposed to be anyway. This sort of thing is what a router is made to do, no?
Solution B is taking shape more slowly, but newer applications don't make assumptions like the IP address is real, and so forth. The reason things like ALG's are needed is that applications made an assumption which is no longer necessarily valid, and then did something like passing the IP address around between machines in the application data level of the packets. There's simplistic fixes for this, like providing a configuration setting to override what the IP address should be, and complex fixes like auto-detection of internal addresses and using other methods to detect the real external IP address.
So, solutions are available, just not yet widespread. The NAT problem the original article mentions is real, but blaming it for discontinuing your work on a project is disingenuous at best. The truth is that the author is too lazy to properly investigate the available solutions and then help to promote them correctly. Old obsolete software and protocols must make way for the changing face of the internet and the network.
I was able to make it happen yesterday, but today, I'm getting failed back. I tried a web page, then tried nslookup, and even tried several of the online web-based nslookup tricks as well. Nothing.
Either everyone I tried is now blocking this, or the BIND patch has spread *unbelievably* rapidly, or they dropped the idea completely.
ASF files appear to be able to carry executable activeX content. (I can't be 100% sure since Microsoft cease and desisted VirtualDub from reverse engineering the format, but I have run ASF file which popped up a web page from an URL contained in the binary of the file in MBCS format.) The problem is that often an ASF file will be renamed (I have noticed this from ASF files I obtained with Kazaa-lite) with an AVI or MPG file extension. Windows media player will detect the file by content, not by file extension, and after warning you about a mis-match, will go ahead and play it anyway. To the best of knowledge, they can't carry executable content other than through buffer overflows. They can, however, carry links that will get pulled up in a browser at specific times in the piece, if you're running WMP8 or above. In WMP9, you can actually disable that in the preferences somewhere. This isn't executable code though, it's part of the file format. I guess the idea was for automatic web based presentations or something.
You might get the paper by bleaching one-dollar bills, but you damn sure ain't getting the press.
Yes, but then if you re-read the post you're replying to, that's exactly what he said. It's not the artwork that's stopping him from making a good counterfeit, it's the lack of ability to obtain the machinery to do it.
Making something "authentic" is relatively easy when the machinery is in every store. The Xerox machine can't make anything not easily counterfeited because everybody could get one cheaply and affordably, and then simply print out their own Glossmark crap.
Yes, but if you're trying to compress heavily clipped music from the CD, then your compressed form would likely be closer to what's on the CD, is my point.
Think of like this.. In a normal MP3, you've only got so many bits per second to work with. Now, if the source material is unclipped, then you've got to use those bits to reproduce the sound wave. If the source material is clipped, then you've lost data, and you don't have to use the bits to reproduce those parts of that sound wave.
If my sound looks like this: 1 54 2 5 2 6 239 53 53 65 Then that's not going to compress as easily as something like this: 1 0 2 5 2 6 0 0 0 0
Now, your clipped music will sound like crap anyway, I grant you that.
But the compressed version of the clipped music is going to be much closer to the clipped music than the compressed version of the unclipped music is going to be to the unclipped music.
In other words, clipped music, while it sounds like crap, will compress better and the compressed version will be closer to it's source material than what you get when you try to compress unclipped material.
So the point I was trying to make is that clipping music will make it compress better, not worse. It'll sound like crap, I grant you, but if the only source material you have is crap (because that's what's on the CD), then hey, no loss.
Slashdot Mirror
I just wanted to say that it's also an interesting case from a security standpoint. Their method of having a hardcoded and difficult to change BIOS protecting the system via hard crypto was basically unbeatable for a while. But when one exploit was found in one version of their signed code, then the system was basically broken open then, and forever more. I think it showcases an important flaw with using public key type signatures on executable code when you have absolutely no way to revoke that signature. One mistake, and your security is history or can be made to be history. All the hacker must have is one way to get in, and then the company can't undo that way in, even when they fix the flaw.
I just found that very interesting, is all.
There are people who've successfully hacked the Series 2 TiVos by replacing the BIOS with one that has the signature-check edited out, but that requires soldering, which is more than most TiVophiles are comfortable with.
If you really want to do it, then there is a way without soldering. It ain't exactly legal, but it works.
A quick explanation of the Tivo's protection methodology:
-The hardcoded BIOS boots up and checks the kernel. It's looking for a signature on the kernel. Since we don't have Tivo's private key, we can't fake or recreate the kernel's signature. If the kernel signature is valid, it boots the kernel.
-The kernel has a chunk of code that checks every file on the root partition. If it doesn't match, then the kernel replaces that file with the right one before continuing on. This pretty much eliminates changing any files on the drive.
And that's how it works. The BIOS protects the kernel, the kernel protects everything else.
The trick to fixing this is, ah ha, an exploit that they accidentally left in one particular BETA kernel which then made it out into the wild. The exploit was removed, but the kernel was already out there.
I believe it was the U5 kernel. Anyway, the exploit is that a BASH environment variable could be set in the boot options and the kernel didn't clear it before booting up the shell. So what you do to get in and actually trick out the kernel is as follows:
- Use the BETA kernel. This kernel has protections, and so you have to have a correct filesystem for it to see.
- Create the BASH env variable such that, when the shell starts, it mounts a new partition with a modified, and therefore unsigned, kernel on it, swaps the root partition out with another, and does a two card monte trick with the kernel. The two card monte trick is where the running kernel loads a module that actually replaces the entire kernel with another one and starts it up. Neat trick, actually. This swaps the unsigned kernel into the kernel space, and bypasses the BIOS check, because the BIOS check is already finished and done.
Then all you do is use a copy of the latest kernel, and modify it slightly to eliminate the initd check of the partition. Two card monte swaps the unsigned kernel in and it runs just fine now that the BIOS check isn't stopping it dead in it's tracks.
The beauty of this hack is that Tivo can't fix the problem without changing the code in the BIOS/PROM chip. The U5 kernel that actually has the flaw is signed. They can't unsign it. The boot code there has the public side of the keyset and will read that kernel as signed forever and ever and ever. The new kernel can't detect that it's been two card monte'd into memory. It could check it's own signature, but that's as easily disabled as the initd part of the kernel is disabled. So once you have a two card monte set up and running, you just need a few good partitions to set it up in and then you have to slightly reconfigure it whenever they release new code for the box (basically disabling the initd in the new kernel and setting the boot params back to the U5 kernel on your other partition), but other than that it's wide, wide open.
Now, this ain't exactly legal, as the U5 kernel is Tivo's code, not yours. Or maybe it is, as the thing is the linux kernel. It's GPL'd. I'm not sure about that, as they never released U5 to the public that I'm aware of. In any case, it works. Search around dealdatabase.com and you'll find it.
Well, from what they're saying on the page, it can take 1 to several minutes to transmit the data over. So I'm just going by that. In theory, with a hard drive and a 100mbit ethernet, then you're probably right. All I know is that the load time on my GC is very, very low for most things.
1. This exploit uses a bug in Phantasy Star Online and a GC ethernet adapter to load the games both to and from the GC. Thus using Nintendo's non-standard drive to read the game itself, and loading the game back in via ethernet instead of from a burned disc (basically by remapping the calls to read from the disc to read from another PC on the network instead).
2. A mod chip is coming out soon, according to fairly good rumors. It will have some means to connect it to an external DVD drive which will then be able to read normal DVD formats instead of N's reversed track format. People have already been able to grab images using the PSO exploit, with this modchip you should be able to burn an image onto a normal DVD or mini-DVD and then play them from the external DVD drive. Or if you have the capability to read them already using the exploit, now you have the capability to write them to the GC's memory and play them without a modchip.
Short version:
Using a GC and a GC ethernet network adapter, along with a copy of Phantasy Star Online, one can upload code to the Cube which the cube then runs.
Longer version:
Combined with the ability to read in a GC disc over the broadband adapter, and write it back similarly, this makes GC Game piracy possible, although it also makes possible other things like writing a version of Linux for the Cube. There exists a GCC cross compiler for the Cube, and people have been using this write their own homebrew demos and such already. This trick makes it possible to run those more easily, if you happen to have a copy of PSO and a GC ethernet adapter.
Even longer:
A mod chip is rumored to be coming out for the GC soon. The trick to the GC is that it uses non-standard discs. They are basically just mini-DVD's which hold 1.5 gig, but they swapped the direction of the tracks. Instead of reading from the inside edge to the outside edge, as all CD's and DVD's do, the GC discs go from the outside edge to the inside edge. They spin the same direction, but the track is reversed. So no existing DVD writer or reader can read them. With the PSO bug exploit and the broadband adapter, one can read the disk via ethernet instead, and now write the disk contents back into RAM on the cube to run the contents and such.
I know what you're thinking, the disk is too large to hold all in the GC's RAM. And you're right. I think the way this works is that it exploits the PSO bug to load a small program into the GC's memory which then remaps the calls to read from the disk into calls to read from the ethernet. So the disc image is sitting on the PC and being read by the GC if and when the GC needs to load data. Then it simply loads the boot block from the image file over and starts 'er up. Voila, it's now playing, and you only have a delay in load times as the network transaction occurs. There's a program running on the PC which handles the disk image to be sent back to the GC as well. It probably must be running all the time the game is playing, or at least whenever the game needs to load something into memory from the disc. Not all games do. Notably, Animal Crossing does all its disc access right at load time, then the disc is idle until you shut the thing down. This program is known to work with Animal Crossing and Luigi's Mansion (which does do loads from the disc on new levels and such).
Delta V isn't a rocket, it's a shorthand term for "change in velocity".
:)
Spaceships don't measure fuel in terms of tons or pounds or gallons.. Well, they could, I suppose, but a more sensible way to measure how much fuel you have left, when in space, is by how much change in velocity you've got left. Once you run out of the ability to change your velocity anymore, you're stuck at whatever speed and direction you happened to be going when you ran out.
This is why spaceships don't make right turns, much less reverse their course. They'd have to burn fuel to eliminate their current velocity (eating up some of their delta V) and then burn more fuel in order to get a new velocity going elsewhere. It's wasteful. If you want to turn around, then it's best to find a handy planet to swing around using its gravitational pull. Get your change in direction for free that way.
Anyway, if you could accelerate at something like 1 G for a pretty much unlimited time, then you could achieve tremendous speeds. In this particular example, you'd be doing 739,214 meters per second at the turnaround point, which is roughly 1.6 million miles per hour.
But, of course, no chemical rocket could achieve that kind of delta V. It's utterly impossible. The problem with a chemical rocket is that you have to carry all the fuel you're going to burn, and you have to push it too. At a certain point, your rocket gets so big that the amount of fuel you've got actually means you lose delta V, because you've got all this fuel to shove around. It's the same reason that it take 2,500 tons of fuel for us to shove a 100 ton shuttle into orbit. All that fuel has to push all the other fuel a good portion of the way up.
In order to get an acceleration for anything remotely like a day and a half, you'd have to have something that didn't weigh so much or use so much fuel. Ion drives can produce fantastic speeds of the particles coming out, and use very little fuel, but the acceleration they produce ain't much. Enough to move a satellite around, I grant you, but it's a long way from what exists now to shoving around ships. And high accelerations with ion drives is just a fantasy. Nuclear power could possibly do it, if someone could come up with a way of harnessing that power and putting it to work. Current tech is woefully poor at extracting the vast amount of power locked up in the atom.
But it's quite possible for it to be done. Just not for a while.
I suppose you mean 'propulsion allowing a higher terminal speed'. Todays chemical rockets are basicly 'burn, then coast'. You accelerate a lot for a while, then glide towards the target. A ion-engine or a nucular rocket will let you accelerate less but for a much longer time, meaning you'll get a higher terminal velocity. The providial Holy Grail for interplanitary missions would be an engine which would let you accelerate forever. Just think about it; you blast off into orbit, then turns on the flightengine. That gently accelerates you to one G.. and keeps that accelatation all the time. Halfway to the target, you simply turns around and deacceleate with one G, leaving you with zero relative speed as you enter orbit around Mars (or wherever you want to go). The speeds you'll reach are way higher than any chemical rocket can provide, the flighttime shortens and we don't have to worry about the determinal effects of living in zero G for years on end. I havn't got my notes and calculator here right now, but maybe someone could punch up some numbers on this?
.5 * acceleration * time^2 .5 * 9.8 * time^2
This is an easy one.. Okay, Mars was at it's closest a few months ago, right? A quick google tells me that it was 55.76 million kilometers away at the time.
So, since we're accelerating to there and then slowing down halfway, basically we divide the problem into two parts. How long will it take to get halfway there? Then we simply double it to get the reverse, how long it'll take to slow down.
-Half of 55,760,000,000 meters is 27,880,000,000 meters.
-One G is 9.8 m/s^2
Distance traveled =
27,880,000,000 =
Solve for time, and you get 75430.73589... seconds. But that's only halfway to Mars, so double it to get the slowdown part too and you have 150861.4717... seconds. Divide by 60 for minutes, divide by 60 for hours, and you come up with roughly 41 hours, or about a 1 and 3/4 days total.
So yeah, if you had all the delta V you could handle, you could be there in under a couple days.
Too bad we don't have that.
I have cable. I also run my own mail server. If that's implemented, then no mail server will receive my mail because my residential cable IP won't be allowed to send mail from my ISP's netblock. Thus we all need to pay just to run our mail domains, which is too expensive.
No, but if it's widely implemented, you won't be able to run your own mail server to forge your From: domain name anymore.
Look at it like this.. You have a mail server setup. It's sending email as if it was a domain that you don't actually own. It may be your email address, granted, but you don't have any right to use that address, or that domain, without the leave of your ISP. That's what you're paying them for. They're perfectly able to dictate that you go thru their mail servers to send mail from that domain.
If your ISP isn't blocking outgoing on port 25 (which many are nowadays anyway.. mine started a few weeks ago, using "to help stop stupid email viruses" as an excuse), then you could very easily get your own domain name and either run your own DNS server or use one of the cheap or even free DNS server services out there. Once you're running a DNS, you can stick an MX line in there and voila, main to your named domain goes *directly* to your mail server.
Problem solved. You're already running a mail server. A domain name can be had for $10-15 a year.
Hey, then you can even implement SPF yourself, if you like, so that nobody but you can send mail from your new domain name. You'd no longer need your ISP's email account. And if you moved to a new ISP or new IP address in any way, a few minutes of changing the DNS record would set your email right back up to point to the new address, and your email address *never changes*, ever again. Not as long as you own the domain.
Try these instead.
Small (about 5.5 meg)
Medium (about 10 meg)
Large (20 meg)
Sorry, but I have a PC. 4 pin firewire built right into my couple year old laptop. I find it much nicer than USB, in general. Have it hooked to a drive bay, an MP3 player, and occasionally to other computers via firewire. Works very well.
If you need to attach a device that can use the high speed connection, like a hard drive or an MP3 player or something, then stick with firewire. It's easier to deal with. Of course, USB is fine for your mouse or keyboard or what have you, but trying to sort out the differences there is just too much of a pain. Firewire has various speeds too, but I've yet to see a firewire device that really needs a high speed work at a lower one.
The one thing that it hasn't supplanted, and I doubt that it will for a while, are long writings. If I want to read a book, rather than use it as a reference, far better to have it in print form where I can carry it with me anywhere and read it on something other than a computer screen. In short, the Internet is probably the best /random-access/ media yet developed, but is lacking for long serial accesses.
:)
I agree, although progress is being made. I'm not too happy with the e-book type stuff available at the moment, but I acquired a handheld computer (a Progear, actually), and have been using it more and more for normal book type stuff. Oh, my dead-tree medium exceeds my e-book medium by a 1000 to 1 now, by far, but that's still better than the 1000000 to 1 a couple of years ago, or the infinity to zero ratio five years ago.
It's all about the devices, methinks. When someone creates a lightweight device with network access, using a display method that's easy on the eyes (I have high hopes of digital ink type stuff), then e-books might come into their own, finally.
The rumors of a thousand ill-informed people do not add up to the knowledge of a single well-informed person.
;)
Perhaps, but when looking for factual information, the internet is a great source to find a thousand well informed people on any given topic.
There's a difference between opinion and fact, and the internet is only useful as a research tool when you learn to distinguish someone who knows what he's talking about from someone who doesn't. In the realm of verifable, factual, knowledge, I find that it's rare that someone will put up something that is provably complete nonsense, unless they're a wacko. And most people's wacko-meter works pretty well.
In the realm of opinion, you're absolutely 100% correct. You can find thousands of conflicting opinions on the internet.
So be careful to verify what you read before accepting it as Truth.
Probably a good idea to do the same in libraries too.
The real problem with MapQuest is not that it's maps are incorrect or that it's directions are wrong. It's that stupid people take them literally instead of actually looking at the damn map themselves. I use MapQuest all the time, because I travel a lot. I never have once followed the sheet of directions it gives me, because I know it's taking the way that a computer thought up. In other words, it's probably the shortest or quickest or easiest, in theory, but reality is far different from theory.
You can't program a computer to know that while this street is shorter, that one is more likely to have less traffic at this particular time of day. Well, you can program it to know that, I suppose, but is it? I doubt it.
I think MapQuest is a great tool, but people read those directions, which seem extremely detailed, and their brain shuts off. When the reality deviates from the expected course, they don't usually bother to turn the brain back on.
Use MapQuest to get a map and find approximate locations. But plot your own course. That's the way to use it properly.
http://www.snopes.com/horrors/poison/cokecan.asp
...
Relevant quotes:
To prevent consumers from identifying partially-filled Coke cans as winners by discerning differences in weight or listening for sloshing sounds, Coca-Cola added a chamber of chlorinated water to these special cans. This special water was doctored with the addition of ammonium sulfate, a foul-smelling yet harmless substance placed there to prevent anyone from mistaking the chlorinated water for Coca-Cola. It also served to alert the lucky consumers that they were holding winning cans, not just misfilled ones, if they somehow failed to notice their prizes and managed to gain access to the sealed-off liquid in the cans' bottoms.
In May 1990, 11-year-old Zachary Gendron of North Andover drank from one of the defective cans. His parents took a whiff of the clear, bad-smelling liquid and felt a foreign object inside the can. "Knowing nothing about the promotion, we thought it might be a case of product tampering," said Robin Gendron, Zachary's mother. The Gendrons handed the can over to the local police, who dissected the can back at the station and contacted state health officials.
Young Zachary had gotten a winning can that misfired. His prize, a soggy five-dollar bill, was duly retrieved and presented to the him (although his mother threatened to have it framed), and Coca-Cola also sent along coupons good for free product. Despite the confusion over his find, the boy had never been in any danger -- the potential harm from drinking the doctored water was limited to possible nausea.
It wasn't the chlorinated water. It was the ammonium sulfate that caused the nausea.
Does this mean that the first person who hacks the transmitter's signal to track down the winning can gets to claim the prize? I don't think this will ever work because most cans are stored in places that don't get good GPS reception (buildings, steel machines, trucks, etc...) and the transmit out (presumably a cell connection?) is another matter entirely.
You got problems, we got answers:
a) Hacking: Build the device so that it doesn't activate until someone opens the can. Then you won't receive any signals from it until it's been bought, or at least, opened. Weight difference could be fixed with hunks of lead filler, or whatever. It's possible to make it indistinguishable from a normal can anyway, unless you have a portable xray scanner or some such thing.
b) Indoors, etc: Simple coding problem. If you don't get a signal from a GPS, wait until you do and then transmit the cell phone message to home base saying where you are. To prevent the guy throwing the can away (which is already unlikely, as he's got an empty can full of electronics and he's going to wonder WTF is up with that), you could stick a speaker in the thing and play a tune with a voice that says "Hey, you just won a prize! Go outside and the prize patrol will meet you there in a few minutes, or dial this number to contact them immediately!" and there you go.
That particular server is always down. Never works right. Try this one instead.
O TK_Preview_(12mins).torrent
http://www.emptylogic.com/suprnova/torrents/233/R
Reverse Polish Notation?!?!? Why exactly is it "Polish"?
Because a Polish man came up with the idea?
Prefix and Postfix notation were developed in the 1920's by Jan Lukasiewicz (who was, in fact, Polish). Prefix notation was often called Polish Notation in honor of Lukasiewicz.
Postfix turned out to be useful for computer operations, if you made it into a stack and then did operations upon that stack. It was called Reverse Polish Notation, since postfix is the opposite of prefix, and prefix was called Polish Notation.
Simple.
Yeah, I'm getting it again now too. I think they had it down for some reason. Possibly to fix their slashdotted server or some such.
however, what happens when i want to have two machines inside the network both serving content?
well, i could have the NAT box forward all connections to port 80 to 10.0.0.2:80 and port 81 to 10.0.0.3:81. however, this mythical protocol that uses port 80 has a lot of clients implementing it that are stupid and always assume port 80 is the one to connect to. all of a sudden, binding a forward to port 81 isn't an option.
As I see it, this is a problem that solves itself, over time. I mean, when there's a problem, solutions are created.
For example, in NAT, there's the problem of user stupidity. Not knowing how to forward ports, for example. uPnP is only the most obvious solution to this, and while it's not very widespread, it *is* a solution that will take hold over time. Most home level NAt boxes support uPnP pretty well now, and several client programs now are starting to support it. Microsoft's various clients are the most obvious of these, I grant you, but uPnP does work to solve the problem. It lets the application forward ports on it's own, without help from the end-user.
The problem you address is one of multiple similar services behind a NAT box. Given that you have one external IP, clients that take the port for granted don't have the easy option of choosing which service they're talking to. This has two possible solutions:
a) Get someone in the network administrator position who has a freakin' clue and won't be using a cheap and simple NAT box for all their internet access to the company, but will instead use a real firewall and router and will therefore give those boxes external IP's of their own, or at least route different IP's to those boxes.
b) Make smarter client applicatons.
Solution A is the one most usually implemented. In a company I used to be at, we had this exact problem. We wanted to run a new webserver for our section of the organization ourselves. So we convinced the network admins that we had a need for it, and eventually they pulled a real IP address out of their uplink's block of IP's and set up rules in the firewall to route those connections to our internal IP'd webserver. Problem solved. Of course, we had to secure that server and convince them of the fact in order to get them to do it, but then that's the way it's supposed to be anyway. This sort of thing is what a router is made to do, no?
Solution B is taking shape more slowly, but newer applications don't make assumptions like the IP address is real, and so forth. The reason things like ALG's are needed is that applications made an assumption which is no longer necessarily valid, and then did something like passing the IP address around between machines in the application data level of the packets. There's simplistic fixes for this, like providing a configuration setting to override what the IP address should be, and complex fixes like auto-detection of internal addresses and using other methods to detect the real external IP address.
So, solutions are available, just not yet widespread. The NAT problem the original article mentions is real, but blaming it for discontinuing your work on a project is disingenuous at best. The truth is that the author is too lazy to properly investigate the available solutions and then help to promote them correctly. Old obsolete software and protocols must make way for the changing face of the internet and the network.
I was able to make it happen yesterday, but today, I'm getting failed back. I tried a web page, then tried nslookup, and even tried several of the online web-based nslookup tricks as well. Nothing.
Either everyone I tried is now blocking this, or the BIND patch has spread *unbelievably* rapidly, or they dropped the idea completely.
Anyone have info on which of these is going on?
ASF files appear to be able to carry executable activeX content. (I can't be 100% sure since Microsoft cease and desisted VirtualDub from reverse engineering the format, but I have run ASF file which popped up a web page from an URL contained in the binary of the file in MBCS format.) The problem is that often an ASF file will be renamed (I have noticed this from ASF files I obtained with Kazaa-lite) with an AVI or MPG file extension. Windows media player will detect the file by content, not by file extension, and after warning you about a mis-match, will go ahead and play it anyway.
To the best of knowledge, they can't carry executable content other than through buffer overflows. They can, however, carry links that will get pulled up in a browser at specific times in the piece, if you're running WMP8 or above. In WMP9, you can actually disable that in the preferences somewhere. This isn't executable code though, it's part of the file format. I guess the idea was for automatic web based presentations or something.
Configure the access point to only allow 11 mbit connections. If it's a Cisco AP, then that's relatively easy to do. I don't know about other APs.
You might get the paper by bleaching one-dollar bills, but you damn sure ain't getting the press.
Yes, but then if you re-read the post you're replying to, that's exactly what he said. It's not the artwork that's stopping him from making a good counterfeit, it's the lack of ability to obtain the machinery to do it.
Making something "authentic" is relatively easy when the machinery is in every store. The Xerox machine can't make anything not easily counterfeited because everybody could get one cheaply and affordably, and then simply print out their own Glossmark crap.
Yes, but if you're trying to compress heavily clipped music from the CD, then your compressed form would likely be closer to what's on the CD, is my point.
Think of like this.. In a normal MP3, you've only got so many bits per second to work with. Now, if the source material is unclipped, then you've got to use those bits to reproduce the sound wave. If the source material is clipped, then you've lost data, and you don't have to use the bits to reproduce those parts of that sound wave.
If my sound looks like this:
1 54 2 5 2 6 239 53 53 65
Then that's not going to compress as easily as something like this:
1 0 2 5 2 6 0 0 0 0
Now, your clipped music will sound like crap anyway, I grant you that.
But the compressed version of the clipped music is going to be much closer to the clipped music than the compressed version of the unclipped music is going to be to the unclipped music.
In other words, clipped music, while it sounds like crap, will compress better and the compressed version will be closer to it's source material than what you get when you try to compress unclipped material.
So the point I was trying to make is that clipping music will make it compress better, not worse. It'll sound like crap, I grant you, but if the only source material you have is crap (because that's what's on the CD), then hey, no loss.