This is a variant of the MQSeries enterprise messaging product aimed at pervasive devices. It is optimised for security and size (both in terms of message size and footprint on the device).
The interesting observation is that although this is a fully Java-based implementation, IBM has produced a C-programming language version of MQe targetted at Palm devices (for example).
In answer to the original poster's question, I would suggest that there is a market for Java-based applications on PDAs but if you want success on all platforms, you need to take into account the support for - and the performance of - Java on some of the lower-end machines and design your implementation to support a C version if customer demand requires it.
"Although i see no reason why the GPL isn't as legal as a click-thru or a shrink wrap license..."
I think the difference is that shrink wrap licenses and the like are designed to be read/agreed to before you use the software. The GPL, by contrast, says nothing about your use of the software. It specifically deals with your rights to further distribute the code.
The article mentions the principle of "privity". IANAL but the argument against the GPL seems to be that you can't impose restrictions on someone further down the chain of distribution, especially if they haven't even been given a copy of the GPL.
But, the GPL isn't a license to use the software, it is a license to further distribute it. If you don't receive the GPL with the software then surely the issue of privity is irrelevant: the code is copyrighted and so, in the absence of a license to redistribute (i.e. the GPL), then you must assume that you can't further distribute it as you don't own the copyright.
But if there is a major company prepared to argue differently, then I guess it proves that IreallyANAL.
My understanding is that there are many (very many) cables across the Atlantic and so the reliability and speed you can expect is in proportion to how much you want to pay.
For example, the UK Academic Network (Janet) is linked to the US using Teleglobe with two (maybe three?) separate fibres. If they go down then we are, in principle, sunk since there are no peering arrangements with other networks. (I think the situation may have changed recently but the point is the same: there is no "One True Fibre" - just lots of networks and you can pay for your traffic to go down any one of them)
So, if you need a reliable trans-atlantic connection, I would think you should just go with a supplier who has multiple redundant links or purchase connectivity on separate networks.
I have no idea how this conjecture will eventually be proved but many claims about integers can be proved (i.e. for all integers up to infinity) by induction. This does not involve trying every number up to infinity. You only need to show it holds for one number (say 4=2+2). Now, if you can show the following, then the theorem is proved:
If the conjecture holds for k then it holds for k+1.
Now, we can obviously test this for small numbers. For example, it holds for 5 (=3+2). However, we can prove a conjecture by proving the inductive step - which means you don't have to try every number up to infinity. Since that might take some time...:-)
Of course, the difficult part is proving the inductive step:-) Indeed, _finding_ the right inductive step is often hard enough...
Slashdot Mirror
Take a look at:
e
http://www.ibm.com/software/ts/mqseries/everyplac
This is a variant of the MQSeries enterprise
messaging product aimed at pervasive devices.
It is optimised for security and size (both
in terms of message size and footprint
on the device).
The interesting observation is that although
this is a fully Java-based implementation, IBM
has produced a C-programming language version
of MQe targetted at Palm devices (for example).
In answer to the original poster's question,
I would suggest that there is a market for
Java-based applications on PDAs but if you want
success on all platforms, you need to take into
account the support for - and the performance of -
Java on some of the lower-end machines and
design your implementation to support a C version
if customer demand requires it.
I hear that the latest version of Microsoft's Natu ral keyboard provides just the most natural Microsoft combinations.
I think the difference is that shrink wrap licenses and the like are designed to be read/agreed to before you use the software. The GPL, by contrast, says nothing about your use of the software. It specifically deals with your rights to further distribute the code.
The article mentions the principle of "privity". IANAL but the argument against the GPL seems to be that you can't impose restrictions on someone further down the chain of distribution, especially if they haven't even been given a copy of the GPL.
But, the GPL isn't a license to use the software, it is a license to further distribute it. If you don't receive the GPL with the software then surely the issue of privity is irrelevant: the code is copyrighted and so, in the absence of a license to redistribute (i.e. the GPL), then you must assume that you can't further distribute it as you don't own the copyright.
But if there is a major company prepared to argue differently, then I guess it proves that IreallyANAL.
For example, the UK Academic Network (Janet) is linked to the US using Teleglobe with two (maybe three?) separate fibres. If they go down then we are, in principle, sunk since there are no peering arrangements with other networks. (I think the situation may have changed recently but the point is the same: there is no "One True Fibre" - just lots of networks and you can pay for your traffic to go down any one of them)
So, if you need a reliable trans-atlantic connection, I would think you should just go with a supplier who has multiple redundant links or purchase connectivity on separate networks.
No - Section 3c of the GPL says:
"This alternative is allowed only for noncommercial distribution ..."
So - they can't just point to someone else's source and make them incur the bandwidth costs.
IIRC, LinuxOne tried this stunt when they were asked for the source - they pointed people to Red Hat's ftp server...
If the conjecture holds for k then it holds for k+1.
Now, we can obviously test this for small numbers. For example, it holds for 5 (=3+2). However, we can prove a conjecture by proving the inductive step - which means you don't have to try every number up to infinity. Since that might take some time... :-)
Of course, the difficult part is proving the inductive step :-) Indeed, _finding_ the right inductive step is often hard enough...