And, I'm willing to bet that the sun would still rise if you were to lose your PDA.
The same can be said of any human invention. Your statement is antagonistic and entirely irrelevant.
As for your main point: That you do not find any relevance in the information that is available online does not invalidate my point.
XML isn't merely useful as a means of interchanging *pure data*. Consider SOAP. SOAP allows things like interoperability between disparate systems. I.E. improved functionality using open standards.
For the transmission/storage of data XML is equally useful to a great many companies and individuals. If properly applied, the technology can save some companies a great deal of money and provide a better, more useful experience for end users.
If UPS could "push" a message out to me when my package is delivered, it'd be sweet. (a la instant messaging, rather than email).
Apparently Microsoft is doing just that with.Net and MSN Messenger... The demo they gave showed things like an alert from eBay popping up to notify you about auction outcomes and such...
If your definition of innovation is a radical change that is immediately and obviously apparent to every individual affected by it, then yeah it's all incremental.
Some things that are pretty radical but aren't end-user-visible are:
-XML: Changing how software communicates. Everything from simple publishing of headlines from one site to another -- RSS to distributed computing -- SOAP. Even HTML is being updated to fall in line with XML -- XHTML. As the percentage of data in XML increases, this will revolutionize how information is processed.)
-PDAs: Ok, this is more user-visible. I can't live without my Palm V. It's just that useful. The same sentiment is held by a great many users of such devices. Add wireless Internet to the mix and you'll change how people communicate.
-ASPs: The idea of outsourcing lesser components of your business isn't new. But when your business is a web site, being able to plug in components from other systems is pretty handy. My bank integrates with Quicken to download transaction data. Some web sites (Aint-it-cool-news.com for example) outsource things like their message boards or their web based e-mail to other companies who co-brand their own products and integrate them with the web site. AICN (for example) doesn't have to install updates, maintain server(s) for the message boards, or take care of any of those hassles. This lets them make a more useful, rich experience for their users while keeping costs low.
I'm sure there are others. The biggest changes are the ones you don't notice until long after the fact. Changes that are immediately apparent as "radical" rarely take hold, and are seldom worth the effort. (Push technology anyone?)
Geoworks' patent that affects WAP is for flexible UIs -- essentially themeing on crack. They've had the patent for a very long time. Since the mid-80's I think...
I wonder if Geoworks will try and bitch-slap apple over this?
1) OLE predates OpenDoc. OLE existed way back on Windows 3.1. The earliest reference I can find right now is a DDJ article on OLE *2.0* written in 1994. The earliest reference to OpenDoc I can find is a press release in late '95 for the OpenDoc for MacOS SDK.
2) OLE is *extremely* widely used. Anyone using Internet Explorer on Windows, or Office on Mac or Windows is using OLE. Anyone using Windows Scripting Host is using OLE. ActiveX? That's OLE too.
3) OLE Automation is *very very handy*. I've had a number of occasions where I've had conceptually simple tasks that were annoying to do in Perl or other Unix-ish methods, but a little OLE-automation of Office and the task is done. Need to parse a bunch of e-mails from my normal POP3 account (no mbox/maildir access), and update an Excel spreadsheet with the new data plus update the charts to include the new data? Need to publish that Excel spreadsheet and charts as a web page on the Extranet for the investors to use, and make the.xls file available internally for the execs? Trivial with Windows Scripting Host and OLE Automation.
Why? It's fairly simple, but it does what it is meant to do, and it does it well. And for the record, I'm referring to the one in Win2K which bears no resemblance to the one in prior versions of Windows.
<<All you really need is a custom renderer for a JList object to do this in java, no html required.>>
You miss my point. I'm not saying that you can't do sophisticated UIs in Java. I'm saying you can't do DOM-based UIs well in Java. Using the DOM-model for developing applications presents a number of distinct advantages:
1) Applications are very lightweight.
2) Applications immediately inherit a lot of UI functionality (such as mousewheel support, automatic rescaling when the container is resized, etc...) with absolutely no effort on the programmer's part.
3) Applications and components can more easily be integrated into other applications or components where such functionality is useful.
4) Making applications that run partially on a server and partially on a client (essentially distributed computing) is MUCH easier.
<<I still maintain html stuff like what they do in MSMoney could be done in any language.>>
Show me. Show me a DOM-based *calculator* written in Java that can be embedded in another application written in C without having to modify the C program.
<<In java for instance their are HTML components that work quite nicely, the Ice browser for one, and one of lesser quality the JEditorPane even comes included with the JDK.>>
Displaying HTML is not what I'm talking about! That has NOTHING TO DO with what I am talking about!
<<All you really need a is good framework behind your application to do this. Maybe JScript, etc. are a good start but that's not to say there aren't other choices. >>
Under IE there's JScript, C#, VBScript, and if you really want to, PerlScript (but your users have to download and install ActiveState Perl). When the.net CLR (the equivalent of the JVM) is widely introduced then it wont matter what language is used. C/C++, VB, COBOL, Perl, Python, C#, and even some obscure functional languages are all being ported to the CLR. Seamless ABI. A.net component can be embedded in a DOM-based application regardless of what language either was made in. Java of course is the exception since Sun isn't going to make javac produce CLR bytecode, and neither is MS.
<<Java isn't as limiting as you make it out to be. I will admit there aren't very many java apps out there right now that do this, publicly available anyway. >>
Show me even *one* DOM-based application in Java. Show me a DOM-based Java application that is embedded in a DOM-based application written in another language and interacts with DOM-based components written in JavaScript.
<<Java is slowly getting better performance on the client too, 1.3 is a vast improvement over 1.2, I just wish it didn't take so long between releases. 1.4 is supposed to have substantial performance and memory requiremnt impovements.>>
And no matter how good it gets, it will still have the following disadvantages:
1) No interoperability with the native platform. (Mousewheel support anyone?)
2) No component-model interoperability on the client-side.
3) It will still be slower and bigger than an equivalent JScript/.net application for most applications -- especially smaller ones.
The very idea of platform independance while quite noble, is the very antithesis of CPU/memory efficiency and interoperability. Merely making your widgets look like the native platform is not enough. They have to *behave* like them too, and your code has to be able to interact in a meaningful fashion with other code on the client.
<<I'm tempted to mock something up in Java to show you how easily an add/remove "like" dialog could be done but I'm sure it would be a complete waste of my time.>>
You need to reread my original messages. I'm not talking about Swing or AWT. I *know* you can make a nice, heavy, client-side GUI with all the trimmings. Making it interact in a sane-manner with the native OS is incredibly complex (JNI anyone?), and making it be lightweight is impossible.
Yes, you could write an add/remove program dialog in Java. Making it behave like the one in Win2K would be very complex and involve a number of custom widgets. Making it be embeddable and controllable by other applications on the system would be nearly impossible.
Yes, a good foundation is the critical component for everything I'm talking about. IE provides a good start,.net makes it a real *platform*. Java does not.
Frankly, Linus is wrong on this one. Full-on context switching associated with process-based threads murders performance.
Solaris for example, offers N:M threading, which is one of the reasons it is considered to be better suited to large-scale back-end systems like database servers. My daytime employer uses MySQL on an 8-way Solaris box with as many as 8,000 simultaneous connections! (Yes, we've spent a great deal of time minimizing the # of connections but we just get *that much* usage of our system...) Linux would come pretty close to choking on such a setup.
As promising as Mason is, the maintainers have a very poor design philosophy. They consider it acceptable for the line numbers produced in error messages to *always* be incorrect! They consider it acceptable for the external and internal names of parameters to a component to use a common naming convention thus ensuring that you cannot use the %ARGS section if you want to use valid HTML parameter names that are NOT valid Perl names. The classic example: If you have an image input called foo, the browser will send parameters called foo.x and foo.y (you can't change this) containing the coordinates of where the user clicked.
Oddly enough the idea of having a generalized mapping was rejected in part because they didn't want to make Mason "HTML specific"! Instead, apparently, they want to force everyone into a lowest-common-denominator between Perl and whatever they are using Mason to interact with.
I used to think Mason was great, but this poor design philosophy forced me to abandon it in favor of tools that are designed with quality in mind.
On the server side you can use many languages, but on the *client side* there are few alternatives -- and Java aint one of them. Bolting an applet into a web page is not the same thing as an HTML-based application.
JavaScript/DOM are a good start but lack a great deal of flexibility. XML-RPC/SOAP are *very* useful! Mozilla provides this, as does.Net but ECMA standard JavaScript effectively prohibits such possibilities. (with the possible exception of a very ugly hack using a hidden IFRAME)
Look at the add/remove programs dialog in Windows 2000. This is an HTML-based application written using JavaScript (or rather, JScript). Microsoft Money is in large part an HTML-based application. *This* is what I mean by "HTML-based application".
The server end of things is irrelevant to my point. Java does very well on the server. I'm referring only to the client.
By "fluid" I mean stuff that loads quickly with no install process and interacts "correctly" with the environment around it. Java does not do this even with standalone Java applications. Indeed, one of the fundamental design goals of Java -- total platform neutrality -- makes this impossible. One cannot, for example, use the mouse wheel in Java without using JNI and coding support yourself.
The event horizon is not the maximum extent of the black hole's gravitational field -- it's the point at which nothing can *escape* regardless of the amount of energy applied.
The distinction is that most matter isn't going to apply a lot of energy in an effort to escape -- it'll just fall in. A spaceship for example, would be pulled towards the black hole well beyond the event horizon, but before it reaches that point it could (theoretically) escape given sufficient energy. (although as you get close to the event horizon the energy required would quickly become phenominal...)
Oh yeah... Forgot to mention that the idea of HTML-based applications has a lot of potential and usefulness in providing a flexible, powerful UI... Windows 2000's add/remove programs dialog is HTML/JavaScript based and so is Microsoft Money 2001...
.net is sort of Java, EJB, JavaBeans and more... C# is the part that is analogous to Java.
The idea of hosted, load-on-demand applications isn't exactly a new idea -- even for Java.
Microsoft's approach is to make things XML/HTML based. JScript, DOM, C#, and SOAP... Much more "fluid" than having this VM bolted onto your browser... Simple apps are simple, small, and quick-loading, complex apps scale accordingly...
It's a very interesting approach actually... Very promising, and in some ways similar to Mozilla -- although somewhat more extensive in its goals...
PS: As for the idea that companies need detailed data about you to function efficiently, that's just plain bullsh*t. What they need is an efficient infrastructure, good lines of internal communication, good management, all the traditional stuff. Only marketers think they "need" detailed data about all of their hypothetical future customers. (Note nobody complains about data companies need to function... surely Amazon needs to know where to ship that book to... while this could be worked around it's not really worth the effort at this time.)
And how do you get an efficient infrastructure? By tailoring it to meet demand. I think it is safe to say that there's nothing wrong with *agregate* statistical data, right? (I.E. "43% of the people going to Amazon.com look at books, 12% of those, actually buy books.")
Consider Amazon.com. The efficiency of their infrastructure is not merely about how many books they can ship in a period of time, or how many hits their web site can handle, but how many *orders* they get per dollar spent on business development (including marketing).
What is more efficient for Amazon.com? 100 customers who each come and buy 1 book, or 10 customers who each come and buy 10 books. The latter. Why? Because there is overhead to processing an order. So clearly, multi-item, and repeat purchases are important to the efficiency of their operation. How do you achieve that? Traditionally it's done via the 80/20 rule. You can get 80% of your customers to behave in the manner you desire with 80% of the effort, and you ignore the other 20% since that would consume the "other" 80% of the effort.
Personal targeting allows businesses to operate *much* more efficiently. Amazon.com can suggest items to me that I am likely to want, and can hide stuff I'm unlikely to want which makes me more likely to buy multiple items or order again. I do, in fact, like this feature.
I do not like the idea that Amazon.com would sell this information, or that it could be used against me by 3rd parties -- that is where the biggest privacy-related problems lay.
Unless you are using MySQL, your DB vendor probably has some handy tips on how to handle disks -- how many to have, how to configure them, what to allocate each one or group to...
I don't see a question in this unless you're using MySQL or some other relatively "low-end" DB in which case, you probably have larger concerns to deal with.
The problem with this is that you have no way of knowing how significant a change was. Many places don't upgrade just because a new version is out. It is helpful to such shops to have version numbers that are meaningul about the depth of changes.
MySQL and Linux both have good version numbering methods. Perl's method, while a little absurd at times (extraneous 0's), also works well.
I wholeheatedly favor the approach of... Possibly with alternating marjor or minor versions for development/stable releases.
Actually, even merely lying down and dying would be in violation of that standard: Doing so would cause your body to decompose and release potential harmful greenhouse gasses into the atmosphere along with who knows what other consequences. Even merely ceasing to exist could potentially be harmful: How would the Earth's orbit be affected if 6 billion people simply ceased to exist. (I.E. their mass/energy was no longer a part of the universe)
The question is not whether the output is radioactive -- if so, this could be used once the craft left the Earth's atmosphere and reached some reasonably safe distance.
The question is really "if the output is radioactive, does our atmosphere protect us from it." There are many many many forms of radiation in space. Our atmosphere protects us from many of them.
I agree. But our web browser would have nothing at all to do with my comment about software distribution in the Windows world. The software installation application that enables more modular software distribution need not even be written by Micro(Richman)soft; none of the major installers used today are.
Actually, With Win2K/WinME Microsoft has introduced a centralized "installer" service, using a special package format (MSI) which does library and version tracking, etc etc. You can download the service for Win98 as well..
You'll note that ActiveState uses MSI exclusively for distributing Windows stuff.
It actually makes a lot of sense... Rather than have InstallShield, Wise, and half a dozen other installer services tracking which DLLs are/aren't being used, and clobbering each other (say, InstallShield deleting foo.dll because IS thought it wasn't being used, but a Wise-installed app was using it...) a central manager for this stuff makes sense.
And actually, this doesn't have to put Wise/InstallShield/etc out of business -- it just means they have to make MSI-compatible installer-generators...
Now, the decision to include.ZIP file support in Windows ME seems a little odd to me... Unlike the installer situation, this pretty much puts WinZip out of business. But at least Windows is catching up to Linux feature-wise... *grin*
1) Pretty much all recent 3D chips have hardware anti-aliasing, and lighting. PS2 included. The problem with anti-aliasing and the PS2 is that it's VERY slow. The performance hit is unacceptable, so programmers turn it off.
2) PS2 isn't confusing to developers because it was "rushed to market" -- developer confusion always stems from fundamental design choices. In this case, the multi-chip architecture where each chip serves a different, or somewhat overlapping purpose results in a very different and complex programming model.
3) While old-school gamers will remember fondly more Nintendo franchises, the younger crowd tends to know non-Nintendo franchises more. FF is just one such franchise and I wouldn't count on a GC version.
The interesting thing to note is that while the PlayStation 2, like the Sega Saturn is suffering from developer confusion (I.E. developers have a whole lot to learn before they can take advantage of its capabilities) the GameCube is designed from the ground up to be a developer-friendly platform.
I read an interview with someone -- maybe Shigeru Miyamoto? -- about how when the N64 launched with Mario 64 showing off what it could do, developers were blindsided by the difficulty of programming for the system. They assumed a Mario-like game would be easy when in fact the platform had a number of bottlenecks and quirks that made development difficult. GameCube is apparently meant to address such difficulties.
The managed version, and multi-port version work well for us. I should point out that we only use the 100+ series and the company is not old enough to predate that...:)
Getting "the best bang for the buck" means a LOT more than just how much you pay for the box. If you go with a brand that is prone to failure you will spend more time (and time is money) fixing problems. Your time is consumed. The time of the employee/student is consumed. Money is consumed in the replacement parts. Opportunities are lost. (you *could* have been applying security patches to the servers, or setting up that new computer lab, or...)
TCO is a VERY big issue when you have hundreds of machines. Now, I agree that "mission critical" is a term usually reserved for much more failure-sensitive environments than a university but that doesn't mean that the cheapest box is automatically the best.
However, it may very well be that AMD boxes are as reliable, or more reliable than Intel -- if so you're lucky.
My daytime employer uses pure Intel for our x86 based servers -- Intel motherboard (with rare exceptions (820 chipset) they tend to be VERY reliable), Intel chip (with rare exceptions (original Pentium), very solid), Intel network cards (always great). However, for our server environment we are more memory bound than CPU bound -- we can afford to go with a slower (but more proven) processor and spend less money that way.
GEOS, the OS at the heart of NewDeal originated as PC/GEOS, around the same time Windows 3.0 came about.
Like Windows 3.x, it is an environment on top of DOS that provides its own ABI and API. Its filesystem module gives you things like longish (32 chars) filenames on top of FAT16, and it provides a great many useful libraries and modules for programmers. (including something roughly analogous to MFC)
It's VERY small, and VERY fast but rather feature-poor and coded in a low-level object-oriented macro assembler so making it work on a 32/64-bit system in such a way as to take advantage of even just the available memory would be nearly impossible.
Slashdot Mirror
And, I'm willing to bet that the sun would still rise if you were to lose your PDA.
The same can be said of any human invention. Your statement is antagonistic and entirely irrelevant.
As for your main point: That you do not find any relevance in the information that is available online does not invalidate my point.
XML isn't merely useful as a means of interchanging *pure data*. Consider SOAP. SOAP allows things like interoperability between disparate systems. I.E. improved functionality using open standards.
For the transmission/storage of data XML is equally useful to a great many companies and individuals. If properly applied, the technology can save some companies a great deal of money and provide a better, more useful experience for end users.
-JF
If UPS could "push" a message out to me when my package is delivered, it'd be sweet. (a la instant messaging, rather than email).
.Net and MSN Messenger... The demo they gave showed things like an alert from eBay popping up to notify you about auction outcomes and such...
Apparently Microsoft is doing just that with
-JF
If your definition of innovation is a radical change that is immediately and obviously apparent to every individual affected by it, then yeah it's all incremental.
Some things that are pretty radical but aren't end-user-visible are:
-XML: Changing how software communicates. Everything from simple publishing of headlines from one site to another -- RSS to distributed computing -- SOAP. Even HTML is being updated to fall in line with XML -- XHTML. As the percentage of data in XML increases, this will revolutionize how information is processed.)
-PDAs: Ok, this is more user-visible. I can't live without my Palm V. It's just that useful. The same sentiment is held by a great many users of such devices. Add wireless Internet to the mix and you'll change how people communicate.
-ASPs: The idea of outsourcing lesser components of your business isn't new. But when your business is a web site, being able to plug in components from other systems is pretty handy. My bank integrates with Quicken to download transaction data. Some web sites (Aint-it-cool-news.com for example) outsource things like their message boards or their web based e-mail to other companies who co-brand their own products and integrate them with the web site. AICN (for example) doesn't have to install updates, maintain server(s) for the message boards, or take care of any of those hassles. This lets them make a more useful, rich experience for their users while keeping costs low.
I'm sure there are others. The biggest changes are the ones you don't notice until long after the fact. Changes that are immediately apparent as "radical" rarely take hold, and are seldom worth the effort. (Push technology anyone?)
-JF
Geoworks' patent that affects WAP is for flexible UIs -- essentially themeing on crack. They've had the patent for a very long time. Since the mid-80's I think...
I wonder if Geoworks will try and bitch-slap apple over this?
-JF
You're joking right?
.xls file available internally for the execs? Trivial with Windows Scripting Host and OLE Automation.
1) OLE predates OpenDoc. OLE existed way back on Windows 3.1. The earliest reference I can find right now is a DDJ article on OLE *2.0* written in 1994. The earliest reference to OpenDoc I can find is a press release in late '95 for the OpenDoc for MacOS SDK.
2) OLE is *extremely* widely used. Anyone using Internet Explorer on Windows, or Office on Mac or Windows is using OLE. Anyone using Windows Scripting Host is using OLE. ActiveX? That's OLE too.
3) OLE Automation is *very very handy*. I've had a number of occasions where I've had conceptually simple tasks that were annoying to do in Perl or other Unix-ish methods, but a little OLE-automation of Office and the task is done. Need to parse a bunch of e-mails from my normal POP3 account (no mbox/maildir access), and update an Excel spreadsheet with the new data plus update the charts to include the new data? Need to publish that Excel spreadsheet and charts as a web page on the Extranet for the investors to use, and make the
-JF
<>
.net CLR (the equivalent of the JVM) is widely introduced then it wont matter what language is used. C/C++, VB, COBOL, Perl, Python, C#, and even some obscure functional languages are all being ported to the CLR. Seamless ABI. A .net component can be embedded in a DOM-based application regardless of what language either was made in. Java of course is the exception since Sun isn't going to make javac produce CLR bytecode, and neither is MS.
.net makes it a real *platform*. Java does not.
Why? It's fairly simple, but it does what it is meant to do, and it does it well. And for the record, I'm referring to the one in Win2K which bears no resemblance to the one in prior versions of Windows.
<<All you really need is a custom renderer for a JList object to do this in java, no html required.>>
You miss my point. I'm not saying that you can't do sophisticated UIs in Java. I'm saying you can't do DOM-based UIs well in Java. Using the DOM-model for developing applications presents a number of distinct advantages:
1) Applications are very lightweight.
2) Applications immediately inherit a lot of UI functionality (such as mousewheel support, automatic rescaling when the container is resized, etc...) with absolutely no effort on the programmer's part.
3) Applications and components can more easily be integrated into other applications or components where such functionality is useful.
4) Making applications that run partially on a server and partially on a client (essentially distributed computing) is MUCH easier.
<<I still maintain html stuff like what they do in MSMoney could be done in any language.>>
Show me. Show me a DOM-based *calculator* written in Java that can be embedded in another application written in C without having to modify the C program.
<<In java for instance their are HTML components that work quite nicely, the Ice browser for one, and one of lesser quality the JEditorPane even comes included with the JDK.>>
Displaying HTML is not what I'm talking about! That has NOTHING TO DO with what I am talking about!
<<All you really need a is good framework behind your application to do this. Maybe JScript, etc. are a good start but that's not to say there aren't other choices. >>
Under IE there's JScript, C#, VBScript, and if you really want to, PerlScript (but your users have to download and install ActiveState Perl). When the
<<Java isn't as limiting as you make it out to be. I will admit there aren't very many java apps out there right now that do this, publicly available anyway. >>
Show me even *one* DOM-based application in Java. Show me a DOM-based Java application that is embedded in a DOM-based application written in another language and interacts with DOM-based components written in JavaScript.
<<Java is slowly getting better performance on the client too, 1.3 is a vast improvement over 1.2, I just wish it didn't take so long between releases. 1.4 is supposed to have substantial performance and memory requiremnt impovements.>>
And no matter how good it gets, it will still have the following disadvantages:
1) No interoperability with the native platform. (Mousewheel support anyone?)
2) No component-model interoperability on the client-side.
3) It will still be slower and bigger than an equivalent JScript/.net application for most applications -- especially smaller ones.
The very idea of platform independance while quite noble, is the very antithesis of CPU/memory efficiency and interoperability. Merely making your widgets look like the native platform is not enough. They have to *behave* like them too, and your code has to be able to interact in a meaningful fashion with other code on the client.
<<I'm tempted to mock something up in Java to show you how easily an add/remove "like" dialog could be done but I'm sure it would be a complete waste of my time.>>
You need to reread my original messages. I'm not talking about Swing or AWT. I *know* you can make a nice, heavy, client-side GUI with all the trimmings. Making it interact in a sane-manner with the native OS is incredibly complex (JNI anyone?), and making it be lightweight is impossible.
Yes, you could write an add/remove program dialog in Java. Making it behave like the one in Win2K would be very complex and involve a number of custom widgets. Making it be embeddable and controllable by other applications on the system would be nearly impossible.
Yes, a good foundation is the critical component for everything I'm talking about. IE provides a good start,
-JF
Frankly, Linus is wrong on this one. Full-on context switching associated with process-based threads murders performance.
Solaris for example, offers N:M threading, which is one of the reasons it is considered to be better suited to large-scale back-end systems like database servers. My daytime employer uses MySQL on an 8-way Solaris box with as many as 8,000 simultaneous connections! (Yes, we've spent a great deal of time minimizing the # of connections but we just get *that much* usage of our system...) Linux would come pretty close to choking on such a setup.
-JF
As promising as Mason is, the maintainers have a very poor design philosophy. They consider it acceptable for the line numbers produced in error messages to *always* be incorrect! They consider it acceptable for the external and internal names of parameters to a component to use a common naming convention thus ensuring that you cannot use the %ARGS section if you want to use valid HTML parameter names that are NOT valid Perl names. The classic example: If you have an image input called foo, the browser will send parameters called foo.x and foo.y (you can't change this) containing the coordinates of where the user clicked.
Oddly enough the idea of having a generalized mapping was rejected in part because they didn't want to make Mason "HTML specific"! Instead, apparently, they want to force everyone into a lowest-common-denominator between Perl and whatever they are using Mason to interact with.
I used to think Mason was great, but this poor design philosophy forced me to abandon it in favor of tools that are designed with quality in mind.
-JF
On the server side you can use many languages, but on the *client side* there are few alternatives -- and Java aint one of them. Bolting an applet into a web page is not the same thing as an HTML-based application.
.Net but ECMA standard JavaScript effectively prohibits such possibilities. (with the possible exception of a very ugly hack using a hidden IFRAME)
JavaScript/DOM are a good start but lack a great deal of flexibility. XML-RPC/SOAP are *very* useful! Mozilla provides this, as does
Look at the add/remove programs dialog in Windows 2000. This is an HTML-based application written using JavaScript (or rather, JScript). Microsoft Money is in large part an HTML-based application. *This* is what I mean by "HTML-based application".
-JF
The server end of things is irrelevant to my point. Java does very well on the server. I'm referring only to the client.
By "fluid" I mean stuff that loads quickly with no install process and interacts "correctly" with the environment around it. Java does not do this even with standalone Java applications. Indeed, one of the fundamental design goals of Java -- total platform neutrality -- makes this impossible. One cannot, for example, use the mouse wheel in Java without using JNI and coding support yourself.
-JF
The event horizon is not the maximum extent of the black hole's gravitational field -- it's the point at which nothing can *escape* regardless of the amount of energy applied.
The distinction is that most matter isn't going to apply a lot of energy in an effort to escape -- it'll just fall in. A spaceship for example, would be pulled towards the black hole well beyond the event horizon, but before it reaches that point it could (theoretically) escape given sufficient energy. (although as you get close to the event horizon the energy required would quickly become phenominal...)
-JF
Oh yeah... Forgot to mention that the idea of HTML-based applications has a lot of potential and usefulness in providing a flexible, powerful UI... Windows 2000's add/remove programs dialog is HTML/JavaScript based and so is Microsoft Money 2001...
.net is sort of Java, EJB, JavaBeans and more... C# is the part that is analogous to Java.
The idea of hosted, load-on-demand applications isn't exactly a new idea -- even for Java.
Microsoft's approach is to make things XML/HTML based. JScript, DOM, C#, and SOAP... Much more "fluid" than having this VM bolted onto your browser... Simple apps are simple, small, and quick-loading, complex apps scale accordingly...
It's a very interesting approach actually... Very promising, and in some ways similar to Mozilla -- although somewhat more extensive in its goals...
-JF
PS: As for the idea that companies need detailed data about you to function efficiently, that's just plain bullsh*t. What they need is an efficient infrastructure, good lines of internal communication, good management, all the traditional stuff. Only marketers think they "need" detailed data about all of their hypothetical future customers. (Note nobody complains about data companies need to function... surely Amazon needs to know where to ship that book to... while this could be worked around it's not really worth the effort at this time.)
And how do you get an efficient infrastructure? By tailoring it to meet demand. I think it is safe to say that there's nothing wrong with *agregate* statistical data, right? (I.E. "43% of the people going to Amazon.com look at books, 12% of those, actually buy books.")
Consider Amazon.com. The efficiency of their infrastructure is not merely about how many books they can ship in a period of time, or how many hits their web site can handle, but how many *orders* they get per dollar spent on business development (including marketing).
What is more efficient for Amazon.com? 100 customers who each come and buy 1 book, or 10 customers who each come and buy 10 books. The latter. Why? Because there is overhead to processing an order. So clearly, multi-item, and repeat purchases are important to the efficiency of their operation. How do you achieve that? Traditionally it's done via the 80/20 rule. You can get 80% of your customers to behave in the manner you desire with 80% of the effort, and you ignore the other 20% since that would consume the "other" 80% of the effort.
Personal targeting allows businesses to operate *much* more efficiently. Amazon.com can suggest items to me that I am likely to want, and can hide stuff I'm unlikely to want which makes me more likely to buy multiple items or order again. I do, in fact, like this feature.
I do not like the idea that Amazon.com would sell this information, or that it could be used against me by 3rd parties -- that is where the biggest privacy-related problems lay.
-JF
Unless you are using MySQL, your DB vendor probably has some handy tips on how to handle disks -- how many to have, how to configure them, what to allocate each one or group to...
I don't see a question in this unless you're using MySQL or some other relatively "low-end" DB in which case, you probably have larger concerns to deal with.
-JF
The problem with this is that you have no way of knowing how significant a change was. Many places don't upgrade just because a new version is out. It is helpful to such shops to have version numbers that are meaningul about the depth of changes.
... Possibly with alternating marjor or minor versions for development/stable releases.
MySQL and Linux both have good version numbering methods. Perl's method, while a little absurd at times (extraneous 0's), also works well.
I wholeheatedly favor the approach of
-JF
<>
Actually, even merely lying down and dying would be in violation of that standard: Doing so would cause your body to decompose and release potential harmful greenhouse gasses into the atmosphere along with who knows what other consequences. Even merely ceasing to exist could potentially be harmful: How would the Earth's orbit be affected if 6 billion people simply ceased to exist. (I.E. their mass/energy was no longer a part of the universe)
It's an inherently paradoxical decision.
-JF
The question is not whether the output is radioactive -- if so, this could be used once the craft left the Earth's atmosphere and reached some reasonably safe distance.
The question is really "if the output is radioactive, does our atmosphere protect us from it." There are many many many forms of radiation in space. Our atmosphere protects us from many of them.
-JF
Since Microsoft already does this for IE, I would count on MSI supporting it in the not-so-distant future...
-JF
I agree. But our web browser would have nothing at all to do with my comment about software distribution in the Windows world. The software installation application that enables more modular software distribution need not even be written by Micro(Richman)soft; none of the major installers used today are.
.ZIP file support in Windows ME seems a little odd to me... Unlike the installer situation, this pretty much puts WinZip out of business. But at least Windows is catching up to Linux feature-wise... *grin*
Actually, With Win2K/WinME Microsoft has introduced a centralized "installer" service, using a special package format (MSI) which does library and version tracking, etc etc. You can download the service for Win98 as well..
You'll note that ActiveState uses MSI exclusively for distributing Windows stuff.
It actually makes a lot of sense... Rather than have InstallShield, Wise, and half a dozen other installer services tracking which DLLs are/aren't being used, and clobbering each other (say, InstallShield deleting foo.dll because IS thought it wasn't being used, but a Wise-installed app was using it...) a central manager for this stuff makes sense.
And actually, this doesn't have to put Wise/InstallShield/etc out of business -- it just means they have to make MSI-compatible installer-generators...
Now, the decision to include
-JF
A couple points:
1) Pretty much all recent 3D chips have hardware anti-aliasing, and lighting. PS2 included. The problem with anti-aliasing and the PS2 is that it's VERY slow. The performance hit is unacceptable, so programmers turn it off.
2) PS2 isn't confusing to developers because it was "rushed to market" -- developer confusion always stems from fundamental design choices. In this case, the multi-chip architecture where each chip serves a different, or somewhat overlapping purpose results in a very different and complex programming model.
3) While old-school gamers will remember fondly more Nintendo franchises, the younger crowd tends to know non-Nintendo franchises more. FF is just one such franchise and I wouldn't count on a GC version.
-JF
The interesting thing to note is that while the PlayStation 2, like the Sega Saturn is suffering from developer confusion (I.E. developers have a whole lot to learn before they can take advantage of its capabilities) the GameCube is designed from the ground up to be a developer-friendly platform.
I read an interview with someone -- maybe Shigeru Miyamoto? -- about how when the N64 launched with Mario 64 showing off what it could do, developers were blindsided by the difficulty of programming for the system. They assumed a Mario-like game would be easy when in fact the platform had a number of bottlenecks and quirks that made development difficult. GameCube is apparently meant to address such difficulties.
-JF
The managed version, and multi-port version work well for us. I should point out that we only use the 100+ series and the company is not old enough to predate that... :)
-JF
Getting "the best bang for the buck" means a LOT more than just how much you pay for the box. If you go with a brand that is prone to failure you will spend more time (and time is money) fixing problems. Your time is consumed. The time of the employee/student is consumed. Money is consumed in the replacement parts. Opportunities are lost. (you *could* have been applying security patches to the servers, or setting up that new computer lab, or...)
TCO is a VERY big issue when you have hundreds of machines. Now, I agree that "mission critical" is a term usually reserved for much more failure-sensitive environments than a university but that doesn't mean that the cheapest box is automatically the best.
However, it may very well be that AMD boxes are as reliable, or more reliable than Intel -- if so you're lucky.
My daytime employer uses pure Intel for our x86 based servers -- Intel motherboard (with rare exceptions (820 chipset) they tend to be VERY reliable), Intel chip (with rare exceptions (original Pentium), very solid), Intel network cards (always great). However, for our server environment we are more memory bound than CPU bound -- we can afford to go with a slower (but more proven) processor and spend less money that way.
-JF
Simple: It's not a new OS.
GEOS, the OS at the heart of NewDeal originated as PC/GEOS, around the same time Windows 3.0 came about.
Like Windows 3.x, it is an environment on top of DOS that provides its own ABI and API. Its filesystem module gives you things like longish (32 chars) filenames on top of FAT16, and it provides a great many useful libraries and modules for programmers. (including something roughly analogous to MFC)
It's VERY small, and VERY fast but rather feature-poor and coded in a low-level object-oriented macro assembler so making it work on a 32/64-bit system in such a way as to take advantage of even just the available memory would be nearly impossible.
-JF