As I write this, I'm listening to the latest EP from a local unsigned band. I bought this on CD for 3 (British) at their gig at a local venue last night.
They're easily better than much of the junk RIAA labels churn out. All you have to do is put in a bit of effort and find artists that are in it for the music, not for the money.
I will be trying to do this as part of my degree final year project. I intend to produce an abstract widget API which maps on to the local environment at a much higher level, so that apps using it will adopt local UI conventions. That's not the entire project, but a major part of it.
How far I can take it without making it a really ugly API (which I will avoid) remains to be seen, but I'd like to think that it could be made to work, at least from the point of view of dialog box layout, button ordering, menu layouts etc.
I'm sure if it works out I'll put up a site about it when I'm done. If it doesn't, I'll probably just quietly hide away and hope no-one notices! :)
Re:Shouldn't this be true only for J2ME games?
on
Nokia N-Gage Cracked
·
· Score: 1
I think you missed your parent's point. The parent was asking what exactly has been achieved by cracking Nokia's DRM, since your grandparent suggested that the best point about this was that now a PC emulator could play the games.
Most of the similarly-equipped phones to the N-Gage are more expensive, so this crack doesn't seem to have any real benefit to anyone except perhaps those who wish to distribute the games illegally.
Trinity: I can't come with you Neo! Neo: Why? Trinity: I have several thick metal rods passing through my abdomen. Neo: Whoah! That sucks. Trinity: Good luck! [Trinity snuffs it]
That death scene was so boring. It was the only scene in Revolutions which I got bored waiting for it to end. A similar sentiment was applied to the many-Agent-Smiths scene from Reloaded: sure, it was kinda cool at first, but it went on far too long.
I got that The Merovingian represented Satan, but what exactly was the point of him? In particular, all this trainman stuff at the start of Revolutions seem to have no bearing on the rest of the story whatsoever.
It almost feels like The Merovingian could have been left out completely without affecting the overall storyline, but it would require a few adjustments to Reloaded to do so.
My thinking right now is that he was really just there to break things up a little.
I've read his design document completely. I fully intend to use it and other similar systems as references in my project. What I don't intend to do is view his actual implementation, since the design and the implementation of that design are different issues.
I was planning to do something very similar for my final year project this year. I think I'll have to stay well away from his source in case I get "inspired" by any of it and get in trouble for plagarism...
Yes, but this story was about how IP telephony is made more difficult by everyone using NAT. The proposed solution (blocking everything incoming) does not make IP telephony any easier.
That depends on what you mean by "default". By default it wouldn't do any routing at all, but you have to enable routing to use NAT, and unless you then add some firewall rules to stop it routing from the external interface it will forward between all interfaces regardless of source and destination so long as there's something in the routing table telling it where to send the packets.
The routing table will tell it to send packets in your LAN subnet out on the LAN interface, so that's what it will do.
I was simplifying a little. I didn't really want to bring up Ethernet when the OP was clearly confused enough about IP as it is.
However, on most cable systems you share one broadcast medium with a bunch of other customers, all of which would be capable of addressing you at the transport level if they wanted to. (Actually, in many cases they'd be addressing the cable modem rather than the router, but there exist devices which do both)
You're not thinking this through properly. The connection is addressed to the NAT box, so the NAT box will deal with it. It will probably simply ignore it because it doesn't have the need to accept incoming connections, but that isn't protecting your internal machines in any way. The packet was not addressed to your internal machines, so they are not involved in this situation.
With pure NAT and no firewall, I can (theoretically) tell my computer to route packets using your public IP address as a gateway and then connect to your internal IP addresses. The only reason this doesn't work in practice is because most routers on the Internet will drop packets which identify a remote box for routing. This restriction wouldn't exist, for example, on your ISP's network, and if you're on a cable modem, you're probably sharing that network with other customers who are untrusted.
If your NAT is one way, then the packets from the external host will reach your internal computers with their external address intact. On the other hand, if your NAT is two-way the router will rewrite the source address to be its own (internal) address, add it to the connection tracking table and forward it on to your internal host looking like it came from the router itself.
The linux box doing the NAT is also configured to route packets. On your LAN, you would configure the "default gateway" to be that box, and thus cause any packets not destined for an address in your LAN subnet to be sent to the NAT box for routing.
Imagine if a computer at your ISP had a route added to its routing table which causes 192.168.0.0/16 to be routed to your external IP address. This computer will now send any packets destined for an address in your LAN subnet to your router, which will inspect its routing table and see that, for example, 192.168.0.0/16 is to be transmitted out of interface eth0 onto your LAN.
The way you stop this is to configure the router to drop packets on your Internet-facing interface which are addressed to internal hosts. Once you do this, you are using a packet filter (ie a "firewall") in addition to NAT.
At DNS level also. Wildcard records are part of the master record format. Verisign's servers are using a more complex decision than "anything not registered" which is detailed in the IAB report.
If they simply added a wildcard record there would be no spec violation.
Who decided on those names? They are terrible! Having to make a "b" sound twice in quick succession like that makes an awful word. They should have picked a better replacement letter for the "g", such as R: "Merabyte", "Kirabyte" and "Girabyte".
I'm guessing "bi" was chosen because it's the start of "binary". It's still a bad choice.
If you're trying to make your HTML document look identical in all browsers, despite the fact that this should theoretically be possible, your goal is wrong.
Sure, IE interprets a lot of the HTML standards wrong, but I don't see how this shows that Word is broken.
Word is poorly-designed with regard to the assumptions it makes when loading and saving documents, but HTML and IE have little to do with it; the goals of the HTML format and the Word document format are completely different.
I do have a possible explanation, however. Perhaps Microsoft originally intended the Word document format to be similar in purpose to the main 'document' part of a LaTeX source file; it describes the text and text attributes which are then used to typeset the document to fit whatever output media is desired. Word can then load the document (which, remember, is simply chunks of text with simple stylistic attributes) and typeset it to suit the metrics of the output device. They've bolted extra features on afterwards which go against this, such as floating objects which have no relation to the text, and this is where they went wrong, in my opinion.
You picked a bad analogy with RSS. Look around and see how many different interpretations of RSS have resulted from people just looking at other people's source and guessing.
You have RSS documents with invalid characters for the specified charset, disagreement over what the 'link' element is actually for, disagreement about the content of 'description' and whether it should be interpreted as escaped HTML, plain text or escaped HTML where all of the newlines should be converted to <br/>.
It's a mess. Now every RSS parser and application has to make vaugue guesses based on what it finds, and each application makes different guesses meaning that different RSS documents break in different software in differing, interesting ways. This is all because people looked at it and guessed what everything was for rather than working from a single, carefully-worded specification or machine-readable schema.
Storing "number of paragraphs" and "number of lines" seems a little dangerous to me, as that metadata can easily get out of sync if other parts of the document are adjusted.
Loki's business model was broken. For one thing, some of the games they ported had been available for Windows before Loki was well-known or possibly even existed, so users bought the Windows versions unaware that they'd be ported later. Had Loki sold a replacement binary without the data at a much reduced price, requiring users to scoop the original game out of the bargain bucket for a few bucks, they may have done better. They'd probably have to restrict themselves to online distribution rather than retail boxes in that case, however.
A far better situation would be for the original developer to create portable code and simultaneously release all of the versions. Since versions for Linux (and, I assume, MacOS X) will, at first, sell far less copies than Windows, it makes sense to bundle them all on the same disc to avoid pressing copies which will just end up sitting in a warehouse not selling. Later, when people get the idea, selling separate versions might become viable but I still don't really see the point when a one-disc-fits-all situation obviously reduces unsold copies.
The Unreal engine is a good example of portable code. I'm speaking of the original Unreal engine here, but I recall that all of its subsystems were pluggable so that (for example) while the original Windows release supported software rendering and 3Dfx they were later able to supply new plugins to go through DirectX and OpenGL for newer cards.
I'm assuming the architecture of the more recent engines, which were built on the work done for the first, is similar. This means that the porting effort for the Linux version was reduced to writing a new driver or porting an existing driver for each subsystem and then recompiling the core. Far easier than taking Half-life 2's code, which uses DirectX 9 directly.
You expect everyone to pay again for a ported binary?
id's model makes more sense. You buy the Windows version at your favourite games retailer, then you download the port of the executable and run it alongside the data from the CD. That way they don't have to waste money producing linux-only game boxes and CDs that only a minority will buy.
The next logical step would be to include the linux port on the disk with the Windows version, so that both binaries are available right off the bat. I'm told Unreal Tournament 2003 did this, but I do not own that game to check.
Now they need to set things up so that their server records the parameter of the MAIL FROM command and use it to send a message to the sender explaining that though that domain does not exist, they can buy it!
Okay, I admit that I would program much slower while holding a stopwatch in one of my hands. OKAY?!
Re:Take that 9th grade English teacher....
on
Can You Raed Tihs?
·
· Score: 1
"I before E except after C, as long as the word isn't weird."
Sadly, this doesn't have the amiguity when written that it does in speech since you can see the lack of quotation marks around "weird". Yay for double-meaning!
Slashdot Mirror
As I write this, I'm listening to the latest EP from a local unsigned band. I bought this on CD for 3 (British) at their gig at a local venue last night.
They're easily better than much of the junk RIAA labels churn out. All you have to do is put in a bit of effort and find artists that are in it for the music, not for the money.
You can get the icing elsewhere.
I will be trying to do this as part of my degree final year project. I intend to produce an abstract widget API which maps on to the local environment at a much higher level, so that apps using it will adopt local UI conventions. That's not the entire project, but a major part of it.
How far I can take it without making it a really ugly API (which I will avoid) remains to be seen, but I'd like to think that it could be made to work, at least from the point of view of dialog box layout, button ordering, menu layouts etc.
I'm sure if it works out I'll put up a site about it when I'm done. If it doesn't, I'll probably just quietly hide away and hope no-one notices! :)
I think you missed your parent's point. The parent was asking what exactly has been achieved by cracking Nokia's DRM, since your grandparent suggested that the best point about this was that now a PC emulator could play the games.
Most of the similarly-equipped phones to the N-Gage are more expensive, so this crack doesn't seem to have any real benefit to anyone except perhaps those who wish to distribute the games illegally.
Trinity: I can't come with you Neo!
Neo: Why?
Trinity: I have several thick metal rods passing through my abdomen.
Neo: Whoah! That sucks.
Trinity: Good luck! [Trinity snuffs it]
That death scene was so boring. It was the only scene in Revolutions which I got bored waiting for it to end. A similar sentiment was applied to the many-Agent-Smiths scene from Reloaded: sure, it was kinda cool at first, but it went on far too long.
I got that The Merovingian represented Satan, but what exactly was the point of him? In particular, all this trainman stuff at the start of Revolutions seem to have no bearing on the rest of the story whatsoever.
It almost feels like The Merovingian could have been left out completely without affecting the overall storyline, but it would require a few adjustments to Reloaded to do so.
My thinking right now is that he was really just there to break things up a little.
I've read his design document completely. I fully intend to use it and other similar systems as references in my project. What I don't intend to do is view his actual implementation, since the design and the implementation of that design are different issues.
I was planning to do something very similar for my final year project this year. I think I'll have to stay well away from his source in case I get "inspired" by any of it and get in trouble for plagarism...
Yes, but this story was about how IP telephony is made more difficult by everyone using NAT. The proposed solution (blocking everything incoming) does not make IP telephony any easier.
That depends on what you mean by "default". By default it wouldn't do any routing at all, but you have to enable routing to use NAT, and unless you then add some firewall rules to stop it routing from the external interface it will forward between all interfaces regardless of source and destination so long as there's something in the routing table telling it where to send the packets.
The routing table will tell it to send packets in your LAN subnet out on the LAN interface, so that's what it will do.
Remember that your neighbours are on your ISP's network too. Do you trust them all?
I was simplifying a little. I didn't really want to bring up Ethernet when the OP was clearly confused enough about IP as it is.
However, on most cable systems you share one broadcast medium with a bunch of other customers, all of which would be capable of addressing you at the transport level if they wanted to. (Actually, in many cases they'd be addressing the cable modem rather than the router, but there exist devices which do both)
You're not thinking this through properly. The connection is addressed to the NAT box, so the NAT box will deal with it. It will probably simply ignore it because it doesn't have the need to accept incoming connections, but that isn't protecting your internal machines in any way. The packet was not addressed to your internal machines, so they are not involved in this situation.
With pure NAT and no firewall, I can (theoretically) tell my computer to route packets using your public IP address as a gateway and then connect to your internal IP addresses. The only reason this doesn't work in practice is because most routers on the Internet will drop packets which identify a remote box for routing. This restriction wouldn't exist, for example, on your ISP's network, and if you're on a cable modem, you're probably sharing that network with other customers who are untrusted.
If your NAT is one way, then the packets from the external host will reach your internal computers with their external address intact. On the other hand, if your NAT is two-way the router will rewrite the source address to be its own (internal) address, add it to the connection tracking table and forward it on to your internal host looking like it came from the router itself.
By blocking all incoming connections, you still can't accept connections from hosts on the Internet, so nothing is solved.
The linux box doing the NAT is also configured to route packets. On your LAN, you would configure the "default gateway" to be that box, and thus cause any packets not destined for an address in your LAN subnet to be sent to the NAT box for routing.
Imagine if a computer at your ISP had a route added to its routing table which causes 192.168.0.0/16 to be routed to your external IP address. This computer will now send any packets destined for an address in your LAN subnet to your router, which will inspect its routing table and see that, for example, 192.168.0.0/16 is to be transmitted out of interface eth0 onto your LAN.
The way you stop this is to configure the router to drop packets on your Internet-facing interface which are addressed to internal hosts. Once you do this, you are using a packet filter (ie a "firewall") in addition to NAT.
At DNS level also. Wildcard records are part of the master record format. Verisign's servers are using a more complex decision than "anything not registered" which is detailed in the IAB report.
If they simply added a wildcard record there would be no spec violation.
Who decided on those names? They are terrible! Having to make a "b" sound twice in quick succession like that makes an awful word. They should have picked a better replacement letter for the "g", such as R: "Merabyte", "Kirabyte" and "Girabyte".
I'm guessing "bi" was chosen because it's the start of "binary". It's still a bad choice.
If you're trying to make your HTML document look identical in all browsers, despite the fact that this should theoretically be possible, your goal is wrong.
Sure, IE interprets a lot of the HTML standards wrong, but I don't see how this shows that Word is broken.
Word is poorly-designed with regard to the assumptions it makes when loading and saving documents, but HTML and IE have little to do with it; the goals of the HTML format and the Word document format are completely different.
I do have a possible explanation, however. Perhaps Microsoft originally intended the Word document format to be similar in purpose to the main 'document' part of a LaTeX source file; it describes the text and text attributes which are then used to typeset the document to fit whatever output media is desired. Word can then load the document (which, remember, is simply chunks of text with simple stylistic attributes) and typeset it to suit the metrics of the output device. They've bolted extra features on afterwards which go against this, such as floating objects which have no relation to the text, and this is where they went wrong, in my opinion.
You picked a bad analogy with RSS. Look around and see how many different interpretations of RSS have resulted from people just looking at other people's source and guessing.
You have RSS documents with invalid characters for the specified charset, disagreement over what the 'link' element is actually for, disagreement about the content of 'description' and whether it should be interpreted as escaped HTML, plain text or escaped HTML where all of the newlines should be converted to <br />.
It's a mess. Now every RSS parser and application has to make vaugue guesses based on what it finds, and each application makes different guesses meaning that different RSS documents break in different software in differing, interesting ways. This is all because people looked at it and guessed what everything was for rather than working from a single, carefully-worded specification or machine-readable schema.
Storing "number of paragraphs" and "number of lines" seems a little dangerous to me, as that metadata can easily get out of sync if other parts of the document are adjusted.
Web pages are a bad analogy. HTML was designed to vary with client capabilities.
Loki's business model was broken. For one thing, some of the games they ported had been available for Windows before Loki was well-known or possibly even existed, so users bought the Windows versions unaware that they'd be ported later. Had Loki sold a replacement binary without the data at a much reduced price, requiring users to scoop the original game out of the bargain bucket for a few bucks, they may have done better. They'd probably have to restrict themselves to online distribution rather than retail boxes in that case, however.
A far better situation would be for the original developer to create portable code and simultaneously release all of the versions. Since versions for Linux (and, I assume, MacOS X) will, at first, sell far less copies than Windows, it makes sense to bundle them all on the same disc to avoid pressing copies which will just end up sitting in a warehouse not selling. Later, when people get the idea, selling separate versions might become viable but I still don't really see the point when a one-disc-fits-all situation obviously reduces unsold copies.
The Unreal engine is a good example of portable code. I'm speaking of the original Unreal engine here, but I recall that all of its subsystems were pluggable so that (for example) while the original Windows release supported software rendering and 3Dfx they were later able to supply new plugins to go through DirectX and OpenGL for newer cards.
I'm assuming the architecture of the more recent engines, which were built on the work done for the first, is similar. This means that the porting effort for the Linux version was reduced to writing a new driver or porting an existing driver for each subsystem and then recompiling the core. Far easier than taking Half-life 2's code, which uses DirectX 9 directly.
You expect everyone to pay again for a ported binary?
id's model makes more sense. You buy the Windows version at your favourite games retailer, then you download the port of the executable and run it alongside the data from the CD. That way they don't have to waste money producing linux-only game boxes and CDs that only a minority will buy.
The next logical step would be to include the linux port on the disk with the Windows version, so that both binaries are available right off the bat. I'm told Unreal Tournament 2003 did this, but I do not own that game to check.
Now they need to set things up so that their server records the parameter of the MAIL FROM command and use it to send a message to the sender explaining that though that domain does not exist, they can buy it!
Step two PROFIT!! (there is no unknown step)
Okay, I admit that I would program much slower while holding a stopwatch in one of my hands. OKAY?!
"I before E except after C, as long as the word isn't weird."
Sadly, this doesn't have the amiguity when written that it does in speech since you can see the lack of quotation marks around "weird". Yay for double-meaning!