Unless you want access to any of the miriad of Java libraries that are available,
No, I don't.
Python might be king of quick hacks, but for a large-scale project where bits of scripting code might be appropriate, this sounds like an excelent option where you would NOT be better off with python.
There are plenty of scripting languages for that. Jython and JavaScript have both C and JVM-based implementations. Beanshell is small and integrates particularly well with Java. I really don't see why we need Groovy.
Except [Groovy] actually elegant, based on Smalltalk, not whatever the heck Python is inspired by.
I don't see anything "elegant" about yet another scripting language built on top of a runtime designed for a simple statically typed language (Java).
And Python reference counting stinks,
True. It also makes the C-Python interpreter slower than a garbage collected version. It is somewhat disconcerting that this misfeature of C-Python still exists after so many years. In fact, the C-Python implementation has a number of other weak points. But it works well enough, and it sure is a lot more practical than running a JVM just to execute Groovy.
I use Python, but I sure don't think there's anything "great" about it,
Neither do I--Python is just one of many scripting languages. But between Python and the available alternatives, I think Python still is the best of the bunch. A JVM-only language like Groovy isn't even worth talking about.
and has a bigger memory footprint (because it uses JVM garbage collection instead of Python reference-counting),
Java does have a bigger footprint than Python, but that is unrelated to whether it uses garbage collection or reference counting. IMO, Python is a nicer language than Java, but the use of reference counting in Python actually makes it both slower and more bloated than a garbage collected implementation of Python would be.
This news item sounds like a troll from one of those people who like to make fun of people concerned about the use of nuclear power in space.
Let's get this straight:
A leak from a nuclear-powered probe to Europa would obviously not be capable of "wiping out" life on Europa' a few pounds of plutonium in Europa's ocean would have at most a local effect; more likely, they'd just sink to the bottom.
There is, however, a huge risk of contamination of Europa by a probe: biological contamination. Biological contamination is the reason why we should plan the exploration of Europa carefully, and possibly put it off for a few decades until we can be absolutely sure that we know how to avoid biological contamination.
Nuclear contamination of other planets is not a reason for people to have concerns over widespread use of nuclear power in space; however, there are plenty of other reasons to be concerned about sending radioactive or fissionable materials into space.
Groovy seems to offer nothing that you don't already get in Python, and Python has implementations available based on C (C Python), Java/JVM (Jython), and C#/CLR (IronPython).
The only thing Groovy does offer is that it is Java/JVM-specific at this point--there are no implementations based on anything other than the Java/JVM runtime. That may be a good thing for Sun--tying people even more to Sun's platform--but it sure isn't good for anybody else.
Real companies have heterogeneous server environments.
Of course, real companies have heterogeneous server environments. But real companies generally don't run the same application on multiple platforms. They run heterogeneous environments because, say, they want to run Oracle on a Sun Enterprise server, Apache on a BSD box, legacy code on a mainframe, and some middleware on a bunch of Windows machines.
In any case, even if a company were foolish enough to run the same code on multiple different platforms, they would still be better off with C++ code compiled specifically for each platform. For example, they can buy and install Oracle for both Windows and Solaris.
Real web apps don't need desktop integration; they are accessed from the browser.
Real server apps benefit from local GUIs for configuration and management. They also benefit from tight integration with local management APIs and GUIs.
I'm not sure what limitations you are referring to when it comes to cross-platform.
With Java? Installers, integration with service managers, integration with package managers, integration with system management APIs and tools, access to memory mapped I/O, raw device access, etc. Java falls short on all of those, and many more.
Access to these components is streamlined by standard Java libraries and implemented universally by Application Servers.
To the degree that Java even provides this kind of functionality, it provides it in a way that is incompatible with the platform it runs in. Sorry, that isn't cross-platform support, it's a strategy by Sun to replace other people's platforms with their own platform.
It sounds like you haven't done much server-side web development.
Another incorrect conclusion you have reached.
One big benefit of Java is that you can write and package applications that will run on multiple server platforms with virtually no modification. For real companies this is a substantial benefit;
No, it isn't. Anybody that deploys the same server software on multiple platforms within the same organization needs to have their head examined because that creates unnecessary costs for no benefit.
Furthermore, the "with virtually no modification" is just wrong. If you want Java applications to run well on, say, Linux, they require plenty of modification: they require platform-specific packaging, desktop integration, integration with Linux's service manager, and lots of other features. The only reason Java packages require "no modification" to run on Linux is because their developers don't bother packaging them right--they just throw out some junk and leave dealing with the mess up to the Linux users. That is not "cross platform support with no modification".
it means that you aren't locked into a single vendor for your infrastructure.
You can achieve the same thing by just targetting UNIX/Linux/BSD. Those systems are so interoperable that people don't even think of it as "cross-platform programming", and you have a choice of half a dozen vendors.
The only time cross-platform programming enters the mix for server-side applications is if you also try to target Windows as a server platform.
The absolute best you can hope for with C++ is the ability to recompile successfully on a different server. If the developers actually have access to your platform then you have a chance that their packaging will compile successfully; but this has not been my experience.
I'm sorry that you can't figure out how to do this.
And since the number of cross-platform libraries is limited a lot of wheels have to be re-invented.
Anything that targets both Windows and UNIX-family systems is going to have serious limitations. That is true for Java just as much as it is for C++ cross-platform libraries. There is an easy solution to that: remove Windows from your mix of target platforms.
But even if you insist on using Windows, C++ still gives you a lot more options than Java. For example, instead of cross-platform toolkits, you can just use Cygwin or uWin to target Windows with a completely UNIX-based codebase.
The problem with C don't go away by supporting it on.NET. The problem with C is its type system and runtime, which are full of holes. One consequence of this is the large number of security problems that C-based system software has (e.g., caused by buffer overflows).
Unfortunately, those problems aren't fixable with better implementations. We have had safe, error-checking C compilers for many years. The problem is that they impose a significant runtime overhead because C semantics make it unnecessarily hard to do error checking (contrary to C mythology, the flexibility of pointers doesn't buy you anything in performance or expressivitiy). Worse yet, they expose the fact that many C programs rely on unportable or undefined features of the C language.
C isn't dying and it won't be dying. But it should. And, sadly, supporting C on.NET won't fix its problems because its problems are deeply encoded in the language definition and in the programming practices of millions of C programmers who keep grinding out unportable code that happens to work most of the time on the platform they are using.
IMHO, java is really successfull in cross platform software development, without much work i can make java software work on another platform. If C# had the same future, i'd be really glad, since i like it too,
First of all, Mono isn't trying to achieve Java-style cross-platform support--many of the people working on, and using, Mono have rejected Java because they don't like Java's cross-platform strategy.
In the end, Mono will probably give you cross-platform functionality no worse than Java's, through its.NET libraries. But Java's cross-platform support is really not very good: Linux is a second class citizen.
With Mono, in addition to its.NET compatibility, you get an independent set of OSS APIs based on Gnome. If you use those, you are creating native Gnome applications. But because Gnome also runs on Windows and OS X, you also get cross-platform support for those applications.
In different words, Mono gives you two cross-platform choices:.NET, which works better on Windows but runs on Linux, and Gtk#, which works better on Linux but runs on Windows. The official Java platform only gives you one choice, Swing, which doesn't really integrate perfectly with the desktop on any platform and whose implementation shows a strong bias towards Windows.
but as Microsoft works harder and harder on.NET i just don't believe MONO guys can keep up with it. C# 2.0 and longhorn will be a huge step forward for.NET technologies, and i don't thinkk MONO team can find resources to keep up with MS.
Microsoft has to be pretty open about the features that come in C# 2.0 and Longhorn. And the way it looks today, OSS will be supporting those features before Microsoft even releases their products.
Yes C++ as a language has compilers for many platforms which are pretty much compatible, but the degree of compatibility of these compilers don't mean much since the compatibility of an application is a totally different story. An application written in C++ will be using some kind of library, for DB access, for GUI, for network operations etc... Most of the times, these libraries are not cross platform.
Well, they are cross-platform if you are writing a cross-platform application, and they are not cross-platform if you don't.
Furthermore, the kind of cross-platform compatibility people primarily worry about with C++ is for libraries: it is things like regexp libraries or XML libraries that are going to be reused across platforms; GUI and I/O parts of applications are best developed in a platform-specific manner.
Or they have to be extended with platform spesific code.
For some reason, Java marketing has created the notion that cross-platform development matters a great deal, but that is nonsense. Cross-platform development (and sandboxing) matters for browser applets, a market that Java has largely ceded to Flash. For desktop applications and server-side applications, cross-platform applications don't matter at all.
Writing in a cross-platform toolkit and adding a small amount of platform-specific code is actually far superior to the 100% cross-platform approach: it is nearly as easy to port the application between platforms, but the application becomes enormously more usable by following platform-specific conventions and offering platform-specific functionality.
What it comes down to is that C++ is a better language than Java for cross-platform development. C# may eventually supplant C++ in that regard, because C# is simpler and safer, but still offers C++'s access to platform-specific features. But Java's religious insistence on what they incorrectly call "cross-platform" support actually is counterproductive.
The multiplicity of countries with many laws is a defense against tyranny (e.g., think of political refugees). If we start bringing the world legally together so that there is one set of laws that applies worldwide (and the attempt to extradite this guy is a step in that direction) then we are eliminating a critical defense against tyranny.
But that is exactly what the US is trying to do: impose US laws and rules on the rest of the world. This extradition request is just another example of that. Much of the rest of the world perceives that just like you do: as a step towards tyranny, and they don't like it. What makes this even less palatable is that the rules the US tries to impose are usually favorable to US citizens and companies.
While his actions were performed in Australia, many of his victims (the owners of said IP) reside in the United States.
Those "owners" may not even own the copyrights in Australia. Did they comply with Australian legal requirements?
Without getting into an IP law debate, It's not that much of a stretch to prosecute someone under the laws of the country of the victim.
That's a huge stretch, actually. Traditionally, crimes are prosecuted where they were committed, not based on the citizenships of the victims. The alternatives raise all sorts of questions.
One simple question is this: is the US willing to reciprocate? If a US citizen publishes "Mein Kampf" on his US web site and Germans can access that web site, should he be extradited to Germany because that's against the law in Germany? If he publishes nude photographs for Saudis to see, should he be extradited to Saudi Arabia, where that sort of thing is a crime?
In fact, the US is apparently unwilling to accept any international jurisdiction over its citizens (viz the refusal to participate in the international criminal court). So, what you consider "reasonable" translates into a very one-sided affair: the US doesn't trust anybody else's legal system, but the US wants to force everybody else to trust the American legal system.
"co-conspirator" implies a number of equals conspiring to do something; that is, it implies something both about the organization of the conspiracy and the position of the conspirator within that conspiracy.
A "conspirator" is just someone who takes part in a conspiracy with no implications about status or position within the conspiracy or the organization of the conspiracy itself.
If I arrange an assassin to murder a US citizen, have I broken my home country's law? Probably not.
Assuming your home country is the UK, yes you have: hiring assassins is illegal in the UK.
Morally, should I be extradited to face trial for my deliberate actions against the murdered US citizen?
That depends on where you committed the crime. If you traveled to the US to hire the assassin on US soil, then US law applies. If you hired the assassin in the UK, then UK law applies.
Generally, the laws of the nation where the crime was committed apply to the crime; the citizenship of the victims and perpetrators should make no difference. That's as close to a "moral" principle as one gets in these matters.
It is the fact that a few nations like the US want to ignore this principle and attempt to prosecute many crimes against US citizens in the US that bothers people. It bothers people even more that this approach generally isn't reciprocal: the US generally refuses to extradite US citizens to be tried in foreign courts.
You seem to have trouble reading. I was specifically talking about identical processors running at different clock speeds. Identical processors take the same number of cycles to carry out each instruction. That's the only place where clock speed comparisons are meaningful, but they are meaningful in that case.
I have seen the early GUI development by PARC. MUCH more R&D was required to get that concept up and running for a machine that could serve as a "personal computer." Yes, the Lisa failed, but it was the first personal computer that had a GUI.
The Xerox Star shipped in 1981, two years before the Lisa. It had a GUI, Ethernet, WYSIWYG editing, printed to laser printers, and was used by office workers.
PARC "invented" the laser printer,
Why do you put that in quotes? Unlike the stuff coming from Apple, the laser printer really was a ground breaking, new technology: a completely new approach for putting ink on paper under computer control.
but it was Apple who heavily underwrote a new company by the name of Adobe and co-developed the laser printer for use with the personal computer.
So, Apple financed product development based on technologies developed elsewhere.
I'll give you that technically, but I used an early Psion in 1986 or so and it was not really a functional information manager. The Newton 120 that I owned a couple of years later was a true PDA that allowed for word processing, information management, communication for email and early Internet via modem and IR, and more.
The Newton was basically a shrunk-down pen-based computer--nothing new there, only better product design. As for PDAs, PARCTAB was much closer to modern PDAs and predates the Newton.
Laptop form factor!(not laptop) with palm rests in front of a full sized keyboard with trackball or (later) trackpad was the innovation there. All of the previous laptops I have owned have been awkward with keyboards up front with no place to rest your hands and no pointing device integral to the laptop.
The Atari Stacy had an integrated pointing device in 1989, several years before the first Powerbook. The integral wrist rests on the Powerbook may have been a new design feature, but Apple itself has moved away from them and moved the keyboard forward again, with just enough room to accomodate the trackpad (which, incidentally, also was not invented by Apple).
"The Apple II was irrelevant to speech recognition research and development" My point still stands, that the first speech synthesis was developed years before anybody else on the Apple ][.
The Apple II was also irrelevant to speech synthesis. The history of electronic speech synthesis goes back to the 1930's. By the time Apple appeared on the scene as a company, people already had a sophisticated algorithmic understanding of how to process speech on computers. Apple made no ground-breaking contributions to speech synthesis, and they never shipped anything that was even close to state-of-the-art in either area.
Consumer digital camera! is what I said. I remember the MavicaPro series and they were hideously expensive. The Quicktake was actually affordable by the consumer.
Again, that's system integration. The underlying technologies (CCD, flash, DSP) were developed elsewhere and the components were produced elsewhere. Even the design came from Sony. All Apple did was to time things right and to cut enough corners to be able to ship a digital camera at a marginally acceptable price for a brief period.
I [...] am grateful that Apple began shipping computers with CD-ROM drives in them for just this reason.
CD-ROMs had been used as a software distribution medium by others. Contrary to what you may think, Microsoft and Apple weren't the first companies to ship bloatware--UNIX vendors had them beat by many years.
Plug and play compatibility is something that is also a huge time saver.
Too bad that Apple didn't invent it. NuBus came from MIT and was commercialized by TI before Apple picked it for the Macintosh II. Again, Apple's role was that of systems integrator.
First to include built in networking is meaningless? There is this thing you are using called the Internet.........
Well, that depends upon what you mean by handicapped. Marketshare? Sure. Useability? Not on your life. I've used Solaris, IRIX, Linux, Windows and others and nothing comes close to how easy, secure and convenient OS X is to administer for servers. Even the base desktop OS includes Apache that is as easy to use as dropping your html into a folder and pressing "Start" to function as a webpage and it can handle the traffic with the best of them. In fact, I am running a retinal anatomy site on an old G3 iMac that gets upwards of 45.000 hits/day from about 3000 unique users.
Yeah, that's your problem: your opinions of how to run server farms are informed by you running an anatomy site of an old G3 iMac.
Give it some time as the G5 really just came out. Between Apple running OS X and IBM running Linux shipping on systems now with the G5, there is going to be some significant market share being gained by those two companies.
Why should I "give it time"? Right now, when I look at price/performance ratios, the Opterons are the best choice for server applications. That's what matters. And unless Apple dramatically lowers prices on the XServe, that's not going to change. Furthermore, they also have more operating systems (Linux, BSD, Windows, Darwin), more compilers, and more application software available for them.
just think about where the computer industry would be without Apple to do the R&D?
Let's look at some of your claims:
3) GUI with the Lisa,
Xerox PARC did the R&D for modern GUIs. The Lisa was Apple's first attempt to copy the Xerox PARC GUI work, and it failed. Then, Apple tried again with Macintosh, and by cutting a lot of corners made the system cheap enough to make it a success.
7) First to develop the laser printer and postscript printing with the Laserwriter,
The laser printer was developed at Xerox PARC. Postscript was developed at Adobe, based on a more complicated PDL developed at Xerox PARC. Apple just happened to create a successful product based on those technologies.
8) First to develop the PDA with the Newton,
The Psion predates the Apple Newton by nearly a decade, and I think it wasn't the first PDA either.
9) First to develop the laptop form factor as we know it with the Powerbook,
Not even close; you can find the history of the laptop here. In fact, the idea goes back to Alan Kay's work on Dynapad--late 1960's or early 1970's.
11) First speech technology with the Apple ][,
The Apple II was irrelevant to speech recognition research and development.
14) First company to ship a consumer digital camera with the Quicktake,
You other examples either refer to system integration issues (e.g., supposed first use of a 3 1/2" floppy--developed by Sony), or are vague and meaningless from a technological point of view.
For a few years, Apple had an R&D department that actually published a little and was fairly high quality. However, I can't think of any fundamental breakthroughs that came out of that, and they disappeared again in the mid-1990's.
In addition to demonstrating your ignorance, I find your posting just offensive: I actually know some of the people who developed the technologies you talk about and I assure you that they didn't work at Apple when they did it. For their own financial gain, Apple has deliberately created the impression that they invented a lot of things that they didn't invent at all--and you fell for that dishonest marketing. Read up on the history of computing--you'll be surprised what you find.
A 1000mhz processor will only be twice as fast as a 500mhz processor if the ram and the peripherals are ALSO twice as fast.
A 1000MHz processor will generally be twice as fast as an identical processor running at 500Mhz. That's why we are talking about processors.
Real programs may not run twice as fast, but that's an entirely different issue. The processor performance is still a meaningful and important figure to people who put together systems and know what they are doing.
If you want to know the performance of a computer, you look at benchmarks. The best ones that are available right now for general purpose computing are the SPECmarks (spec.org).
People have used, and continue to use, Megahertz as a basis for comparison within the same processor family and generation. There, clock speed has a predictable meaning for raw CPU performance, and that is entirely legitimate.
The real "Megahertz Myth" is a marketing concept used by certain companies who have been trying to peddle underpowered and outdated CPUs as state-of-the-art by making inflated claims about their performance.
Apple isn't developing the PowerPC, IBM is. So, if anybody matters in the non-x86 CPU game, it's IBM. Apple is basically just an upscale systems integrator.
This will translate into more sales as Apple is now finding out with significant interest in the G5 Xserve from a large number of corporations and government agencies.
Maybe the interest appears large by Apple standards, but in the market overall, Apple's Xserve and G5-based machines are niche machines and they don't really offer compelling performance advantages--high-end Opteron and P4 system have similar SPECmarks at similar prices. And OS X is severely handicapped in the market relative to Linux and Windows--OS X just isn't used very widely as a server operating system.
So, if Intel can get around some of the performance bottlenecks and deal with the loss of backwards compatibility, they may be able to get back on track.
Intel did miscalculate with Itanium. But the threat to Intel is AMD, not PPC.
I don't get what your point is. My own point was simple: I think the GPL is a bad license for Qt and the MySQL client libraries. I think it's bad not for some abstract philosophical reason, but because it reduces the chance for the long term survival of these projects. In part, that's because there are less restrictive alternatives available, both commercially and freely. And the expected chances of long-term survival of a project have a profound influence on my choice of software: I don't want to invest effort in a piece of software if it's going to disappear or change unpredictably and uncontrollably after a few years.
I am looking for an existing license that lets a closed-source project take my code, use it for some fixed time (say 5 years) and then they have to release their changes to the public. This would be an equivalent of the original copyright law, modified for specific requirements/development speed of software.
That sounds like an LGPL license with a time provision. That would work for the MySQL libraries and Qt. So would the BSD license or many other OSS licenses. However, I think formulating such a license so that it does what you want is hard. I'd just go with one of the existing licenses. I do agree with your unease about the "or later version" provision and don't use them myself in the OSS I write.
I have no problem with the making such a license change per se--they have the right to do it and it doesn't limit the existing license in any wqy.
But, the approach itself strikes me as unnecessarily complex and short-sighted. There is a growing list of compatible licenses in there--who is going to keep that up to date? What's going to happen when MySQL disappears and nobody can make such little changes to the license anymore?
A fairly straightforward compromise would be to put them under the LGPL license. I think that would also make sense because it would get vendors of commercial tools to incorporate the client libraries into their software. But it seems like MySQL's business strategy is getting into the way there because they appear to want to make money from licensing even the MySQL client libraries that way.
This situation seems vaguely analogous to Qt's GPL license: in both cases, a commercial owner of an OSS project is choosing the GPL license as an encumbrance in order to be able to get money from some class of commercial users. In the case of MySQL, they are trying to limit the "collateral damage" to non-GPL compatible OSS projects by making exceptions. But in both cases, I suspect that having these libraries under the GPL is itself a suboptimal strategy because it limits the adoption of OSS. For things like GUI toolkits and database client libraries, it seems best for OSS if companies incorporate them into their commercial software as much as possible, and that means choosing a license more liberal than the GPL. But, again, commercial interests prevent that in these cases.
Well, I personally had just assume that the MySQL client libraries were LGPL or BSD. Thanks for bringing this up. Not the license change itself, but the fact that it has brought the MySQL license situation to my attention, is a reason for me to think about using SQLite and PostgreSQL more seriously.
And, to be fair as well, there is a high likelihood that the anti-trust action was brought as a political move, rather than one based on law. That's not to discount the legal merits of the case, but that's the reason the case was brought.
Your argument is twisted. If there is an anti-trust suit that is justified, this is it. Clinton did what is right in this case, period.
You are trying to spin an argument like "Bush didn't pursue the lawsuit because it was politically inconvenient for him, therefore if Clinton does bring it now and does the right thing, Clinton's actions are politically motivated". Nonsense. The only thing that is politically motivated is not following the law; enforcing the law does not need any justification or explanation.
The problem is now, there isn't a reasonable tech saavy person around who can argue that Windows still has a monopoly hold on any market. Linux is an equal or superior product in every possible way, without exception, without question, period. There is nothing MS can do to stop its growth,
Whether MS actually has "a monopoly" or not is not relevant. MS is, as they always have been, using their market position to exclude competitors--for a company of Microsoft's size and power, that is not acceptable.
In different words, it doesn't matter whether there exist credible competitors and it doesn't matter whether Microsoft's marketshare is 90% or 99%. What matters is Microsoft's business practices. As long as Microsoft's business practices are monopolistic, they are behaving illegally. It just happens to be the case that below a certain market share, monopolistic practices don't pay, but obviously Microsoft hasn't sunk to that marketshare yet.
Slashdot Mirror
Unless you want access to any of the miriad of Java libraries that are available,
No, I don't.
Python might be king of quick hacks, but for a large-scale project where bits of scripting code might be appropriate, this sounds like an excelent option where you would NOT be better off with python.
There are plenty of scripting languages for that. Jython and JavaScript have both C and JVM-based implementations. Beanshell is small and integrates particularly well with Java. I really don't see why we need Groovy.
Except [Groovy] actually elegant, based on Smalltalk, not whatever the heck Python is inspired by.
I don't see anything "elegant" about yet another scripting language built on top of a runtime designed for a simple statically typed language (Java).
And Python reference counting stinks,
True. It also makes the C-Python interpreter slower than a garbage collected version. It is somewhat disconcerting that this misfeature of C-Python still exists after so many years. In fact, the C-Python implementation has a number of other weak points. But it works well enough, and it sure is a lot more practical than running a JVM just to execute Groovy.
I use Python, but I sure don't think there's anything "great" about it,
Neither do I--Python is just one of many scripting languages. But between Python and the available alternatives, I think Python still is the best of the bunch. A JVM-only language like Groovy isn't even worth talking about.
and has a bigger memory footprint (because it uses JVM garbage collection instead of Python reference-counting),
Java does have a bigger footprint than Python, but that is unrelated to whether it uses garbage collection or reference counting. IMO, Python is a nicer language than Java, but the use of reference counting in Python actually makes it both slower and more bloated than a garbage collected implementation of Python would be.
Let's get this straight:
Groovy seems to offer nothing that you don't already get in Python, and Python has implementations available based on C (C Python), Java/JVM (Jython), and C#/CLR (IronPython).
The only thing Groovy does offer is that it is Java/JVM-specific at this point--there are no implementations based on anything other than the Java/JVM runtime. That may be a good thing for Sun--tying people even more to Sun's platform--but it sure isn't good for anybody else.
Real companies have heterogeneous server environments.
Of course, real companies have heterogeneous server environments. But real companies generally don't run the same application on multiple platforms. They run heterogeneous environments because, say, they want to run Oracle on a Sun Enterprise server, Apache on a BSD box, legacy code on a mainframe, and some middleware on a bunch of Windows machines.
In any case, even if a company were foolish enough to run the same code on multiple different platforms, they would still be better off with C++ code compiled specifically for each platform. For example, they can buy and install Oracle for both Windows and Solaris.
Real web apps don't need desktop integration; they are accessed from the browser.
Real server apps benefit from local GUIs for configuration and management. They also benefit from tight integration with local management APIs and GUIs.
I'm not sure what limitations you are referring to when it comes to cross-platform.
With Java? Installers, integration with service managers, integration with package managers, integration with system management APIs and tools, access to memory mapped I/O, raw device access, etc. Java falls short on all of those, and many more.
Access to these components is streamlined by standard Java libraries and implemented universally by Application Servers.
To the degree that Java even provides this kind of functionality, it provides it in a way that is incompatible with the platform it runs in. Sorry, that isn't cross-platform support, it's a strategy by Sun to replace other people's platforms with their own platform.
It sounds like you haven't done much server-side web development.
Another incorrect conclusion you have reached.
One big benefit of Java is that you can write and package applications that will run on multiple server platforms with virtually no modification. For real companies this is a substantial benefit;
No, it isn't. Anybody that deploys the same server software on multiple platforms within the same organization needs to have their head examined because that creates unnecessary costs for no benefit.
Furthermore, the "with virtually no modification" is just wrong. If you want Java applications to run well on, say, Linux, they require plenty of modification: they require platform-specific packaging, desktop integration, integration with Linux's service manager, and lots of other features. The only reason Java packages require "no modification" to run on Linux is because their developers don't bother packaging them right--they just throw out some junk and leave dealing with the mess up to the Linux users. That is not "cross platform support with no modification".
it means that you aren't locked into a single vendor for your infrastructure.
You can achieve the same thing by just targetting UNIX/Linux/BSD. Those systems are so interoperable that people don't even think of it as "cross-platform programming", and you have a choice of half a dozen vendors.
The only time cross-platform programming enters the mix for server-side applications is if you also try to target Windows as a server platform.
The absolute best you can hope for with C++ is the ability to recompile successfully on a different server. If the developers actually have access to your platform then you have a chance that their packaging will compile successfully; but this has not been my experience.
I'm sorry that you can't figure out how to do this.
And since the number of cross-platform libraries is limited a lot of wheels have to be re-invented.
Anything that targets both Windows and UNIX-family systems is going to have serious limitations. That is true for Java just as much as it is for C++ cross-platform libraries. There is an easy solution to that: remove Windows from your mix of target platforms.
But even if you insist on using Windows, C++ still gives you a lot more options than Java. For example, instead of cross-platform toolkits, you can just use Cygwin or uWin to target Windows with a completely UNIX-based codebase.
The problem with C don't go away by supporting it on .NET. The problem with C is its type system and runtime, which are full of holes. One consequence of this is the large number of security problems that C-based system software has (e.g., caused by buffer overflows).
.NET won't fix its problems because its problems are deeply encoded in the language definition and in the programming practices of millions of C programmers who keep grinding out unportable code that happens to work most of the time on the platform they are using.
Unfortunately, those problems aren't fixable with better implementations. We have had safe, error-checking C compilers for many years. The problem is that they impose a significant runtime overhead because C semantics make it unnecessarily hard to do error checking (contrary to C mythology, the flexibility of pointers doesn't buy you anything in performance or expressivitiy). Worse yet, they expose the fact that many C programs rely on unportable or undefined features of the C language.
C isn't dying and it won't be dying. But it should. And, sadly, supporting C on
IMHO, java is really successfull in cross platform software development, without much work i can make java software work on another platform. If C# had the same future, i'd be really glad, since i like it too,
.NET libraries. But Java's cross-platform support is really not very good: Linux is a second class citizen.
.NET compatibility, you get an independent set of OSS APIs based on Gnome. If you use those, you are creating native Gnome applications. But because Gnome also runs on Windows and OS X, you also get cross-platform support for those applications.
.NET, which works better on Windows but runs on Linux, and Gtk#, which works better on Linux but runs on Windows. The official Java platform only gives you one choice, Swing, which doesn't really integrate perfectly with the desktop on any platform and whose implementation shows a strong bias towards Windows.
.NET i just don't believe MONO guys can keep up with it. C# 2.0 and longhorn will be a huge step forward for .NET technologies, and i don't thinkk MONO team can find resources to keep up with MS.
First of all, Mono isn't trying to achieve Java-style cross-platform support--many of the people working on, and using, Mono have rejected Java because they don't like Java's cross-platform strategy.
In the end, Mono will probably give you cross-platform functionality no worse than Java's, through its
With Mono, in addition to its
In different words, Mono gives you two cross-platform choices:
but as Microsoft works harder and harder on
Microsoft has to be pretty open about the features that come in C# 2.0 and Longhorn. And the way it looks today, OSS will be supporting those features before Microsoft even releases their products.
Yes C++ as a language has compilers for many platforms which are pretty much compatible, but the degree of compatibility of these compilers don't mean much since the compatibility of an application is a totally different story. An application written in C++ will be using some kind of library, for DB access, for GUI, for network operations etc... Most of the times, these libraries are not cross platform.
Well, they are cross-platform if you are writing a cross-platform application, and they are not cross-platform if you don't.
Furthermore, the kind of cross-platform compatibility people primarily worry about with C++ is for libraries: it is things like regexp libraries or XML libraries that are going to be reused across platforms; GUI and I/O parts of applications are best developed in a platform-specific manner.
Or they have to be extended with platform spesific code.
For some reason, Java marketing has created the notion that cross-platform development matters a great deal, but that is nonsense. Cross-platform development (and sandboxing) matters for browser applets, a market that Java has largely ceded to Flash. For desktop applications and server-side applications, cross-platform applications don't matter at all.
Writing in a cross-platform toolkit and adding a small amount of platform-specific code is actually far superior to the 100% cross-platform approach: it is nearly as easy to port the application between platforms, but the application becomes enormously more usable by following platform-specific conventions and offering platform-specific functionality.
What it comes down to is that C++ is a better language than Java for cross-platform development. C# may eventually supplant C++ in that regard, because C# is simpler and safer, but still offers C++'s access to platform-specific features. But Java's religious insistence on what they incorrectly call "cross-platform" support actually is counterproductive.
The multiplicity of countries with many laws is a defense against tyranny (e.g., think of political refugees). If we start bringing the world legally together so that there is one set of laws that applies worldwide (and the attempt to extradite this guy is a step in that direction) then we are eliminating a critical defense against tyranny.
But that is exactly what the US is trying to do: impose US laws and rules on the rest of the world. This extradition request is just another example of that. Much of the rest of the world perceives that just like you do: as a step towards tyranny, and they don't like it. What makes this even less palatable is that the rules the US tries to impose are usually favorable to US citizens and companies.
While his actions were performed in Australia, many of his victims (the owners of said IP) reside in the United States.
Those "owners" may not even own the copyrights in Australia. Did they comply with Australian legal requirements?
Without getting into an IP law debate, It's not that much of a stretch to prosecute someone under the laws of the country of the victim.
That's a huge stretch, actually. Traditionally, crimes are prosecuted where they were committed, not based on the citizenships of the victims. The alternatives raise all sorts of questions.
One simple question is this: is the US willing to reciprocate? If a US citizen publishes "Mein Kampf" on his US web site and Germans can access that web site, should he be extradited to Germany because that's against the law in Germany? If he publishes nude photographs for Saudis to see, should he be extradited to Saudi Arabia, where that sort of thing is a crime?
In fact, the US is apparently unwilling to accept any international jurisdiction over its citizens (viz the refusal to participate in the international criminal court). So, what you consider "reasonable" translates into a very one-sided affair: the US doesn't trust anybody else's legal system, but the US wants to force everybody else to trust the American legal system.
"co-conspirator" implies a number of equals conspiring to do something; that is, it implies something both about the organization of the conspiracy and the position of the conspirator within that conspiracy.
A "conspirator" is just someone who takes part in a conspiracy with no implications about status or position within the conspiracy or the organization of the conspiracy itself.
If I arrange an assassin to murder a US citizen, have I broken my home country's law? Probably not.
Assuming your home country is the UK, yes you have: hiring assassins is illegal in the UK.
Morally, should I be extradited to face trial for my deliberate actions against the murdered US citizen?
That depends on where you committed the crime. If you traveled to the US to hire the assassin on US soil, then US law applies. If you hired the assassin in the UK, then UK law applies.
Generally, the laws of the nation where the crime was committed apply to the crime; the citizenship of the victims and perpetrators should make no difference. That's as close to a "moral" principle as one gets in these matters.
It is the fact that a few nations like the US want to ignore this principle and attempt to prosecute many crimes against US citizens in the US that bothers people. It bothers people even more that this approach generally isn't reciprocal: the US generally refuses to extradite US citizens to be tried in foreign courts.
You seem to have trouble reading. I was specifically talking about identical processors running at different clock speeds. Identical processors take the same number of cycles to carry out each instruction. That's the only place where clock speed comparisons are meaningful, but they are meaningful in that case.
I have seen the early GUI development by PARC. MUCH more R&D was required to get that concept up and running for a machine that could serve as a "personal computer." Yes, the Lisa failed, but it was the first personal computer that had a GUI.
The Xerox Star shipped in 1981, two years before the Lisa. It had a GUI, Ethernet, WYSIWYG editing, printed to laser printers, and was used by office workers.
PARC "invented" the laser printer,
Why do you put that in quotes? Unlike the stuff coming from Apple, the laser printer really was a ground breaking, new technology: a completely new approach for putting ink on paper under computer control.
but it was Apple who heavily underwrote a new company by the name of Adobe and co-developed the laser printer for use with the personal computer.
So, Apple financed product development based on technologies developed elsewhere.
I'll give you that technically, but I used an early Psion in 1986 or so and it was not really a functional information manager. The Newton 120 that I owned a couple of years later was a true PDA that allowed for word processing, information management, communication for email and early Internet via modem and IR, and more.
The Newton was basically a shrunk-down pen-based computer--nothing new there, only better product design. As for PDAs, PARCTAB was much closer to modern PDAs and predates the Newton.
Laptop form factor!(not laptop) with palm rests in front of a full sized keyboard with trackball or (later) trackpad was the innovation there. All of the previous laptops I have owned have been awkward with keyboards up front with no place to rest your hands and no pointing device integral to the laptop.
The Atari Stacy had an integrated pointing device in 1989, several years before the first Powerbook. The integral wrist rests on the Powerbook may have been a new design feature, but Apple itself has moved away from them and moved the keyboard forward again, with just enough room to accomodate the trackpad (which, incidentally, also was not invented by Apple).
"The Apple II was irrelevant to speech recognition research and development" My point still stands, that the first speech synthesis was developed years before anybody else on the Apple ][.
The Apple II was also irrelevant to speech synthesis. The history of electronic speech synthesis goes back to the 1930's. By the time Apple appeared on the scene as a company, people already had a sophisticated algorithmic understanding of how to process speech on computers. Apple made no ground-breaking contributions to speech synthesis, and they never shipped anything that was even close to state-of-the-art in either area.
Consumer digital camera! is what I said. I remember the MavicaPro series and they were hideously expensive. The Quicktake was actually affordable by the consumer.
Again, that's system integration. The underlying technologies (CCD, flash, DSP) were developed elsewhere and the components were produced elsewhere. Even the design came from Sony. All Apple did was to time things right and to cut enough corners to be able to ship a digital camera at a marginally acceptable price for a brief period.
I [...] am grateful that Apple began shipping computers with CD-ROM drives in them for just this reason.
CD-ROMs had been used as a software distribution medium by others. Contrary to what you may think, Microsoft and Apple weren't the first companies to ship bloatware--UNIX vendors had them beat by many years.
Plug and play compatibility is something that is also a huge time saver.
Too bad that Apple didn't invent it. NuBus came from MIT and was commercialized by TI before Apple picked it for the Macintosh II. Again, Apple's role was that of systems integrator.
First to include built in networking is meaningless? There is this thing you are using called the Internet.........
Well, that depends upon what you mean by handicapped. Marketshare? Sure. Useability? Not on your life. I've used Solaris, IRIX, Linux, Windows and others and nothing comes close to how easy, secure and convenient OS X is to administer for servers. Even the base desktop OS includes Apache that is as easy to use as dropping your html into a folder and pressing "Start" to function as a webpage and it can handle the traffic with the best of them. In fact, I am running a retinal anatomy site on an old G3 iMac that gets upwards of 45.000 hits/day from about 3000 unique users.
Yeah, that's your problem: your opinions of how to run server farms are informed by you running an anatomy site of an old G3 iMac.
Give it some time as the G5 really just came out. Between Apple running OS X and IBM running Linux shipping on systems now with the G5, there is going to be some significant market share being gained by those two companies.
Why should I "give it time"? Right now, when I look at price/performance ratios, the Opterons are the best choice for server applications. That's what matters. And unless Apple dramatically lowers prices on the XServe, that's not going to change. Furthermore, they also have more operating systems (Linux, BSD, Windows, Darwin), more compilers, and more application software available for them.
Let's look at some of your claims:
You other examples either refer to system integration issues (e.g., supposed first use of a 3 1/2" floppy--developed by Sony), or are vague and meaningless from a technological point of view.
For a few years, Apple had an R&D department that actually published a little and was fairly high quality. However, I can't think of any fundamental breakthroughs that came out of that, and they disappeared again in the mid-1990's.
In addition to demonstrating your ignorance, I find your posting just offensive: I actually know some of the people who developed the technologies you talk about and I assure you that they didn't work at Apple when they did it. For their own financial gain, Apple has deliberately created the impression that they invented a lot of things that they didn't invent at all--and you fell for that dishonest marketing. Read up on the history of computing--you'll be surprised what you find.
It's called SPEC. SPEC may not be perfect, but it's pretty good.
A 1000mhz processor will only be twice as fast as a 500mhz processor if the ram and the peripherals are ALSO twice as fast.
A 1000MHz processor will generally be twice as fast as an identical processor running at 500Mhz. That's why we are talking about processors.
Real programs may not run twice as fast, but that's an entirely different issue. The processor performance is still a meaningful and important figure to people who put together systems and know what they are doing.
If you want to know the performance of a computer, you look at benchmarks. The best ones that are available right now for general purpose computing are the SPECmarks (spec.org).
People have used, and continue to use, Megahertz as a basis for comparison within the same processor family and generation. There, clock speed has a predictable meaning for raw CPU performance, and that is entirely legitimate.
The real "Megahertz Myth" is a marketing concept used by certain companies who have been trying to peddle underpowered and outdated CPUs as state-of-the-art by making inflated claims about their performance.
What really matters is real power [apple.com].
Apple isn't developing the PowerPC, IBM is. So, if anybody matters in the non-x86 CPU game, it's IBM. Apple is basically just an upscale systems integrator.
This will translate into more sales as Apple is now finding out with significant interest in the G5 Xserve from a large number of corporations and government agencies.
Maybe the interest appears large by Apple standards, but in the market overall, Apple's Xserve and G5-based machines are niche machines and they don't really offer compelling performance advantages--high-end Opteron and P4 system have similar SPECmarks at similar prices. And OS X is severely handicapped in the market relative to Linux and Windows--OS X just isn't used very widely as a server operating system.
So, if Intel can get around some of the performance bottlenecks and deal with the loss of backwards compatibility, they may be able to get back on track.
Intel did miscalculate with Itanium. But the threat to Intel is AMD, not PPC.
I don't get what your point is. My own point was simple: I think the GPL is a bad license for Qt and the MySQL client libraries. I think it's bad not for some abstract philosophical reason, but because it reduces the chance for the long term survival of these projects. In part, that's because there are less restrictive alternatives available, both commercially and freely. And the expected chances of long-term survival of a project have a profound influence on my choice of software: I don't want to invest effort in a piece of software if it's going to disappear or change unpredictably and uncontrollably after a few years.
I am looking for an existing license that lets a closed-source project take my code, use it for some fixed time (say 5 years) and then they have to release their changes to the public. This would be an equivalent of the original copyright law, modified for specific requirements/development speed of software.
That sounds like an LGPL license with a time provision. That would work for the MySQL libraries and Qt. So would the BSD license or many other OSS licenses. However, I think formulating such a license so that it does what you want is hard. I'd just go with one of the existing licenses. I do agree with your unease about the "or later version" provision and don't use them myself in the OSS I write.
I have no problem with the making such a license change per se--they have the right to do it and it doesn't limit the existing license in any wqy.
But, the approach itself strikes me as unnecessarily complex and short-sighted. There is a growing list of compatible licenses in there--who is going to keep that up to date? What's going to happen when MySQL disappears and nobody can make such little changes to the license anymore?
A fairly straightforward compromise would be to put them under the LGPL license. I think that would also make sense because it would get vendors of commercial tools to incorporate the client libraries into their software. But it seems like MySQL's business strategy is getting into the way there because they appear to want to make money from licensing even the MySQL client libraries that way.
This situation seems vaguely analogous to Qt's GPL license: in both cases, a commercial owner of an OSS project is choosing the GPL license as an encumbrance in order to be able to get money from some class of commercial users. In the case of MySQL, they are trying to limit the "collateral damage" to non-GPL compatible OSS projects by making exceptions. But in both cases, I suspect that having these libraries under the GPL is itself a suboptimal strategy because it limits the adoption of OSS. For things like GUI toolkits and database client libraries, it seems best for OSS if companies incorporate them into their commercial software as much as possible, and that means choosing a license more liberal than the GPL. But, again, commercial interests prevent that in these cases.
Well, I personally had just assume that the MySQL client libraries were LGPL or BSD. Thanks for bringing this up. Not the license change itself, but the fact that it has brought the MySQL license situation to my attention, is a reason for me to think about using SQLite and PostgreSQL more seriously.
And, to be fair as well, there is a high likelihood that the anti-trust action was brought as a political move, rather than one based on law. That's not to discount the legal merits of the case, but that's the reason the case was brought.
Your argument is twisted. If there is an anti-trust suit that is justified, this is it. Clinton did what is right in this case, period.
You are trying to spin an argument like "Bush didn't pursue the lawsuit because it was politically inconvenient for him, therefore if Clinton does bring it now and does the right thing, Clinton's actions are politically motivated". Nonsense. The only thing that is politically motivated is not following the law; enforcing the law does not need any justification or explanation.
The problem is now, there isn't a reasonable tech saavy person around who can argue that Windows still has a monopoly hold on any market. Linux is an equal or superior product in every possible way, without exception, without question, period. There is nothing MS can do to stop its growth,
Whether MS actually has "a monopoly" or not is not relevant. MS is, as they always have been, using their market position to exclude competitors--for a company of Microsoft's size and power, that is not acceptable.
In different words, it doesn't matter whether there exist credible competitors and it doesn't matter whether Microsoft's marketshare is 90% or 99%. What matters is Microsoft's business practices. As long as Microsoft's business practices are monopolistic, they are behaving illegally. It just happens to be the case that below a certain market share, monopolistic practices don't pay, but obviously Microsoft hasn't sunk to that marketshare yet.