More importantly, the 510n comes with an ATI card that will be difficult to get to work properly with X.org
What makes you say that? I've had far better luck with ATI cards under linux and FreeBSD lately than with nVidia. Granted I haven't tried the X series cards, but for the cards I have set up, the X.org ati driver seems pretty solid- far better than either the X.org nv driver or the nVidia binary drivers.
What does FreeDOS have? Well it is DOS based, like Windows.
And there's your most likely answer. No need for MS conspiracy theories or fear of starting a linux distro flamewar. Occam's Razor and all that... Dell has a diagnostic suite that they run on every computer before it is shipped. This was why they originally claimed years ago that they wouldn't sell a PC without an OS. By installing a DOS-based OS, they can probably still use much of the same diagnostic suite.
As an added bonus, they don't have to update their install cd and their testing process every 6 months when whichever linux distro they choose releases a new version.
Yes, I've written 'AJAX' applications. I've been writing them since 2001. It's not the easiest platform to develop for, but it's not that bad either.
The reason Java failed is not that Java applications suck to write. From all accounts, and from my admittedly limited personal experience, Java is a great language to do application development in. The problem with Java applications is that they suck to use. Nobody (at least nobody I've ever talked to) likes using aplications written in Java. They're terrible. Every single Java application I've ever used has been hideous and slow, with one exception. The Zend IDE for PHP was still terribly slow, but it did at least manage to be almost attractive.
So tell me, what good is it to have a language that's easy to develop in if nobody ever wants to use the result? I'd rather spend a little bit more time in an environment that is harder to program for in order to end up with an application that is far more pleasant to use.
When you say in one sentence that something is about to occur (imminent), and then in the next that it may take some time, you contradict yourself. Imminent implies immediacy. I believe the word you were looking for is inevitable.
Sorry, I didn't mean to nitpick- It's just that as I read your post I heard a Spanish accented voice in my head saying "You keep using that word. I do not think it means what you think it means."
I suppose that depends who you are talking to. I've generally seen AJAX used to describe any type of interactive web application that uses javascript to load data from the server asynchronously. If you want to use a strict definition, Google Maps isn't AJAX either, as it uses neither XML nor the XmlHttpRequest object.
Given that it is new APIs and new software, you can bet that it's going to cost the client more, given that there are fewer toolkits and less experience with implementing these kinds of apps.
My point was that (IMO) the name was coined because developers could develop the exact same solutions, but charge more for it by slapping a buzzwordy name on it (with a bonus for piggybacking off the buzzwordy-ness of XML, even though most 'AJAX' applications don't actually use XML). And it is most definitely not new technology. It's a new name for something that many people have been doing for years. I wrote my first 'AJAX' app in 2001, and I'm pretty sure there were others before me, even if I wasn't aware of it at the time.
P.S. The trademark comment was a joke. You know... Sarcasm. As many others have said, names are rarely unique. But just FYI, capitalization does enter into trademarking, together with font and color. The word spam is not trademarked, but if you put up a web site talking about junk mail, with the heading SPAM in bold yellow letters, you could probably expect to be hearing from Hormel's lawyers over it.
What linux distribution are you using and how old is it? Every Linux Distro I've installed in the last year or two, everything, including sound, "just worked". The only things that didn't work out of the box are proprietary media formats, and that can be quickly solved by downloading the binary codecs from the mplayer website and dropping them in/usr/lib/win32 (no, i don't expect a casual user to know that, and I'm surprised that there aren't more distro's that automate that step.) AFAIK, pretty much all recent distros use ALSA which doesn't require a sound server, and even if you do need a sound server, KDE and Gnome take care of that for you automatically.
The point is, that as long as simple issues like playing a video become mammoth tasks, then the average person will just stick with something simpler. Hell, 90% of the time I can just install Windows and everything will work right out of the box.
In my experience, Linux is actually far superior to Windows in this area. With Linux, it takes an hour or so to run through the installer and get everything set up. (plus or minus, depending on distro, how much software you are installing, cd vs network, etc.) Once that's finished, run your distro's autoupdate program once to pick up all the latest updates, and you're set.
With windows (and I just installed WinXP on my wife's laptop a few days ago, so this is fresh in my memory)
Run through the install. Piece of cake. Then you have six iterations of windows update, each of which requires a reboot after completing.
update windows updater and install windows genuine advantage tool
install some random patches
install service pack 2 (for some reason it wouldn't let me do this until after I had done #2, even though SP2 superceded most if not all of the patches installed in #2.)
update media player or some other program that must be updated separately from all other upgrades.
install various post SP2 security updates and addons.
install updates to the updates in #5 (no, i'm not kidding)
Of course, once you get this far, you still have no useful software except windows media player and internet explorer (at least XP finally has the built in ability to handle.zip files and preview images). So now you spend another two hours downloading or installing from CD:
anti-virus
anti-spyware
X instant messenger
adobe acrobat
microsoft office, or some other office suite, or some form of office file viewer
mail program (unless you use a webmail service or the email program included with your office software)
whatever programs you have to use to actually get work done.
AJAX is a floor cleaner, Ajax is a (er, two) hero of Greek Mythology. That's the beauty of a trademark. Just like we can call junk mail spam without being harassed by Hormel, but we can't call it SPAM.
Anyway, in the translation I read they were names Aias.
As far as I can tell, the term AJAX was coined to allow consultants a way to bill more money for doing the same work. If they just described how they were going to build a dynamic web application to a client PHB, his eyes would glaze over, but if they tell him they're going to build him a webside using AJAX, his PHB Buzzword Fetish kicks in and suddenly the consultant can bump his billing rate up 10-20% for doing the exact same thing he would have done anyway.
Actually, I think all of your points could be summed up as:
The reason people use AJAX over Java applets is due to the spectacular failure of SUN to make Java not suck. (At least for app development. I will concede that Java doesn't necessarily suck for server side development, even though I personally dislike it.)
If I leave a loaded gun lying on the sidewalk and someone picks it up and shoots someone else, I think I may get some bad karma.
It sounds to me to be more equivalent to leaving an unloaded gun laying out, and then somebody else picked it up and loaded it before using it to shoot somebody. It sounds like it needed to be modified by somebody for it to be used for malicious purposes.
When all is said and done, HD-DVD will win. Based off of ONE reason. People will think BLU-RAY is something new and weird, but HD-DVD is just a new version of DVDs. Consumers are stupid, which makes HD-DVD the default winner. It's the one consumers are going to know what it is and buy it.
That must be why SACD trounced all over DVD-Audio as the successor to CD's.
Wait, what was that? Everyone you know still has a CD player?
It seems to me that sending a large chunk of SQL over the wire, parsing / validating it, compiling it, and executing it must be for any sane DB slower than a stored proc.
While I am a fan of stored procedures in many cases (if only to avoid having random sql statements strewn around your code), the above is not necessarily true. All DB's that I've used will cache the query plan for queries that you execute, meaning that if you write your query correctly , you only hit the performance penalty for parsing, compiling, etc. the first time.
Of course, this only works if the database supports the concept of bind variables, because a database can't necessarily tell that the following queries are identical: insert into t values (1); insert into t values (2); insert into t values (3);
but it can if you do something like this with varying values for ':X': insert into t values (:X)
even if it were illegal, they would probably have to prove that he intentionally lied and was not merely misinformed, which can sometimes be very difficult (or at least expensive) to prove.
To end, I'll summarize the document. You can't use true XHTML unless you don't care about IE. Unless you really know your stuff, XHTML as HTML will just confuse you and give you wrong impressions about true XHTML. XHTML as HTML has no advantages over HTML. Therefore, most people should use HTML.
That looks like a pretty accurate summary to me. I've bolded that point that (IMO, anyway) he is completely wrong about. And without the point, the rest of it is not very convincing.
On the other hand, it is a pretty good checklist of things to watch out for when writing XHTML, regardless of what mime type you use.
I am not saying that we should break document.write() for existing applications. I am merely suggesting that anyone writing a new web page now (or remotely recently) should not use document.write(), especially if they are writing XHTML (obviously, since it is not supported), but (IMO) also if they are not.
In other words, I'm not saying: FTP isn't secure. Kill it! Force everyone to use SFTP right now! I'm saying: FTP isn't secure. From now on all new servers should be set up with SFTP instead!
Except that it's still a little different, because there are cases where SFTP is not a workable alternative to FTP which is not the case for document.write().
* Microsoft brought computing to the masses (what's wrong with that?)
* Microsoft made lots of money by being good at what they do (what's wrong with that?)
The funny thing about those comments is that in many ways Microsoft really has made the software world what it is today, and not in a good way. I can't find the original quote anymore, but IMO the most damning comment I have ever read regarding the effect that Microsoft has had in bringing computing to the masses came from a prominent aerospace/mechanical engineer some years ago:
If [my company] took the same approach to our work as Microsoft takes to designing software, airliners would be falling out of the sky at a rate of several times per week and everyone would think that was normal.
Maybe some people are interested in other features of the CN400, such as 400 MHz memory bus, SATA controller, etc., but don't really care about video encoding?
I'm considering getting an SP board to use in a home firewall/file server as my old pentium pro is starting to reach the end of it's life.
If you remember nothing else today remember this sentence: "Security costs CPU cycles.."... To get security you have to spend a metric-fuckton of CPU cycles. Fact. What I want people to recognise is that it is worth making your programs slower to consign buffer overflows to the history book.
Not necessarily true. There is a tradeoff that can be made. You can implement security without the cost of extra CPU cycles (or at least very minimal extra CPU cycles) at the cost of greatly increased programmer cycles. Depending on the type of project you are working on, CPU cycles tend to be far easier to come by than programmer cycles, but this is not always the case. It is possible to write a very large C/C++ program without buffer overflows, even without using any stack protecting tools at compile time. But it takes strong discipline and a lot of time from experienced programmers to do it. If you aren't willing to put that time in, by all means, use the automated tools or slower managed code environments, but please don't spread the myth that secure == slower.
No, there are significant differences. Try this code, for example:... The result it gives in HTML is completely different to the result it gives in XHTML.
As I said, I've never seen a non-contrived example where there was a meaningful difference. Why would you ever use that in a real webpage? And as I also said, even here, the solution is trivial: be consistent about how you use tbody's. I never said there weren't any differences. I only said that there weren't any differences that would prevent you from designing a page that works fine as both text/html and appliation/xhtml+xml.
Now put yourself in the place of a Slashdot staffer who knows that he's not going to be able to force advertisers to rewrite their Javascript. That's why I said that I understand why slashdot didn't go the XHTML route. There's no reason that XHTML would be a benefit to them over good clean HTML 4. That said, I also believe that anyone who still writes code using document.write() deserves a good beating, and as more sites and site authors want to support XHTML, the advertisers are going to have to change soon enough anyway. Either way, that is not a reason that people in general should wait until all popular browsers support application/xhtml+xml to use XHTML, which is what the author of the site linked in the OP was suggesting.
You've missed the point: the script and style tags are PCDATA in XHTML, not CDATA. That means comments are not ignored, so your HTMLish scripts and styles, hidden in comment tags, will be invisible to an XHTML user agent. If they aren't, it isn't an XHTML user agent.
No, I didn't miss the point. I was saying that there's no reason to even use HTML/XML comments in the first place. Hiding scripts in HTML comment tags was a nasty hack to keep browsers that didn't recognize the script or style tags from displaying the contents of the script tag. No browser (that I am aware of) released in the last 8 years requires this nasty hack, but everyone still does it anyway. My point was that all of his nasty escaping is unnecessary. The following will work fine in every browser that I'm aware of:
And if you still want to be paranoid, and you don't believe me that the comments are completely unnecessary, you can (as I stated) just use external files:
Firstly a 64bit program will be bigger and probably slower (dispite what the zealots tell you) because of having to drag double sized data across the memory bottleneck.
Correct me if I'm wrong, but aren't you only dealing with double sized data when you use pointers? byte, char, int, etc. should all still be the same size, right?
(Actually I know int can vary depending on the underlying architecture, but I thought I remembered reading somewhere that for compatibility, x86-64 still uses 32 bit ints.)
Slashdot Mirror
I've not had any problem getting Linux or FreeBSD to work with any ATI card I've owned in the last 6 years. I wish I could say the same for nVidia.
More importantly, the 510n comes with an ATI card that will be difficult to get to work properly with X.org
What makes you say that? I've had far better luck with ATI cards under linux and FreeBSD lately than with nVidia. Granted I haven't tried the X series cards, but for the cards I have set up, the X.org ati driver seems pretty solid- far better than either the X.org nv driver or the nVidia binary drivers.
What does FreeDOS have? Well it is DOS based, like Windows.
And there's your most likely answer. No need for MS conspiracy theories or fear of starting a linux distro flamewar. Occam's Razor and all that... Dell has a diagnostic suite that they run on every computer before it is shipped. This was why they originally claimed years ago that they wouldn't sell a PC without an OS. By installing a DOS-based OS, they can probably still use much of the same diagnostic suite.
As an added bonus, they don't have to update their install cd and their testing process every 6 months when whichever linux distro they choose releases a new version.
Yes, I've written 'AJAX' applications. I've been writing them since 2001. It's not the easiest platform to develop for, but it's not that bad either.
The reason Java failed is not that Java applications suck to write. From all accounts, and from my admittedly limited personal experience, Java is a great language to do application development in. The problem with Java applications is that they suck to use. Nobody (at least nobody I've ever talked to) likes using aplications written in Java. They're terrible. Every single Java application I've ever used has been hideous and slow, with one exception. The Zend IDE for PHP was still terribly slow, but it did at least manage to be almost attractive.
So tell me, what good is it to have a language that's easy to develop in if nobody ever wants to use the result? I'd rather spend a little bit more time in an environment that is harder to program for in order to end up with an application that is far more pleasant to use.
About to occur; impending:
When you say in one sentence that something is about to occur (imminent), and then in the next that it may take some time, you contradict yourself. Imminent implies immediacy. I believe the word you were looking for is inevitable.
Sorry, I didn't mean to nitpick- It's just that as I read your post I heard a Spanish accented voice in my head saying "You keep using that word. I do not think it means what you think it means."
I suppose that depends who you are talking to. I've generally seen AJAX used to describe any type of interactive web application that uses javascript to load data from the server asynchronously. If you want to use a strict definition, Google Maps isn't AJAX either, as it uses neither XML nor the XmlHttpRequest object.
Given that it is new APIs and new software, you can bet that it's going to cost the client more, given that there are fewer toolkits and less experience with implementing these kinds of apps.
My point was that (IMO) the name was coined because developers could develop the exact same solutions, but charge more for it by slapping a buzzwordy name on it (with a bonus for piggybacking off the buzzwordy-ness of XML, even though most 'AJAX' applications don't actually use XML). And it is most definitely not new technology. It's a new name for something that many people have been doing for years. I wrote my first 'AJAX' app in 2001, and I'm pretty sure there were others before me, even if I wasn't aware of it at the time.
P.S. The trademark comment was a joke. You know... Sarcasm. As many others have said, names are rarely unique. But just FYI, capitalization does enter into trademarking, together with font and color. The word spam is not trademarked, but if you put up a web site talking about junk mail, with the heading SPAM in bold yellow letters, you could probably expect to be hearing from Hormel's lawyers over it.
The point is, that as long as simple issues like playing a video become mammoth tasks, then the average person will just stick with something simpler. Hell, 90% of the time I can just install Windows and everything will work right out of the box.
In my experience, Linux is actually far superior to Windows in this area. With Linux, it takes an hour or so to run through the installer and get everything set up. (plus or minus, depending on distro, how much software you are installing, cd vs network, etc.) Once that's finished, run your distro's autoupdate program once to pick up all the latest updates, and you're set.
With windows (and I just installed WinXP on my wife's laptop a few days ago, so this is fresh in my memory)
Run through the install. Piece of cake. Then you have six iterations of windows update, each of which requires a reboot after completing.
Of course, once you get this far, you still have no useful software except windows media player and internet explorer (at least XP finally has the built in ability to handle
AJAX is a floor cleaner, Ajax is a (er, two) hero of Greek Mythology. That's the beauty of a trademark. Just like we can call junk mail spam without being harassed by Hormel, but we can't call it SPAM.
Anyway, in the translation I read they were names Aias.
As far as I can tell, the term AJAX was coined to allow consultants a way to bill more money for doing the same work. If they just described how they were going to build a dynamic web application to a client PHB, his eyes would glaze over, but if they tell him they're going to build him a webside using AJAX, his PHB Buzzword Fetish kicks in and suddenly the consultant can bump his billing rate up 10-20% for doing the exact same thing he would have done anyway.
Actually, I think all of your points could be summed up as:
The reason people use AJAX over Java applets is due to the spectacular failure of SUN to make Java not suck.
(At least for app development. I will concede that Java doesn't necessarily suck for server side development, even though I personally dislike it.)
If I leave a loaded gun lying on the sidewalk and someone picks it up and shoots someone else, I think I may get some bad karma.
It sounds to me to be more equivalent to leaving an unloaded gun laying out, and then somebody else picked it up and loaded it before using it to shoot somebody. It sounds like it needed to be modified by somebody for it to be used for malicious purposes.
Are we just seeing lighter materials? More efficient solar sails? More efficient transfer of solar energy to kinetic?
Nah, it's just global warming.
The death of DRM is imminent. It might take some time... but it'll come for sure.
I don't think that word means what you think it means.
When all is said and done, HD-DVD will win. Based off of ONE reason. People will think BLU-RAY is something new and weird, but HD-DVD is just a new version of DVDs. Consumers are stupid, which makes HD-DVD the default winner. It's the one consumers are going to know what it is and buy it.
That must be why SACD trounced all over DVD-Audio as the successor to CD's.
Wait, what was that? Everyone you know still has a CD player?
It seems to me that sending a large chunk of SQL over the wire, parsing / validating it, compiling it, and executing it must be for any sane DB slower than a stored proc.
While I am a fan of stored procedures in many cases (if only to avoid having random sql statements strewn around your code), the above is not necessarily true. All DB's that I've used will cache the query plan for queries that you execute, meaning that if you write your query correctly , you only hit the performance penalty for parsing, compiling, etc. the first time.
Of course, this only works if the database supports the concept of bind variables, because a database can't necessarily tell that the following queries are identical:
insert into t values (1);
insert into t values (2);
insert into t values (3);
but it can if you do something like this with varying values for ':X':
insert into t values (:X)
even if it were illegal, they would probably have to prove that he intentionally lied and was not merely misinformed, which can sometimes be very difficult (or at least expensive) to prove.
To end, I'll summarize the document. You can't use true XHTML unless you don't care about IE. Unless you really know your stuff, XHTML as HTML will just confuse you and give you wrong impressions about true XHTML. XHTML as HTML has no advantages over HTML. Therefore, most people should use HTML.
That looks like a pretty accurate summary to me. I've bolded that point that (IMO, anyway) he is completely wrong about. And without the point, the rest of it is not very convincing.
On the other hand, it is a pretty good checklist of things to watch out for when writing XHTML, regardless of what mime type you use.
I am not saying that we should break document.write() for existing applications. I am merely suggesting that anyone writing a new web page now (or remotely recently) should not use document.write(), especially if they are writing XHTML (obviously, since it is not supported), but (IMO) also if they are not.
In other words, I'm not saying:
FTP isn't secure. Kill it! Force everyone to use SFTP right now!
I'm saying:
FTP isn't secure. From now on all new servers should be set up with SFTP instead!
Except that it's still a little different, because there are cases where SFTP is not a workable alternative to FTP which is not the case for document.write().
* Microsoft brought computing to the masses (what's wrong with that?)
* Microsoft made lots of money by being good at what they do (what's wrong with that?)
The funny thing about those comments is that in many ways Microsoft really has made the software world what it is today, and not in a good way. I can't find the original quote anymore, but IMO the most damning comment I have ever read regarding the effect that Microsoft has had in bringing computing to the masses came from a prominent aerospace/mechanical engineer some years ago:
If [my company] took the same approach to our work as Microsoft takes to designing software, airliners would be falling out of the sky at a rate of several times per week and everyone would think that was normal.
Maybe some people are interested in other features of the CN400, such as 400 MHz memory bus, SATA controller, etc., but don't really care about video encoding?
I'm considering getting an SP board to use in a home firewall/file server as my old pentium pro is starting to reach the end of it's life.
the new via epia sp uses the cn400 chipset, although apparently it still uses the vt1623 tv encoder.
s p?motherboardId=261
http://www.viaembedded.com/product/epia_sp_spec.j
If you remember nothing else today remember this sentence: "Security costs CPU cycles.." ... To get security you have to spend a metric-fuckton of CPU cycles. Fact. What I want people to recognise is that it is worth making your programs slower to consign buffer overflows to the history book.
Not necessarily true. There is a tradeoff that can be made. You can implement security without the cost of extra CPU cycles (or at least very minimal extra CPU cycles) at the cost of greatly increased programmer cycles. Depending on the type of project you are working on, CPU cycles tend to be far easier to come by than programmer cycles, but this is not always the case. It is possible to write a very large C/C++ program without buffer overflows, even without using any stack protecting tools at compile time. But it takes strong discipline and a lot of time from experienced programmers to do it. If you aren't willing to put that time in, by all means, use the automated tools or slower managed code environments, but please don't spread the myth that secure == slower.
No, there are significant differences. Try this code, for example: ...
The result it gives in HTML is completely different to the result it gives in XHTML.
As I said, I've never seen a non-contrived example where there was a meaningful difference. Why would you ever use that in a real webpage? And as I also said, even here, the solution is trivial: be consistent about how you use tbody's. I never said there weren't any differences. I only said that there weren't any differences that would prevent you from designing a page that works fine as both text/html and appliation/xhtml+xml.
Now put yourself in the place of a Slashdot staffer who knows that he's not going to be able to force advertisers to rewrite their Javascript.
That's why I said that I understand why slashdot didn't go the XHTML route. There's no reason that XHTML would be a benefit to them over good clean HTML 4. That said, I also believe that anyone who still writes code using document.write() deserves a good beating, and as more sites and site authors want to support XHTML, the advertisers are going to have to change soon enough anyway. Either way, that is not a reason that people in general should wait until all popular browsers support application/xhtml+xml to use XHTML, which is what the author of the site linked in the OP was suggesting.
You've missed the point: the script and style tags are PCDATA in XHTML, not CDATA. That means comments are not ignored, so your HTMLish scripts and styles, hidden in comment tags, will be invisible to an XHTML user agent. If they aren't, it isn't an XHTML user agent.
// <![CDATA[
...
// ]]>
No, I didn't miss the point. I was saying that there's no reason to even use HTML/XML comments in the first place. Hiding scripts in HTML comment tags was a nasty hack to keep browsers that didn't recognize the script or style tags from displaying the contents of the script tag. No browser (that I am aware of) released in the last 8 years requires this nasty hack, but everyone still does it anyway. My point was that all of his nasty escaping is unnecessary. The following will work fine in every browser that I'm aware of:
<script type="text/javascript">
</script>
And if you still want to be paranoid, and you don't believe me that the comments are completely unnecessary, you can (as I stated) just use external files:
<script type="text/javascript" src="foo.js"></script>
Firstly a 64bit program will be bigger and probably slower (dispite what the zealots tell you) because of having to drag double sized data across the memory bottleneck.
Correct me if I'm wrong, but aren't you only dealing with double sized data when you use pointers? byte, char, int, etc. should all still be the same size, right?
(Actually I know int can vary depending on the underlying architecture, but I thought I remembered reading somewhere that for compatibility, x86-64 still uses 32 bit ints.)
Of course, some of us read the light version because we prefer the way it looks, not because of the download size.
That said, everything but the "Post Comment" page looks the same to me as it did before, so I'm not quite sure what their complaining about.