Good console, but seriously lacking in the software department.
Oh, come on! Sure, the SMS had a smaller library than the NES, but it had some great games: R-Type, Quartet, Fantasy Zone, Wonderboy in Monsterland, Alex Kidd in Miracle World, Double Dragon, Time Soldier, Shinobi, Penguin Land... the list goes on. And, while the NES library is vast, the amount of sheer *crap* is equally vast.:)
I doubt that it really uses 20MB. It just appears to use 20MB. What's almost certainly really happening is that it's mapping 20MB more of virtual memory, of which very little is actually used. For example, if the program needs a class or two from some JAR, the JVM will mmap() the entire JAR file, reserving virtual address space for all of it, even though only the pages that actually get read will be faulted in and consume real RAM. So several megabytes of virtual address space has been "consumed", but only a few KB of actual RAM is used
And just to further this point, modern JVMs will, if the OS allows it (like, say, Linux), mark unused pages as free for use by the OS. So, the JVM may allocate a very large hunk of memory, then, through garbage collection, free up a bunch of that memory and then release the pages back to the OS. However, process monitoring tools may not properly reflect this, and simply display the peak amount of memory the JVM has requested.
Huh... so, by that logic, we should take the long-lived radioactive waste from nuclear plants (the stuff that we currently spend so much effort trying to bury in mountains), aerosolize it, and spray it into the atmosphere! Man, why hasn't anyone else thought of this?!?
I got an Ogg-player for Palm Tungsten, however it doesn't allow you to delete files, so I have to re-format the MMC every time I want to change my selection.
*Why* do you want your audio player to delete your files for you? Haven't you installed Filez or something comparable?
And barring that, you didn't consider buying a $20 USB2 card reader?
While I appreciate the Perl support here, I don't think anyone would put more than a couple of hours' worth of effort into a game that doesn't support pretty 3D stuff on modern graphics cards.
Okay:
a) Not every game needs to be 3D. This attitude is why gameplay has languished in the name of pretty graphics.
b) With the continued success of things like the GBA, it's clear that there's plenty of interest in 2D games.
c) The general approach to making games is the same, whether 2D or 3D. Perl+SDL creates a low-barrier environment for beginners to try their hand at game creation.
d) It takes a lot more work to create art for a 3D game (models, textures, etc), which is just a further barrier for hobbyists, especially beginners.
Uhh, no, they're not. While they have 640x480 resolution, they render 320x240 graphics. Granted, this increases the fidelity of the image, but the amount you can actually fit on the screen does not change.
Now, you can get a tool like SE_VGA to switch the PDA to true 640x480 resolution, but this renders most text practically unreadable, and may destabilize your PDA, to boot. Moreover, there are many applications which aren't designed to run at true 640x480.
The funny thing is, in the PDA marketplace, crashiness is, apparently, the norm. Windows Mobile is hardly a stable platform (heck, all the stories about soft resets with the Axim and similar devices scared me away), with ActiveSync being the source of many of those problems. Meanwhile with the TX, Palm has proven that it can produce a fairly stable PDA at a very competative price.
Which brings me to my ultimate point: with all this Palm bashing, tell me, how are PPCs with Windows Mobile any better? Certainly, from a price/features standpoint, Palms are very competative (heck, a comparable PPC to the TX costs $100 more, and it's still runs at a measly 240x320 display, despite being coined 'VGA' PDA). As I mentioned previously, from a stability standpoint, Palm is as good, if not a bit better. There's plenty of apps for both, although development for the Palm is more open, AFAIK. And, of course, Palm has better platform support, thanks to projects like JPilot.
So, what's the deal? I ask because, I recently entered the PDA market, having never owned one before (and, frankly, I was really leaning toward a PPC before I started researching), and without question, the TX struck me as one of the best options available at that price point.
There's no way that'll work. There are a ton of websites (and I suspect even more mail servers, etc) out there with self-signed certificates, because they only care about encrypting the session and are unconcerned with identity verification.
No, what they *should* be using is SSL. It's standard. There's plenty of libraries for all common languages. And an SSL negotation looks the same, regardless of the data being transported, meaning your ISP would be unable to tell the difference between an HTTPS download and a BitTorrent-S download.
Uhhh, once the encrypted session is negotiated, the only in-the-clear headers are the IP/TCP headers. Moreover, SSL negotiations all look the same, so if the implementers were to use SSL (which I don't think they do... but that's a mistake, IMHO), then there would be no way to tell one SSL-encrypted session from another.
You didn't RTFA, did you? They're using layer-7 filtering to shape BitTorrent traffic, in both directions, throttling it down to a mere trickle. I know this because I'm a victim of it.:(
Riiight... so the ISPs are gonna throttle HTTPS? What about SFTP transfers? Hell, what about POPS and SMTPS? Because there's no way, in principle, to tell the difference between these (legitimate) protocols and an encrypted (supposedly illegitimate) BitTorrent stream.
One wire, different frequencies. Or are you not able to use your phone when your DSL connection is enabled? Moreover, the traffic for the two services ends up in vastly different infrastructure (DSLAM-terminated connection into a packet network vs a circuit switched network).
Put another way, OTA radio and TV are clearly different services, but they use the same 'wire' (EM wave propagation).
Re:Soda: Lots of calories and no nourishment
on
Obesity Contagious?
·
· Score: 1
Assuming, that is, one lived on a diet comprised entirely of Cola...
Re:People are Obese regarless of Income or Geograp
on
Obesity Contagious?
·
· Score: 1
Assuming that you didn't metabolize those 110 calories, you're absolutely right.
Re:People are Obese regarless of Income or Geograp
on
Obesity Contagious?
·
· Score: 1
Bullshit... a 325ml can of Coke contains about 110 calories, give or take (assuming, of course, that the nutritional information on the side of the can isn't somehow fabricated). So, assuming my math is correct, that's about 700 calories for a 2L bottle.
Uhh... you do realize that the effect of Gravity is limited by the speed of light, right? Otherwise, you'd be able to use the force of gravity to transmit information faster than the speed of light, which flies in the face of modern physics.
So, to answer your question, no, gravity does not act instantaneously over large distances. In fact, if the sun were to spontaneously cease to exist, the Earth would continue in it's orbit for roughly 8 minutes (IIRC).
Go is cool, except the baroqueness comes out in (1) the scoring (2) all the rule subvariants about time, scoring, ko/superko, etc.
I humbly disagree.:) No child needs to know the intricacies of ever Go ruleset. Just pick one scoring system (Japanese is probably simplest), regular ko (superko is interesting, but certainly not worth introducing early on), and don't even both teaching byoyomi. At this point, Go has a mere handful of rules, and no wonky special cases (aside from Ko), as opposed to Chess with it's 6 pieces, all with different properties, not to mention a variety of more obscure rules.
It's probably easier for a kid to estimate winning/losing in a game of chess.
This is certainly true, and is difficult for even experienced amateur players. OTOH, children are little sponges and can catch on to such things remarkably quickly. Moreover, early on, it's rarely necessary to be able to accurately count score, since games aren't typically that close.
Frankly, I think both games have something to offer, and which to play is really more a matter of taste.
In the end, I think the biggest problem with teaching Go is finding cheap, quality equipment to play with. While you can makeshift a Go board pretty easily, getting at least a cheap wood board + plastic stones can be surprisingly difficult.
The only technological solution I can think of to solve that problem is strong, durable watermarking. If one could apply a watermark to the content that could survive an DA/AD conversion, one could then simply mandate, in law, that recording devices must reject materials that have said watermark (kinda like that dot pattern that exists on US currency that triggers a sort of DRM in photocopiers).
'course, there are a number of problems with this. First, there's all the old recording technology lying around. But, hey, wait 50 years and a lot of that stuff simply won't work anymore. Second, one has to create a durable, mostly transparent watermark that can survive a potentially very lossy DA/AD conversion. I know there are folks working on this problem, but I'm not sure what kind of progress has been achieved.
Slashdot Mirror
Good console, but seriously lacking in the software department.
:)
Oh, come on! Sure, the SMS had a smaller library than the NES, but it had some great games: R-Type, Quartet, Fantasy Zone, Wonderboy in Monsterland, Alex Kidd in Miracle World, Double Dragon, Time Soldier, Shinobi, Penguin Land... the list goes on. And, while the NES library is vast, the amount of sheer *crap* is equally vast.
I doubt that it really uses 20MB. It just appears to use 20MB. What's almost certainly really happening is that it's mapping 20MB more of virtual memory, of which very little is actually used. For example, if the program needs a class or two from some JAR, the JVM will mmap() the entire JAR file, reserving virtual address space for all of it, even though only the pages that actually get read will be faulted in and consume real RAM. So several megabytes of virtual address space has been "consumed", but only a few KB of actual RAM is used
And just to further this point, modern JVMs will, if the OS allows it (like, say, Linux), mark unused pages as free for use by the OS. So, the JVM may allocate a very large hunk of memory, then, through garbage collection, free up a bunch of that memory and then release the pages back to the OS. However, process monitoring tools may not properly reflect this, and simply display the peak amount of memory the JVM has requested.
Huh... so, by that logic, we should take the long-lived radioactive waste from nuclear plants (the stuff that we currently spend so much effort trying to bury in mountains), aerosolize it, and spray it into the atmosphere! Man, why hasn't anyone else thought of this?!?
I got an Ogg-player for Palm Tungsten, however it doesn't allow you to delete files, so I have to re-format the MMC every time I want to change my selection.
*Why* do you want your audio player to delete your files for you? Haven't you installed Filez or something comparable?
And barring that, you didn't consider buying a $20 USB2 card reader?
True, it traps most sulfur and other nasty stuff and gives you a twice-through before all that carbon winds up in the atmosphere,
Which is then later drawn out of the atmosphere by the algae being used to produce the next batch of oil. How is this not a closed loop?
While I appreciate the Perl support here, I don't think anyone would put more than a couple of hours' worth of effort into a game that doesn't support pretty 3D stuff on modern graphics cards.
Okay:
a) Not every game needs to be 3D. This attitude is why gameplay has languished in the name of pretty graphics.
b) With the continued success of things like the GBA, it's clear that there's plenty of interest in 2D games.
c) The general approach to making games is the same, whether 2D or 3D. Perl+SDL creates a low-barrier environment for beginners to try their hand at game creation.
d) It takes a lot more work to create art for a 3D game (models, textures, etc), which is just a further barrier for hobbyists, especially beginners.
Uhh, no, they're not. While they have 640x480 resolution, they render 320x240 graphics. Granted, this increases the fidelity of the image, but the amount you can actually fit on the screen does not change.
Now, you can get a tool like SE_VGA to switch the PDA to true 640x480 resolution, but this renders most text practically unreadable, and may destabilize your PDA, to boot. Moreover, there are many applications which aren't designed to run at true 640x480.
women who have already borne a child are considered better marriage prospects.
Well, that and you know she's a) fertile and b) capable of bringing a child to term.
The funny thing is, in the PDA marketplace, crashiness is, apparently, the norm. Windows Mobile is hardly a stable platform (heck, all the stories about soft resets with the Axim and similar devices scared me away), with ActiveSync being the source of many of those problems. Meanwhile with the TX, Palm has proven that it can produce a fairly stable PDA at a very competative price.
Which brings me to my ultimate point: with all this Palm bashing, tell me, how are PPCs with Windows Mobile any better? Certainly, from a price/features standpoint, Palms are very competative (heck, a comparable PPC to the TX costs $100 more, and it's still runs at a measly 240x320 display, despite being coined 'VGA' PDA). As I mentioned previously, from a stability standpoint, Palm is as good, if not a bit better. There's plenty of apps for both, although development for the Palm is more open, AFAIK. And, of course, Palm has better platform support, thanks to projects like JPilot.
So, what's the deal? I ask because, I recently entered the PDA market, having never owned one before (and, frankly, I was really leaning toward a PPC before I started researching), and without question, the TX struck me as one of the best options available at that price point.
There's no way that'll work. There are a ton of websites (and I suspect even more mail servers, etc) out there with self-signed certificates, because they only care about encrypting the session and are unconcerned with identity verification.
No, what they *should* be using is SSL. It's standard. There's plenty of libraries for all common languages. And an SSL negotation looks the same, regardless of the data being transported, meaning your ISP would be unable to tell the difference between an HTTPS download and a BitTorrent-S download.
Uhhh, once the encrypted session is negotiated, the only in-the-clear headers are the IP/TCP headers. Moreover, SSL negotiations all look the same, so if the implementers were to use SSL (which I don't think they do... but that's a mistake, IMHO), then there would be no way to tell one SSL-encrypted session from another.
You didn't RTFA, did you? They're using layer-7 filtering to shape BitTorrent traffic, in both directions, throttling it down to a mere trickle. I know this because I'm a victim of it. :(
Riiight... so the ISPs are gonna throttle HTTPS? What about SFTP transfers? Hell, what about POPS and SMTPS? Because there's no way, in principle, to tell the difference between these (legitimate) protocols and an encrypted (supposedly illegitimate) BitTorrent stream.
One wire, different frequencies. Or are you not able to use your phone when your DSL connection is enabled? Moreover, the traffic for the two services ends up in vastly different infrastructure (DSLAM-terminated connection into a packet network vs a circuit switched network).
Put another way, OTA radio and TV are clearly different services, but they use the same 'wire' (EM wave propagation).
Assuming, that is, one lived on a diet comprised entirely of Cola...
Assuming that you didn't metabolize those 110 calories, you're absolutely right.
Bullshit... a 325ml can of Coke contains about 110 calories, give or take (assuming, of course, that the nutritional information on the side of the can isn't somehow fabricated). So, assuming my math is correct, that's about 700 calories for a 2L bottle.
Except, of course, that FISA is a secret court, meaning it's proceedings are closed and classified.
Now now... that's not lying. That's flip-flopping. ;)
or, put more succinctly by The Simpsons: Don't blame me, I voted for Kodos. :)
Uhh... you do realize that the effect of Gravity is limited by the speed of light, right? Otherwise, you'd be able to use the force of gravity to transmit information faster than the speed of light, which flies in the face of modern physics.
So, to answer your question, no, gravity does not act instantaneously over large distances. In fact, if the sun were to spontaneously cease to exist, the Earth would continue in it's orbit for roughly 8 minutes (IIRC).
Go is cool, except the baroqueness comes out in (1) the scoring (2) all the rule subvariants about time, scoring, ko/superko, etc.
:) No child needs to know the intricacies of ever Go ruleset. Just pick one scoring system (Japanese is probably simplest), regular ko (superko is interesting, but certainly not worth introducing early on), and don't even both teaching byoyomi. At this point, Go has a mere handful of rules, and no wonky special cases (aside from Ko), as opposed to Chess with it's 6 pieces, all with different properties, not to mention a variety of more obscure rules.
I humbly disagree.
It's probably easier for a kid to estimate winning/losing in a game of chess.
This is certainly true, and is difficult for even experienced amateur players. OTOH, children are little sponges and can catch on to such things remarkably quickly. Moreover, early on, it's rarely necessary to be able to accurately count score, since games aren't typically that close.
Frankly, I think both games have something to offer, and which to play is really more a matter of taste.
In the end, I think the biggest problem with teaching Go is finding cheap, quality equipment to play with. While you can makeshift a Go board pretty easily, getting at least a cheap wood board + plastic stones can be surprisingly difficult.
The only technological solution I can think of to solve that problem is strong, durable watermarking. If one could apply a watermark to the content that could survive an DA/AD conversion, one could then simply mandate, in law, that recording devices must reject materials that have said watermark (kinda like that dot pattern that exists on US currency that triggers a sort of DRM in photocopiers).
'course, there are a number of problems with this. First, there's all the old recording technology lying around. But, hey, wait 50 years and a lot of that stuff simply won't work anymore. Second, one has to create a durable, mostly transparent watermark that can survive a potentially very lossy DA/AD conversion. I know there are folks working on this problem, but I'm not sure what kind of progress has been achieved.
Good lord... I've used Perl for a long time, and consider myself reasonable versed in the language, and I had *no* idea this was possible.
OTOH, I'm as likely to blame the idiot programmer who *used* this feature as I am to blame the language designer for providing it.