About Java: There is a "standard" called Java. It is controlled by Sun. If Java was not a standard, then Sun could not have convinced MS to pay for corrupting it.
There is no legal penalty for "corrupting a standard", so Sun cannot have used that as an argument against Microsoft.
In fact, Sun sued Microsoft for contractual violations. And the contract was about something that Sun owned and that Microsoft damaged: Java. What that shows is that Java is proprietary to Sun. If it weren't proprietary to Sun, then Sun couldn't have claimed to have been injured by Microsoft's actions.
I think you are using the word "standard" to imply "open standards". That seems silly after your insistence that we use words correctly. "Big Macs" are a standard. If you want to call food a "Big Mac", you need to satisfy the trademark holder. If you can make it different, then call it "J++".
The word "standard" can have many meanings, so multiple usages can be correct. Yes, Java is a "standard" in the sense of being a popular (if proprietary) product. But that's not what I was referring to.
I was using the term in the sense of "a specification for a system that permits independent implementation". What I was really saying is that even if we accept Sun's interpretation of the term "open", Java still fails to be an "open standard" because its definition is simply technically not precise enough to be an "open standard".
[Sun has made a fatal mistake by lying to, and deceiving the Java community] I missed this. Could you elaborate?
During the first several years of Java's existence, Sun kept promising to submit Java to an open standards body. That promise mattered a great deal because without it, companies like IBM wouldn't have adopted it and Java would have died quickly and probably been replaced by an open source system for running applets right away (which were all the rage back then). But after several years of dithering, Sun pulled out of both ISO and ECMA standardization and instead chose to make Java into what it is today.
Sun's API documentation is just API documentation. It contains almost no actual specification of the semantics. Programmers just call what sounds reasonable and then adapt their code to the behavior they actually get. The only way to clone Java would be to perform extensive experimentation on Sun's actual Java implementation.
The specification is there for everyone to see.
You can see the official API docs but only if you agree to Sun's license terms. Furthermore, whether you can see the API docs or not doesn't matter much because Sun also has lots of patents on Java.
So pick a version and implement it.
How am I supposed to pass Sun's compatibility suite if I do that?
You might not be able to call it java when you are done, but what is the difference?
You won't get done; the process that Sun has created ensures that.
Yes, they are. Check MSDN. Microsoft has extensive published API documentation.
that's one of the reasons why the EU sued Microsoft - so they would publish APIs and protocols.
The EU sued Microsoft over internal APIs and internal protocols. Sun Java is also full of those.
IBM, apple etc are full java implementations, not derivatives.
No, they are not. They depend on huge amounts of Sun-licensed source code, and they have "SUN PROPRIETARY/CONFIDENTIAL" notices all over them.
And you can implement Java without restrictions. However, if you want to call the result 'Java' you must be compatible, otherwise what is the point?
No, that is false. Even if you don't call the result "Java", you violate Sun's intellectual property rights (mostly patents, but also licenses on their specifications) if you implement Java. Sun may not assert those rights (they have left gcj and kaffe alone, for now), but that doesn't change that they could.
And yes, gcj and kaffe DO count. gcj can run IBM's eclipse IDE - that's impressive and useful.
Very little code written for Sun Java runs on kaffe or gcj. If you count kaffe and gcj as "Java", then Java is one of the worst languages for cross-platform programming and some of its implementations have some of the most incomplete libraries of any popular platform. On the other hand, if you don't count those kinds of implementations, then Java just has a single, proprietary implementation, Sun's, and its proprietary derivatives. You can't have it both ways.
Following is the piece from the GPL that says that the license has to be conspicuous, but it doesn't say that each user has to understand what they're using.
You are mincing words and retreating from your own statement. It is obvious that Sun can't actually go into people's brains and ensure understanding. But they are responsible, as you yourself point out, for a conspicuous display, which is intended to achieve that understanding for anybody who would care about.
They can bury it in a clickthrough license area, and they'd be fine.
Whether they are legally "fine", I don't know; I would guess that if it's "buried", it's not "conspicuous".
But the community isn't getting upset about a legal issue, it is getting upset about Sun's behavior.
That's my point. It's too bad if the "community" feels that they're not playing nice. They're just following the GPL, and if the GPL isn't clear enough, that's the developers' problem for using it in the first place.
Don't fear: because of the behavior of companies like Sun, the GPL will probably be clarified. Then Sun can keep shipping whatever they are shipping, but if they want anything later, they have to comply with the clarified terms.
I knew this was going to happen years ago. I knew that the OSS movement, once companies started really exploiting their code and making tons of money on it, would be upset that they were getting the short end of the stick, when in reality, it was their own short sightedness that led to this in the first place./i>
What upsets people is not that Sun is making money off GPL'ed software, what upsets people is that Sun is arguably violating the spirit and intent of the GPL. The intent of the GPL is clearly to promote the use of free (libre) software. It states as much.
Nobody held a gun to their heads requiring them to program for free.
What makes you think people program "for free"? I have gotten paid very well for the free software I have developed.
What about them? Real-time garbage collectors give you guaranteed real-time responses.
I suspect that you have actually never used a real-time storage allocator of any form. The memory allocators that ship with major C/C++ compilers certainly make no real-time guarantees. The way people usually get real-time performance out of them is by pre-allocating large chunks of memory. Well, you can do in garbage collected languages as well.
GC are generally non-deterministic (they start and finish according to their own rules),
No, they don't. Just like with malloc implementations, their behavior may differ from implementation to implementation, but it is generally pretty well understood. It can usually also be controlled well.
Simple garbage collectors only will start a garbage collection when you ask for a block of memory and it can't satisfy the request; they don't just start up for no reason at all. Parallel garbage collector may run a thread in parallel to the main program but never stopping it. Incremental collectors do a little bit of work each time you allocate. Real-time collectors guarantee well-defined maximum responses for allocation.
If the garbage collector in your language (Java?) doesn't do what you want, it's not a problem with garbage collection in general, it's a problem with the specific implementation your vendor has chosen to give you. Just like there are mediocre or bad malloc implementations, there are mediocre or bad garbage collectors.
How about one of the earlier comments to the effect that mark-and-sweep type algorithms page-faults all the memory used by an application? That has got to be inefficient, and since virtual memory is not under the control of the application by definition there is nothing that can be done, except if the GC is directly under the control of the OS, which doesn't often makes sense (it's not very flexible then).
Well, that comment is wrong. First of all, you don't have to use a mark-and-sweep collector. Most high-performance collectors are, in fact, generational and are very VM friendly (moreso than malloc/free in many cases). Second, operating systems have interfaces to their VM subsystems, so the GC can, in fact, control what is happening with paging--prefetching pages, etc. And they do. Even 20 years ago, Berkeley UNIX had system calls specifically designed to let Franz Lisp let the kernel know what it was doing. Third, a malloc implementation cannot move pointers around to make accesses more local or sequential--good garbage collectors do, so GC is actually superior in that regard.
The article itself says that there is no way to make a GC perform as well or better as a finely tuned hand-micro-managed in every case.
You can "micro-manage" and "fine tune" in the presence of a GC as much as you can in its absence. But in the presence of GC, you have the freedom to be sloppy and your code will still run--so many people don't bother. In C/C++, you don't have a choice.
In languages that don't have GCs you can add one yourself (Bohm's GC works fine for C/C++, and is in fact used for GCJ, the GNU implementation of the Java language), with the benefit that you can turn it off if you don't want it for some reason, something you can't do in Java for example.
No, that is backwards. In languages without GC, you cannot add a GC and get all the benefits from the GC. Boehm's GC, for example, may retain arbitrary amounts of garbage, and its lack of integration with the language and compiler means that it can't be anywhere near as efficient as an integrated GC. Boehm's GC is a great hack, and it work really well, but it is not something you can ultimately rely on. Furthermore, if you add Boehm's GC to a language without GC, you are still left with an unsafe programming language.
Secondly, languages with garbage collection often give you full control over the GC: you can enable it or disable i
I was using the phrase "open source" in the early 90s to describe changes in the software world.
How nice, but your meaning did not become common usage. And for words, first-to-invent doesn't count, what matters is what meaning the term acquired when people started using it widely.
Until 1998, there were less than a thousand mentions of "open source" on USENET each year, most of them referring to "open source intelligence" (something completely different). In 1998, there were 17000, That's when the term acquired its meaning.
"free software" could be used without paying for it.
And your point is what? We aren't discussing the term "free software". I stated myself that the term "free software" is confusing. But even there, starting around 1987/88, the term pretty much acquired its present day meaning, meaning specifically what the FSF says it means. The other kind of software, the software that is "free-as-in-beer" is now referred to as "freeware". I don't like this terminology and I gather you don't either (although probably for different reasons), but that's the way the terms are being used today. If you deliberately use them differently, you are either beating your head against the wall or just trying to confuse people.
IBM wrote their own compiler, and there are others. [...] Anyone can write a Java compiler, and can get it approved for some money or tons of public relations.
We aren't talking about "a Java compiler", we are talking about the Java standard, which includes a compiler, a runtime, an binary format, and a huge set of libraries. Other than Sun's, there is no (!) implementation of the Java platform, approved or not, that comes even close to implementing Sun's "specification" correctly. And that's not because Sun Java is such a sophisticated system, it's because Sun's documentation sucks and is full of legal pitfalls.
So Java is a free standard. But Sun controls it, so it is not an open standard.
Java isn't a standard at all, it's a single, widely-used implementation with some vendor hacks and some documentation. Lacking a standards document from a recognized independent standards body, in order for Java to be at least a de-facto standard, there would have to be multiple, independent implementations (which there aren't) and a much more detailed specification that is available without having to agree to Sun's intellectual property restrictions. Neither of those is true.
Will there be an "Open Standards" organization that wants all standards to be open soon? Or is that implied by the "Open Source" movement?
The open standards movement preceded the open source movement by nearly two decades. It was driven by a reaction against dominance of single vendors in markets. Sun used to be a major proponent of open standards--standards that are not controlled by a single company or entity and that anybody can implement freely. The existence of Linux and BSD is one consequence, as is the fact that Sun is still around as a company--they wouldn't have made it without open standards.
In any case, none of this matters anymore. Sun has made a fatal mistake by lying to, and deceiving the Java community, and they will have to live with the consequences. It will still take a few years for it to play out, but Sun is essentially history. Java and many of its APIs will likely continue to live on, but only in the form of another language on the CLR platform.
Excellent point. I would also add that so much high-quality software is available for free it has the effect of devaluing the worth of what programmers do. It's something that a brilliant coder should consider first before giving away their hard work - you have to weigh the advantages with the disadvantages.
Yes: if people do something for little money because they enjoy it or because it benefits them in some other way, it means other people can charge less for the same work.
Welcome to the free market.
Furthermore, our government and laws take a dim view on people colluding to keep prices artificially high--your suggestion is anti free-enterprise and anti-free market.
This is another case of OSS people saying, "I gave my stuff away for free... now it's not fair." To this I say, sorry kids. You gave it away for free. You're not entitled to money or acknowledgement of any kind.
Open source software is not given away "for free" in the sense of "public domain". Legally, open source software is still owned by its authors and enjoys strong copyright protection. The GPL and LGPL is every bit as binding and restrictive as Microsoft's EULA or the most restrictive of Sun's licenses, it is just that their restrictions are different.
As long as Sun does what the "license" says, they don't have to acknowledge squat.
The license requires them to make sure that every single one of their users understands that they are using open source software and where they can get the source. If Sun fails to comply with that part of the license, they may lose all rights to distributing the software in perpetuity--no more Java Desktop at all.
And if you think those legal requirements don't have teeth or consequences for Sun and their executive private jets, think again. Sun is teetering on the brink of irrelevancy anyway and if they have to stop shipping Gnome and Linux because they violated their licenses, it would probably push them over the edge.
Yeah, why should they know, does it really matter, no.
The GPL has a strong political, philosophical, and educational component in it--that's why it contains all that editorializing. It may not matter to you, but it matters to the people who created and own the software. And what counts is the owners of the software who license it to you and Sun.
Sun can put it in there if they want.
It's not a choice--the GPL actually requires them to inform their users. Maybe Sun can weasel their way out of that requirement through legal loopholes, but that doesn't change the fact that the GPL clearly wants them to inform their users.
People companies are using linux for what it's worth. Why do some think that if someone is using linux they must spread the virtures of it and be a sales person for it. Also not having mention fo GNU, or GPL doesn't change what it is. In the end it's the software that matters. If you base how good something is on the if it's GPL or not your pretty much out of it.
None of that is for you to judge. If you (or Sun) don't like the evangelical side of GPL-licensed software, just don't use it. But if you do use GPL-licensed software, people can expect from you that you comply both with the letter and with the spirit of the license.
Does Intel need to show in their end product what brand chairs the engineers at intel sit in? Does GM need to put stickers all over there cars saying what brand steel was used for the fenders?
If the contract under which those products were bought by GM or Intel required them to acknowledge their use in the creation of the final product, yes, they would have to acknowledge it. And sometimes suppliers impose just that requirement: "we give you product X for free if you acknowledge its use in your own product". It's uncommon for chairs and steel, but it is quite common for other products (e.g., cars placed in movies).
That's the deal Sun is getting with GPL'ed software: use it and acknowlege it prominently, and Sun should be expected to comply with it. If Sun didn't want to do that, nobody forced them to use GPL'ed software.
Complying with the letter of the license is sufficient for avoiding lawsuits. But complying with the letter of the license is not a morally sufficient justification to be immune from criticism--for that, you have to comply with the intent of the license. Even if it were sufficient moral justification, it clearly is not sufficient to avoid criticism in practice.
Why does everything have to bow down and act like the GPL is all holy?
Sun should pay the proper respect to the GPL because Sun is building a billion dollar business on top of GPL'ed software. That should mean scrupulous compliance not just with the letter of the GPL but with the intentions and wishes of the creators of the GPL'ed software.
And that software didn't just drop from the sky with a GPL license stamped on it, it is the work of thousands of volunteers, who probably didn't really intend to contribute to a Sun-proprietary product in the way Sun is using their work.
This is another example how how un-free the GPL philosphy is, and why BSD licensing is the best way to go.
So why doesn't Sun just take a BSD-licensed desktop and ship that instead of Gnome? It is Sun that picked GPL-licensed software, GPL-licensed software didn't impose itself on Sun.
Nevermind that Sun has contributed dozens of Engineers and probably a significant sum of money to the Gnome project. (Which last time I checked is open source). Lets also forget the fact that without Sun's money/effort, Gnome Usability (ie. HIG) would be nowhere near as good as it currently is. Sun is a major backer of Gnome, and a corporate contributor to the Gnome Foundation..
Yes, do let us forget all of that. Because, if Sun is really trying to kill open source in the long run, it doesn't matter how much money they invest in it in the short term.
Instead, lets bash Sun for not sufficiently acknowledging it's Linux roots in the JDS. (Something that the GPL does not require)
Yes, let's. Because Sun's attitude has been and continues to be that it takes a proprietary approach and a commercial entity to deliver high quality software. And that belief is fundamentally incompatible with open source.
Sun has made valuable contributions, but they are also doing things I don't like. On balance, I would prefer if Sun would just stop interacting with the open source community altogether--stop giving money/contributing on the one hand, and stop using open source as part of their corporate strategy, products, and PR on the other.
Overall, I don't feel an obligation to be grateful to Sun for things I didn't ask for, and their unwanted contributions certainly don't give them the right to be immune from criticism for things I find highly objectionable.
PAM was pretty much the same situation as Java -- Sun invented something good and released it under a non-free license, and the GNU/Linux people (in this case, it really was the Linux people specifically) reimplemented it. The full quote from that documentation is
The problem is that the GNU/Linux people can't do that with Java. They can't do that for several reasons. First, the Java specification isn't open and free. Second, the Java specification is incomplete and changing so rapidly that people couldn't produce an implementation satisfying Sun's compatibility requirements if they wanted to.
Sun has learned well from Microsoft how to create and maintain a proprietary platform (make it overly complex and keep changing it). Sun's great insight was to add to Microsoft's strategy a web of legal requirements, copyrights, and patents that give them the final say over whether anything even resembling their platform can be released or not, Sun's compatibility requirements.
(As always, Microsoft has never shied away from copying a good idea--hence the.NET patent. But, like many Microsoft cloning attempts, the.NET patent doesn't have the same teeth as the original. Most importantly, the.NET patent doesn't apply to core C#, and even for the parts it applies to, it is unclear whether it matters much. Sun's patents, however apply to some core functionality of Java and they do matter a great deal.)
The term "open source" never changed meaning: it didn't exist prior to the open source movement. The people who created the term have the right to define it.
And the people who created the term aren't "GNU/Minions" anyway, they are the open source movement. The GNU project and the FSF actually don't like open source licenses, they like free ("libre") licenses. Now, the term "free software" is misleading, but not very: "free (libre)" software is also pretty much "free (as in beer)", but it comes with additional rights for the user.
But there has been a nefarious attempt at changing the meaning of the term "open", namely in "open standard". An "open standard" is a standard that anybody can implement without obligation to anyone else. And there, it is Sun that has been trying to change the meaning, in order to mislead people into thinking of their highly proprietary system as an "open system".
The Sun Java implementation is not open source, nor is the Java platform in any way an open standard. The fact that Sun Java is not open source doesn't really matter much, but the fact that the Java platform is not an open standard is a huge problem because it legally threatens any attempt at open source or even commercial alternatives.
[sorry for the near-duplicate; I screwed up on the first posting]
In the eyes of the developer community, they are better than say, Microsoft or even IBM simply because Sun's standards are open, or at the very least more open than the competition.
That is just not true. Sun's standards are among the most proprietary in the industry. If you try to implement the Java APIs, Sun reserves the right to test your implementation for compatibility and reject it if they don't like it. And, realistically, you aren't going to produce an implementation that's going to be sufficiently compatible without using their sources--their specification just isn't detailed enough. That's not an "open standard".
If Sun's use of the term "open standard" were true, then Windows would be even more of an open standard: after all, the Windows APIs are publicly documented, in at least as much detail as Java, and people can implement them freely.
An "open standard" is a standard anybody can implement in whatever way they like, without control or supervision by a company, interest group, or a consortium. Java just does not satisfy that criterion.
In reality, there isn't a Java standard, there is a single Java implementation (Sun Java), its derivatives (Blackdown, IBM, Apple), and its API documentation (the J2SE/J2EE "specifications"). If Java were an open standard, people could implement it without any restrictions (not even compatibility requirements), but compatible and complete third party implementations would exist (no, gcj and kaffe don't count).
I'm not sure how the meaning of Open changed, but it sure seems to have, at least around slashdot, or assorted GNU/Minions.
The term "open source" never changed meaning: it didn't exist prior to the open source movement. The people who created the term have the right to define it.
And the people who created the term aren't "GNU/Minions" anyway, they are the open source movement. The GNU project and the FSF actually don't like open source licenses, they like free ("libre") licenses. Now, the term "free software" is misleading, but not very: "free (libre)" software is also pretty much "free (as in beer)", but it comes with additional rights for the user.
But there has been a nefarious attempt at changing the meaning of the term "open", namely in "open standard". An "open standard" is a standard that anybody can implement without obligation to anyone else. And there, it is Sun that has been trying to change the meaning, in order to mislead people into thinking of their highly proprietary system as an "open system".
The Sun Java implementation is not open source, nor is the Java platform in any way an open standard. The fact that Sun Java is not open source doesn't really matter much, but the fact that the Java platform is not an open standard is a huge problem because it legally threatens any attempt at open source or even commercial alternatives.
You can look at the source code for Microsoft Windows as well. Whether you look at the sources for Java (don't) or Windows, you have to enter into complex legal agreements with its respective owner, agreements that impose conditions on you that many people don't want to accept.
The fact that with Sun Java, you agree to those conditions merely by downloading their sources makes it worse, not better, since many people end up being duped into accepting conditions they probably wouldn't accept if they thought about what they mean.
however, [manual storage management] can be more efficient in many ways if properly handled. This discrepancy in efficiency has slowed the widespread adoption of the automated approach.
There hasn't been a "discrepancy in efficiency". Good garbage collectors have been comparable to, or better than, manual storage allocators for decades.
The perception of a "discrepancy in efficiency" has several causes:
Garbage collection allows programmers to get sloppy about storage managmentt: if a non-GC program gets sloppy about storage management, it crashes, if a non-GC program gets sloppy about storage management, it just runs slowly. Unfortunately, as a result, many core libraries in garbage collected languages are pretty sloppily written and slow--the fault is with the libraries, not with garbage collection.
Garbage collection allows language implementors to make different design decisions. Many garbage collected languages will do memory allocation every time you use a floating point number. Imagine how slow C would be if you called "malloc" for every floating point number.
Garbage collection often bundles memory management overhead into single chunks of time, while manual storage allocators don't. Furthermore, garbage collector implementations really rub your nose in it, printing messages like "[starting garbage collection... done]". But doing a lot of storage management at once is usually more efficient overall--in aggregate, manual storage managers spend more time, they just diffuse it out. However, both kinds of behaviors exist with both storage managers, and you can pick and choose.
The article is right that garbage collection is a good choice today. It is wrong in that it has pretty much always been a good choice. Garbage collection could have been widely adopted in the 1970's or 1980's, and we would have saved ourselves a lot of headaches and troubles without any loss in efficiency.
Yeah, just about any car on the road, for most commonly used definitions of "better". For example, a Civic is cheaper to buy, cheaper to insure, cheaper to maintain, easier to drive, quieter, rides better, more comfortable, has more cargo space, and has better gas mileage.
I definitely disagree. Check out DP Review's review of the Sigma SD10 [dpreview.com] which uses the Foveon sensor. You'll see images from the Foveon sensor that have been upsampled to match those of a Canon dSLR. The Canon does appear to resolve a bit more detail, but remember that the Sigma's images have been "digitally zoomed" from 3.4 MP to 6.3MP.
You say that as if there was something wrong with upsampling for comparison. But upsampling the Foveon images is exactly the way to compare the Foveon images to the Bayer ones. And, as you observe, the Canon SLR resolves more detail. That's the point and that's all there is to it. Well, not quite, actually: the Canon SLR may well use pretty conservative image processing and anti-aliasing--if you want a bit more resolution, you may well be able to make more aggressive tradeoffs with it (by processing the raw images) than is possible with the Foveon sensor.
It's not a huge difference but it is one that some people will appreciate.
You are just comparing two cameras and you are not looking at cost/benefit. Basically, there is little evidence that the engineering tradeoff the Fuji makes is a good one.
His argument is that Microsoft Word won because it was the "best" word processor because Microsoft has listened so carefully to its customers. There are several things wrong with that argument.
First, it is naive to think that there is a single "best" piece of software for everybody. Is there a single "best" car? A single "best" phone company? A single "best" suit of clothes? A single best food? They tried the one-size-fits-all in the planned economies of Russia and China, and you know how well that worked. It seems naive to think that there is any single word processor that works well for 90% of the people.
Second, the quality differences are irrelevant to most people. Lotus Smartsuite, StarOffice, WordPerfect, etc. were almost certainly all good enough for at least 90% of all users. But the fact is that no amount of lowering the prices of those other products made them competitive.
Today, people buy Microsoft Word even though they can get OpenOffice for free. Why? It's not because Microsoft Word has more buttons or more features, it is because the only way people can be sure that they can read Microsoft Word documents is by buying Microsoft Word. Microsoft Word may also happen to be a well-engineered word processor, but the need to read Word's proprietary format was the thing that assured Microsoft Word adoption half a dozen years ago, and it still is.
The codec (H.263) isn't tied into the server - the buddy system is. However, iChat is very capable of video conferencing over a local area network
I didn't mention iChat, but since you brought it up...
If this port wanted to, it could provide support for zeroconf and thereby allow compatibility with iChat clients over Rendezvous.
Using mDNS service discovery for iChat is a gimmick of no big practical significance--if you are on the same subnet, you can usually just walk over. But I suspect GnomeMeeting (not GAIM) will support this anyway at some point.
The real question is why iChat doesn't let you connect host-to-host across the Internet (at least I could never find a way). Given that they have Rendezvous-based connections for iChat, that would be trivial. If they did support that, iChat users could easily talk to GnomeMeeting users, as well as each other, anywhere in the world already, without signing up with anybody. The reason Apple doesn't enable that functionality is probably that Apple, like AOL and Yahoo!, like to keep this audience captive, but Apple has even less of a technical excuse.
Fortunately, open, free, non-proprietary video conferencing solutions without such arbitrary restrictions have been ported to MacOS as well.
The images produced from a DSLR are generally deeper, with superior dynamic range, color depth and detail resolved (albeit smaller numerical resolution).
Right as far as dynamic range and noise are concerned. Wrong as far as "detail resolved" is concerned. A small 8 Mpixel sensor, given sufficient light, will resolve more detail than even the largest 4 Mpixel sensor. Furthermore, in particular for digital SLR sensors, you are better off taking the higher resolution and smaller pixels and removing noise in software than to limit yourself by an otherwise equivalent lower resolution sensor.
Thankfully, some manufacturers have moved beyond pushing megapixels. Cameras that utilize Foveon's X3 sensor produce smaller images, but they are much sharper, as red, blue and green color channels are captured in every photosite, as opposed to the more standard use of Bayer interpolation.
]Foveon's images have not lived up to the hype in tests, and there is no reason to believe that they would. The Foveon sensor really does have 1/4 the spatial resolution of a regular CCD sensor. In return, it avoids some color artifacts and requires a bit less post-processing. But that turns out not to be a very good tradeoff.
Fujifilm is also taking things up a notch by adding a set of photosites just for the purpose of improving dynamic range with their SuperCCD IV SR sensors.
That was a nice idea. It's too bad that it makes very little difference in practice.
Basically, the same kind of people that used to endlessly tout the virtues of film and vinyl records are now out in force making similarly silly arguments about digital cameras.
Yes, you should remember that higher resolution does not guarantee better quality: a lot of factors need to come together. But high resolution also isn't intrinsically bad and low resolution is no guarantee of lower image noise either. Furthermore, companies like Foveon and Fuji are guilty of using inflated pixel counts to make up for what are actually low actual resolution in their cameras compared to similarly priced models--generally, their cameras are just not good deals.
If you want to know how well a camera works, the only way to do it is to look at tests and at real images. And within each market segment, both resolution and quality keep going up, and that is no accident.
And the reason why people want higher resolutions is no accident either: it permits cropping, image processing, big enlargements, and gives people far more flexibility for post-processing. And we can go way beyond 8 or 14 Mpixels before people's thirst for additional resolution will be satisfied.
Slashdot Mirror
About Java: There is a "standard" called Java. It is controlled by Sun. If Java was not a standard, then Sun could not have convinced MS to pay for corrupting it.
There is no legal penalty for "corrupting a standard", so Sun cannot have used that as an argument against Microsoft.
In fact, Sun sued Microsoft for contractual violations. And the contract was about something that Sun owned and that Microsoft damaged: Java. What that shows is that Java is proprietary to Sun. If it weren't proprietary to Sun, then Sun couldn't have claimed to have been injured by Microsoft's actions.
I think you are using the word "standard" to imply "open standards". That seems silly after your insistence that we use words correctly. "Big Macs" are a standard. If you want to call food a "Big Mac", you need to satisfy the trademark holder. If you can make it different, then call it "J++".
The word "standard" can have many meanings, so multiple usages can be correct. Yes, Java is a "standard" in the sense of being a popular (if proprietary) product. But that's not what I was referring to.
I was using the term in the sense of "a specification for a system that permits independent implementation". What I was really saying is that even if we accept Sun's interpretation of the term "open", Java still fails to be an "open standard" because its definition is simply technically not precise enough to be an "open standard".
[Sun has made a fatal mistake by lying to, and deceiving the Java community] I missed this. Could you elaborate?
During the first several years of Java's existence, Sun kept promising to submit Java to an open standards body. That promise mattered a great deal because without it, companies like IBM wouldn't have adopted it and Java would have died quickly and probably been replaced by an open source system for running applets right away (which were all the rage back then). But after several years of dithering, Sun pulled out of both ISO and ECMA standardization and instead chose to make Java into what it is today.
This patent is on long button presses on "limited power computing devices". Are you saying your Mac qualifies? :-)
The api is the spec
Sun's API documentation is just API documentation. It contains almost no actual specification of the semantics. Programmers just call what sounds reasonable and then adapt their code to the behavior they actually get. The only way to clone Java would be to perform extensive experimentation on Sun's actual Java implementation.
The specification is there for everyone to see.
You can see the official API docs but only if you agree to Sun's license terms. Furthermore, whether you can see the API docs or not doesn't matter much because Sun also has lots of patents on Java.
So pick a version and implement it.
How am I supposed to pass Sun's compatibility suite if I do that?
You might not be able to call it java when you are done, but what is the difference?
You won't get done; the process that Sun has created ensures that.
Publically documented? No they aren't,
Yes, they are. Check MSDN. Microsoft has extensive published API documentation.
that's one of the reasons why the EU sued Microsoft - so they would publish APIs and protocols.
The EU sued Microsoft over internal APIs and internal protocols. Sun Java is also full of those.
IBM, apple etc are full java implementations, not derivatives.
No, they are not. They depend on huge amounts of Sun-licensed source code, and they have "SUN PROPRIETARY/CONFIDENTIAL" notices all over them.
And you can implement Java without restrictions. However, if you want to call the result 'Java' you must be compatible, otherwise what is the point?
No, that is false. Even if you don't call the result "Java", you violate Sun's intellectual property rights (mostly patents, but also licenses on their specifications) if you implement Java. Sun may not assert those rights (they have left gcj and kaffe alone, for now), but that doesn't change that they could.
And yes, gcj and kaffe DO count. gcj can run IBM's eclipse IDE - that's impressive and useful.
Very little code written for Sun Java runs on kaffe or gcj. If you count kaffe and gcj as "Java", then Java is one of the worst languages for cross-platform programming and some of its implementations have some of the most incomplete libraries of any popular platform. On the other hand, if you don't count those kinds of implementations, then Java just has a single, proprietary implementation, Sun's, and its proprietary derivatives. You can't have it both ways.
Following is the piece from the GPL that says that the license has to be conspicuous, but it doesn't say that each user has to understand what they're using.
/i>
You are mincing words and retreating from your own statement. It is obvious that Sun can't actually go into people's brains and ensure understanding. But they are responsible, as you yourself point out, for a conspicuous display, which is intended to achieve that understanding for anybody who would care about.
They can bury it in a clickthrough license area, and they'd be fine.
Whether they are legally "fine", I don't know; I would guess that if it's "buried", it's not "conspicuous".
But the community isn't getting upset about a legal issue, it is getting upset about Sun's behavior.
That's my point. It's too bad if the "community" feels that they're not playing nice. They're just following the GPL, and if the GPL isn't clear enough, that's the developers' problem for using it in the first place.
Don't fear: because of the behavior of companies like Sun, the GPL will probably be clarified. Then Sun can keep shipping whatever they are shipping, but if they want anything later, they have to comply with the clarified terms.
I knew this was going to happen years ago. I knew that the OSS movement, once companies started really exploiting their code and making tons of money on it, would be upset that they were getting the short end of the stick, when in reality, it was their own short sightedness that led to this in the first place.
What upsets people is not that Sun is making money off GPL'ed software, what upsets people is that Sun is arguably violating the spirit and intent of the GPL. The intent of the GPL is clearly to promote the use of free (libre) software. It states as much.
Nobody held a gun to their heads requiring them to program for free.
What makes you think people program "for free"? I have gotten paid very well for the free software I have developed.
What about real-time constraints?
What about them? Real-time garbage collectors give you guaranteed real-time responses.
I suspect that you have actually never used a real-time storage allocator of any form. The memory allocators that ship with major C/C++ compilers certainly make no real-time guarantees. The way people usually get real-time performance out of them is by pre-allocating large chunks of memory. Well, you can do in garbage collected languages as well.
GC are generally non-deterministic (they start and finish according to their own rules),
No, they don't. Just like with malloc implementations, their behavior may differ from implementation to implementation, but it is generally pretty well understood. It can usually also be controlled well.
Simple garbage collectors only will start a garbage collection when you ask for a block of memory and it can't satisfy the request; they don't just start up for no reason at all. Parallel garbage collector may run a thread in parallel to the main program but never stopping it. Incremental collectors do a little bit of work each time you allocate. Real-time collectors guarantee well-defined maximum responses for allocation.
If the garbage collector in your language (Java?) doesn't do what you want, it's not a problem with garbage collection in general, it's a problem with the specific implementation your vendor has chosen to give you. Just like there are mediocre or bad malloc implementations, there are mediocre or bad garbage collectors.
How about one of the earlier comments to the effect that mark-and-sweep type algorithms page-faults all the memory used by an application? That has got to be inefficient, and since virtual memory is not under the control of the application by definition there is nothing that can be done, except if the GC is directly under the control of the OS, which doesn't often makes sense (it's not very flexible then).
Well, that comment is wrong. First of all, you don't have to use a mark-and-sweep collector. Most high-performance collectors are, in fact, generational and are very VM friendly (moreso than malloc/free in many cases). Second, operating systems have interfaces to their VM subsystems, so the GC can, in fact, control what is happening with paging--prefetching pages, etc. And they do. Even 20 years ago, Berkeley UNIX had system calls specifically designed to let Franz Lisp let the kernel know what it was doing. Third, a malloc implementation cannot move pointers around to make accesses more local or sequential--good garbage collectors do, so GC is actually superior in that regard.
The article itself says that there is no way to make a GC perform as well or better as a finely tuned hand-micro-managed in every case.
You can "micro-manage" and "fine tune" in the presence of a GC as much as you can in its absence. But in the presence of GC, you have the freedom to be sloppy and your code will still run--so many people don't bother. In C/C++, you don't have a choice.
In languages that don't have GCs you can add one yourself (Bohm's GC works fine for C/C++, and is in fact used for GCJ, the GNU implementation of the Java language), with the benefit that you can turn it off if you don't want it for some reason, something you can't do in Java for example.
No, that is backwards. In languages without GC, you cannot add a GC and get all the benefits from the GC. Boehm's GC, for example, may retain arbitrary amounts of garbage, and its lack of integration with the language and compiler means that it can't be anywhere near as efficient as an integrated GC. Boehm's GC is a great hack, and it work really well, but it is not something you can ultimately rely on. Furthermore, if you add Boehm's GC to a language without GC, you are still left with an unsafe programming language.
Secondly, languages with garbage collection often give you full control over the GC: you can enable it or disable i
I was using the phrase "open source" in the early 90s to describe changes in the software world.
How nice, but your meaning did not become common usage. And for words, first-to-invent doesn't count, what matters is what meaning the term acquired when people started using it widely.
Until 1998, there were less than a thousand mentions of "open source" on USENET each year, most of them referring to "open source intelligence" (something completely different). In 1998, there were 17000, That's when the term acquired its meaning.
"free software" could be used without paying for it.
And your point is what? We aren't discussing the term "free software". I stated myself that the term "free software" is confusing. But even there, starting around 1987/88, the term pretty much acquired its present day meaning, meaning specifically what the FSF says it means. The other kind of software, the software that is "free-as-in-beer" is now referred to as "freeware". I don't like this terminology and I gather you don't either (although probably for different reasons), but that's the way the terms are being used today. If you deliberately use them differently, you are either beating your head against the wall or just trying to confuse people.
IBM wrote their own compiler, and there are others. [...] Anyone can write a Java compiler, and can get it approved for some money or tons of public relations.
We aren't talking about "a Java compiler", we are talking about the Java standard, which includes a compiler, a runtime, an binary format, and a huge set of libraries. Other than Sun's, there is no (!) implementation of the Java platform, approved or not, that comes even close to implementing Sun's "specification" correctly. And that's not because Sun Java is such a sophisticated system, it's because Sun's documentation sucks and is full of legal pitfalls.
So Java is a free standard. But Sun controls it, so it is not an open standard.
Java isn't a standard at all, it's a single, widely-used implementation with some vendor hacks and some documentation. Lacking a standards document from a recognized independent standards body, in order for Java to be at least a de-facto standard, there would have to be multiple, independent implementations (which there aren't) and a much more detailed specification that is available without having to agree to Sun's intellectual property restrictions. Neither of those is true.
Will there be an "Open Standards" organization that wants all standards to be open soon? Or is that implied by the "Open Source" movement?
The open standards movement preceded the open source movement by nearly two decades. It was driven by a reaction against dominance of single vendors in markets. Sun used to be a major proponent of open standards--standards that are not controlled by a single company or entity and that anybody can implement freely. The existence of Linux and BSD is one consequence, as is the fact that Sun is still around as a company--they wouldn't have made it without open standards.
In any case, none of this matters anymore. Sun has made a fatal mistake by lying to, and deceiving the Java community, and they will have to live with the consequences. It will still take a few years for it to play out, but Sun is essentially history. Java and many of its APIs will likely continue to live on, but only in the form of another language on the CLR platform.
Excellent point. I would also add that so much high-quality software is available for free it has the effect of devaluing the worth of what programmers do. It's something that a brilliant coder should consider first before giving away their hard work - you have to weigh the advantages with the disadvantages.
Yes: if people do something for little money because they enjoy it or because it benefits them in some other way, it means other people can charge less for the same work.
Welcome to the free market.
Furthermore, our government and laws take a dim view on people colluding to keep prices artificially high--your suggestion is anti free-enterprise and anti-free market.
This is another case of OSS people saying, "I gave my stuff away for free... now it's not fair." To this I say, sorry kids. You gave it away for free. You're not entitled to money or acknowledgement of any kind.
Open source software is not given away "for free" in the sense of "public domain". Legally, open source software is still owned by its authors and enjoys strong copyright protection. The GPL and LGPL is every bit as binding and restrictive as Microsoft's EULA or the most restrictive of Sun's licenses, it is just that their restrictions are different.
As long as Sun does what the "license" says, they don't have to acknowledge squat.
The license requires them to make sure that every single one of their users understands that they are using open source software and where they can get the source. If Sun fails to comply with that part of the license, they may lose all rights to distributing the software in perpetuity--no more Java Desktop at all.
And if you think those legal requirements don't have teeth or consequences for Sun and their executive private jets, think again. Sun is teetering on the brink of irrelevancy anyway and if they have to stop shipping Gnome and Linux because they violated their licenses, it would probably push them over the edge.
Yeah, why should they know, does it really matter, no.
The GPL has a strong political, philosophical, and educational component in it--that's why it contains all that editorializing. It may not matter to you, but it matters to the people who created and own the software. And what counts is the owners of the software who license it to you and Sun.
Sun can put it in there if they want.
It's not a choice--the GPL actually requires them to inform their users. Maybe Sun can weasel their way out of that requirement through legal loopholes, but that doesn't change the fact that the GPL clearly wants them to inform their users.
People companies are using linux for what it's worth. Why do some think that if someone is using linux they must spread the virtures of it and be a sales person for it. Also not having mention fo GNU, or GPL doesn't change what it is. In the end it's the software that matters. If you base how good something is on the if it's GPL or not your pretty much out of it.
None of that is for you to judge. If you (or Sun) don't like the evangelical side of GPL-licensed software, just don't use it. But if you do use GPL-licensed software, people can expect from you that you comply both with the letter and with the spirit of the license.
Does Intel need to show in their end product what brand chairs the engineers at intel sit in? Does GM need to put stickers all over there cars saying what brand steel was used for the fenders?
If the contract under which those products were bought by GM or Intel required them to acknowledge their use in the creation of the final product, yes, they would have to acknowledge it. And sometimes suppliers impose just that requirement: "we give you product X for free if you acknowledge its use in your own product". It's uncommon for chairs and steel, but it is quite common for other products (e.g., cars placed in movies).
That's the deal Sun is getting with GPL'ed software: use it and acknowlege it prominently, and Sun should be expected to comply with it. If Sun didn't want to do that, nobody forced them to use GPL'ed software.
As long as it complies, it's fine.
Complying with the letter of the license is sufficient for avoiding lawsuits. But complying with the letter of the license is not a morally sufficient justification to be immune from criticism--for that, you have to comply with the intent of the license. Even if it were sufficient moral justification, it clearly is not sufficient to avoid criticism in practice.
Why does everything have to bow down and act like the GPL is all holy?
Sun should pay the proper respect to the GPL because Sun is building a billion dollar business on top of GPL'ed software. That should mean scrupulous compliance not just with the letter of the GPL but with the intentions and wishes of the creators of the GPL'ed software.
And that software didn't just drop from the sky with a GPL license stamped on it, it is the work of thousands of volunteers, who probably didn't really intend to contribute to a Sun-proprietary product in the way Sun is using their work.
This is another example how how un-free the GPL philosphy is, and why BSD licensing is the best way to go.
So why doesn't Sun just take a BSD-licensed desktop and ship that instead of Gnome? It is Sun that picked GPL-licensed software, GPL-licensed software didn't impose itself on Sun.
Nevermind that Sun has contributed dozens of Engineers and probably a significant sum of money to the Gnome project. (Which last time I checked is open source). Lets also forget the fact that without Sun's money/effort, Gnome Usability (ie. HIG) would be nowhere near as good as it currently is. Sun is a major backer of Gnome, and a corporate contributor to the Gnome Foundation..
Yes, do let us forget all of that. Because, if Sun is really trying to kill open source in the long run, it doesn't matter how much money they invest in it in the short term.
Instead, lets bash Sun for not sufficiently acknowledging it's Linux roots in the JDS. (Something that the GPL does not require)
Yes, let's. Because Sun's attitude has been and continues to be that it takes a proprietary approach and a commercial entity to deliver high quality software. And that belief is fundamentally incompatible with open source.
Sun has made valuable contributions, but they are also doing things I don't like. On balance, I would prefer if Sun would just stop interacting with the open source community altogether--stop giving money/contributing on the one hand, and stop using open source as part of their corporate strategy, products, and PR on the other.
Overall, I don't feel an obligation to be grateful to Sun for things I didn't ask for, and their unwanted contributions certainly don't give them the right to be immune from criticism for things I find highly objectionable.
PAM was pretty much the same situation as Java -- Sun invented something good and released it under a non-free license, and the GNU/Linux people (in this case, it really was the Linux people specifically) reimplemented it. The full quote from that documentation is
.NET patent. But, like many Microsoft cloning attempts, the .NET patent doesn't have the same teeth as the original. Most importantly, the .NET patent doesn't apply to core C#, and even for the parts it applies to, it is unclear whether it matters much. Sun's patents, however apply to some core functionality of Java and they do matter a great deal.)
The problem is that the GNU/Linux people can't do that with Java. They can't do that for several reasons. First, the Java specification isn't open and free. Second, the Java specification is incomplete and changing so rapidly that people couldn't produce an implementation satisfying Sun's compatibility requirements if they wanted to.
Sun has learned well from Microsoft how to create and maintain a proprietary platform (make it overly complex and keep changing it). Sun's great insight was to add to Microsoft's strategy a web of legal requirements, copyrights, and patents that give them the final say over whether anything even resembling their platform can be released or not, Sun's compatibility requirements.
(As always, Microsoft has never shied away from copying a good idea--hence the
The term "open source" never changed meaning: it didn't exist prior to the open source movement. The people who created the term have the right to define it.
And the people who created the term aren't "GNU/Minions" anyway, they are the open source movement. The GNU project and the FSF actually don't like open source licenses, they like free ("libre") licenses. Now, the term "free software" is misleading, but not very: "free (libre)" software is also pretty much "free (as in beer)", but it comes with additional rights for the user.
But there has been a nefarious attempt at changing the meaning of the term "open", namely in "open standard". An "open standard" is a standard that anybody can implement without obligation to anyone else. And there, it is Sun that has been trying to change the meaning, in order to mislead people into thinking of their highly proprietary system as an "open system".
The Sun Java implementation is not open source, nor is the Java platform in any way an open standard. The fact that Sun Java is not open source doesn't really matter much, but the fact that the Java platform is not an open standard is a huge problem because it legally threatens any attempt at open source or even commercial alternatives.
[sorry for the near-duplicate; I screwed up on the first posting]
In the eyes of the developer community, they are better than say, Microsoft or even IBM simply because Sun's standards are open, or at the very least more open than the competition.
That is just not true. Sun's standards are among the most proprietary in the industry. If you try to implement the Java APIs, Sun reserves the right to test your implementation for compatibility and reject it if they don't like it. And, realistically, you aren't going to produce an implementation that's going to be sufficiently compatible without using their sources--their specification just isn't detailed enough. That's not an "open standard".
If Sun's use of the term "open standard" were true, then Windows would be even more of an open standard: after all, the Windows APIs are publicly documented, in at least as much detail as Java, and people can implement them freely.
An "open standard" is a standard anybody can implement in whatever way they like, without control or supervision by a company, interest group, or a consortium. Java just does not satisfy that criterion.
In reality, there isn't a Java standard, there is a single Java implementation (Sun Java), its derivatives (Blackdown, IBM, Apple), and its API documentation (the J2SE/J2EE "specifications"). If Java were an open standard, people could implement it without any restrictions (not even compatibility requirements), but compatible and complete third party implementations would exist (no, gcj and kaffe don't count).
I'm not sure how the meaning of Open changed, but it sure seems to have, at least around slashdot, or assorted GNU/Minions.
The term "open source" never changed meaning: it didn't exist prior to the open source movement. The people who created the term have the right to define it.
And the people who created the term aren't "GNU/Minions" anyway, they are the open source movement. The GNU project and the FSF actually don't like open source licenses, they like free ("libre") licenses. Now, the term "free software" is misleading, but not very: "free (libre)" software is also pretty much "free (as in beer)", but it comes with additional rights for the user.
But there has been a nefarious attempt at changing the meaning of the term "open", namely in "open standard". An "open standard" is a standard that anybody can implement without obligation to anyone else. And there, it is Sun that has been trying to change the meaning, in order to mislead people into thinking of their highly proprietary system as an "open system".
The Sun Java implementation is not open source, nor is the Java platform in any way an open standard. The fact that Sun Java is not open source doesn't really matter much, but the fact that the Java platform is not an open standard is a huge problem because it legally threatens any attempt at open source or even commercial alternatives.
You can look at the source code for Microsoft Windows as well. Whether you look at the sources for Java (don't) or Windows, you have to enter into complex legal agreements with its respective owner, agreements that impose conditions on you that many people don't want to accept.
The fact that with Sun Java, you agree to those conditions merely by downloading their sources makes it worse, not better, since many people end up being duped into accepting conditions they probably wouldn't accept if they thought about what they mean.
There hasn't been a "discrepancy in efficiency". Good garbage collectors have been comparable to, or better than, manual storage allocators for decades.
The perception of a "discrepancy in efficiency" has several causes:
- Garbage collection allows programmers to get sloppy about storage managmentt: if a non-GC program gets sloppy about storage management, it crashes, if a non-GC program gets sloppy about storage management, it just runs slowly. Unfortunately, as a result, many core libraries in garbage collected languages are pretty sloppily written and slow--the fault is with the libraries, not with garbage collection.
- Garbage collection allows language implementors to make different design decisions. Many garbage collected languages will do memory allocation every time you use a floating point number. Imagine how slow C would be if you called "malloc" for every floating point number.
- Garbage collection often bundles memory management overhead into single chunks of time, while manual storage allocators don't. Furthermore, garbage collector implementations really rub your nose in it, printing messages like "[starting garbage collection... done]". But doing a lot of storage management at once is usually more efficient overall--in aggregate, manual storage managers spend more time, they just diffuse it out. However, both kinds of behaviors exist with both storage managers, and you can pick and choose.
The article is right that garbage collection is a good choice today. It is wrong in that it has pretty much always been a good choice. Garbage collection could have been widely adopted in the 1970's or 1980's, and we would have saved ourselves a lot of headaches and troubles without any loss in efficiency."Are there any cars better than this?"
Yeah, just about any car on the road, for most commonly used definitions of "better". For example, a Civic is cheaper to buy, cheaper to insure, cheaper to maintain, easier to drive, quieter, rides better, more comfortable, has more cargo space, and has better gas mileage.
I definitely disagree. Check out DP Review's review of the Sigma SD10 [dpreview.com] which uses the Foveon sensor. You'll see images from the Foveon sensor that have been upsampled to match those of a Canon dSLR. The Canon does appear to resolve a bit more detail, but remember that the Sigma's images have been "digitally zoomed" from 3.4 MP to 6.3MP.
You say that as if there was something wrong with upsampling for comparison. But upsampling the Foveon images is exactly the way to compare the Foveon images to the Bayer ones. And, as you observe, the Canon SLR resolves more detail. That's the point and that's all there is to it. Well, not quite, actually: the Canon SLR may well use pretty conservative image processing and anti-aliasing--if you want a bit more resolution, you may well be able to make more aggressive tradeoffs with it (by processing the raw images) than is possible with the Foveon sensor.
It's not a huge difference but it is one that some people will appreciate.
You are just comparing two cameras and you are not looking at cost/benefit. Basically, there is little evidence that the engineering tradeoff the Fuji makes is a good one.
His argument is that Microsoft Word won because it was the "best" word processor because Microsoft has listened so carefully to its customers. There are several things wrong with that argument.
First, it is naive to think that there is a single "best" piece of software for everybody. Is there a single "best" car? A single "best" phone company? A single "best" suit of clothes? A single best food? They tried the one-size-fits-all in the planned economies of Russia and China, and you know how well that worked. It seems naive to think that there is any single word processor that works well for 90% of the people.
Second, the quality differences are irrelevant to most people. Lotus Smartsuite, StarOffice, WordPerfect, etc. were almost certainly all good enough for at least 90% of all users. But the fact is that no amount of lowering the prices of those other products made them competitive.
Today, people buy Microsoft Word even though they can get OpenOffice for free. Why? It's not because Microsoft Word has more buttons or more features, it is because the only way people can be sure that they can read Microsoft Word documents is by buying Microsoft Word. Microsoft Word may also happen to be a well-engineered word processor, but the need to read Word's proprietary format was the thing that assured Microsoft Word adoption half a dozen years ago, and it still is.
With the impending release of Valve's Half-Life 2 and id's Doom 3
I wouldn't hold my breath--it's probably less "impending" than the author thinks.
The codec (H.263) isn't tied into the server - the buddy system is. However, iChat is very capable of video conferencing over a local area network
I didn't mention iChat, but since you brought it up...
If this port wanted to, it could provide support for zeroconf and thereby allow compatibility with iChat clients over Rendezvous.
Using mDNS service discovery for iChat is a gimmick of no big practical significance--if you are on the same subnet, you can usually just walk over. But I suspect GnomeMeeting (not GAIM) will support this anyway at some point.
The real question is why iChat doesn't let you connect host-to-host across the Internet (at least I could never find a way). Given that they have Rendezvous-based connections for iChat, that would be trivial. If they did support that, iChat users could easily talk to GnomeMeeting users, as well as each other, anywhere in the world already, without signing up with anybody. The reason Apple doesn't enable that functionality is probably that Apple, like AOL and Yahoo!, like to keep this audience captive, but Apple has even less of a technical excuse.
Fortunately, open, free, non-proprietary video conferencing solutions without such arbitrary restrictions have been ported to MacOS as well.
Actually, most of them use SIP in a peer to peer fashion. There's no server dependancy with SIP.
Oh? So, how do I use AIM to do peer-to-peer video conferencing, completely separate from any AOL servers?
As I was saying, they are tied into a proprietary server infrastructure; that doesn't mean that every packet goes through the server.
The images produced from a DSLR are generally deeper, with superior dynamic range, color depth and detail resolved (albeit smaller numerical resolution).
Right as far as dynamic range and noise are concerned. Wrong as far as "detail resolved" is concerned. A small 8 Mpixel sensor, given sufficient light, will resolve more detail than even the largest 4 Mpixel sensor. Furthermore, in particular for digital SLR sensors, you are better off taking the higher resolution and smaller pixels and removing noise in software than to limit yourself by an otherwise equivalent lower resolution sensor.
Thankfully, some manufacturers have moved beyond pushing megapixels. Cameras that utilize Foveon's X3 sensor produce smaller images, but they are much sharper, as red, blue and green color channels are captured in every photosite, as opposed to the more standard use of Bayer interpolation.
]Foveon's images have not lived up to the hype in tests, and there is no reason to believe that they would. The Foveon sensor really does have 1/4 the spatial resolution of a regular CCD sensor. In return, it avoids some color artifacts and requires a bit less post-processing. But that turns out not to be a very good tradeoff.
Fujifilm is also taking things up a notch by adding a set of photosites just for the purpose of improving dynamic range with their SuperCCD IV SR sensors.
That was a nice idea. It's too bad that it makes very little difference in practice.
Basically, the same kind of people that used to endlessly tout the virtues of film and vinyl records are now out in force making similarly silly arguments about digital cameras.
Yes, you should remember that higher resolution does not guarantee better quality: a lot of factors need to come together. But high resolution also isn't intrinsically bad and low resolution is no guarantee of lower image noise either. Furthermore, companies like Foveon and Fuji are guilty of using inflated pixel counts to make up for what are actually low actual resolution in their cameras compared to similarly priced models--generally, their cameras are just not good deals.
If you want to know how well a camera works, the only way to do it is to look at tests and at real images. And within each market segment, both resolution and quality keep going up, and that is no accident.
And the reason why people want higher resolutions is no accident either: it permits cropping, image processing, big enlargements, and gives people far more flexibility for post-processing. And we can go way beyond 8 or 14 Mpixels before people's thirst for additional resolution will be satisfied.