There have been several good Duke Nukem games actually finished and released, you realize? This one is "Duke Nukem Forever". So one might say "Duke Nukem Forever'ed", or just "DNF'ed". "DNF" has a long history from auto racing (and probably from other racing before that). It's an abbreviation for "did not finish", which is apropos for the game.
So I think you'll find "DNF" is the phrasing of choice for such a situation, really.
Replying to myself to note that uzbl works, too. As it uses WebKit, I'm not too surprised. I'm not sure of the exact version, as the command line parser seems to be broken and the option to print the version and quit doesn't print the version and actually leaves some processes running. (Bad coders! No cookies!)
I installed it via urpmi rather than compiling it, so I'm not sure of the git version, either. The RPM name is uzbl-0.0-0.1.20091130.0.1mdv2010.0 so I'm guessing it's version 0.0-01.20091130.0 since the other part is standard Mandriva patch level info.
Works in Epiphany 2.28.1 too. The larger animations like Strongbad are much slower than Flash Player, but the banners are only a frame or two behind.
In Fennec 1.0.0 the smokescreen version works and I have no Flash Player plugin. Since that's supposed to be primarily for mobiles, it just seems right. The larger animations do seem a bit really in Fennec as well, but the banner ads are snappy. The Lyris one is actually a bit faster in smokescreen than in Flash Player.
Does not work in Konqueror 4.3.5 for some reason. I wonder if that version supports the necessary elements of HTML 5 yet. The "No smokescreen.:(" string doesn't show up and the space required is set aside in the render, but nothing ever loads. AdBlock enabled and disabled do the same thing: they run the Flash Player but not the smokescreen version.
Dillo 2.2.1 as expected doesn't support the necessary elements.
As expected, Links 2.2 in graphical doesn't support what smokescreen needs. I didn't bother trying the curses version.
NetSurf 2.5 (as compiled by me since there's no distro package for this one) doesn't work with smokescreen. Neither does the SVN development version of what will be 3.0 for that matter.
Oddly enough, some of the major browsers slowed down even more than the minor ones on the larger files.
Flash isn't just the Flash Player. The Flash Player only exists because there was at one time no other decent way to run the output of the design and development tool Flash Professional.
Adobe doesn't care if you use Adobe Reader to read a PDF so long as they can sell you Acrobat Professional to produce them. All the same, they don't give a rat's ass about whether you use Flash Player, Gnash, or a dead bloated squirrel to play back SWF files so long as you buy Flash Professional to produce the output file. There's even an option in Flash Professional to produce a standalone executable so someone doesn't need a Flash Player instance installed to view a presentation or play a game.
Now that HTML 5, the video element, the canvas element, and JavaScript are going to be suitable replacements for Flash Player, Adobe already has plans to target those technologies from Flash Professional.
That's their business model. It always has been. They sell high-end tools to people producing content, and they don't care what you use (other than they like the brand reinforcement of their own versions I'm sure) to view the content so long as your tools adequately reproduce the content.
Adobe as of Creative Suite 5 (CS5) even has Flash Pro producing its save files as XML so they can be edited by other tools in addition to Flash Pro for better integration of third-party tools. The save format inherited from Macromedia when Adobe bought that company for Flash and some other tools was more or less just a dump of the memory Flash Pro was using.
VT100 is a smart enough terminal, but it was never a client. It was a peripheral. Telnet was a software system with both a client module and a server module to enable two separate full computers to interact, not a terminal with a computer. As a client goes, a telnet client is a very thin one. However, thin vs. thick is a very different distinction from client/not client.
To say telnet isn't client/server draws the line at systems using X11, NX, VNC, RDP, HTTP, SMTP, POP3, and many more protocols not being client/server either simply because the transport protocol is simple.
Be clear here that I'm not saying the Telnet protocol is a client/server system. It's just a protocol. The programs that used it, starting from the telnetd daemon with a login and an OS shell on the server side and the basic telnet client on the client side, were simple client/server applications. What's more is that other systems used the same protocols and had thicker servers and thicker clients.
I'm not sure why you're so tied to Microsoft technologies, but the programming language has nothing to do with whether the finished implementation of a project is client/server. Sure, a language and its libraries can make developing a client/server model easier than doing the same project in another language. It doesn't make anything possible that some suitably flexible other language like C can't do, though.
Hardly. Xmodem is a non-interactive data transfer protocol. Telnet enables a user to request multiple different and possibly unrelated services from a server and receive multiple different responses. Protocols like XModem and ZModem can even run within any telnet that is 8-bit clean. Calling telnet client/server is much more like calling the Web client/server than calling XModem client/server.
Thanks for reading the thread... oh, wait, you didn't. I already said that Perl's extended "regexes" are not regular. Well, thanks for weighing in anyway.
Any artificial language you're parsing should be designed with this in mind, or at least a different tool could be clearly chosen for it.
If you're parsing any sort of natural language, well first you kind of deserve what you get.;-) The variability of the language would seem to preclude this sort of massive backtracking in the common case, and the parser could use multiple separate regexes to help lower the chances of triggering the problem.
It still seems from my experience that the common case is of reasonable performance is much more common, although rare incidents might happen.
Innovention Toys won an injunction against MGA Entertainment, Toy-R-Us, and Wal-Mart for the game Laser Battle infringing on Innovention's game Khet, and was granted summary judgment when MGA and Wal-mart appealed.
So as far as I know, yes.
And now you know... and knowing is half the battle.
Yeah, and checking specifically for a possible type of pathological regex in order to work around it would require slowing the engine for the common case. So I'd say the power of the engine to do so many things is a good trade for the easily avoided pathological cases.
There are only two situations in which such pathological cases are likely to be given to the regex engine anyway. One is when long regexes are built automatically by a program based on a set of rules and a particular data set, which should only trigger a pathological case rarely based on random chance. The other is when people set out to specify something pathological on purpose just to demonstrate the issue. The rest of the time, a programmer should be interested in using the regex engine to actually do something useful and there's really no use in any of the contrivances used for such torture tests.
SAP isn't some little two-guys-in-a-basement operation and has had plenty of time to see this coming. I say their customers should bitch, collectively, to get them to support their customers on modern platforms. Perhaps they could even use something supported by the vendor, which IE6 hasn't been in quite some time.
Careful there. "STD" has a specific meaning regarding the Internet. Don't let some neophyte to RFCs and STDs think you're calling IE6 an ISC approved standard. You'll get flamed like a kabob dinner with baked Alaska and crème brul for dessert.
Actually, you can patent gameplay. You can't copyright it. In fact, games ranging from Monopoly to Magic: The Gathering have been patented. A prior collectible card game patent was issued in 1904. There really is nothing new under the sun. Random citations:
I think there's some prior art to be found. For once, you'd actually see the trolls pointing it out. So you're saying you want to force them to prove they understand the concept of prior art? Brilliant!
The "M" is actually for "Millennium". Digital copyrights and copyrights of printed materials actually differ in only a few ways. What is eligible for copyright in the first place is not one of them.
For the devices using a SIMD engine and a DSP to do H.264 with instructions in firmware, it's just a firmware upgrade to support other codecs that are substantially similar. That maybe not be the approach everyone's using, but it seems a likely combination for some devices. Lots of ARM-based devices tend to use this, if I'm not mistaken. Cell phones and tablets would be a good place to not have to spend an extra dollar for licensing costs, too.
What they're saying is that MPEG-LA, Apple, and Microsoft won't scare them away with patent threats just by saying VP8 is infringing on H.264. Whether that means they believe it doesn't infringe or that they're willing to pony up licensing funds isn't really clear from the summary.
Ah, thanks. You had me worried there for a minute. I still probably won't buy the game at least for a long time, mostly because I don't buy many games these days. With all the older games I already have and the decent noncommercial games out there, I just can't see the point of buying yet another RTS at full launch price right now, even if it is really good. I'll keep it in mind next year, though.
Matchmaking? What about search? If you can't search for the players you want, then your LAN party can't play the game, even on BNet. Surely there's search? Automatch only would be a real deal-breaker worse than no LAN.
Maxis did that with some of their games, as did SSI. SimEarth from Maxis at least and Eye of the Beholder from SSI.
I'm sure there were others. The bargain-bin 10-older-games-for-10-bucks boxes would include a PDF copy of the manual with a paper note to look in it, or sometimes would even have a list of just the questions and answers if they didn't offer the manuals.
There have been several good Duke Nukem games actually finished and released, you realize? This one is "Duke Nukem Forever". So one might say "Duke Nukem Forever'ed", or just "DNF'ed". "DNF" has a long history from auto racing (and probably from other racing before that). It's an abbreviation for "did not finish", which is apropos for the game.
So I think you'll find "DNF" is the phrasing of choice for such a situation, really.
Replying to myself to note that uzbl works, too. As it uses WebKit, I'm not too surprised. I'm not sure of the exact version, as the command line parser seems to be broken and the option to print the version and quit doesn't print the version and actually leaves some processes running. (Bad coders! No cookies!)
I installed it via urpmi rather than compiling it, so I'm not sure of the git version, either. The RPM name is uzbl-0.0-0.1.20091130.0.1mdv2010.0 so I'm guessing it's version 0.0-01.20091130.0 since the other part is standard Mandriva patch level info.
These are all on Mandriva 2010.
Works in Midori 0.2.0 albeit slowly.
Works in Epiphany 2.28.1 too. The larger animations like Strongbad are much slower than Flash Player, but the banners are only a frame or two behind.
In Fennec 1.0.0 the smokescreen version works and I have no Flash Player plugin. Since that's supposed to be primarily for mobiles, it just seems right. The larger animations do seem a bit really in Fennec as well, but the banner ads are snappy. The Lyris one is actually a bit faster in smokescreen than in Flash Player.
Does not work in Konqueror 4.3.5 for some reason. I wonder if that version supports the necessary elements of HTML 5 yet. The "No smokescreen. :(" string doesn't show up and the space required is set aside in the render, but nothing ever loads. AdBlock enabled and disabled do the same thing: they run the Flash Player but not the smokescreen version.
Dillo 2.2.1 as expected doesn't support the necessary elements.
As expected, Links 2.2 in graphical doesn't support what smokescreen needs. I didn't bother trying the curses version.
NetSurf 2.5 (as compiled by me since there's no distro package for this one) doesn't work with smokescreen. Neither does the SVN development version of what will be 3.0 for that matter.
Oddly enough, some of the major browsers slowed down even more than the minor ones on the larger files.
Flash isn't just the Flash Player. The Flash Player only exists because there was at one time no other decent way to run the output of the design and development tool Flash Professional.
Adobe doesn't care if you use Adobe Reader to read a PDF so long as they can sell you Acrobat Professional to produce them. All the same, they don't give a rat's ass about whether you use Flash Player, Gnash, or a dead bloated squirrel to play back SWF files so long as you buy Flash Professional to produce the output file. There's even an option in Flash Professional to produce a standalone executable so someone doesn't need a Flash Player instance installed to view a presentation or play a game.
Now that HTML 5, the video element, the canvas element, and JavaScript are going to be suitable replacements for Flash Player, Adobe already has plans to target those technologies from Flash Professional.
That's their business model. It always has been. They sell high-end tools to people producing content, and they don't care what you use (other than they like the brand reinforcement of their own versions I'm sure) to view the content so long as your tools adequately reproduce the content.
Adobe as of Creative Suite 5 (CS5) even has Flash Pro producing its save files as XML so they can be edited by other tools in addition to Flash Pro for better integration of third-party tools. The save format inherited from Macromedia when Adobe bought that company for Flash and some other tools was more or less just a dump of the memory Flash Pro was using.
VT100 is a smart enough terminal, but it was never a client. It was a peripheral. Telnet was a software system with both a client module and a server module to enable two separate full computers to interact, not a terminal with a computer. As a client goes, a telnet client is a very thin one. However, thin vs. thick is a very different distinction from client/not client.
To say telnet isn't client/server draws the line at systems using X11, NX, VNC, RDP, HTTP, SMTP, POP3, and many more protocols not being client/server either simply because the transport protocol is simple.
Be clear here that I'm not saying the Telnet protocol is a client/server system. It's just a protocol. The programs that used it, starting from the telnetd daemon with a login and an OS shell on the server side and the basic telnet client on the client side, were simple client/server applications. What's more is that other systems used the same protocols and had thicker servers and thicker clients.
I'm not sure why you're so tied to Microsoft technologies, but the programming language has nothing to do with whether the finished implementation of a project is client/server. Sure, a language and its libraries can make developing a client/server model easier than doing the same project in another language. It doesn't make anything possible that some suitably flexible other language like C can't do, though.
Hardly. Xmodem is a non-interactive data transfer protocol. Telnet enables a user to request multiple different and possibly unrelated services from a server and receive multiple different responses. Protocols like XModem and ZModem can even run within any telnet that is 8-bit clean. Calling telnet client/server is much more like calling the Web client/server than calling XModem client/server.
Thanks for reading the thread... oh, wait, you didn't. I already said that Perl's extended "regexes" are not regular. Well, thanks for weighing in anyway.
Sure, it happens, but with what frequency?
Any artificial language you're parsing should be designed with this in mind, or at least a different tool could be clearly chosen for it.
If you're parsing any sort of natural language, well first you kind of deserve what you get. ;-) The variability of the language would seem to preclude this sort of massive backtracking in the common case, and the parser could use multiple separate regexes to help lower the chances of triggering the problem.
It still seems from my experience that the common case is of reasonable performance is much more common, although rare incidents might happen.
Monopoly's multiple patents were been variously upheld and overturned on the facts of the cases.
Atari settled over a patent for an in-game camera perspective.
Beneficial Innovations received a settlement from Digg Inc., CBS Interactive Inc., and Jabez Networks Inc. over a patent on Internet gaming technology.
Innovention Toys won an injunction against MGA Entertainment, Toy-R-Us, and Wal-Mart for the game Laser Battle infringing on Innovention's game Khet, and was granted summary judgment when MGA and Wal-mart appealed.
So as far as I know, yes.
And now you know... and knowing is half the battle.
Yeah, and checking specifically for a possible type of pathological regex in order to work around it would require slowing the engine for the common case. So I'd say the power of the engine to do so many things is a good trade for the easily avoided pathological cases.
There are only two situations in which such pathological cases are likely to be given to the regex engine anyway. One is when long regexes are built automatically by a program based on a set of rules and a particular data set, which should only trigger a pathological case rarely based on random chance. The other is when people set out to specify something pathological on purpose just to demonstrate the issue. The rest of the time, a programmer should be interested in using the regex engine to actually do something useful and there's really no use in any of the contrivances used for such torture tests.
SAP isn't some little two-guys-in-a-basement operation and has had plenty of time to see this coming. I say their customers should bitch, collectively, to get them to support their customers on modern platforms. Perhaps they could even use something supported by the vendor, which IE6 hasn't been in quite some time.
Careful there. "STD" has a specific meaning regarding the Internet. Don't let some neophyte to RFCs and STDs think you're calling IE6 an ISC approved standard. You'll get flamed like a kabob dinner with baked Alaska and crème brul for dessert.
You're kidding! I thought that'd be one of the first misspellings to be snatched up, especially on Slashdot!
Wait... user 205075. You really were kidding.
Oddly enough, "Nostradomus" actually isn't a Slashdot account despite how often that spelling appears in the comments. I could have sworn it would.
Actually, you can patent gameplay. You can't copyright it. In fact, games ranging from Monopoly to Magic: The Gathering have been patented. A prior collectible card game patent was issued in 1904. There really is nothing new under the sun. Random citations:
Monopoly
Magic
However, Tetris isn't patented so the whole patent issue is moot. Besides, trademarks and patents aren't enforced by the DMCA.
I think there's some prior art to be found.
For once, you'd actually see the trolls pointing it out. So you're saying you want to force them to prove they understand the concept of prior art? Brilliant!
The "M" is actually for "Millennium". Digital copyrights and copyrights of printed materials actually differ in only a few ways. What is eligible for copyright in the first place is not one of them.
PDF about computer software copyrights
For the devices using a SIMD engine and a DSP to do H.264 with instructions in firmware, it's just a firmware upgrade to support other codecs that are substantially similar. That maybe not be the approach everyone's using, but it seems a likely combination for some devices. Lots of ARM-based devices tend to use this, if I'm not mistaken. Cell phones and tablets would be a good place to not have to spend an extra dollar for licensing costs, too.
What they're saying is that MPEG-LA, Apple, and Microsoft won't scare them away with patent threats just by saying VP8 is infringing on H.264. Whether that means they believe it doesn't infringe or that they're willing to pony up licensing funds isn't really clear from the summary.
Never is a long time. Did you know Theora is based on VP3? Eventually they probably would have done the same thing, just not so soon.
Ah, thanks. You had me worried there for a minute. I still probably won't buy the game at least for a long time, mostly because I don't buy many games these days. With all the older games I already have and the decent noncommercial games out there, I just can't see the point of buying yet another RTS at full launch price right now, even if it is really good. I'll keep it in mind next year, though.
They should have made it a flavor rather than a scent. Then they could license it to Miller Brewing.
Sorry, but the name "Nostradomus" is also taken.
Matchmaking? What about search? If you can't search for the players you want, then your LAN party can't play the game, even on BNet. Surely there's search? Automatch only would be a real deal-breaker worse than no LAN.
Maxis did that with some of their games, as did SSI. SimEarth from Maxis at least and Eye of the Beholder from SSI.
I'm sure there were others. The bargain-bin 10-older-games-for-10-bucks boxes would include a PDF copy of the manual with a paper note to look in it, or sometimes would even have a list of just the questions and answers if they didn't offer the manuals.
Taken over by Activision, for instance? Or did you mean Activision (who made Pitfall) taken over by someone else?