It only works for user agents that handle JavaScript (which includes the major search engine spiders); the 301 redirect method on the other hand has been part of http specification from the beginning and is (anecdotally speaking) supported by just about every http client.
The user-agent string is not a reliable indicator of which user-agent is being used (as counter-intuitive as this seems), a much better methodology (that several other people have already mentioned) is to use IE conditional comments to serve additional stylesheets to specific versions of Internet Explorer after the main stylesheet to override only the specific rules required to get that version of internet explorer to display the content as expected.
This has several advantages:
the ability to have different rules to handle bugs in specific versions of IE.
if future versions are released then they'll ignore the stylesheets targeted at older versions (so if IE8 is as good as it's been made out to be your documents should render correctly without any additional work)...
and if there are still some some small bugs then IE8 can itself get a stylesheet designed to fix just these.
unlike methods that rely on the UA string, it is guaranteed only to be applied by the browser you specify (because browsers other than IE see the conditional comments as just plain old HTML comments (relying on the UA string would mean that UAs pretending to be IE would not be incorrectly served the IE hack filled stylesheet)
This is the methodology I prefer to follow with the sites that I develop, and after the experiences I had testing compatibility and fixing various layout problems that remained in IE7 I can say that it definitely pays off. Personally I'm hoping that IE8 will be close enough that I can finally dump IE conditional comments entirely once the older versions have disappeared and relegate it to the pile of no-longer relevant skills alongside the ability to generate pixel perfect layouts using tables & invisible spacer gifs and the ability to consistently beat almost anyone at Perfect Dark multiplayer.
I disagree with your assertion that win2k would still the best version of Windows for daily use for a single reason; win2k (the desktop version) doesn't run a terminal services server. In XP pro I can enable remote desktop on all my windows machines and launch a terminal services client (mstsc on windows, rdesktop from linux etc) and access the machine remotely from anywhere on the network (or with some firewall configuration any computer with internet access - this feature alone sold me on XP, being able to use my workstation without having to be physically infront of it is a fantastic time-saver.
I seem to recall using something similar with VNC, however being a separate application it requires installing the server software on the machine you wish to access and client software on the machine you're using to access it (though, I believe there are stand-alone versions) and takes more time/effort than enabling a single checkbox.
Already, most software works or "mostly works" with Wine. I routinely run IE with Flash on my Fedora Core 6 laptop in Wine. How long before Wine becomes a "target platform" for software vendors who are otherwise locked into the Win32 API?
Not long at all, infact there was an article less than a month ago about Eve Online's linux and max osx support via wine (Cadega). Personally I can't decide if it's a good thing (because it's now a supported platform) or a bad thing (because there's little motivation to create native ports if running it through wine is "good enough").
* However, it can (mostly) deal with it if you (incorrectly, IMO, despite appendix C) send the mime-type as text/html and skip the XML prologue by parsing it as 'tag soup'.
I'd agree with you if you'd been talking about XHTML 1.1. XHTML 1.0 SHOULD be served as application/xhtml+xml, but MAY be served as text/html when the compatibility guidelines are met. XTHML 1.1, however, SHOULD NOT be served as text/html. Even then, it's not a MUST NOT. But since it's a MAY for 1.0, i think calling it "incorrect" is a bit harsh.
May, as you probably know, but just incase, is defined by RFC2119 as:
Yes, I was talking about XHTML 1.0 (Appendix C is the location of said compatibility guidelines), it is widely considered to have been a mistake to allow developers to send XHTML documents with the wrong Content-Type because it causes subtle errors and defeats the purpose of using an XML based language (amongst many other reasons). My point is that when you serve XHTML as text/html you negate the point of using XML; You lose the ability to embed other XML languages (such as MathML or SVG) within your document, the page is no longer sent through an XML parser that checks for well-formedness thusly you're likely to introduce subtle errors without realising. When the day comes that all major UAs support application/xhtml+xml correctly and you decide to switch the Content-Type over there is a good chance of your pages not being displayed (works fine in IE but dies in Firefox due to crappy content negotiation) due to subtle errors in your markup that weren't apparent when your document was being parsed as tag soup.
And for all these difficulties you get what? On the web today, with IE still having ~80% market share, XHTML offers no advantage of HTML4 and has a whole pile of potential pitfalls that a developer must take into account of and hack around. For example, <, >, & are all treat as markup irrelevant of where they are in a document when a page is treat as XML, causing problems with inline JavaScript blocks; as a developer you have to explicitly declare the contents of script block as cdata using <![CDATA[ followed by a closing ]]> with all Javascript between those two elements, however because the Javascript interpreter treats anything within a JavaScript block as code (and you're sending it as text/html) you have to comment them out so that when served as text/html to older browsers they don't try to execute the cdata declaration as code.
There are many, many more problems associated with sending XHTML as text/html with various hacks to mitigate some of them to a greater or lesser degree. However I don't feel that sending XHMTL as text/html is ever a good idea and if you insist on generating XHTML markup then I suggest you use a good content negotiation script to send it as application/xhtml+xml where the browser supports it and when it does not using XSLT to transform the document to HTML before sending it to UAs that do not.
Content and presentation have been slowly merging over the course of the web. Adding these semantic tags appears to be an attempt to separate the presentation from the content.
Do you have any evidence to back up this sweeping statement? In my opinion this was the case from the early days of the web, through the original browser wars and for a period afterwards (until maybe '01-02) at which point people started realising that contaminating the markup with presentational cruft was a good way to create maintainability nightmares, and made major redesigns of medium to large sites a frustrating and time-consuming (thus costly) process.
The trouble is that nobody will add the new tags until a majority of browsers support HTML5. And nobody will be interested in upgrading until the major sites require it (or until the format is slowly merged in during users normal upgrade schedules).
This is, of course, very true (and I forsee Internet Explorer lagging behind the other 'major' browser vendors), however this can be said about any new web specifications (the XHTML 1.0 spec was released as a recommendation in January 2000, and IE doesn't support it in any way, shape or form*).
Add that to the fact that the current generation of browsers don't agree on implementations within HTML4, and I suspect that this will not really help us web developers.
Nowadays, the commonly used browsers (>IE6, Gecko based browsers, Konq, Safari, Opera) all implement a large subset of the HTML 4 spec, although you are right that there are some presentational issues (mostly due to the fact that the spec is vague in places) these can be eliminated with a judicious application of CSS rules.
Personally i'm glad that the w3 have taken the helm wrt the HTML5 spec - I had major problems with the direction that WHATWG were going with it. A specific example is their introduction of the presentational font element; their note that it should only be used by WYSIWIG tools and to be syntactically valid said tool must add a special meta element is laughably nieve. As the font element has no semantic meaning and no benefit over the equally semantically meaningless span element with a suitable styling via CSS - sure you could argue it offers backwards compatibility with legacy documents, however I would assume that a document that is not syntactically valid HTML4 would need major work to be cleaned up to be valid HTML5 anyway (plus, that would be disobeying the spirit of the spec, being as such content would not be generated by a WYSIWIG editor).
Another worry is that they're integrating DOM stuff into the same spec, although it does make sense in some ways it seems like there is the distinct potential of losing focus by covering too diverse a set of problems. However, it is still early days yet and I will withhold judgement until we start seeing near-finalised drafts and browsers start implementing some of the new features.
* However, it can (mostly) deal with it if you (incorrectly, IMO, despite appendix C) send the mime-type as text/html and skip the XML prologue by parsing it as 'tag soup'.
Honestly, there's no site that I'm aware of that fills the same niche - personally I find the best reference for CSS / HTML questions are their respective specifications on the w3c site. My issue with w3schools, by the way, stems from the fact that often their information is misleading and occasionally even outright wrong; if you're an experienced developer these errors are fairly obvious, however if you're an experienced developer you're not really in the target audience for the site.
Okay nobody seems to have picked up on the obvious flaw with this statistic - the w3school's site (from which the data on which this prediction was based) is a (poor imho) web developer's resource. Naturally with an audience that has an intrinsic interest in browsers and standards Firefox (and other alternative browsers) it will show up in statistics generated disproportionately to it's actual usage in the general public, it also explains the adoption rate of IE7 being very high. These statistics are useless and that prediction is completely invalid outside of that specific site.
Although Gecko supports more extensions, I would argue that WebCore is more standards compliant. As far as I know no Gecko based browser has passed the ACID2 test yet.
I'd disagree with your statement and moreover you're reasoning is fallacious. You're implying that either passing (or not) the Acid2 test acts as a good metric on which to judge how well a browser supports the CSS2 standard, an obviously false assumption being as the Acid2 test only ensures support for a tiny subset of the standard it claims to support. The only reasonable way to compare support would be to go through the specification and test the individual components work (for example webdevout's comparison of Firefox, Opera & IE) and then putting each browser through a comprehensive set of test pages and comparing how they render them compared to an expected example render as well as each other. Anything less is a purely subjective judgement.
My (purely subjective) opinion on the matter is that right now (Firefox 2 & Safari 2) are roughly equal in their support for the standards I use daily as a web developer - both have areas that are lacking wrt each other. However, i've recently been playing with the Firefox 3 nightlies and I'm inclined to think that Gecko 1.9 might give Fx3 an advantage when compared to Safari 3 in their respective current states.
As far as I am concerned Stargate SG1 "jumped the shark" when Annubis was killed.
I can't help but agree with you; there have been some good episodes of SG1 after that point (most of season 8's conclusion was decent enough), but season 9 & 10 have been dire overall - the Ori as an enemy are just uninteresting. However, I disagree strongly with you about Atlantis - at first I was reluctant to even watch it and when I did start watching the first few episodes I did so with a very strong bias against it, however the bias was unwarranted and in fact Atlantis is the only thing that has been maintaining my interest in the Stargate franchise as of late. Though there are parallels that can be drawn between the main Atlantis and SG1 casts there are more than enough differences in terms of personality and history to keep my interest in them. I only hope that with the release of these two movies they finally bury SG1:/
Note: I was the AC for that comment - I had thought I was logged in but evidently I was not.
Please note I explicitly said caching agents which includes caching proxys and your browser amongst other things, but even with respect to only the browser as you seem to have (mis)interpreted the thrust of my point and you're incorrect in your assertion that they should cache everything - browsers too must (and do in my experience, with a few fun bugs) follow the instructions in the headers with regards to caching. I kindly point you to RFC2616 (HTTP 1.1 spec) section 14.9 (Cache-Control):
The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the
request/response chain.
That is besides the point however, my point was that although GET requests can be used to generate dynamic content specific to the user this is very often not the case - for example most sites which have some form of news entrys will use get requests with some form of unique identifier to pull the article from the database and format it correctly. In this situation the developer of the application almost certainly wants the generated article cached in multiple stages to minimise load on the server (for example squid between the web and the application so that every time a person visits the page it does not need to be generated again, by the users ISP and by the users browser). Further, we all know that the contents of a URI in no way relate to what is actually happening server-side - tools such as mod_rewrite can be used to great effect and hide those pesky question marks, ampersands and verbose key and value pairs.
My point is this, as a skilled software engineer focused on web development I can make static pages look dynamic and dynamic pages look static trivially and so can anybody else - the URI was never intended to give any information about the resource it is identifying beyond it's location, it is misinterpretation and flawed analogys which give most people the impression that the URIs have intrinsic meaning; so making assumptions with regards to the cacheability of a resource based on it's URI if at best foolish (and hence isn't done). Instead implementation of (for example) the Vary field should be considered by the developer of 'dynamic' pages so that caching agents are aware that it is dynamic, and know which value in a request changes it and so can cache the variations of the page based on this.
If you're using more div elements than the corrosponding elements used to create a syntaxically and semantically correct table then you're doing something seriously wrong. This whole CSS/semantic HTML 'revolution' isn't about getting rid of tables because of some vague ideal that tables are somehow intrinsically evil - it is about taking a step backwards and re-thinking the whole web development process. If you recall HTML was designed as a hyper text markup language (emphasis mine), it's purpose is to 'mark up' data in a semantic manner, tables used for presentational purposes are incorrect because designers are ignoring the semantic meaning of them. In the same way, using many div elements in place of table elements is equally as incorrect - div elements by definition do not denote any particular meaning to the structure of that part of the document.
Fallout 2 is exceptional from both a gameplay and story perspective. Completely non-linear, amazing easter-eggs and probably 100+ hours of gameplay easy (only running through it once) - for me no other CRPG can hold a candle to the Fallout series, I only hope that Bethesda do the Fallout series justice if/when they eventually release Fallout 3.
Last I understood AJAX stood for Asynchronous JavaScript and XML - XUL is a XML UI markup language and uses JavaScript as glue code, as long as they use the XMLHTTPRequest object to communicate with the server then of course it can be claseed as an AJAX application (moreso than most AJAX apps infact, as it's actually an XML document as opposed to HTML or XHTML served incorrectly).
Firstly i'd like to point out the fact that you've not addressed my main point: That Java being (theoretically) cross-platform means jack shit when it depends on a JVM which is platform-specific and propriatary.*
As for my platform: Currently it's primerily Linux on AMD64 (used on both my laptop and desktop machines), sure there's a JVM available today but for a long period of time (greater than a year, at a minimum) I was on a platform which lacked a usable JVM. Additionally, I use Linux on PPC almost daily and that still doesn't (and probably won't ever) have a JVM from sun - sure there's a couple of open-source VMs that run on this architecture, but none of them seem to be in a useable state yet.
Those two are just architectures I use daily, as I understand it there's no JVM provided by Sun for the BSDs, the version used for OSX is maintained by Apple and isn't fully compatible with Sun's JVM etc etc. Going back to the AMD64 architecture - it took them nearly two years I seem to recall to release a stable JVM for it - if another architecture is relased for the masses how long will it take Sun to release a new JVM - baring in mind that the codebase is only going to grow and Sun don't directly make any profit from Java (at least afaict).
*Sure the spec is available and there are people attempting to make an open-source JVM but today afaik there aren't any that are actually at the point where they're useful.
Yeah, cross-platform coding sucks. When are these companies going to learn that we want proprietary binaries that need to be recompiled on each platform?
Isn't that an accurate description of Sun's JVM:)
There are those of us who don't have the luxury of running a platform which Sun feels is important enough to warrent a pre-compiled propriatory binary for, and for us Java applications simply aren't an option.
Re:I don't get the question, I think
on
AJAX and IE7?
·
· Score: 1
Indeed, and that is infact my point - I was intending to mention the fact the change actually benefits developers in the long term as it means that it will be a truely standardised interface, i'm not a fan of Microsoft or IE (I do a fair bit of development work for the web) but at least it seems like they're really trying to fix things up in IE7 (preferable imho to adding more buggy features).
Re:I don't get the question, I think
on
AJAX and IE7?
·
· Score: 1
They have. It's now identical to that used by all the alternative browsers (the team state the reason as being corporate users block all active X content, meaning that currently AJAX applications are unsuitable for corporate environments using IE).
I don't know about the official PS2 Dev kit, but one of my housemates and myself purchased the PS2 linux development kit for something in the region of ~200GBP and it's great - sure you need a grounding in GNU/Linux (I've got some experience with GNUU/Linux so helped my housemate who while being an excellent programmer had been strictly Windows only). It's good enough for us to tinker with in our spare time and to make some (admittedly) primitive games.
Check out these WHO statistics, posted by earlier on in this discussion:
Belgium has a population density of 339 p/km^2 and a suicide rate of 29.4 (males) 10.7 (females) per 100k (I assume deaths).
Japan has a population density of 337 p/km^2 and a suicide rate of 36.5 (males) 14.1 (females) per 100k (I assume deaths).
The Netherlands is has a significantly lower relative suicide rate though. I'm not agreeing with the gp but there does at least with the above examples appear to be correlation, if not causation.
They can, but only if non-Sun developers sign over their copyright to them ala mySQL - the problem stems from the fact that contributors to OO.o are contributing code to the GPL'd version and Sun does not own the copyrights to these changes unless the submitter signs them over (infact, I believe Sun already requires contributers to do this so the changes can be rolled back into StarOffice). Of course the GGP is correct - people buy StarOffice for the support Sun offers with it and not the rebranding so the arguement can easily be made that Sun has nothing to lose by only maintaining a GPL version of the codebase, making it easier for developers to contribute source code to the project.
I can't resist the chance to pimp out the content negotiation script I wrote precisely for this purpose (conditonal serving of content to UAs that support it). It's robust, simple to use and when compared to other scripts i've looked at since writing it, follows the HTTP spec a lot more accurately* and has no 'gotchas'. Any criticism is very welcome.
*As the spec doesn't specify how to handle malformed headers i've used my own judgement as to how to deal with them.
It seems to me that you're looking at the issue from only a single perspective - I used to be the admin for a fairly popular DoD server a few years back; we had a minimal swearing policy - the occasional 'oh fuck' and such over the comms was generally given the blind eye but we were not as leniant in the text chat as that involves a little more thought to type. The reason for this is that we found that by keeping the language in check we achieved two goals - firstly the annoying 14 year olds were quickly weeded out and secondly it was a more family friendly environment - we had several teenage kids and their parents who would play together. In all the games that i've played online before and after this i've never encountered such a situation where two generations of a family can play together and frankly I miss it - it was the most friendly gaming environment i've been a part of and was so without being at the expense of competition (father versus son battles were always hard fought).
If you use Windows, AutoUpdate at least weekly. Nightly may be overkill, but isn't really hurting anything.
The thing is Microsoft only release patches once a month (with the notable exception of the WMF vulnerability), so that would be largely pointless. I patch my Windows installations on the first Tuesday of the month, every month - this is sufficient for sysadmins of large corporate environments and it's good enough for me.
The best bet for windows users is to run as a non-priveledged user and modify the file/folder permissions of any applications that require administrative write access. For really shoddily designed programs, holding down shift and right-clicking the exe/shortcut brings up the context menu with the "run as" option. Use it to run such programs that require it, that or use the runas command in said shortcut and deal with entering a password at the command-line.
Slashdot Mirror
It only works for user agents that handle JavaScript (which includes the major search engine spiders); the 301 redirect method on the other hand has been part of http specification from the beginning and is (anecdotally speaking) supported by just about every http client.
The user-agent string is not a reliable indicator of which user-agent is being used (as counter-intuitive as this seems), a much better methodology (that several other people have already mentioned) is to use IE conditional comments to serve additional stylesheets to specific versions of Internet Explorer after the main stylesheet to override only the specific rules required to get that version of internet explorer to display the content as expected.
This has several advantages:
This is the methodology I prefer to follow with the sites that I develop, and after the experiences I had testing compatibility and fixing various layout problems that remained in IE7 I can say that it definitely pays off. Personally I'm hoping that IE8 will be close enough that I can finally dump IE conditional comments entirely once the older versions have disappeared and relegate it to the pile of no-longer relevant skills alongside the ability to generate pixel perfect layouts using tables & invisible spacer gifs and the ability to consistently beat almost anyone at Perfect Dark multiplayer.
I disagree with your assertion that win2k would still the best version of Windows for daily use for a single reason; win2k (the desktop version) doesn't run a terminal services server. In XP pro I can enable remote desktop on all my windows machines and launch a terminal services client (mstsc on windows, rdesktop from linux etc) and access the machine remotely from anywhere on the network (or with some firewall configuration any computer with internet access - this feature alone sold me on XP, being able to use my workstation without having to be physically infront of it is a fantastic time-saver.
I seem to recall using something similar with VNC, however being a separate application it requires installing the server software on the machine you wish to access and client software on the machine you're using to access it (though, I believe there are stand-alone versions) and takes more time/effort than enabling a single checkbox.
Not long at all, infact there was an article less than a month ago about Eve Online's linux and max osx support via wine (Cadega). Personally I can't decide if it's a good thing (because it's now a supported platform) or a bad thing (because there's little motivation to create native ports if running it through wine is "good enough").
Yes, I was talking about XHTML 1.0 (Appendix C is the location of said compatibility guidelines), it is widely considered to have been a mistake to allow developers to send XHTML documents with the wrong Content-Type because it causes subtle errors and defeats the purpose of using an XML based language (amongst many other reasons). My point is that when you serve XHTML as text/html you negate the point of using XML; You lose the ability to embed other XML languages (such as MathML or SVG) within your document, the page is no longer sent through an XML parser that checks for well-formedness thusly you're likely to introduce subtle errors without realising. When the day comes that all major UAs support application/xhtml+xml correctly and you decide to switch the Content-Type over there is a good chance of your pages not being displayed (works fine in IE but dies in Firefox due to crappy content negotiation) due to subtle errors in your markup that weren't apparent when your document was being parsed as tag soup.
And for all these difficulties you get what? On the web today, with IE still having ~80% market share, XHTML offers no advantage of HTML4 and has a whole pile of potential pitfalls that a developer must take into account of and hack around. For example, <, >, & are all treat as markup irrelevant of where they are in a document when a page is treat as XML, causing problems with inline JavaScript blocks; as a developer you have to explicitly declare the contents of script block as cdata using <![CDATA[ followed by a closing ]]> with all Javascript between those two elements, however because the Javascript interpreter treats anything within a JavaScript block as code (and you're sending it as text/html) you have to comment them out so that when served as text/html to older browsers they don't try to execute the cdata declaration as code.
There are many, many more problems associated with sending XHTML as text/html with various hacks to mitigate some of them to a greater or lesser degree. However I don't feel that sending XHMTL as text/html is ever a good idea and if you insist on generating XHTML markup then I suggest you use a good content negotiation script to send it as application/xhtml+xml where the browser supports it and when it does not using XSLT to transform the document to HTML before sending it to UAs that do not.
Do you have any evidence to back up this sweeping statement? In my opinion this was the case from the early days of the web, through the original browser wars and for a period afterwards (until maybe '01-02) at which point people started realising that contaminating the markup with presentational cruft was a good way to create maintainability nightmares, and made major redesigns of medium to large sites a frustrating and time-consuming (thus costly) process.
This is, of course, very true (and I forsee Internet Explorer lagging behind the other 'major' browser vendors), however this can be said about any new web specifications (the XHTML 1.0 spec was released as a recommendation in January 2000, and IE doesn't support it in any way, shape or form*).
Nowadays, the commonly used browsers (>IE6, Gecko based browsers, Konq, Safari, Opera) all implement a large subset of the HTML 4 spec, although you are right that there are some presentational issues (mostly due to the fact that the spec is vague in places) these can be eliminated with a judicious application of CSS rules.
Personally i'm glad that the w3 have taken the helm wrt the HTML5 spec - I had major problems with the direction that WHATWG were going with it. A specific example is their introduction of the presentational font element; their note that it should only be used by WYSIWIG tools and to be syntactically valid said tool must add a special meta element is laughably nieve. As the font element has no semantic meaning and no benefit over the equally semantically meaningless span element with a suitable styling via CSS - sure you could argue it offers backwards compatibility with legacy documents, however I would assume that a document that is not syntactically valid HTML4 would need major work to be cleaned up to be valid HTML5 anyway (plus, that would be disobeying the spirit of the spec, being as such content would not be generated by a WYSIWIG editor).
Another worry is that they're integrating DOM stuff into the same spec, although it does make sense in some ways it seems like there is the distinct potential of losing focus by covering too diverse a set of problems. However, it is still early days yet and I will withhold judgement until we start seeing near-finalised drafts and browsers start implementing some of the new features.
* However, it can (mostly) deal with it if you (incorrectly, IMO, despite appendix C) send the mime-type as text/html and skip the XML prologue by parsing it as 'tag soup'.
Honestly, there's no site that I'm aware of that fills the same niche - personally I find the best reference for CSS / HTML questions are their respective specifications on the w3c site. My issue with w3schools, by the way, stems from the fact that often their information is misleading and occasionally even outright wrong; if you're an experienced developer these errors are fairly obvious, however if you're an experienced developer you're not really in the target audience for the site.
Okay nobody seems to have picked up on the obvious flaw with this statistic - the w3school's site (from which the data on which this prediction was based) is a (poor imho) web developer's resource. Naturally with an audience that has an intrinsic interest in browsers and standards Firefox (and other alternative browsers) it will show up in statistics generated disproportionately to it's actual usage in the general public, it also explains the adoption rate of IE7 being very high. These statistics are useless and that prediction is completely invalid outside of that specific site.
I'd disagree with your statement and moreover you're reasoning is fallacious. You're implying that either passing (or not) the Acid2 test acts as a good metric on which to judge how well a browser supports the CSS2 standard, an obviously false assumption being as the Acid2 test only ensures support for a tiny subset of the standard it claims to support. The only reasonable way to compare support would be to go through the specification and test the individual components work (for example webdevout's comparison of Firefox, Opera & IE) and then putting each browser through a comprehensive set of test pages and comparing how they render them compared to an expected example render as well as each other. Anything less is a purely subjective judgement.
My (purely subjective) opinion on the matter is that right now (Firefox 2 & Safari 2) are roughly equal in their support for the standards I use daily as a web developer - both have areas that are lacking wrt each other. However, i've recently been playing with the Firefox 3 nightlies and I'm inclined to think that Gecko 1.9 might give Fx3 an advantage when compared to Safari 3 in their respective current states.
I can't help but agree with you; there have been some good episodes of SG1 after that point (most of season 8's conclusion was decent enough), but season 9 & 10 have been dire overall - the Ori as an enemy are just uninteresting. However, I disagree strongly with you about Atlantis - at first I was reluctant to even watch it and when I did start watching the first few episodes I did so with a very strong bias against it, however the bias was unwarranted and in fact Atlantis is the only thing that has been maintaining my interest in the Stargate franchise as of late. Though there are parallels that can be drawn between the main Atlantis and SG1 casts there are more than enough differences in terms of personality and history to keep my interest in them. I only hope that with the release of these two movies they finally bury SG1 :/
Note: I was the AC for that comment - I had thought I was logged in but evidently I was not.
Please note I explicitly said caching agents which includes caching proxys and your browser amongst other things, but even with respect to only the browser as you seem to have (mis)interpreted the thrust of my point and you're incorrect in your assertion that they should cache everything - browsers too must (and do in my experience, with a few fun bugs) follow the instructions in the headers with regards to caching. I kindly point you to RFC2616 (HTTP 1.1 spec) section 14.9 (Cache-Control):
That is besides the point however, my point was that although GET requests can be used to generate dynamic content specific to the user this is very often not the case - for example most sites which have some form of news entrys will use get requests with some form of unique identifier to pull the article from the database and format it correctly. In this situation the developer of the application almost certainly wants the generated article cached in multiple stages to minimise load on the server (for example squid between the web and the application so that every time a person visits the page it does not need to be generated again, by the users ISP and by the users browser). Further, we all know that the contents of a URI in no way relate to what is actually happening server-side - tools such as mod_rewrite can be used to great effect and hide those pesky question marks, ampersands and verbose key and value pairs.
My point is this, as a skilled software engineer focused on web development I can make static pages look dynamic and dynamic pages look static trivially and so can anybody else - the URI was never intended to give any information about the resource it is identifying beyond it's location, it is misinterpretation and flawed analogys which give most people the impression that the URIs have intrinsic meaning; so making assumptions with regards to the cacheability of a resource based on it's URI if at best foolish (and hence isn't done). Instead implementation of (for example) the Vary field should be considered by the developer of 'dynamic' pages so that caching agents are aware that it is dynamic, and know which value in a request changes it and so can cache the variations of the page based on this.
LFS would almost certainly be a good place to start assuming you're meaning the whole GNU/Linux package and not just the Linux kernel.
If you're using more div elements than the corrosponding elements used to create a syntaxically and semantically correct table then you're doing something seriously wrong. This whole CSS/semantic HTML 'revolution' isn't about getting rid of tables because of some vague ideal that tables are somehow intrinsically evil - it is about taking a step backwards and re-thinking the whole web development process. If you recall HTML was designed as a hyper text markup language (emphasis mine), it's purpose is to 'mark up' data in a semantic manner, tables used for presentational purposes are incorrect because designers are ignoring the semantic meaning of them. In the same way, using many div elements in place of table elements is equally as incorrect - div elements by definition do not denote any particular meaning to the structure of that part of the document.
Hear hear!
Fallout 2 is exceptional from both a gameplay and story perspective. Completely non-linear, amazing easter-eggs and probably 100+ hours of gameplay easy (only running through it once) - for me no other CRPG can hold a candle to the Fallout series, I only hope that Bethesda do the Fallout series justice if/when they eventually release Fallout 3.
Last I understood AJAX stood for Asynchronous JavaScript and XML - XUL is a XML UI markup language and uses JavaScript as glue code, as long as they use the XMLHTTPRequest object to communicate with the server then of course it can be claseed as an AJAX application (moreso than most AJAX apps infact, as it's actually an XML document as opposed to HTML or XHTML served incorrectly).
Firstly i'd like to point out the fact that you've not addressed my main point: That Java being (theoretically) cross-platform means jack shit when it depends on a JVM which is platform-specific and propriatary.*
As for my platform: Currently it's primerily Linux on AMD64 (used on both my laptop and desktop machines), sure there's a JVM available today but for a long period of time (greater than a year, at a minimum) I was on a platform which lacked a usable JVM. Additionally, I use Linux on PPC almost daily and that still doesn't (and probably won't ever) have a JVM from sun - sure there's a couple of open-source VMs that run on this architecture, but none of them seem to be in a useable state yet.
Those two are just architectures I use daily, as I understand it there's no JVM provided by Sun for the BSDs, the version used for OSX is maintained by Apple and isn't fully compatible with Sun's JVM etc etc. Going back to the AMD64 architecture - it took them nearly two years I seem to recall to release a stable JVM for it - if another architecture is relased for the masses how long will it take Sun to release a new JVM - baring in mind that the codebase is only going to grow and Sun don't directly make any profit from Java (at least afaict).
*Sure the spec is available and there are people attempting to make an open-source JVM but today afaik there aren't any that are actually at the point where they're useful.
Isn't that an accurate description of Sun's JVM :)
There are those of us who don't have the luxury of running a platform which Sun feels is important enough to warrent a pre-compiled propriatory binary for, and for us Java applications simply aren't an option.
Indeed, and that is infact my point - I was intending to mention the fact the change actually benefits developers in the long term as it means that it will be a truely standardised interface, i'm not a fan of Microsoft or IE (I do a fair bit of development work for the web) but at least it seems like they're really trying to fix things up in IE7 (preferable imho to adding more buggy features).
They have. It's now identical to that used by all the alternative browsers (the team state the reason as being corporate users block all active X content, meaning that currently AJAX applications are unsuitable for corporate environments using IE).
I don't know about the official PS2 Dev kit, but one of my housemates and myself purchased the PS2 linux development kit for something in the region of ~200GBP and it's great - sure you need a grounding in GNU/Linux (I've got some experience with GNUU/Linux so helped my housemate who while being an excellent programmer had been strictly Windows only). It's good enough for us to tinker with in our spare time and to make some (admittedly) primitive games.
Check out these WHO statistics, posted by earlier on in this discussion:
Belgium has a population density of 339 p/km^2 and a suicide rate of 29.4 (males) 10.7 (females) per 100k (I assume deaths).
Japan has a population density of 337 p/km^2 and a suicide rate of 36.5 (males) 14.1 (females) per 100k (I assume deaths).
The Netherlands is has a significantly lower relative suicide rate though. I'm not agreeing with the gp but there does at least with the above examples appear to be correlation, if not causation.
They can, but only if non-Sun developers sign over their copyright to them ala mySQL - the problem stems from the fact that contributors to OO.o are contributing code to the GPL'd version and Sun does not own the copyrights to these changes unless the submitter signs them over (infact, I believe Sun already requires contributers to do this so the changes can be rolled back into StarOffice). Of course the GGP is correct - people buy StarOffice for the support Sun offers with it and not the rebranding so the arguement can easily be made that Sun has nothing to lose by only maintaining a GPL version of the codebase, making it easier for developers to contribute source code to the project.
I can't resist the chance to pimp out the content negotiation script I wrote precisely for this purpose (conditonal serving of content to UAs that support it). It's robust, simple to use and when compared to other scripts i've looked at since writing it, follows the HTTP spec a lot more accurately* and has no 'gotchas'. Any criticism is very welcome.
*As the spec doesn't specify how to handle malformed headers i've used my own judgement as to how to deal with them.
It seems to me that you're looking at the issue from only a single perspective - I used to be the admin for a fairly popular DoD server a few years back; we had a minimal swearing policy - the occasional 'oh fuck' and such over the comms was generally given the blind eye but we were not as leniant in the text chat as that involves a little more thought to type. The reason for this is that we found that by keeping the language in check we achieved two goals - firstly the annoying 14 year olds were quickly weeded out and secondly it was a more family friendly environment - we had several teenage kids and their parents who would play together. In all the games that i've played online before and after this i've never encountered such a situation where two generations of a family can play together and frankly I miss it - it was the most friendly gaming environment i've been a part of and was so without being at the expense of competition (father versus son battles were always hard fought).
The thing is Microsoft only release patches once a month (with the notable exception of the WMF vulnerability), so that would be largely pointless. I patch my Windows installations on the first Tuesday of the month, every month - this is sufficient for sysadmins of large corporate environments and it's good enough for me.
The best bet for windows users is to run as a non-priveledged user and modify the file/folder permissions of any applications that require administrative write access. For really shoddily designed programs, holding down shift and right-clicking the exe/shortcut brings up the context menu with the "run as" option. Use it to run such programs that require it, that or use the runas command in said shortcut and deal with entering a password at the command-line.