It's too bad, Gameboy was so commonplace, it was a generic name like 'walkman' for a while. Okay, maybe 'walkman' dates me, but you get the idea. Even my nine year old daughter says that having no backlight on the first GBA was a major screw-up. Then the SP comes out and we're supposed to pay all over again for the same device done right? Don't even get me started on the DS and how it's "not a replacement for the GBA."
Nintendo did miss the boat. They've parlayed their one-time leadership of the market into a great big bust. They could hope to catch the low-cost segment of the market with the specs that are given for the Revolution, but that would still require them to take advantage of media events like E3.
I think they're going the way of Sega and Atari. If they keep it up they won't be able to keep producing their own console.
I thought about that as well, but what about users that don't connect their Xbox360 to the internet? They still have to be able to play their old games. What if they just had chunks of the games rewritten and stored on the hard drive. Remember, this only has to be done once for each existing title that they choose to support, and all those titles are out today.
Okay, it's kind of far fetched, but Windows really does have the names of a bunch of games and applications in the registry that it does special handling for. That's what the whole application compatibility connection was about. It was the first thing that came to mind with the mention of "selective" support.
designed for a 8 bit OS in seventies called the CP/M
This is the worst part of backwards compatibility - even though those old headers are there, I'm sure that nothing using them would be able to run under CP/M for several generations of software now.
I don't know, I got hooked on Quake long, long after it came out. People that aren't on the cutting edge, not geeks (bascially no one in this crowd) don't want to keep two systems set up and might have an emotional investment in an older game.
Another part of it is just the press - if you can't play your old games on Xbox360, why not just jump to the other brand? The PS3 won't play your old Xbox games, so the two would be on equal footing on that count.
Since they can't change the game, I wonder if they'll do this by working over some of the code that the ships in the Xbox360. They do something like that in Windows.
Hard to say. The discussion around bug #240493 makes it sound like image/svg+xml (the MIME type for SVG) might not even be in the Accept Header. To me that sounds very very odd. It also makes it impossible to decide simply based on the accept header whether or not to serve SVG. This means client side scripts (to detect support) and another trip to the server (to get the appropriate file).
I actually just tried out Friday's nightly yesterday. Up to now I've been relying on the Adobe SVG Viewer (ASV) 6.0 Beta in Firefox, along with some advice from surfers using the SVG-enabled Mozilla. It definitely looks cool and seems to render faster than ASV. There's less of a feeling that the SVG is a separate entity and more that it's just part of the page.
I did a side-by side comparison of ASV in IE and native SVG on my site. My examples are all very simple and rendered almost identically. The major exception to this is that filters are totally missing. From the Mozilla project page:
"Big areas of the SVG specification where we're still lacking include filters, svg defined fonts, and declarative animations."
It's a beta, so I don't expect it to be complete, but it brought to mind the utility of having a simple way to check which implementation of SVG is being used to render the page. For example, without knowing that animations aren't supported, the casual user will be very confused as to why an SVG-based game simply doesn't function. Right now it's not casual users who are downloading this build (the nightlies), but there will always be differences between implementations, so when the next release comes out I hope it's simple to tell how the SVG is being rendered.
It's also a good idea to pay attention to the version of the standard supported, whether it's Tiny or Full and whether it's 1.1 or 1.2 (which could come from W3C in May).
I definitely agree with this sentiment, but what's an SVG developer to do? The Adobe SVG plugin is available for a variety of platforms including IE and Firefox, Corel has their plugin, Opera supports SVG Tiny and those are just the ones that I know of. More implementations are undoubtedly out there or on the way.
I like the idea of being able to hand code markup - at least for prototypes and one-offs (the reason I started the site mentioned in my sig). For big sites bigger tools can be better, but the amount of quirks detection is getting ridiculous.
I don't want to tell the user what browser is best, but I just don't have the resources to try out every combination myself.
There already is one. XAML iirc. XAML is expected to be an important part of Avalon. I haven't read that much on it, but with buzz around Avalon lately, maybe XAML gets split out and promoted separately as well. That would lead to more fragmentation in what appears to be a market being choked by alternatives.
This is a perfect example of the problem with spreadsheets. As for using a database from the start: it is the better idea, but you'd be surprised at the opposition that you can get. Some managers just don't like databases. Don't ask me why, but it happens.
The scary thing is the suggestion that the IT department should take over spreadsheets. Many people use a spreadsheet for applications that would better be served by a database with the appropriate front end and back end, or a dedicated software application. This article mentions managers specifically, but lots of employees whip up a spreadsheet and throw in some macros then find that the spreadsheet grows to a point of some real usefulness.
It's when the spreadsheet becomes useful that people realize it's not scalable (maybe they don't use that word, but I do) and can be tough to maintain.
Not to single out IT departments in particular, but I think the reason that these spreadsheets start up and grow is specifically that it's often difficult to get someone in another department to understand your needs well enough to make the tool that you really need.
Today managers can't fund a good solution because their budget doesn't allow for the necessary development. Tomorrow they won't be able to afford to get the support they need to get a spreadsheet done.
I don't have a great solution outside of better training for people on how to make spreadsheets that serve their needs.
Just because the standard is open doesn't mean the tools are free (as in beer). Adobe is already making a few bucks selling tools that utilize that open standard.
The mobile market needs tools too. I'm sure they do want to cash in on that. Perhaps they see a way to make better SVG Tiny support in Flash Lite. That gets them two platforms at once (which is also a feature they can sell developers on). Playing in two of the big mobile development arenas will make them better prepared for when Microsoft moves Avalon (and therefore XAML) to high-end cell phones.
This way Adobe will have more hold in more of the existing platforms. When Microsoft enters a market like that they (MS) tend to have to adapt to the current players before taking over. This move buys Adobe a couple more versions or a couple more years once that happens.
It's been passed off as a joke before, but I think Adobe may really consider embedding Flash or something like Flash in PDFs. When we think about Flash the most ready examples are distracting online games and annoying ads. Really Flash has grown into a multimedia platform. It streams vector and raster graphics, animates, and times sound to it. SVG doesn't have all the hooks for sounds laid out in it's current incarnation (unless there's something in SMIL I'm not up on).
Even if it's not Flash in PDF, they still do control the two most common proprietary formats on the web. They've been pushing SVG, but they will have stiff competition from XAML. Using an established platform like Flash can at least give them a head start when that battle comes (which they're already foreseeing according to Dvorak's article).
The statement from Drupal indicates that they reduce server load by not requiring so much database access for cached pages. Perhaps even no database access at all.
Although the MySQL error is not guaranteed to be due to Drupal database access, that would be my first suspicion if I were debugging it. After all, it should be Drupal that's actually emitting the message, right?
And yes, I do know how to interpret error messages: read them track down the source that emitted them, and figure out what's really going on.
Fwiw, I think the page caching scheme is a great idea and it's simple enough to do in PHP that I'm working on doing it on my own pages.
While SVG is often compared to Flash, it's more accurate to say they cover overlapping areas. I can't see Adobe dropping support for it, but I could definitely see more interaction between their SVG products and the Macromedia software.
If you look at the SVG standard, there are representatives of Macromedia listed there. They've been involved, I just don't know to what degree.
Macromedia has also added some SVG capabilities to their products, but it's been seen as a token gesture in the articles that I've read.
And of course I've got to say that I'm glad that the tutorials I do in SVG (see the sig) are at least starting to work in Firefox (just this weekend actually).
There could be a reason to make clean, but even in other cases, incorrect dependencies will eventually get you in any reasonably large project. If your dependencies are wrong, there are scripts out there (makedep or makemake) for making dependency information.
Slashdot Mirror
It's too bad, Gameboy was so commonplace, it was a generic name like 'walkman' for a while. Okay, maybe 'walkman' dates me, but you get the idea. Even my nine year old daughter says that having no backlight on the first GBA was a major screw-up. Then the SP comes out and we're supposed to pay all over again for the same device done right?
Don't even get me started on the DS and how it's "not a replacement for the GBA."
Nintendo did miss the boat. They've parlayed their one-time leadership of the market into a great big bust. They could hope to catch the low-cost segment of the market with the specs that are given for the Revolution, but that would still require them to take advantage of media events like E3.
I think they're going the way of Sega and Atari. If they keep it up they won't be able to keep producing their own console.
I thought about that as well, but what about users that don't connect their Xbox360 to the internet? They still have to be able to play their old games. What if they just had chunks of the games rewritten and stored on the hard drive. Remember, this only has to be done once for each existing title that they choose to support, and all those titles are out today.
Okay, it's kind of far fetched, but Windows really does have the names of a bunch of games and applications in the registry that it does special handling for. That's what the whole application compatibility connection was about. It was the first thing that came to mind with the mention of "selective" support.
designed for a 8 bit OS in seventies called the CP/M
This is the worst part of backwards compatibility - even though those old headers are there, I'm sure that nothing using them would be able to run under CP/M for several generations of software now.
I don't know, I got hooked on Quake long, long after it came out. People that aren't on the cutting edge, not geeks (bascially no one in this crowd) don't want to keep two systems set up and might have an emotional investment in an older game.
Another part of it is just the press - if you can't play your old games on Xbox360, why not just jump to the other brand? The PS3 won't play your old Xbox games, so the two would be on equal footing on that count.
Since they can't change the game, I wonder if they'll do this by working over some of the code that the ships in the Xbox360. They do something like that in Windows.
Please read the standard. It's all perfectly legitimate under XML.
Hard to say. The discussion around bug #240493 makes it sound like image/svg+xml (the MIME type for SVG) might not even be in the Accept Header. To me that sounds very very odd. It also makes it impossible to decide simply based on the accept header whether or not to serve SVG. This means client side scripts (to detect support) and another trip to the server (to get the appropriate file).
I actually just tried out Friday's nightly yesterday. Up to now I've been relying on the Adobe SVG Viewer (ASV) 6.0 Beta in Firefox, along with some advice from surfers using the SVG-enabled Mozilla. It definitely looks cool and seems to render faster than ASV. There's less of a feeling that the SVG is a separate entity and more that it's just part of the page.
I did a side-by side comparison of ASV in IE and native SVG on my site. My examples are all very simple and rendered almost identically. The major exception to this is that filters are totally missing. From the Mozilla project page:
"Big areas of the SVG specification where we're still lacking include filters, svg defined fonts, and declarative animations."
It's a beta, so I don't expect it to be complete, but it brought to mind the utility of having a simple way to check which implementation of SVG is being used to render the page. For example, without knowing that animations aren't supported, the casual user will be very confused as to why an SVG-based game simply doesn't function. Right now it's not casual users who are downloading this build (the nightlies), but there will always be differences between implementations, so when the next release comes out I hope it's simple to tell how the SVG is being rendered.
It's also a good idea to pay attention to the version of the standard supported, whether it's Tiny or Full and whether it's 1.1 or 1.2 (which could come from W3C in May).
I definitely agree with this sentiment, but what's an SVG developer to do? The Adobe SVG plugin is available for a variety of platforms including IE and Firefox, Corel has their plugin, Opera supports SVG Tiny and those are just the ones that I know of. More implementations are undoubtedly out there or on the way.
I like the idea of being able to hand code markup - at least for prototypes and one-offs (the reason I started the site mentioned in my sig). For big sites bigger tools can be better, but the amount of quirks detection is getting ridiculous.
I don't want to tell the user what browser is best, but I just don't have the resources to try out every combination myself.
SodiPodi is a native SVG editor. ImageMagick and the Gimp also have some SVG support.
There already is one. XAML iirc. XAML is expected to be an important part of Avalon. I haven't read that much on it, but with buzz around Avalon lately, maybe XAML gets split out and promoted separately as well. That would lead to more fragmentation in what appears to be a market being choked by alternatives.
This is a perfect example of the problem with spreadsheets. As for using a database from the start: it is the better idea, but you'd be surprised at the opposition that you can get. Some managers just don't like databases. Don't ask me why, but it happens.
The scary thing is the suggestion that the IT department should take over spreadsheets. Many people use a spreadsheet for applications that would better be served by a database with the appropriate front end and back end, or a dedicated software application. This article mentions managers specifically, but lots of employees whip up a spreadsheet and throw in some macros then find that the spreadsheet grows to a point of some real usefulness.
It's when the spreadsheet becomes useful that people realize it's not scalable (maybe they don't use that word, but I do) and can be tough to maintain.
Not to single out IT departments in particular, but I think the reason that these spreadsheets start up and grow is specifically that it's often difficult to get someone in another department to understand your needs well enough to make the tool that you really need.
Today managers can't fund a good solution because their budget doesn't allow for the necessary development. Tomorrow they won't be able to afford to get the support they need to get a spreadsheet done.
I don't have a great solution outside of better training for people on how to make spreadsheets that serve their needs.
Just because the standard is open doesn't mean the tools are free (as in beer). Adobe is already making a few bucks selling tools that utilize that open standard.
The mobile market needs tools too. I'm sure they do want to cash in on that. Perhaps they see a way to make better SVG Tiny support in Flash Lite. That gets them two platforms at once (which is also a feature they can sell developers on). Playing in two of the big mobile development arenas will make them better prepared for when Microsoft moves Avalon (and therefore XAML) to high-end cell phones.
This way Adobe will have more hold in more of the existing platforms. When Microsoft enters a market like that they (MS) tend to have to adapt to the current players before taking over. This move buys Adobe a couple more versions or a couple more years once that happens.
It's been passed off as a joke before, but I think Adobe may really consider embedding Flash or something like Flash in PDFs. When we think about Flash the most ready examples are distracting online games and annoying ads. Really Flash has grown into a multimedia platform. It streams vector and raster graphics, animates, and times sound to it. SVG doesn't have all the hooks for sounds laid out in it's current incarnation (unless there's something in SMIL I'm not up on).
Even if it's not Flash in PDF, they still do control the two most common proprietary formats on the web. They've been pushing SVG, but they will have stiff competition from XAML. Using an established platform like Flash can at least give them a head start when that battle comes (which they're already foreseeing according to Dvorak's article).
Okay, I'll take the bait. Maybe I'll be sorry.
The statement from Drupal indicates that they reduce server load by not requiring so much database access for cached pages. Perhaps even no database access at all.
Although the MySQL error is not guaranteed to be due to Drupal database access, that would be my first suspicion if I were debugging it. After all, it should be Drupal that's actually emitting the message, right?
And yes, I do know how to interpret error messages: read them track down the source that emitted them, and figure out what's really going on.
Fwiw, I think the page caching scheme is a great idea and it's simple enough to do in PHP that I'm working on doing it on my own pages.
While SVG is often compared to Flash, it's more accurate to say they cover overlapping areas. I can't see Adobe dropping support for it, but I could definitely see more interaction between their SVG products and the Macromedia software.
If you look at the SVG standard, there are representatives of Macromedia listed there. They've been involved, I just don't know to what degree.
Macromedia has also added some SVG capabilities to their products, but it's been seen as a token gesture in the articles that I've read.
And of course I've got to say that I'm glad that the tutorials I do in SVG (see the sig) are at least starting to work in Firefox (just this weekend actually).
There could be a reason to make clean, but even in other cases, incorrect dependencies will eventually get you in any reasonably large project. If your dependencies are wrong, there are scripts out there (makedep or makemake) for making dependency information.
I haven't tried it that I recall, but Open Office Draw has an Export option for HTML or SVG.