Yes, which I gather is rather how the PassMe works. It is a device that plugs into the DS slot, and you then plug a DS game into the PassMe. The PassMe uses the game for authentication, but redirects execution to the GBA slot.
This is the current method for running homebrew games. It stands to reason that an official game can do the same thing by itself. I suppose it is possible that we might see an update to the Play-Yan that incldues a DS cart to run the required DS code, but who knows how flexible the Play-Yan is. That is, how much it can be modified via firmware.
You're right though about them probably not messing with it... being compatible with so many consoles all at once is awesome... heh.. when do we start seeing people putting play-yans in gamecube game boy players and making a Nintendo HTPC?:P
An interesting thought, and one that is almost possible. The Play-Yan can actually decode video up to about 352x288, but can only display it at 240x160 due to the limitations of the GBA screen. If the GB player didn't have to follow the GBA resolution requirements it could certainly allow the GameCube to play back cable-TV quality content.
As it is now people will likely be able to use existing podcatchers and vidcatching clients with the play-yan and just sync to the SD card, so wifi syncing of podcasts/etc isn't really neccesary, but would be cool.
Not quite. The Play-Yan, at least with the new firmware, is only halfway there. It supports the MP4 fileformat, and it is very easy to encode/transcode for/to it with ffmpeg. However it is highly unlikely that existing content on the internet will play without transcoding. This probably isn't an issue though. ffmpeg is quite fast, it is opensource, and as a command line tool it should be easy to throw into whatever pipeline you want to use to get content onto the Play-Yan. Simply set your setup to transcode the file before copying it onto the SD card and you are set.
HOWEVER I would LOVE my iPod to wirelessly sync and if Nintendo were to do this with the Play-Yan I think we'd see Apple push that feature through pretty quickly given the large GBA install base and that with the Play-Yan Nintendo is effectively competing with Apple.
Ah, but the GBA install base is only a potential. It only becomes a real competitor if the Play-Yan install base is significant. 100 million people could own GBAs, but if Nintendo only sells 1 million Play-Yans, they aren't exactly cutting into the iPod Shuffle marketspace.
Not to mention that the cost of a GBA, plus Play-Yan, plus 1GB SD card exceeds the cost of a iPod Shuffle. The 1GB iPod Shuffle goes for about $129 US, while if we say the GBA can be had for $50, the Play-Yan is $50, and perhaps $100 for a decent 1GB SD card, we're already approaching double the cost of an iPod Shuffle.
Of course, the iPod Shuffle doesn't play video, nor does it play games, and it doesn't even have a screen, so that extra $70 gets you a lot of extra functionality. Still, I think the two market spaces are far enough apart that they won't interfere with eachother.
It should be noted that one of the reasons the Play-Yan works more reliably than other unofficial solutions is that the Play-Yan has dedicated decoding hardware onboard in the form of an MPEG-4 decoder chip. This is how it manages to decode 352x288 video at 1mbit with 320kbit AAC audio in realtime. Even writing your own video playing solution for the gameboy and running it in an emulator, it would be unlikely that you'd be able to match the Play-Yan's performance. However, you would certainly be able to get some video decoding working; the generation 2 Gameboy Movie Player accessory (The predecessor to the M3) relied entirely on the Gameboy CPU, if I recall correctly. It was forced to use special audio and video codecs.
Of course a GBA emulator for the iPod is still really cool:)
While streaming podcasts and videos seems neat at first thought, I don't think in practice it would be all that handy. Any place I have a wifi connection I'd rather be using something like a laptop. If I'm at home I'd rather not be watching stuff on the small screen of a DS, and even if I wanted to, I could copy stuff to the SD card.
Extending the Play-Yan to take advantage of the DS's capabilities would be nice, though unlike you I'd say that using the full screen size would be more important than stylus support. After all, once you're watching/listening to something, you're non-interactive, but using all the screen instead of black borders around the image would certainly improve the user experience.
I suppose it IS possible to do this with the play-yan. Since Nintendo can change the DS's firmware all they want, it is certainly possible for them to add support for this to the DS itself. After all, hacked firmware is already available to do it, the difference is that Nintendo would be able to apply security so that you can't just run any DS code off the GBA slot. However without knowing more about how the Play-Yan and DS interact, I don't know if you could also upgrade that with a simple software update.
So while it is possible to get the DS doing what you want with a simple software update, I think that a hardware update might be needed for the Play-Yan. I'm no expert though, I'm only guessing.
It doesn't look like they have any immediate plans to do this, though. Nintendo seems to think the Play-Yan is good enough, and it might very well be; there is a lot to be said for having ONE single product that will work on the GBA, GBA SP, GBA Micro, and DS, without modification. That certainly helps keep the costs down rather than having to produce a seperate unit for the DS. I would also guess that part of the reason they're doing it this way for now is that the number of DS users is currently tiny compared to the number of GBA users.
Confusing? How? Did you examine the guide at emule-project.net? Or are you just assuming that because BitTorrent (BT) does everything for you emule will do the same?
Yes, I RTFMd. Elitist attitudes on the part of supporters and developers are not usually conductive to popular software, though sometimes the usefulness of the product outweighs that. Much (most?) of BitTorrent's success, and what propelled it beyond eDonkey/eMule, was that it was very simple. On the other hand, I work for a company that produces a linux distribution DESIGNED to do absolutely as much as it can without user input, so maybe I'm just biased. We call such things autonomic software.
Substantiate and justify this please. (Lists of servers are largely irrelevant. One server with a large number of users is enough. See +++ below.)
The number of known servers was erratic and went up and down greatly, which would seem to indicate that either most of the servers are extremely unreliable, or eMule was doing something wrong.
Kademlia (kad) is fully p2p, no servers. You need previously-known contacts to connect. Every time you download or upload a file part from/to a client which *is* on kad, your client records that person as a contact. When you start off, you have no contacts, you need to be patient, and in any case you dont have to use kad.
For the server method, you only *need* one server to start - your client will learn about other servers +++ from other clients as you exchange file parts. You can *google* for server lists too, if you must. There may even be a server list linked from emule-project.net
This is what centralized bootstrapping servers are for. This is the approach Azureus takes, and it seems to me like it is a lot more effective.
Googling for server lists? Don't make me laugh. I tried that, nearly every single one I tried was no longer available.
Downloads are not *instant*. Yes, there is the queuing system. Please explain to me why you should jump ahead of everyone else who is already waiting for a file? The source's bandwidth is a limited resource. emule slices by time, I'm guessing BT slices by speed. Incidentally, if you are downloading a large, popular file, receiving several parts are once, emule can really eat bandwidth. It comes down to the number of people sharing a file, ultimately.
And this is where you see the divide in usefulness. BitTorrent is much better oriented at moving large amounts of data very quickly. eMule is best suited for locating a much larger range of content. New releases on BitTorrent tend to have thousands, even tens of thousands of peers, and they're all visible through the tracker or kademlia. Every peer is (usually) concentrating on just that one file. With eMule, every peer is handling every file. This is why BitTorrent is better for the content available on it.
At least it *has* a built-in search facility. Different search results are caused by the nature of the search mechanism (more so for kad). The search is *not* an index (unlike, say, google). Also, emule tends not to do a full search if it quickly finds >50 unique matches. And the total number of unique matches is limited to 300. With BT, you're searching (fixed) index sites. emule has equivalents, such as the-realworld, osloskop, osiolek, if you care to look.
And I'm saying that that built in search isn't as good as it should be. If those three sites you gave are examples of the quality of eMule index sites, I'll steer clear. the-realworld have shut themselves down, osloskop has a buggy interface (I keep selecting english, it keeps displaying default language), an overabundance of flash ads (They even pop up and cover the page) that suck CPU power like no tommorow, and typical searches for new releases only returns extremely small result sets for out of date content. osiolek at least had a clean, non-buggy, stable interface, but again suffered from extremely small result sets.
It is just a GBA title. On the DS it still works, but at GBA resolution (Which is a lower than the DS).
None of this matters for music of course, but for video it does.
The restriction comes from this using the GBA socket. It has to, really, since the DS socket is so tiny. But because it uses the GBA socket, it has to stay in GBA mode. The DS is very strict about that, and it requires hacked firmware, or a PassMe (goes into DS socket, plug DS game into passme, passme redirects DS execution to GBA slot).
The M3 uses a passme-type device. Despite the fact that the M3 uses the GBA slot and works on GBA, thanks to the hardware hack it is also able to run in DS mode at native res.
I've been debating importing one for quite some time. Originally I discarded the idea because it turned out that videos encoded for the thing could only handle mono 8khz audio (Yes, eight kilohertz), which sounded horrible. However, a recent firmware update added support for AAC audio in the videos, allowing up to 320kbit 48khz stereo.
What put me off importing is the price; the unit costs $50 US in japan, but the importers sell it for $80, even before shipping costs. I understand they want to make a profit, but a 60% markup over retail is a bit much. Because it is expected to sell for $50 when it comes to North America, I think I'll probably just wait for it to be available here instead of importing.
When you think about it, the unit is really rather impressive. A hardware MPEG-4 decoder that can handle video at over a megabit, and AAC audio over 320kbit, at the same time, and it costs only $50.
My laptop also has an SD slot, so I can save some cash on an SD reader.
The only downside of the play-yan is that while it can be used in the DS, it only displays content at GBA resolution; the upcoming M3, a similar device, uses a PassMe type solution to allow it to run both in a GBA and on a DS at native res. This means that if I purchase the Play-Yan for my GBA, if I get a DS I won't be able to take advantage of the additional screen space.
Oh well. I'll probably still pick one up when it launches here.
This is why I am very frustrated at the FCC's limitations on UWB broadcast signal strengths. UWB devices are resistant to interference, and can have enormous ranges at very low power outputs. Not to mention enormous bandwidth and the potential for an enormous number of users. We're talking multiple gigabits at insane ranges with very little power. That is a lot more simultaneous voice than HAM radio or cellular service (or even wimax) can provide. Wimax is a joke next to UWB's potential, but with current limitations on UWB, it looks like UWB is limited to wires (UWB over cable TV coax), ultra-short range uses (Wireless USB), and wifi-type ranges (100 to 300 feet).
300 feet at a thousandth the power of a cellphone. Now imagine if you had the broadcast power of a cellphone in a UWB device.
Totally beyond fighting a patent legally, it is also worth considering as to if it is a good thing that they are patenting a gameplay mechanic. This is a VERY slipper slope.
Where would gaming be right now if somebody had taken out a patent on "a method to activate visual representations of physical objects on a video screen via the push of a button or key"? That one patent would pretty much render games totally non-interactive as you'd effectively have a patent for using any sort of switch, button, or interactive prop in any game. Patenting game mechanics is dangerous and shouldn't be tolerated.
If I were developers producing games for Nintendo consoles, I would be mighty worried about this. I'd also probably threaten to move development to more popular platforms (xbox, PS2) until Nintendo decided to drop the patent.
I've tried giving eMule a whirl, but unfortunately after spending an enormous amount of time trying to both get it working, and once working, actually download files, I've come to the conclusion that it is best relegated to only rare files that can't be found on better services such as BitTorrent.
My main complaints:
1) Setup and use is much too confusing. While BitTorrent has streamlined the process by integrating such things as the "server" (tracker) into the torrent file, eMule tries to manage a list of servers, and doesn't seem to do a very good job of it.
2) It doesn't "just work". Getting your client to connect to the kademlia network is a nightmare, and after the client launches, IF you have previously been on the network, you CAN expect it to connect. Eventually. Azureus, on the other hand, connects to it's Kademlia network in under a minute, and it works every time. Azureus can also use UPnP to autoconfigure your router for BitTorrent use.
3) Downloads are slow. I thought I had left behind queues back in the days of fserves and Kazaa. There is nothing like having a file sit at 0% for several days because all the clients that have the file report that their queues are full. BitTorrent's method of isolating client instances into seperate swarms has eliminated this problem. Some clients, such as Azureus, have support for multiple swarms in one client instance, but ensure that each swarm is being properly handled, unlike eMule and it's queues (and queue limits).
4) It is hard to search. If I do a search one minute on eMule, and then try a minute later, I get quite different search results, and most of the results have very few peers. With BitTorrent, I frequent the few search sites that I use, and get consistant, fast search results. Usually what I want to download has quite a few peers.
5) eMule "swarms" have tons of useless peers. People who are leeching, or have full queues, or long queues, or are seeding too many files. In a BitTorrent swarm, EVERYBODY is uploading, because if they don't, nobody is going to upload to them, and they aren't going to get very far. BitTorrent users also tend to be dealing with less files at once (Such as only one or two), so they can "concentrate" on those files. An eMule client could be seeding hundreds or thousands of files.
I will give eMule one thing, it DOES have a lot of rare stuff. It's very hard to download, as I spent a week downloading a 90MB file, but it was sufficiently rare that it was worth it. I will continue to use eMule for when I just can't find what I'm looking for elsewhere, but for more popular files, BitTorrent is a heck of a lot faster.
The only real advantage of eMule, as I see it, other than having rare files, is that it is a tad more decentralized. Yes, it still has central servers which isn't, but a client can rely entirely on the Kademlia network (considering he can get the bloody thing bootstrapped with no servers). BitTorrent doesn't quite work like this yet. Trackers are now optional due to Azureus's own Kademlia network, and many torrents don't include a tracker at all (Of course this makes them azureus-only since no other BT client has a kademlia implementation that is compatible, or as good). BitTorrent still, no matter what else, requires a source of Torrent files, and that is usually going to be a web site.
I suppose that technically there is no reason that torrent files couldn't be served up via Azureus's kademlia network... I'm not sure I want that to happen though, as the centralized source that is websites like TorrentSpy and PirateBay just work faster and more reliably than decentralized search solutions. Still, in a pinch...
Sorry, you're not going to get an accurate look of your web site in IE by running it under Wine. For one thing, Wine doesn't render things exactly like Windows, and for another, all the fonts would be quite off.
So no, Wine doesn't fix that. You still need to (or should) be running IE on Windows. VMware and similar programs are rather handy for this, as you can have a suspended state already running IE that starts up about as fast as IE itself would otherwise;)
Well, seeing as how the flash EULA prohibits every system there is no native Flash client for, it really doesn't matter if Wine runs on non-Linux systems, does it?
It all boils down to, how many non-webbrowser applications are out there that require the user to have Flash seperately installed (and not integrated into the app)? In my experience such programs tend to use (or be) Shockwave or some such thing.
I was about to suggest the same thing. The guy is a Mac user, the first thing he should have thought of was the Mac Mini. They are (relatively) cheap at just under $500, draw very little power (Enough to run on a battery modded into the case), and can run OSX or Linux. I hear Ubuntu works quite well on macs, as there is a guy here at the office who runs Ubuntu on his powerbook G3.
Most canadian ISPs. Really, like sympatico.ca, videotron.ca, rogers.ca, telus.ca, cogeco.ca, etc? I can't think of any other major Canadian ISPs. They probably have some more cable companies out west or something, but all the major ones I can think of are.ca.
That's not my point though, my point is that he never LEFT, Call for Help has always been around, it was just only in Canada. Now it will also air in the US, but they never stopped making it.
That's not the big problem, because here in Canada, it was the high paid lawyers of the incumbent ISPs like Bell Canada that argued such things. They won, and Bell didn't have to give out names for the IPs.
Point, though the less media used, the less assets that had to be created. I think my other points stand though, such as the limited power of the system.
It doesn't take nearly as much effort for an artist to put out a 1,000 poly model with a 256x256 texture as it does a 1 million poly model normal mapped onto a 5,000 poly model with a 512x512 texture.
Notice the use of the words "sites like". The MPAA isn't using Suprnova's log files because Suprnova shut themselves down, and didn't have any reason to give log files to anyone.
Webserver logs wouldn't record the information you refer to, because the trackers usually run their own web server; you're not going to have it as part of your standard Apache log.
Furthermore, even if you did have webserver logs from the tracker, it is still not direct proof. I can send requests to the tracker that say whatever I want. I can send a requset to the tracker indicating that I have uploaded 100GB of data even though I'm not even running a BitTorrent client.
Log files are really not going to help them here, the only way to prove it would have been if they connected directly to the swarm and seen if the IPs sent them any copyrighted data. Since the swarms are long dead this won't work.
That's the problem, though, isn't it? I'm going to totally ignore any ethical questions and look at this from a technological standpoint: torrent site log files are not proof of infringement.
The MPAA has a bunch of IPs that they identified via the log files as downloading the torrent files. The problem is that the torrent files are just metadata, they don't have any copyright content in them. Downloading such a file doesn't mean a user committed copyright infringement, only that they might have. Certainly users may have downloaded a torrent file but never did anything with it. That is, just left it sitting around or deleted it.
Normally in a court case this might not be a problem. But the MPAA isn't sueing people, they're sueing john does. They have the IP addresses, and they are sueing the people behind those IP addresses. The MPAA needs to prove to the court that these IP addresses commited copyright infringement in order to get the names of the people out of the ISPs via a court order. But since the only information they have is that the IPs downloaded torrent files, they have no direct proof.
IIRC, in Canada it was ruled that such things were NOT enough to force the ISPs to give up customer/IP matches. I wouldn't be surprised if the courts in the US denied the MPAA's requests to get these IPs turned into names either.
Am I saying it's impossible? Well, no, the US courts have a tendency to not rule logically when it comes to such issues, as the cases often go before judges that really have no idea what is going on. Why is this the case? I don't know, it could be any number of reasons, but my bet is that either the US court system is overburdened and these types of cases can't get assigned to the proper judges because there aren't enough judges, or that the MPAA chooses their judges carefully.
1) The PSP has a lower resolution screen. This means stuff doesn't have to be as detailed 2) The PSP isn't as powerful as a PS2, as I understand it it is somewhere between a PS1 and PS2 3) UMDs don't have as much capacity as a DVD, let alone a dual-layer DVD. UMDs are 1.8GB IIRC. You can't fit as much game media.
The cost of developing a game with lower detail assets is a lot less.
Don't rule it out entirely; from a recent interview with J Allard:
Q: Why is the hard drive so highly priced? A 20GB hard drive now a days goes for about 20-30... why $100? I believe this will deter alot of sales.. A: the 20 gb hard drive is a 2.5 inch user servicable drive and is more expense than a pc "crack the box" drive. it's one of the reasons we pushed to create a compelling premium bundle. one of the reasons that we designed a user removable hard drive is in direct response to the hard core gaming audience to make it easier to take game saves, game maps, soundtracks, etc. easily to their friends house or lan party. they also wanted the ability to upgrade to larger capacity drives. and if the drive is not present because someone in the house took it on the road, you still want to be able to use the console for movies, music or games.
Note the section "upgrade to larger capacity drives". This might simply mean that Microsoft will make larger drives available, or it might mean that Microsoft may allow for user upgrades to cater to the "hard core" audience.
Sorry, I meant failed so far, not failed-it's-all-over. To date the PSP has been a failure, but as I mentioned if Sony were to do even some of the things I suggested (Especially the games points as you pointed out) they could potentially still turn it into a viable product.
$100 US gets you a 60GB 2.5" notebook drives at retail. While the "250GB" comment is just plain ignorance, the fact remains that Microsoft is overcharging for the hard drive, charging the price of a 60GB drive for a 20GB drive.
Slashdot Mirror
Yes, which I gather is rather how the PassMe works. It is a device that plugs into the DS slot, and you then plug a DS game into the PassMe. The PassMe uses the game for authentication, but redirects execution to the GBA slot.
This is the current method for running homebrew games. It stands to reason that an official game can do the same thing by itself. I suppose it is possible that we might see an update to the Play-Yan that incldues a DS cart to run the required DS code, but who knows how flexible the Play-Yan is. That is, how much it can be modified via firmware.
You're right though about them probably not messing with it... being compatible with so many consoles all at once is awesome... heh.. when do we start seeing people putting play-yans in gamecube game boy players and making a Nintendo HTPC? :P
:)
An interesting thought, and one that is almost possible. The Play-Yan can actually decode video up to about 352x288, but can only display it at 240x160 due to the limitations of the GBA screen. If the GB player didn't have to follow the GBA resolution requirements it could certainly allow the GameCube to play back cable-TV quality content.
As it is now people will likely be able to use existing podcatchers and vidcatching clients with the play-yan and just sync to the SD card, so wifi syncing of podcasts/etc isn't really neccesary, but would be cool.
Not quite. The Play-Yan, at least with the new firmware, is only halfway there. It supports the MP4 fileformat, and it is very easy to encode/transcode for/to it with ffmpeg. However it is highly unlikely that existing content on the internet will play without transcoding. This probably isn't an issue though. ffmpeg is quite fast, it is opensource, and as a command line tool it should be easy to throw into whatever pipeline you want to use to get content onto the Play-Yan. Simply set your setup to transcode the file before copying it onto the SD card and you are set.
HOWEVER I would LOVE my iPod to wirelessly sync and if Nintendo were to do this with the Play-Yan I think we'd see Apple push that feature through pretty quickly given the large GBA install base and that with the Play-Yan Nintendo is effectively competing with Apple.
Ah, but the GBA install base is only a potential. It only becomes a real competitor if the Play-Yan install base is significant. 100 million people could own GBAs, but if Nintendo only sells 1 million Play-Yans, they aren't exactly cutting into the iPod Shuffle marketspace.
Not to mention that the cost of a GBA, plus Play-Yan, plus 1GB SD card exceeds the cost of a iPod Shuffle. The 1GB iPod Shuffle goes for about $129 US, while if we say the GBA can be had for $50, the Play-Yan is $50, and perhaps $100 for a decent 1GB SD card, we're already approaching double the cost of an iPod Shuffle.
Of course, the iPod Shuffle doesn't play video, nor does it play games, and it doesn't even have a screen, so that extra $70 gets you a lot of extra functionality. Still, I think the two market spaces are far enough apart that they won't interfere with eachother.
It should be noted that one of the reasons the Play-Yan works more reliably than other unofficial solutions is that the Play-Yan has dedicated decoding hardware onboard in the form of an MPEG-4 decoder chip. This is how it manages to decode 352x288 video at 1mbit with 320kbit AAC audio in realtime. Even writing your own video playing solution for the gameboy and running it in an emulator, it would be unlikely that you'd be able to match the Play-Yan's performance. However, you would certainly be able to get some video decoding working; the generation 2 Gameboy Movie Player accessory (The predecessor to the M3) relied entirely on the Gameboy CPU, if I recall correctly. It was forced to use special audio and video codecs.
Of course a GBA emulator for the iPod is still really cool
While streaming podcasts and videos seems neat at first thought, I don't think in practice it would be all that handy. Any place I have a wifi connection I'd rather be using something like a laptop. If I'm at home I'd rather not be watching stuff on the small screen of a DS, and even if I wanted to, I could copy stuff to the SD card.
Extending the Play-Yan to take advantage of the DS's capabilities would be nice, though unlike you I'd say that using the full screen size would be more important than stylus support. After all, once you're watching/listening to something, you're non-interactive, but using all the screen instead of black borders around the image would certainly improve the user experience.
I suppose it IS possible to do this with the play-yan. Since Nintendo can change the DS's firmware all they want, it is certainly possible for them to add support for this to the DS itself. After all, hacked firmware is already available to do it, the difference is that Nintendo would be able to apply security so that you can't just run any DS code off the GBA slot. However without knowing more about how the Play-Yan and DS interact, I don't know if you could also upgrade that with a simple software update.
So while it is possible to get the DS doing what you want with a simple software update, I think that a hardware update might be needed for the Play-Yan. I'm no expert though, I'm only guessing.
It doesn't look like they have any immediate plans to do this, though. Nintendo seems to think the Play-Yan is good enough, and it might very well be; there is a lot to be said for having ONE single product that will work on the GBA, GBA SP, GBA Micro, and DS, without modification. That certainly helps keep the costs down rather than having to produce a seperate unit for the DS. I would also guess that part of the reason they're doing it this way for now is that the number of DS users is currently tiny compared to the number of GBA users.
Confusing? How? Did you examine the guide at emule-project.net? Or are you just assuming that because BitTorrent (BT) does everything for you emule will do the same?
Yes, I RTFMd. Elitist attitudes on the part of supporters and developers are not usually conductive to popular software, though sometimes the usefulness of the product outweighs that. Much (most?) of BitTorrent's success, and what propelled it beyond eDonkey/eMule, was that it was very simple. On the other hand, I work for a company that produces a linux distribution DESIGNED to do absolutely as much as it can without user input, so maybe I'm just biased. We call such things autonomic software.
Substantiate and justify this please. (Lists of servers are largely irrelevant. One server with a large number of users is enough. See +++ below.)
The number of known servers was erratic and went up and down greatly, which would seem to indicate that either most of the servers are extremely unreliable, or eMule was doing something wrong.
Kademlia (kad) is fully p2p, no servers. You need previously-known contacts to connect. Every time you download or upload a file part from/to a client which *is* on kad, your client records that person as a contact. When you start off, you have no contacts, you need to be patient, and in any case you dont have to use kad.
For the server method, you only *need* one server to start - your client will learn about other servers +++ from other clients as you exchange file parts. You can *google* for server lists too, if you must. There may even be a server list linked from emule-project.net
This is what centralized bootstrapping servers are for. This is the approach Azureus takes, and it seems to me like it is a lot more effective.
Googling for server lists? Don't make me laugh. I tried that, nearly every single one I tried was no longer available.
Downloads are not *instant*. Yes, there is the queuing system. Please explain to me why you should jump ahead of everyone else who is already waiting for a file? The source's bandwidth is a limited resource. emule slices by time, I'm guessing BT slices by speed. Incidentally, if you are downloading a large, popular file, receiving several parts are once, emule can really eat bandwidth. It comes down to the number of people sharing a file, ultimately.
And this is where you see the divide in usefulness. BitTorrent is much better oriented at moving large amounts of data very quickly. eMule is best suited for locating a much larger range of content. New releases on BitTorrent tend to have thousands, even tens of thousands of peers, and they're all visible through the tracker or kademlia. Every peer is (usually) concentrating on just that one file. With eMule, every peer is handling every file. This is why BitTorrent is better for the content available on it.
At least it *has* a built-in search facility. Different search results are caused by the nature of the search mechanism (more so for kad). The search is *not* an index (unlike, say, google). Also, emule tends not to do a full search if it quickly finds >50 unique matches. And the total number of unique matches is limited to 300. With BT, you're searching (fixed) index sites. emule has equivalents, such as the-realworld, osloskop, osiolek, if you care to look.
And I'm saying that that built in search isn't as good as it should be. If those three sites you gave are examples of the quality of eMule index sites, I'll steer clear. the-realworld have shut themselves down, osloskop has a buggy interface (I keep selecting english, it keeps displaying default language), an overabundance of flash ads (They even pop up and cover the page) that suck CPU power like no tommorow, and typical searches for new releases only returns extremely small result sets for out of date content. osiolek at least had a clean, non-buggy, stable interface, but again suffered from extremely small result sets.
TorrentSpy and PirateBay seem to work better as
It is just a GBA title. On the DS it still works, but at GBA resolution (Which is a lower than the DS).
None of this matters for music of course, but for video it does.
The restriction comes from this using the GBA socket. It has to, really, since the DS socket is so tiny. But because it uses the GBA socket, it has to stay in GBA mode. The DS is very strict about that, and it requires hacked firmware, or a PassMe (goes into DS socket, plug DS game into passme, passme redirects DS execution to GBA slot).
The M3 uses a passme-type device. Despite the fact that the M3 uses the GBA slot and works on GBA, thanks to the hardware hack it is also able to run in DS mode at native res.
The M3's site can be found at http://www.m3adapter.com/
Of course, the M3 isn't out yet, and I have a GBA, so the added bulk and probably added cost isn't really worth it for me.
I've been debating importing one for quite some time. Originally I discarded the idea because it turned out that videos encoded for the thing could only handle mono 8khz audio (Yes, eight kilohertz), which sounded horrible. However, a recent firmware update added support for AAC audio in the videos, allowing up to 320kbit 48khz stereo.
What put me off importing is the price; the unit costs $50 US in japan, but the importers sell it for $80, even before shipping costs. I understand they want to make a profit, but a 60% markup over retail is a bit much. Because it is expected to sell for $50 when it comes to North America, I think I'll probably just wait for it to be available here instead of importing.
When you think about it, the unit is really rather impressive. A hardware MPEG-4 decoder that can handle video at over a megabit, and AAC audio over 320kbit, at the same time, and it costs only $50.
My laptop also has an SD slot, so I can save some cash on an SD reader.
The only downside of the play-yan is that while it can be used in the DS, it only displays content at GBA resolution; the upcoming M3, a similar device, uses a PassMe type solution to allow it to run both in a GBA and on a DS at native res. This means that if I purchase the Play-Yan for my GBA, if I get a DS I won't be able to take advantage of the additional screen space.
Oh well. I'll probably still pick one up when it launches here.
This is why I am very frustrated at the FCC's limitations on UWB broadcast signal strengths. UWB devices are resistant to interference, and can have enormous ranges at very low power outputs. Not to mention enormous bandwidth and the potential for an enormous number of users. We're talking multiple gigabits at insane ranges with very little power. That is a lot more simultaneous voice than HAM radio or cellular service (or even wimax) can provide. Wimax is a joke next to UWB's potential, but with current limitations on UWB, it looks like UWB is limited to wires (UWB over cable TV coax), ultra-short range uses (Wireless USB), and wifi-type ranges (100 to 300 feet).
300 feet at a thousandth the power of a cellphone. Now imagine if you had the broadcast power of a cellphone in a UWB device.
Totally beyond fighting a patent legally, it is also worth considering as to if it is a good thing that they are patenting a gameplay mechanic. This is a VERY slipper slope.
Where would gaming be right now if somebody had taken out a patent on "a method to activate visual representations of physical objects on a video screen via the push of a button or key"? That one patent would pretty much render games totally non-interactive as you'd effectively have a patent for using any sort of switch, button, or interactive prop in any game. Patenting game mechanics is dangerous and shouldn't be tolerated.
If I were developers producing games for Nintendo consoles, I would be mighty worried about this. I'd also probably threaten to move development to more popular platforms (xbox, PS2) until Nintendo decided to drop the patent.
I've tried giving eMule a whirl, but unfortunately after spending an enormous amount of time trying to both get it working, and once working, actually download files, I've come to the conclusion that it is best relegated to only rare files that can't be found on better services such as BitTorrent.
My main complaints:
1) Setup and use is much too confusing. While BitTorrent has streamlined the process by integrating such things as the "server" (tracker) into the torrent file, eMule tries to manage a list of servers, and doesn't seem to do a very good job of it.
2) It doesn't "just work". Getting your client to connect to the kademlia network is a nightmare, and after the client launches, IF you have previously been on the network, you CAN expect it to connect. Eventually. Azureus, on the other hand, connects to it's Kademlia network in under a minute, and it works every time. Azureus can also use UPnP to autoconfigure your router for BitTorrent use.
3) Downloads are slow. I thought I had left behind queues back in the days of fserves and Kazaa. There is nothing like having a file sit at 0% for several days because all the clients that have the file report that their queues are full. BitTorrent's method of isolating client instances into seperate swarms has eliminated this problem. Some clients, such as Azureus, have support for multiple swarms in one client instance, but ensure that each swarm is being properly handled, unlike eMule and it's queues (and queue limits).
4) It is hard to search. If I do a search one minute on eMule, and then try a minute later, I get quite different search results, and most of the results have very few peers. With BitTorrent, I frequent the few search sites that I use, and get consistant, fast search results. Usually what I want to download has quite a few peers.
5) eMule "swarms" have tons of useless peers. People who are leeching, or have full queues, or long queues, or are seeding too many files. In a BitTorrent swarm, EVERYBODY is uploading, because if they don't, nobody is going to upload to them, and they aren't going to get very far. BitTorrent users also tend to be dealing with less files at once (Such as only one or two), so they can "concentrate" on those files. An eMule client could be seeding hundreds or thousands of files.
I will give eMule one thing, it DOES have a lot of rare stuff. It's very hard to download, as I spent a week downloading a 90MB file, but it was sufficiently rare that it was worth it. I will continue to use eMule for when I just can't find what I'm looking for elsewhere, but for more popular files, BitTorrent is a heck of a lot faster.
The only real advantage of eMule, as I see it, other than having rare files, is that it is a tad more decentralized. Yes, it still has central servers which isn't, but a client can rely entirely on the Kademlia network (considering he can get the bloody thing bootstrapped with no servers). BitTorrent doesn't quite work like this yet. Trackers are now optional due to Azureus's own Kademlia network, and many torrents don't include a tracker at all (Of course this makes them azureus-only since no other BT client has a kademlia implementation that is compatible, or as good). BitTorrent still, no matter what else, requires a source of Torrent files, and that is usually going to be a web site.
I suppose that technically there is no reason that torrent files couldn't be served up via Azureus's kademlia network... I'm not sure I want that to happen though, as the centralized source that is websites like TorrentSpy and PirateBay just work faster and more reliably than decentralized search solutions. Still, in a pinch...
Sorry, you're not going to get an accurate look of your web site in IE by running it under Wine. For one thing, Wine doesn't render things exactly like Windows, and for another, all the fonts would be quite off.
;)
So no, Wine doesn't fix that. You still need to (or should) be running IE on Windows. VMware and similar programs are rather handy for this, as you can have a suspended state already running IE that starts up about as fast as IE itself would otherwise
Well, seeing as how the flash EULA prohibits every system there is no native Flash client for, it really doesn't matter if Wine runs on non-Linux systems, does it?
It all boils down to, how many non-webbrowser applications are out there that require the user to have Flash seperately installed (and not integrated into the app)? In my experience such programs tend to use (or be) Shockwave or some such thing.
Perhaps I'm missing some sort of in-joke, but why would you want to run Flash under Wine when there is a native Linux version?
I was about to suggest the same thing. The guy is a Mac user, the first thing he should have thought of was the Mac Mini. They are (relatively) cheap at just under $500, draw very little power (Enough to run on a battery modded into the case), and can run OSX or Linux. I hear Ubuntu works quite well on macs, as there is a guy here at the office who runs Ubuntu on his powerbook G3.
Most canadian ISPs. Really, like sympatico.ca, videotron.ca, rogers.ca, telus.ca, cogeco.ca, etc? I can't think of any other major Canadian ISPs. They probably have some more cable companies out west or something, but all the major ones I can think of are .ca.
That's not my point though, my point is that he never LEFT, Call for Help has always been around, it was just only in Canada. Now it will also air in the US, but they never stopped making it.
He's not really returning, he never went anywhere. Call for Help never left the air (Not long anyhow). It was just moved to G4TechTV Canada.
.ca to .com ;)
I'm not sure why such a big deal is being made over this, it's really not a big thing, he's just moving from
That's not the big problem, because here in Canada, it was the high paid lawyers of the incumbent ISPs like Bell Canada that argued such things. They won, and Bell didn't have to give out names for the IPs.
Point, though the less media used, the less assets that had to be created. I think my other points stand though, such as the limited power of the system.
It doesn't take nearly as much effort for an artist to put out a 1,000 poly model with a 256x256 texture as it does a 1 million poly model normal mapped onto a 5,000 poly model with a 512x512 texture.
Notice the use of the words "sites like". The MPAA isn't using Suprnova's log files because Suprnova shut themselves down, and didn't have any reason to give log files to anyone.
Webserver logs wouldn't record the information you refer to, because the trackers usually run their own web server; you're not going to have it as part of your standard Apache log.
Furthermore, even if you did have webserver logs from the tracker, it is still not direct proof. I can send requests to the tracker that say whatever I want. I can send a requset to the tracker indicating that I have uploaded 100GB of data even though I'm not even running a BitTorrent client.
Log files are really not going to help them here, the only way to prove it would have been if they connected directly to the swarm and seen if the IPs sent them any copyrighted data. Since the swarms are long dead this won't work.
These people did not.
That's the problem, though, isn't it? I'm going to totally ignore any ethical questions and look at this from a technological standpoint: torrent site log files are not proof of infringement.
The MPAA has a bunch of IPs that they identified via the log files as downloading the torrent files. The problem is that the torrent files are just metadata, they don't have any copyright content in them. Downloading such a file doesn't mean a user committed copyright infringement, only that they might have. Certainly users may have downloaded a torrent file but never did anything with it. That is, just left it sitting around or deleted it.
Normally in a court case this might not be a problem. But the MPAA isn't sueing people, they're sueing john does. They have the IP addresses, and they are sueing the people behind those IP addresses. The MPAA needs to prove to the court that these IP addresses commited copyright infringement in order to get the names of the people out of the ISPs via a court order. But since the only information they have is that the IPs downloaded torrent files, they have no direct proof.
IIRC, in Canada it was ruled that such things were NOT enough to force the ISPs to give up customer/IP matches. I wouldn't be surprised if the courts in the US denied the MPAA's requests to get these IPs turned into names either.
Am I saying it's impossible? Well, no, the US courts have a tendency to not rule logically when it comes to such issues, as the cases often go before judges that really have no idea what is going on. Why is this the case? I don't know, it could be any number of reasons, but my bet is that either the US court system is overburdened and these types of cases can't get assigned to the proper judges because there aren't enough judges, or that the MPAA chooses their judges carefully.
Not quite as much as a PS2 game. My reasons:
1) The PSP has a lower resolution screen. This means stuff doesn't have to be as detailed
2) The PSP isn't as powerful as a PS2, as I understand it it is somewhere between a PS1 and PS2
3) UMDs don't have as much capacity as a DVD, let alone a dual-layer DVD. UMDs are 1.8GB IIRC. You can't fit as much game media.
The cost of developing a game with lower detail assets is a lot less.
Don't rule it out entirely; from a recent interview with J Allard:
Q: Why is the hard drive so highly priced? A 20GB hard drive now a days goes for about 20-30... why $100? I believe this will deter alot of sales..
A: the 20 gb hard drive is a 2.5 inch user servicable drive and is more expense than a pc "crack the box" drive. it's one of the reasons we pushed to create a compelling premium bundle.
one of the reasons that we designed a user removable hard drive is in direct response to the hard core gaming audience to make it easier to take game saves, game maps, soundtracks, etc. easily to their friends house or lan party. they also wanted the ability to upgrade to larger capacity drives. and if the drive is not present because someone in the house took it on the road, you still want to be able to use the console for movies, music or games.
Note the section "upgrade to larger capacity drives". This might simply mean that Microsoft will make larger drives available, or it might mean that Microsoft may allow for user upgrades to cater to the "hard core" audience.
There is a dip in spam? Who cares! Almost all of the junk mail I get these days are phishing mails, not spam.
Sorry, I meant failed so far, not failed-it's-all-over. To date the PSP has been a failure, but as I mentioned if Sony were to do even some of the things I suggested (Especially the games points as you pointed out) they could potentially still turn it into a viable product.
$100 US gets you a 60GB 2.5" notebook drives at retail. While the "250GB" comment is just plain ignorance, the fact remains that Microsoft is overcharging for the hard drive, charging the price of a 60GB drive for a 20GB drive.
My notebook has a 15" screen and weighs about 2.5 to 3 kg. At the time it also has the fastest GPU available, the Mobility Radeon 9700.