Any sysadmin that has ever had to juggle multiple JVMs can tell you that Sun's Write Once Run Anywhere motto can quickly become Write Once Debug Everywhere.
Do you have an example? I have never found this; even substantial applications like NetBeans run on different VMs, and even different vendors VMs.
Don't forget that IBM is still pushing their non-Java SWT instead of Swing.
Apart from the fact that few people are using SWT, it is not an instead-of situation; any distribution of Java called Java has to include Swing.
it's harder to write a description for them so that you can parse them using a general purpose XML library than it is to parse them using the traditional UNIX tools...
No it isn't. Just stick to the simple XML guidelines and any XML parser can parse them.
If you want people to treat XML seriously
Almost everyone already is treating XML seriously.
, give them the tools to do something useful with them. Before you produce another "ant", give us xmlgrep, xmlsort, xmlawk, xmlsql.
All this is already there. There is a standard XML dialect called XSL that includes searching, sorting, and extracting, and there are other XML dialects for interfacting with SQL. These features have been around for years!
besides, what's stopping you to use make should you create your own java sysadmin tools?
Nothing, except that Ant has a huge amount of support for Java and associated tools. Almost every tool and product developed to assist Java developers provides an Ant library to add functionality. To work with 'make' would be a huge step backwards.
XML syntax is mostly noise with a bit of data thrown in and delivers on none of it's promises.
What utter nonsense! Of course XML has delivered. An example is the Open Office document format, that is XML-based, easy to transform to other formats (such as PDF), and because it is XML (open and documented) is also now accepted by KDE office applications.
Think of the irony that the resources we spend on trying to find new places to explore or colonize hundreds or thousands of years down the road would greatly increase the standard of living for the world's poor today?
If you want to increase the standard of living for the world's poor, why are you interested in the comparatively minor spending on exploration? The amount spend on space exploration and research is, and has always been, insignificant compared to the spending on defence, for example. Why not cut back on weapons spending and research? To suggest cutting back on space research is a silly as to suggest cutting back on education, when you consider how much money is spend elsewhere.
You can. But you should not. You're falling into the Turing Tar Pit. The C and C++ building facilities are too immature for now. And the Ant developers certainly are not putting priority in making it work well with C and C++ building anyhow.
This is a reasonable point. However, the original post mentioned C or C++ as part of a general Java project, so any support should be adequate. For better or worse, ant is Java-focused, so C and C++ building is not going to be a priority.
I know the moderators will hit me for this, but from the sys admins point of view - ant is evil!
Ant isn't for sys admins.
It is simply another build program to learn. The C and C++ stuff for the kernel is "make" - now I have to learn "ant" for Java programs.
As Java isn't used (yet!) for kernel stuff, what is the problem?
I am not against learning new things, but where some people see XML as a good thing - I think it sucks! I despise any time I see a config file that is XML. XML is for the "parsing impaired" - use a plain text file like everything in/etc !!!
Sorry, wrong way around. XML was designed specifically from the start to be parser-friendly. There are very simple APIs which handle any XML file such as SAX./etc is a very good example of what is wrong with plain text files - no single program or API could ever handle the range of formats of files there! Incidentally - XML IS plain text.
Buffer overflow exploits dropped of the face of the map after the morris worm. They fixed the flaws and everyone promptly forgot about it.
I think your emphasis on exploits is detracting from the main issue. It is the buffer overflows themselves that are the problem, and have been a general software issue for decades. Even if not used for deliberate exploits, they certainly gave rise to an endless series of bugs in C-based applications. This is why Gate's comment is so unhelpful - the 'allocate and hope' attitude to memory management is not just poor in terms of exploits; it is poor in terms of general software development quality, and the implication - that Microsoft's Windows developers were writing code so thoughlessly - is troubling. Some of us software engineers have higher standards!
What it wasn't easy to do was exploit buffer overflows. Buffer overflow exploit knowledge has only really happened in the last 10 years or so
I would certainly argue with this.
One of the first widely publicized buffer overrun attacks occurred in 1988 as part of the infamous Internet worm incident. Just because kits to make exploiting buffer overruns easy weren't available does not mean that the problem was not widely known.
Gates says: "When you look at the issue of buffer overruns, eight to 10 years ago in software development, you did not know how much space you might need for something so you just create a big buffer zone to allow things to happen. Who knew that people could go exploit that and use that buffer space to do malicious things?"
Well, anyone who was a half-competent developer knew this was a possibility, as there had been widely known exploits at least 17 years ago!
The same is true with this point. 10 years ago, while Buffer overflows were known, they weren't common knowledge, and the average developer certainly didn't have the knowledge or tools to combat them.
Of course they were common knowledge! They were common knowledge for C programmers even 30 years ago. Just check the man page for C functions like 'gets', and read the warnings.
No, he's right and you're either an idiot or a liar. If not the latter, you might want to put your arrogance aside for a moment and consider that maybe, just maybe, you don't know it all. After all, you've already proved it to the rest of us.
Just to clarify things - the point I am trying to make should surely be uncontroversial. If you are dealing with a very high volume website and you are trying to attract customers, it makes sense to make those people visiting your website feel welcome! Any sort of barrier to the use is not just bad manners, it is bad business. This sort of website is not like a bank or other company where you already have clients and the website is simply yet another service, so if it doesn't work this is not a problem.
If you really think someone is a 'liar or idiot' or 'arrogant' for doing this approach, I would suggest that you are getting far too worked up about it. Is it really worth getting so offensive about what is, after all, a relatively minor matter - conditionally including some HTML and CSS?
No, he's right and you're either an idiot or a liar. If not the latter, you might want to put your arrogance aside for a moment and consider that maybe, just maybe, you don't know it all. After all, you've already proved it to the rest of us.
In what way? For actually supporting the requirements of users and not telling them that my website is going to reject them? Is that a sensible way for a commercial website to behave when it does not take much effort (just a peek at a user agent string to present alternate pages) to keep them happy?
How is it idiotic to support thousands of clients?
How is it lying to state that a significant fraction of users still have old buggy browsers, and this is a real problem for high volume websites, especially those that deal with thousands of new vistors each day?
I find the defensiveness on this issue very strange. Perhaps it is an attempt to justify lazy development - not being bothered to do anything but support the very latest browsers.
It seems more arrogant to casually reject thousands of users than to accept that a developer should support them.
In every case I have described there are major products which use Java. For example, in GIS Java is now the main language for application development. Boeing now uses Java for embedded real-time apps. There are major interpreters written in Java: Jython, Groovy etc. Banking hardly uses C++ for new development at all now. Most major stock markets use Java/J2EE for handling stock trading.
I don't tend to do anything in Java if I have a choice in the matter. I've never been in a situation where it was the right choice.
Why do you assume that your approach is the same one every one else uses? You may not think things are the right choice, but millions of others don't.
Also, you might want to look up the word "generally".
I would suggest you do before commenting further, and that you research other things.
Check the TIOBE index of website resources. Check the job market. You will see that as C++ declines, Java is picking up those jobs in all areas (with the exception of system development).
I'm not saying this is good, or that Java is a great language. I'm just saying that this is the actual situation in the real world away from the frequent Slashdot fantasy that 'Java is hardly used'.
How many of you out there who are programmers use Java? Very few.
The number of downloads of Java development kits is in the millions.
Unless you're developing for very, very specific things, you generally don't use Java.
Very specific things like web applications, mobile device applications, high-performance databases (HSQLDB), Office applications, IRC/chat clients, CRM systems, image processing software, GIS (Graphical Information Systems) programs, embedded applications, real time device control, security software, mathematical modelling, banking, stock trading, compiler software, interpreters...
ALL object-oriented languages are built on extending the capabilities of procedural languages, and adding a layer that improves productivity for complex tasks
This isn't true. Languages like Smalltalk and object-oriented LISP certainly aren't.
It used to be you *started* with assembler and worked your way up. This way, you were forced to see the consequences of things like improper looping, improper memory addressing, frivolous use of storage, etc. Learning any high-level language before assembler makes any true understanding of interpreters or compilers *meaningless*.
Having been developing for 30 years, this is not the way I remember things. Assembler was always a specialised and advanced subject. Computing was taught in terms of data structures (starting with simple variable) and how they were processed. Then, as simple language like Basic or Pascal was presented as a way of expressing such processing. No mention of assembler....Java et al will never approach the simplicity for data processing of records.
These days a lot of data processing in Java is not coded as processing records. It is coded as the processing of objects, and mechanisms like ORM (Object Relational Mapping) transparently translate this to record handling. This means that data processing in Java is certainly as simple as in COBOL or other such languages.
The shareholders are the OWNERS of the company. It is McNealy's JOB to increase shareholder value. He has no other function. Therefore, he (management) has failed miserably.
What I was saying was that Wall Street has a limited perspective in terms of time, not in terms of what a company does. Simply keeping a company going through the dot-com crash was a success. Microsoft's stock has been stagnant for years, but few call them a failure.
You were saying that the performance of 8 cores (in-order) with 4 threads per core was going to be a competitive advantage for Sun. I am saying that IBM already has similar technology with CELL which it is already ramping in volume. Again - Sun's processor development is late and redundant.
Yes - a competitive advantage against Intel and AMD.
IE - they have equivalent throughput to current dual core offerings.
I would say it depends what you are using them for. I am not a chip designer (I only have experience in electronics and circuit design), but I do understand the principles and it looks like Niagra is tuned for high volume multi-threaded network use, with features like a crypto processor for each core and very high-bandwith memory interface. I suspect that for this sort of server use you will get huge benefits over designs that require more processors.
No, actually, IE 5 most certainly is an aging browser. It is not being developed any more, and in fact doesn't even come with OS X any more.
Yes, actually. It may not be shipped with OS/X anymore, but it is still present on a large number of OS/X systems out there.
As for the rest of your points, I'm sorry but you really don't know what you're talking about for the most part. I work for a firm that does big sites for thousands of users. We decided not to support version 4 browsers any more and it has only helped us.
Good luck to you. I'm sure you are happily dealing with those customers who give up because your website doesn't support them. Or perhaps you never hear about them because they can't be bothered with you. Perhaps because I deal with hundreds of thousands of users, I have a bigger customer base, and a larger number of users. You may have the luxury of rejecting those users. I don't.
Also, I don't think you know much at all about the psychology of web users.
Well, as I deal with them and their problems a daily basis, and I have produced award-winning high-volume websites... perhaps you might be wrong?
Maybe a few years ago, but what I'm seeing is that 99% of the users are "Version 6 or greater", and there's significantly more customer pressure for sites to display on smartphones, etc than on old v4 browsers.
I wish this were so. I recognise the increasing need for smartphones etc., but I'm still seeing enough older browsers to cause real problems.
I am not claiming that there aren't quirks in some aging browsers,
IE 5 is not an ageing browser - it is widely used even on modern MacOS/X systems.
I just mean that it should be possible to make the site modern and make it quite usable in old browsers at the same time. If a certain bit of code makes one browser or another crash, don't use it.
This was just an example, but the principle is sound - what do you test on? IE 4, IE5, IE5, Netscape 4, Netscape 6, FireFox, Safari, Opera, Lynx?
I guess it depends on what you mean by barely readable.
So embarassing in terms of presentation that a customer would give up.
When designing a site I first write up the basic HTML as if I were targeting text-only browsers like lynx. Then I add the CSS.
Modern websites are rich and complex. This is not a practical approach.
Maybe that's not good enough for business sites
It certainly isn't.
but then most business sites aren't worth visiting anyway IMHO.;
Have you ever booked a holiday? Looked for a train or plane timetable? These are the sort of sites I am talking about - corporate sites that have to look sleek and professional.
I'm not saying that such sites should not work on Lynx, or older browsers. What I am saying is that using a single set of HTML pages and CSS to do this is simply not realistic, hence the need to check user agent strings.
RedHat has probably been spending a bundle on Open Source Java for over a year now. The first results can be seen in Fedora Core 4.
And this is nowhere near ready for serious commercial development use. This requires full certified compatibility with Java 1.3 or Java 1.4. There is a project to do this, called Harmony, but it is unlikely to deliver a compatible implementation for years.
Even when integrating the most modern CSS/JavaScript/etc., a site should work in any HTML viewer ever made. If all visitors can't still click the links on your site and view its content, submit any forms on it, etc., you're doing something wrong.
This is simply false. For example, there are bugs in IE 5 on the Mac that mean it can actually crash when viewing pages that are perfectly valid and work fine on other browsers. I'm not doing things wrong - it is well-established browser bugs.
But that's the beauty of working with CSS and server-side scripting. You don't have to leave anyone behind, you just have to accept that it will not look and feel exactly the same for users of older browsers.
I'm sorry, but this is just wishful thinking. It might be so if you are designing simple pages, but companies now require that their websites are their shop windows. Websites can't look good on modern browsers and be just barely readable on older ones (which is what happens if you use modern CSS techniques).
If you do that, you have most of the web. The rest are then people using outdated tech (like Netscape 4.x, IE 4/5 etc)
Most is often not enough. If you are developing and supporting a website that has tens or hundreds of thousands of users, and even a few percent are still using old browsers, your complaints department will be swamped by annoyed users. Simply telling them that they are out of date is not good enough. I speak from harsh experience.
Checking the user agent string is often an unfortunate necessity.
Slashdot Mirror
Any sysadmin that has ever had to juggle multiple JVMs can tell you that Sun's Write Once Run Anywhere motto can quickly become Write Once Debug Everywhere.
Do you have an example? I have never found this; even substantial applications like NetBeans run on different VMs, and even different vendors VMs.
Don't forget that IBM is still pushing their non-Java SWT instead of Swing.
Apart from the fact that few people are using SWT, it is not an instead-of situation; any distribution of Java called Java has to include Swing.
it's harder to write a description for them so that you can parse them using a general purpose XML library than it is to parse them using the traditional UNIX tools...
No it isn't. Just stick to the simple XML guidelines and any XML parser can parse them.
If you want people to treat XML seriously
Almost everyone already is treating XML seriously.
, give them the tools to do something useful with them. Before you produce another "ant", give us xmlgrep, xmlsort, xmlawk, xmlsql.
All this is already there. There is a standard XML dialect called XSL that includes searching, sorting, and extracting, and there are other XML dialects for interfacting with SQL. These features have been around for years!
besides, what's stopping you to use make should you create your own java sysadmin tools?
Nothing, except that Ant has a huge amount of support for Java and associated tools. Almost every tool and product developed to assist Java developers provides an Ant library to add functionality. To work with 'make' would be a huge step backwards.
XML syntax is mostly noise with a bit of data thrown in and delivers on none of it's promises.
What utter nonsense! Of course XML has delivered. An example is the Open Office document format, that is XML-based, easy to transform to other formats (such as PDF), and because it is XML (open and documented) is also now accepted by KDE office applications.
I have to sort through a bunch of noise - the tags
As against what? Some arbitrary and undocumented text format?
Think of the irony that the resources we spend on trying to find new places to explore or colonize hundreds or thousands of years down the road would greatly increase the standard of living for the world's poor today?
If you want to increase the standard of living for the world's poor, why are you interested in the comparatively minor spending on exploration? The amount spend on space exploration and research is, and has always been, insignificant compared to the spending on defence, for example. Why not cut back on weapons spending and research? To suggest cutting back on space research is a silly as to suggest cutting back on education, when you consider how much money is spend elsewhere.
You can. But you should not. You're falling into the Turing Tar Pit. The C and C++ building facilities are too immature for now. And the Ant developers certainly are not putting priority in making it work well with C and C++ building anyhow.
This is a reasonable point. However, the original post mentioned C or C++ as part of a general Java project, so any support should be adequate. For better or worse, ant is Java-focused, so C and C++ building is not going to be a priority.
Oh... And I can use make and a Makefile to compile C code and the Java code of the same project.
If you understood Ant, you would know that it can do this as well.
I know the moderators will hit me for this, but from the sys admins point of view - ant is evil!
/etc !!!
/etc is a very good example of what is wrong with plain text files - no single program or API could ever handle the range of formats of files there! Incidentally - XML IS plain text.
Ant isn't for sys admins.
It is simply another build program to learn. The C and C++ stuff for the kernel is "make" - now I have to learn "ant" for Java programs.
As Java isn't used (yet!) for kernel stuff, what is the problem?
I am not against learning new things, but where some people see XML as a good thing - I think it sucks! I despise any time I see a config file that is XML. XML is for the "parsing impaired" - use a plain text file like everything in
Sorry, wrong way around. XML was designed specifically from the start to be parser-friendly. There are very simple APIs which handle any XML file such as SAX.
Buffer overflow exploits dropped of the face of the map after the morris worm. They fixed the flaws and everyone promptly forgot about it.
I think your emphasis on exploits is detracting from the main issue. It is the buffer overflows themselves that are the problem, and have been a general software issue for decades. Even if not used for deliberate exploits, they certainly gave rise to an endless series of bugs in C-based applications. This is why Gate's comment is so unhelpful - the 'allocate and hope' attitude to memory management is not just poor in terms of exploits; it is poor in terms of general software development quality, and the implication - that Microsoft's Windows developers were writing code so thoughlessly - is troubling. Some of us software engineers have higher standards!
What it wasn't easy to do was exploit buffer overflows. Buffer overflow exploit knowledge has only really happened in the last 10 years or so
I would certainly argue with this.
One of the first widely publicized buffer overrun attacks occurred in 1988 as part of the infamous Internet worm incident. Just because kits to make exploiting buffer overruns easy weren't available does not mean that the problem was not widely known.
Gates says:
"When you look at the issue of buffer overruns, eight to 10 years ago in software development, you did not know how much space you might need for something so you just create a big buffer zone to allow things to happen. Who knew that people could go exploit that and use that buffer space to do malicious things?"
Well, anyone who was a half-competent developer knew this was a possibility, as there had been widely known exploits at least 17 years ago!
The same is true with this point. 10 years ago, while Buffer overflows were known, they weren't common knowledge, and the average developer certainly didn't have the knowledge or tools to combat them.
Of course they were common knowledge! They were common knowledge for C programmers even 30 years ago. Just check the man page for C functions like 'gets', and read the warnings.
No, he's right and you're either an idiot or a liar. If not the latter, you might want to put your arrogance aside for a moment and consider that maybe, just maybe, you don't know it all. After all, you've already proved it to the rest of us.
Just to clarify things - the point I am trying to make should surely be uncontroversial. If you are dealing with a very high volume website and you are trying to attract customers, it makes sense to make those people visiting your website feel welcome! Any sort of barrier to the use is not just bad manners, it is bad business. This sort of website is not like a bank or other company where you already have clients and the website is simply yet another service, so if it doesn't work this is not a problem.
If you really think someone is a 'liar or idiot' or 'arrogant' for doing this approach, I would suggest that you are getting far too worked up about it. Is it really worth getting so offensive about what is, after all, a relatively minor matter - conditionally including some HTML and CSS?
No, he's right and you're either an idiot or a liar. If not the latter, you might want to put your arrogance aside for a moment and consider that maybe, just maybe, you don't know it all. After all, you've already proved it to the rest of us.
In what way? For actually supporting the requirements of users and not telling them that my website is going to reject them? Is that a sensible way for a commercial website to behave when it does not take much effort (just a peek at a user agent string to present alternate pages) to keep them happy?
How is it idiotic to support thousands of clients?
How is it lying to state that a significant fraction of users still have old buggy browsers, and this is a real problem for high volume websites, especially those that deal with thousands of new vistors each day?
I find the defensiveness on this issue very strange. Perhaps it is an attempt to justify lazy development - not being bothered to do anything but support the very latest browsers.
It seems more arrogant to casually reject thousands of users than to accept that a developer should support them.
Java is only actually used for the first two
I'm sorry but this is total nonsense!
A few minutes with google will prove otherwise.
In every case I have described there are major products which use Java. For example, in GIS Java is now the main language for application development. Boeing now uses Java for embedded real-time apps. There are major interpreters written in Java: Jython, Groovy etc. Banking hardly uses C++ for new development at all now. Most major stock markets use Java/J2EE for handling stock trading.
I don't tend to do anything in Java if I have a choice in the matter. I've never been in a situation where it was the right choice.
Why do you assume that your approach is the same one every one else uses? You may not think things are the right choice, but millions of others don't.
Also, you might want to look up the word "generally".
I would suggest you do before commenting further, and that you research other things.
Check the TIOBE index of website resources. Check the job market. You will see that as C++ declines, Java is picking up those jobs in all areas (with the exception of system development).
I'm not saying this is good, or that Java is a great language. I'm just saying that this is the actual situation in the real world away from the frequent Slashdot fantasy that 'Java is hardly used'.
How many of you out there who are programmers use Java? Very few.
The number of downloads of Java development kits is in the millions.
Unless you're developing for very, very specific things, you generally don't use Java.
Very specific things like web applications, mobile device applications, high-performance databases (HSQLDB), Office applications, IRC/chat clients, CRM systems, image processing software, GIS (Graphical Information Systems) programs, embedded applications, real time device control, security software, mathematical modelling, banking, stock trading, compiler software, interpreters...
ALL object-oriented languages are built on extending the capabilities of procedural languages, and adding a layer that improves productivity for complex tasks
...Java et al will never approach the simplicity for data processing of records.
This isn't true. Languages like Smalltalk and object-oriented LISP certainly aren't.
It used to be you *started* with assembler and worked your way up. This way, you were forced to see the consequences of things like improper looping, improper memory addressing, frivolous use of storage, etc. Learning any high-level language before assembler makes any true understanding of interpreters or compilers *meaningless*.
Having been developing for 30 years, this is not the way I remember things. Assembler was always a specialised and advanced subject. Computing was taught in terms of data structures (starting with simple variable) and how they were processed. Then, as simple language like Basic or Pascal was presented as a way of expressing such processing. No mention of assembler.
These days a lot of data processing in Java is not coded as processing records. It is coded as the processing of objects, and mechanisms like ORM (Object Relational Mapping) transparently translate this to record handling. This means that data processing in Java is certainly as simple as in COBOL or other such languages.
Not if you're contact page isn't accessible either.
Customers often see the website via marketing literature they have requested. Then they turn on their Windows 95 machine and try and have a look...
The shareholders are the OWNERS of the company. It is McNealy's JOB to increase shareholder value. He has no other function. Therefore, he (management) has failed miserably.
What I was saying was that Wall Street has a limited perspective in terms of time, not in terms of what a company does. Simply keeping a company going through the dot-com crash was a success. Microsoft's stock has been stagnant for years, but few call them a failure.
You were saying that the performance of 8 cores (in-order) with 4 threads per core was going to be a competitive advantage for Sun. I am saying that IBM already has similar technology with CELL which it is already ramping in volume. Again - Sun's processor development is late and redundant.
Yes - a competitive advantage against Intel and AMD.
IE - they have equivalent throughput to current dual core offerings.
I would say it depends what you are using them for. I am not a chip designer (I only have experience in electronics and circuit design), but I do understand the principles and it looks like Niagra is tuned for high volume multi-threaded network use, with features like a crypto processor for each core and very high-bandwith memory interface. I suspect that for this sort of server use you will get huge benefits over designs that require more processors.
No, actually, IE 5 most certainly is an aging browser. It is not being developed any more, and in fact doesn't even come with OS X any more.
Yes, actually. It may not be shipped with OS/X anymore, but it is still present on a large number of OS/X systems out there.
As for the rest of your points, I'm sorry but you really don't know what you're talking about for the most part. I work for a firm that does big sites for thousands of users. We decided not to support version 4 browsers any more and it has only helped us.
Good luck to you. I'm sure you are happily dealing with those customers who give up because your website doesn't support them. Or perhaps you never hear about them because they can't be bothered with you. Perhaps because I deal with hundreds of thousands of users, I have a bigger customer base, and a larger number of users. You may have the luxury of rejecting those users. I don't.
Also, I don't think you know much at all about the psychology of web users.
Well, as I deal with them and their problems a daily basis, and I have produced award-winning high-volume websites... perhaps you might be wrong?
Maybe a few years ago, but what I'm seeing is that 99% of the users are "Version 6 or greater", and there's significantly more customer pressure for sites to display on smartphones, etc than on old v4 browsers.
I wish this were so. I recognise the increasing need for smartphones etc., but I'm still seeing enough older browsers to cause real problems.
I am not claiming that there aren't quirks in some aging browsers,
;
IE 5 is not an ageing browser - it is widely used even on modern MacOS/X systems.
I just mean that it should be possible to make the site modern and make it quite usable in old browsers at the same time. If a certain bit of code makes one browser or another crash, don't use it.
This was just an example, but the principle is sound - what do you test on? IE 4, IE5, IE5, Netscape 4, Netscape 6, FireFox, Safari, Opera, Lynx?
I guess it depends on what you mean by barely readable.
So embarassing in terms of presentation that a customer would give up.
When designing a site I first write up the basic HTML as if I were targeting text-only browsers like lynx. Then I add the CSS.
Modern websites are rich and complex. This is not a practical approach.
Maybe that's not good enough for business sites
It certainly isn't.
but then most business sites aren't worth visiting anyway IMHO.
Have you ever booked a holiday? Looked for a train or plane timetable? These are the sort of sites I am talking about - corporate sites that have to look sleek and professional.
I'm not saying that such sites should not work on Lynx, or older browsers. What I am saying is that using a single set of HTML pages and CSS to do this is simply not realistic, hence the need to check user agent strings.
RedHat has probably been spending a bundle on Open Source Java for over a year now. The first results can be seen in Fedora Core 4.
And this is nowhere near ready for serious commercial development use. This requires full certified compatibility with Java 1.3 or Java 1.4. There is a project to do this, called Harmony, but it is unlikely to deliver a compatible implementation for years.
Even when integrating the most modern CSS/JavaScript/etc., a site should work in any HTML viewer ever made. If all visitors can't still click the links on your site and view its content, submit any forms on it, etc., you're doing something wrong.
This is simply false. For example, there are bugs in IE 5 on the Mac that mean it can actually crash when viewing pages that are perfectly valid and work fine on other browsers. I'm not doing things wrong - it is well-established browser bugs.
But that's the beauty of working with CSS and server-side scripting. You don't have to leave anyone behind, you just have to accept that it will not look and feel exactly the same for users of older browsers.
I'm sorry, but this is just wishful thinking. It might be so if you are designing simple pages, but companies now require that their websites are their shop windows. Websites can't look good on modern browsers and be just barely readable on older ones (which is what happens if you use modern CSS techniques).
If you do that, you have most of the web.
The rest are then people using outdated tech
(like Netscape 4.x, IE 4/5 etc)
Most is often not enough. If you are developing and supporting a website that has tens or hundreds of thousands of users, and even a few percent are still using old browsers, your complaints department will be swamped by annoyed users. Simply telling them that they are out of date is not good enough. I speak from harsh experience.
Checking the user agent string is often an unfortunate necessity.