Ok, glad you acknowledge that STL has nothing to do with virtuals.
So yes, let's say you have a templated class and instantiate it for 15 different type specalizations. What's the memory overhead of this? Not much.
On top of that, if you really do have 15 differen things, how are you going to shave off that overhead using a different mechanism? Will you create 15 seperate classes intead? That's even MORE overhead than the templating. Will you create one class with a type = field? Use comparision in all functions that relate to the class with seperate paths where needed for each of the 15 different cases?
I hope you're starting to see that if you *really* have 15 seperate things, you pay that overhead no matter if you're dealing with ansi c using templates.
These are criticisms that are parroted over and over without much understanding of what's going on. Please don't perpetuate ignorance. Go test it yourself, see the results.
wtf are you blathering on about. KDE's dynamic linking broker has nothing whoatsoever to do with the performance of c++ in general.
That's like saying c sucks because my linear search of my 100meg dataset is slow. Perl is much faster when I use binary search, therefore Perl is always faster than c.
Now, you *have* raised one valid point about template heavy c++: It can be a bit slower to compile. So far, this has never been an issue for me. By far the longest compiles I've had to deal with were output from yacc, which is of course, POCC (plain ole c code).
Go do a benchmark, stream based io often beats atomic io. Never automaticly equate low level code with fast code. Just because it's specified in a way close to the machine representation does not mean it's effective code. Anyone can write slow c, and slow assembly just as easily as they could write slow c++ or slow ocaml.
I think your simplist move would be to archive them on a PC. There are plenty of choices for lossless compressors out there, and they all result in a reduction of 40-50%. As another comment mentions, drives are cheap. Back of the envelope math says your entire collection should fit in just over 200gig's.
As for playback, get either a very high quality playback card (midiman, hoontech), or use digital output to a reciever with digital input. Use a video card with tv out and a wireless keyboard with built in pointing device to control it. I believe there's software out there for automagickly grabbing the cd/song titles from cddb or freedb and providing indexing capability for easy playback.
It's perhaps not the cheapest solution, and doesn't have quite the appeal of a consumerized all in one device. But then again, someone with 350 cd's obviously has some disposable income and is pretty agressive about enjoying music on their terms.
1.54mbit/1.54mbit SDSL, 6 static IP addresses (with more if I ask for them), no bandwith metering or limiting, no restrictions on ports, services or what I do with it.
New features in hardware and the software that uses it is a classic catch-22.
One of the ways nVida has been so successful is to take the long view and say "even if it's not a feature people use for comparing our product to competitior X, we'll include it because a year after that, it WILL be the killer feature because our hardware being out there will make it attractive to game developers to use".
NV25 will run current applications faster than NV20. Maybe that's not a big deal, after all, I mostly play counterstrike and even a lowly geforce ddr runs that at blazing speed. But the fact that it's faster will be enough for some people to buy it.
However, the programability of the current geforce3 was the shape edge of the wedge, to get those features into the market. The hammer will come with NV25, Doom3 and a myraid of titles developed by people familiar with xbox. It *will* be a big deal, and as soon as stuff like realtime shadowmapping gets on the screen, people will scream for hardware that supports it.
3dfx was trying to ski uphill with a set of gear that had been obsolete for some time. nVidia was no longer worried about the, rather about ATI and competing in the OEM deals. Buying 3dfx just gave them protection against someone else buying 3dfx's IP and starting patent litigation against them.
And the fact of the matter is, you don't know what 3dfx was working on, wheither it was "killer routines" or not. Gigapixels technology may have breathed some extra life into t-buffer, but it's hardware transform and programability that will be the forseeable future, 2 things 3dfx was not making much progress towards.
Look, I liked 3dfx as well. I replaced my rendition with a voodoo when there were exactly 3 games that ran on it. However, I don't let my fondness for 3dfx pull the wool over my eyes and convince me that they were somehow not doomed, were going to come back and do great things if only nasty nvidia hadn't bought them.
Remember, 3dfx chose to sell.
What will be the next big innovations? If someone can figure out how to get realisitc sizes of embeded dram, that'll be nice for fill rate. Some people might try heirarchical zbuffering, but that hasn't been a win for a while on most architectures. As vertex processing throughput approaches fillrate throughput, I expect to see things move to randomized splat samping, since it appears the best way to get logarithmic complexity vs number of primatives. I've not seen any other way to get realistic rendering times on datasets involving billions of polygons or more.
The problem with using FPGA's for ray-tracing is that, when you fire a ray into the scene, you don't know what it's going to hit. If it hits something, then typically you examine illumination to that spot from all the light sources, and spawn another ray if you're doing reflection, transmission, or diffuse interreflection.
The problem is, you can't parellel this easily:
for each pixel in image
for each primative in scene
if ray through pixel hits primative
for each light
if ray from light to hit doesn't hit something else first, calculate illumination
calculate reflected color based on material
write color to image
so let's say we equip each node of an FPGA with a program that evaluates this program. If we have 1,000 of these nodes, that means we can like, render 1000 pixels at the same time right?
wrong. The scene is going to be far to large to store in each FPGA. So, each FPGA node is going to have to wander down the list of primatives in ram to do it's intersection tests. That is not fast.
Now sure, you can set things up so that all the nodes are listening to one broadcast bus, and all the primatives in the stream are listed off, and any nodes find a hit, they remember it. After that you let list the light sources, letting nodes calculate illumination at the hit, then let them process the material. Most likely they have to do some texture lookups here.
So sure, that's a way of reshuffling the loop order and doing a lot of tests in parellel, but the real truth is, if you use some sort of spatial hierarchy on a general purpose cpu, it will be much faster.
Traditional beowulf clusters are typically much better for this sort of thing, because they usually can store an signifigant portion of the scene discription locally, so there's no communication overhead that limits the parellelism.
The deal with Final Fantasy is they didn't take into account subsurface scattering. Only recently have good models for that surfaced, and the computation time is prehibitive.
Ruby tends to be slower than perl, and faster than python. Of course, this depends the specifics of what you're doing.
Ruby lends itself to a style of programing where you prototype in pure ruby, then rewrite performance critical portions in c++. As many will observe, only a small fracton of an application's code tends to need specific optimization.
cddb did offer something to the community: they hosted the database, and it's my understanding, dealt with the costs involved.
the community gave cddb something: the data.
if my understanding is correct, they should be free to do anything they like with the service. if they want to begin to charge for it to offset their costs, or to profit, so be it.
however, ownership of the data is more tricky. when someone conducts a poll, individual respondants contribute data to it. but it's accepted that the company that goes to the work execute the poll rightly owns the data, and can profit from it however they wish. this seems to suggest that they own the cddb data, and can do as the like
however, I can also see the situation where individuals contribute to a work, such as building an object. then one of them takes the object to a museam, and charges admission to see it. in this circumstance, it seems totally right that those contributing had an understanding of ownership that was violated. perhaps there was no contract, but I would think it's plausible a court would find that all the individuals are entitled to a fair share.
Honestly, I don't know the law that governs this in the US or anywhere else.
Honestly, I can't think of a law that could deal with this situation without relying heavily on a court judgement.
I'd love to hear it if someone does know, or can think
Ohh, and popularity is not nessisarly the sole basis of surviveability
for example: NetBSD usage is small, but on many of the bazillion platforms it supports, it's the sole option, as there is no linux or freebsd or alternative ported there. So maybe the user base is small, but the the software is assured to survive as long as the platforms do.
seems alive, well, running fast and with more support than I've encountered from linux distrobutions
so before you put a spike in it's heart you might stop kicking it and let it get up.
Freebsd is averaging 125 cvs commits a day. I'd say that's pretty alive and running.
I'm pragmatic, BSD has certain advantages, and the various linux distros have certain advantages. But bsd is most certainly not in the grave, and remains a good alternative to solaris for many organizations critical systems.
Although the analagy may seem a little on the ridiculus side, would you permit a government, or government sanctioned organization to decide that you could no longer be named "Jim" unless you had red hair? Or, not "Gregory" unless you passed the bar exam?
After you stop laughing at my rediculous analogy, try to think of a reason why restricting.org names to non-profit organizations is justified, and the above isn't.
I have to agree, I like the idea and motivation behind a non-profit only TLD, but I dislike the implications.
I think organizations should have the right to choose their name as they please. If we're going to let.tv or.to pass into the hands of organizations that are not located in, or have nothing to do with those countries, why should we enforce a restriction on.org?
Even if we like the idea of an enforced.org, it is of course, completely unfair to revoke currently granted domains on this basis. I imagine that won't ever happen. But changing the precident is just as bad. What use is it to enforce.org for the future, if there are.org domains held now that will continue to exist that do not meet the enforcement criteria? How does that help the public in any way?
Non-profit organizations can protect their names through traditional means of trademark. Looser, non-legal organizations cannot. Why does there need to be enforcement when other means, such as trademarks protect the interests of individual not-for-profits.
1.) The ability to determine one's own name, or of an ogranization to determine it's own name, are cleary a fundamental right. Compramising this may not lead to the end of humanity, but I do believe it to be a very wrong path to go down.
2.) Restricting.org does not seem to be in the public's best interest, or particularly desired.
3.) It is totally unreasonable to revoke.org domains granted when things were unenforced. With these domains continueing to exist, how is the public's collective interest served by enforcing the rule for the future..org will not assuradly = a not-for-profit any more than it does today. Unless you revoke the current.orgs, which is by all views, completely unreasonable, enforcing.org for the future doesn't do anything meaningful.
4.) Because individual.org's are legal entities, they can protect their interests with trademark. Perhaps a legal precident does need to be set that when trademarked company foo owns foo.com as well as foo.org, and the not-for-profit foo has a similar (or the same) trademark, that the.org should rightly be granted to the not-for-profit, and the.com rightly be granted to the commercial entity. The previously stated intention of.org sets up justification for this interpretation, and the statement of that intent *should* continue for this and similar reasons. However, it shouldn't be enforced.
Although I think it's clear ICANN exists in a way that it's motiveations push it directly away from the world's public interest, which it is supposed to represent, I'll hold off ranting on that. I personally don't see any way ICANN can be 'fixed' or replaced at this point.
The first is a technological part, which involves moving to a JIT compiled intermediate language with multiple front end languages, setting up web based infrastructure such as the soap protocol, and in general, moving toward an xml centric encoding of data, when appropriate.
The second is a business initiative to move microsoft's applications and services into web based subscription services.
Now, on the technology side, it's all rather nice actually. Because the common language runtime targets a narrower application scope than java, as well as assures native code compilation, it's really quite speedy. It's not as fast as native c, but it's acceptibly close. There are many other smaller changes related to multi-versioning shared librarys, etc that have been needed a long time. The interfacing to legacy or external code/languages is certainly much nicer than the java world's. The guts of the web forms framework in asp.net as well as the windows forms (MFC goes away yay!) are all quite nice to work with. At least in the technology reguard, they're doing a lot of good things java never targeted... which is not the same as saying ".net is better".
As for web based services... I, and I'm sure everyone, has some real fears concerning privacy and security. I'd really like to see MS (and everyone) center around some sort of manditory user permission and policy based protocol for accessing personal information. The more the line becomes blurred between what's local to your machine, and what's on the net, the more important it is for a user to be given the right to control their personal data.
Those issues asside, there are of course benifits to moving data onto the network, such as getting access from any public terminal, etc. Of course,.net is about way more than just network centric data storage (but that's what gets talked about most).
From a business perspective, these things are already happening. More and more often, the websites people use combine information from multiple sources to deliver to their readers. And that's going to continue to gain momentum, weither it's done within the.net realm, or in apache/php/etc.
Really, both java and sun are about grabbing the biggest piece of a pie possible for sun and ms.
In the java world, sun doesn't really care about applications, but they *Do* care about implimentations. They want to be making $$, off every sale of a java platform implimentation. It's very nice to see apache jakarta and the other free tools they've released/supported/allowed, don't get me wrong. I use them and love them. But I doubt you'll see many free J2EE implimentations anytime soon.
On the other hand, MS doesn't care so much about the plumbing in.net. I still haven't seen weither they'll let the CLR intermediate language be implimented on other platforms, but at least they're pretending to play nice in reguards to soap and whatnot. What MS does care about, is being the biggest provider of services that the plumbing delivers. And the way they can do that is the same way they always do: by wielding the strength of their user base to create an advantage for their products. A good example is MS passport. Such a service is *only* an advantage to the end user if the majority of sites use it (pardon me while I shudder over subconcious security fears *shudder*). So, MS plans to roll out a whole host of integrated services, some free, some not free, for other web developers to integrate with.
In the end, it all comes down to figuring out how to attach a money leech to the IP pipeline.
Now, that's not nessisarily a bad thing. I like free stuff, but I don't mind making reasonable $$ contributions to create incentive for products that meet my desires and needs. I think the real fear is one organization's leech getting so big it hogs the blood money, starves the rest, and in the end, screws the users.
Slashdot Mirror
Ok, glad you acknowledge that STL has nothing to do with virtuals.
So yes, let's say you have a templated class and instantiate it for 15 different type specalizations. What's the memory overhead of this? Not much.
On top of that, if you really do have 15 differen things, how are you going to shave off that overhead using a different mechanism? Will you create 15 seperate classes intead? That's even MORE overhead than the templating. Will you create one class with a type = field? Use comparision in all functions that relate to the class with seperate paths where needed for each of the 15 different cases?
I hope you're starting to see that if you *really* have 15 seperate things, you pay that overhead no matter if you're dealing with ansi c using templates.
These are criticisms that are parroted over and over without much understanding of what's going on. Please don't perpetuate ignorance. Go test it yourself, see the results.
wtf are you blathering on about. KDE's dynamic linking broker has nothing whoatsoever to do with the performance of c++ in general.
That's like saying c sucks because my linear search of my 100meg dataset is slow. Perl is much faster when I use binary search, therefore Perl is always faster than c.
Now, you *have* raised one valid point about template heavy c++: It can be a bit slower to compile. So far, this has never been an issue for me. By far the longest compiles I've had to deal with were output from yacc, which is of course, POCC (plain ole c code).
Go do a benchmark, stream based io often beats atomic io. Never automaticly equate low level code with fast code. Just because it's specified in a way close to the machine representation does not mean it's effective code. Anyone can write slow c, and slow assembly just as easily as they could write slow c++ or slow ocaml.
The only speed hit relevant to c++ would be using virtual methods, which is just one of many tools c++ provides you.
Templates, for example, allow for similar common factoring of code without resorting to inheritance and virtuals.
C++ certainly has it's downsides, but please don't reject it based on arguments that have been repeated over and over without basis.
I think your simplist move would be to archive them on a PC. There are plenty of choices for lossless compressors out there, and they all result in a reduction of 40-50%. As another comment mentions, drives are cheap. Back of the envelope math says your entire collection should fit in just over 200gig's.
As for playback, get either a very high quality playback card (midiman, hoontech), or use digital output to a reciever with digital input. Use a video card with tv out and a wireless keyboard with built in pointing device to control it. I believe there's software out there for automagickly grabbing the cd/song titles from cddb or freedb and providing indexing capability for easy playback.
It's perhaps not the cheapest solution, and doesn't have quite the appeal of a consumerized all in one device. But then again, someone with 350 cd's obviously has some disposable income and is pretty agressive about enjoying music on their terms.
1.54mbit/1.54mbit SDSL, 6 static IP addresses (with more if I ask for them), no bandwith metering or limiting, no restrictions on ports, services or what I do with it.
$85/month
and worth every US$0.01
New features in hardware and the software that uses it is a classic catch-22.
One of the ways nVida has been so successful is to take the long view and say "even if it's not a feature people use for comparing our product to competitior X, we'll include it because a year after that, it WILL be the killer feature because our hardware being out there will make it attractive to game developers to use".
NV25 will run current applications faster than NV20. Maybe that's not a big deal, after all, I mostly play counterstrike and even a lowly geforce ddr runs that at blazing speed. But the fact that it's faster will be enough for some people to buy it.
However, the programability of the current geforce3 was the shape edge of the wedge, to get those features into the market. The hammer will come with NV25, Doom3 and a myraid of titles developed by people familiar with xbox. It *will* be a big deal, and as soon as stuff like realtime shadowmapping gets on the screen, people will scream for hardware that supports it.
negative
3dfx was trying to ski uphill with a set of gear that had been obsolete for some time. nVidia was no longer worried about the, rather about ATI and competing in the OEM deals. Buying 3dfx just gave them protection against someone else buying 3dfx's IP and starting patent litigation against them.
And the fact of the matter is, you don't know what 3dfx was working on, wheither it was "killer routines" or not. Gigapixels technology may have breathed some extra life into t-buffer, but it's hardware transform and programability that will be the forseeable future, 2 things 3dfx was not making much progress towards.
Look, I liked 3dfx as well. I replaced my rendition with a voodoo when there were exactly 3 games that ran on it. However, I don't let my fondness for 3dfx pull the wool over my eyes and convince me that they were somehow not doomed, were going to come back and do great things if only nasty nvidia hadn't bought them.
Remember, 3dfx chose to sell.
What will be the next big innovations? If someone can figure out how to get realisitc sizes of embeded dram, that'll be nice for fill rate. Some people might try heirarchical zbuffering, but that hasn't been a win for a while on most architectures. As vertex processing throughput approaches fillrate throughput, I expect to see things move to randomized splat samping, since it appears the best way to get logarithmic complexity vs number of primatives. I've not seen any other way to get realistic rendering times on datasets involving billions of polygons or more.
The problem with using FPGA's for ray-tracing is that, when you fire a ray into the scene, you don't know what it's going to hit. If it hits something, then typically you examine illumination to that spot from all the light sources, and spawn another ray if you're doing reflection, transmission, or diffuse interreflection.
The problem is, you can't parellel this easily:
for each pixel in image
for each primative in scene
if ray through pixel hits primative
for each light
if ray from light to hit doesn't hit something else first, calculate illumination
calculate reflected color based on material
write color to image
so let's say we equip each node of an FPGA with a program that evaluates this program. If we have 1,000 of these nodes, that means we can like, render 1000 pixels at the same time right?
wrong. The scene is going to be far to large to store in each FPGA. So, each FPGA node is going to have to wander down the list of primatives in ram to do it's intersection tests. That is not fast.
Now sure, you can set things up so that all the nodes are listening to one broadcast bus, and all the primatives in the stream are listed off, and any nodes find a hit, they remember it. After that you let list the light sources, letting nodes calculate illumination at the hit, then let them process the material. Most likely they have to do some texture lookups here.
So sure, that's a way of reshuffling the loop order and doing a lot of tests in parellel, but the real truth is, if you use some sort of spatial hierarchy on a general purpose cpu, it will be much faster.
Traditional beowulf clusters are typically much better for this sort of thing, because they usually can store an signifigant portion of the scene discription locally, so there's no communication overhead that limits the parellelism.
The deal with Final Fantasy is they didn't take into account subsurface scattering. Only recently have good models for that surfaced, and the computation time is prehibitive.
Ruby tends to be slower than perl, and faster than python. Of course, this depends the specifics of what you're doing.
Ruby lends itself to a style of programing where you prototype in pure ruby, then rewrite performance critical portions in c++. As many will observe, only a small fracton of an application's code tends to need specific optimization.
cddb did offer something to the community: they hosted the database, and it's my understanding, dealt with the costs involved.
the community gave cddb something: the data.
if my understanding is correct, they should be free to do anything they like with the service. if they want to begin to charge for it to offset their costs, or to profit, so be it.
however, ownership of the data is more tricky. when someone conducts a poll, individual respondants contribute data to it. but it's accepted that the company that goes to the work execute the poll rightly owns the data, and can profit from it however they wish. this seems to suggest that they own the cddb data, and can do as the like
however, I can also see the situation where individuals contribute to a work, such as building an object. then one of them takes the object to a museam, and charges admission to see it. in this circumstance, it seems totally right that those contributing had an understanding of ownership that was violated. perhaps there was no contract, but I would think it's plausible a court would find that all the individuals are entitled to a fair share.
Honestly, I don't know the law that governs this in the US or anywhere else.
Honestly, I can't think of a law that could deal with this situation without relying heavily on a court judgement.
I'd love to hear it if someone does know, or can think
Ohh, and popularity is not nessisarly the sole basis of surviveability
for example: NetBSD usage is small, but on many of the bazillion platforms it supports, it's the sole option, as there is no linux or freebsd or alternative ported there. So maybe the user base is small, but the the software is assured to survive as long as the platforms do.
seems alive, well, running fast and with more support than I've encountered from linux distrobutions
so before you put a spike in it's heart you might stop kicking it and let it get up.
Freebsd is averaging 125 cvs commits a day. I'd say that's pretty alive and running.
I'm pragmatic, BSD has certain advantages, and the various linux distros have certain advantages. But bsd is most certainly not in the grave, and remains a good alternative to solaris for many organizations critical systems.
Although the analagy may seem a little on the ridiculus side, would you permit a government, or government sanctioned organization to decide that you could no longer be named "Jim" unless you had red hair? Or, not "Gregory" unless you passed the bar exam?
.org names to non-profit organizations is justified, and the above isn't.
.tv or .to pass into the hands of organizations that are not located in, or have nothing to do with those countries, why should we enforce a restriction on .org?
.org, it is of course, completely unfair to revoke currently granted domains on this basis. I imagine that won't ever happen. But changing the precident is just as bad. What use is it to enforce .org for the future, if there are .org domains held now that will continue to exist that do not meet the enforcement criteria? How does that help the public in any way?
.org does not seem to be in the public's best interest, or particularly desired.
.org domains granted when things were unenforced. With these domains continueing to exist, how is the public's collective interest served by enforcing the rule for the future. .org will not assuradly = a not-for-profit any more than it does today. Unless you revoke the current .orgs, which is by all views, completely unreasonable, enforcing .org for the future doesn't do anything meaningful.
.org's are legal entities, they can protect their interests with trademark. Perhaps a legal precident does need to be set that when trademarked company foo owns foo.com as well as foo.org, and the not-for-profit foo has a similar (or the same) trademark, that the .org should rightly be granted to the not-for-profit, and the .com rightly be granted to the commercial entity. The previously stated intention of .org sets up justification for this interpretation, and the statement of that intent *should* continue for this and similar reasons. However, it shouldn't be enforced.
After you stop laughing at my rediculous analogy, try to think of a reason why restricting
I have to agree, I like the idea and motivation behind a non-profit only TLD, but I dislike the implications.
I think organizations should have the right to choose their name as they please. If we're going to let
Even if we like the idea of an enforced
Non-profit organizations can protect their names through traditional means of trademark. Looser, non-legal organizations cannot. Why does there need to be enforcement when other means, such as trademarks protect the interests of individual not-for-profits.
1.) The ability to determine one's own name, or of an ogranization to determine it's own name, are cleary a fundamental right. Compramising this may not lead to the end of humanity, but I do believe it to be a very wrong path to go down.
2.) Restricting
3.) It is totally unreasonable to revoke
4.) Because individual
Although I think it's clear ICANN exists in a way that it's motiveations push it directly away from the world's public interest, which it is supposed to represent, I'll hold off ranting on that. I personally don't see any way ICANN can be 'fixed' or replaced at this point.
.NET is divided up into 2 real parts.
.net is about way more than just network centric data storage (but that's what gets talked about most).
.net realm, or in apache/php/etc.
.net. I still haven't seen weither they'll let the CLR intermediate language be implimented on other platforms, but at least they're pretending to play nice in reguards to soap and whatnot. What MS does care about, is being the biggest provider of services that the plumbing delivers. And the way they can do that is the same way they always do: by wielding the strength of their user base to create an advantage for their products. A good example is MS passport. Such a service is *only* an advantage to the end user if the majority of sites use it (pardon me while I shudder over subconcious security fears *shudder*). So, MS plans to roll out a whole host of integrated services, some free, some not free, for other web developers to integrate with.
The first is a technological part, which involves moving to a JIT compiled intermediate language with multiple front end languages, setting up web based infrastructure such as the soap protocol, and in general, moving toward an xml centric encoding of data, when appropriate.
The second is a business initiative to move microsoft's applications and services into web based subscription services.
Now, on the technology side, it's all rather nice actually. Because the common language runtime targets a narrower application scope than java, as well as assures native code compilation, it's really quite speedy. It's not as fast as native c, but it's acceptibly close. There are many other smaller changes related to multi-versioning shared librarys, etc that have been needed a long time. The interfacing to legacy or external code/languages is certainly much nicer than the java world's. The guts of the web forms framework in asp.net as well as the windows forms (MFC goes away yay!) are all quite nice to work with. At least in the technology reguard, they're doing a lot of good things java never targeted... which is not the same as saying ".net is better".
As for web based services... I, and I'm sure everyone, has some real fears concerning privacy and security. I'd really like to see MS (and everyone) center around some sort of manditory user permission and policy based protocol for accessing personal information. The more the line becomes blurred between what's local to your machine, and what's on the net, the more important it is for a user to be given the right to control their personal data.
Those issues asside, there are of course benifits to moving data onto the network, such as getting access from any public terminal, etc. Of course,
From a business perspective, these things are already happening. More and more often, the websites people use combine information from multiple sources to deliver to their readers. And that's going to continue to gain momentum, weither it's done within the
Really, both java and sun are about grabbing the biggest piece of a pie possible for sun and ms.
In the java world, sun doesn't really care about applications, but they *Do* care about implimentations. They want to be making $$, off every sale of a java platform implimentation. It's very nice to see apache jakarta and the other free tools they've released/supported/allowed, don't get me wrong. I use them and love them. But I doubt you'll see many free J2EE implimentations anytime soon.
On the other hand, MS doesn't care so much about the plumbing in
In the end, it all comes down to figuring out how to attach a money leech to the IP pipeline.
Now, that's not nessisarily a bad thing. I like free stuff, but I don't mind making reasonable $$ contributions to create incentive for products that meet my desires and needs. I think the real fear is one organization's leech getting so big it hogs the blood money, starves the rest, and in the end, screws the users.