"Jackson then viewed those 1K-resolution QuickTime files on an Apple Cinema Display, tied to his G4 laptop, which drew directly from his iPod."
I've been warned against using the iPod in this way. It was designed (I was told) for brief disk access, i.e. pulling the next x minutes of compressed music into ram. Sustained access, however, will invite disk problems due to cooling problems. (Indeed I find mine heats up noticeably when copying large amounts).
Perhaps this quote is misleading. OTOH I guess their budget could cope with a few failures (unlike mine:-).
I think that even more impressive than the Bluetooth wireless wizardry is the fact that this new Apple keyboard finally has a separate island for INS/DEL/HOM/END/PUP/PDN and the cursor keys.
Ok, I give up: what do you mean? Apple keyboards have had that for years - I'm using an old G4 400 and the keyboard layout is identical to the new ones, AFAICT.
As I read it the only "problem" here is that the very same version of the jar the program was linked against is the one required to run
That's the second time I've seen this claim, and I'm interested to know where you got this information from. If this were the case then how could swing apps work across different java versions? (well, I use the word 'work' with care for swing;-).
I'm not getting at you, but just intrigued.
Re:The phrase in question seems to be:
on
LGPL is Viral for Java
·
· Score: 2, Informative
Isn't the issue that for security reasons java requires the exact version of the jar linked against to be present and fails if you compile your own modified version?
No, you can drop in updated jars (pace usual API compatibility issues). You might be thinking of serialisation issues that can crop up (but even then they can be worked around).
...shared libs more or less are used all over the JVM, a typical example is tomcat which puts its shared libs for all webapps into the commons folder and handles multiple apps withing one JVM.
That's a good point. Java is an interesting case - is tomcat an application with plugins, or multiple applications working in an special environment? Should keep to FSF busy...
I also recall that someone (Apple?) were working on a persistent JVM to speed java app startup, but that might also make java libraries more 'shared'.
Re:The phrase in question seems to be:
on
LGPL is Viral for Java
·
· Score: 2, Insightful
Is probably OK. Note that I say probably. I'm not a lawyer, nor do I play one on TV.
Neither am I (or do I):-)
I think you might be wrong about this. The second condition is fine - you don't need interfaces. For example I could write my own javax.swing.* classes (just give me a while:-). That satisfies 2) since "the modified version is interface-compatible with the version that the work was made with."
1) is, I suspect, the contentious part. Each instance of a java executable has a copy of the classes in memory. No sharing, IIRC. Although the linking mechanism is dynamic, it isn't shared, which is what the text is trying to define.
But I may be very wrong about all of this, so take my words with the appropriate quantity of salt.
We modify the LGPL to comply with its purpose. The GPL is on version 2, isn't it? Just edit section 6, name it LGPL 2.0, and call it a night.
I had a look for the problem section. I guess it's this:
6b:
Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable...
This, AIUI, is the main difference between GPL and LGPL. It is intended to distinguish between static linking (derivative work must be LGPLd) and linking to shared libs (no restriction).
Java doesn't have two kinds of linking, and would appear to violate condition 1.
Why should venders fix this it an OS problem and Microsofts fault. Working around bugs only lead to more bugs and problems.
I agree absolutely. Letting any app call any function as described in the paper isn't a smart idea (I assume it predates multiple users in windows, but still...).
However Microsoft's advice is sound. Having setuid apps is always hairy - anyone remember Apple's moment of shame? There's a little bit of guilt on the vendor side, too.
I was thinking of ObjC and Ruby here, plus I'd been trying Java's dynamic proxy class stuff, which achieves a similar 'dynamic typing' feel (but in long winded and painful fashion).
Versatile indeed.
:-).
"Jackson then viewed those 1K-resolution QuickTime files on an Apple Cinema Display, tied to his G4 laptop, which drew directly from his iPod."
I've been warned against using the iPod in this way. It was designed (I was told) for brief disk access, i.e. pulling the next x minutes of compressed music into ram. Sustained access, however, will invite disk problems due to cooling problems. (Indeed I find mine heats up noticeably when copying large amounts).
Perhaps this quote is misleading. OTOH I guess their budget could cope with a few failures (unlike mine
Apple's iChat uses XMPP for local (rendevous) chats, IIRC. It uses AOL's protocol for remote sessions, however.
Strangeberry were known for jRendezvous (a java zeroconf library). It's moved to SourceForge, for future reference.
I think the series 2 tivo uses rendezvous, which is the only connection I can think of between the two companies.
Good point. In a similar vein there is also MIT's Haystack (although the requirements are terrifying to behold).
here. ;-)
Anyway, it's a good idea and very useful.
These explained a little:
... thousands?
udev presentation (PDF), Google HTML version.
Detailed paper on udev (PDF), Google HTML version.
devfs works fine for me, but since some people (see second link) want thousands of disks I guess I'm not the target market. I mean
That would be the Reduced Shakespeare Company. They've been going for over twenty years now, so it's possible they might be the originators.
I think that even more impressive than the Bluetooth wireless wizardry is the fact that this new Apple keyboard finally has a separate island for INS/DEL/HOM/END/PUP/PDN and the cursor keys.
Ok, I give up: what do you mean? Apple keyboards have had that for years - I'm using an old G4 400 and the keyboard layout is identical to the new ones, AFAICT.
Talk about flamebait. vi vs emacs is one thing, but FSF Emacs vs XEmacs... entering a world of pain.
XEmacs is far superior, of course, and I urge people not to vote for someone so clueless. (ducks)
Before the medication wears off.
$32 for using my tivo? I believe that uses many of the contested server technologies.
PS I am being sarcastic
flightgear runs under linux.
Flightgear runs under Linux, Windows, OS X, IRIX and Solaris. BTW, there is a binary of 0.92 for OS X - follow the link to the master location for OS X.
Cool. And I'm connected using ipv6. Like the future ... but with ascii animation.
As I read it the only "problem" here is that the very same version of the jar the program was linked against is the one required to run
;-).
That's the second time I've seen this claim, and I'm interested to know where you got this information from. If this were the case then how could swing apps work across different java versions? (well, I use the word 'work' with care for swing
I'm not getting at you, but just intrigued.
Isn't the issue that for security reasons java requires the exact version of the jar linked against to be present and fails if you compile your own modified version?
No, you can drop in updated jars (pace usual API compatibility issues). You might be thinking of serialisation issues that can crop up (but even then they can be worked around).
...shared libs more or less are used all over the JVM, a typical example is tomcat which puts its shared libs for all webapps into the commons folder and handles multiple apps withing one JVM.
That's a good point. Java is an interesting case - is tomcat an application with plugins, or multiple applications working in an special environment? Should keep to FSF busy...
I also recall that someone (Apple?) were working on a persistent JVM to speed java app startup, but that might also make java libraries more 'shared'.
Is probably OK. Note that I say probably. I'm not a lawyer, nor do I play one on TV.
:-)
:-). That satisfies 2) since "the modified version is interface-compatible with the version that the work was made with."
Neither am I (or do I)
I think you might be wrong about this. The second condition is fine - you don't need interfaces. For example I could write my own javax.swing.* classes (just give me a while
1) is, I suspect, the contentious part. Each instance of a java executable has a copy of the classes in memory. No sharing, IIRC. Although the linking mechanism is dynamic, it isn't shared, which is what the text is trying to define.
But I may be very wrong about all of this, so take my words with the appropriate quantity of salt.
We modify the LGPL to comply with its purpose. The GPL is on version 2, isn't it? Just edit section 6, name it LGPL 2.0, and call it a night.
I had a look for the problem section. I guess it's this:
6b:
Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable...
This, AIUI, is the main difference between GPL and LGPL. It is intended to distinguish between static linking (derivative work must be LGPLd) and linking to shared libs (no restriction).
Java doesn't have two kinds of linking, and would appear to violate condition 1.
Does anyone know where I can get one of these in the UK?
Why should venders fix this it an OS problem and Microsofts fault. Working around bugs only lead to more bugs and problems.
I agree absolutely. Letting any app call any function as described in the paper isn't a smart idea (I assume it predates multiple users in windows, but still...).
However Microsoft's advice is sound. Having setuid apps is always hairy - anyone remember Apple's moment of shame? There's a little bit of guilt on the vendor side, too.
Your argument is specious
:-)
How dare you...
I was thinking of ObjC and Ruby here, plus I'd been trying Java's dynamic proxy class stuff, which achieves a similar 'dynamic typing' feel (but in long winded and painful fashion).
/me adding noise to this discussion, so I'll be brief...
In a dynamically typed language, you would only have to write myvar.fooMethod().
Ok, so ObjC and Ruby are dynamically typed (and, I guess all smalltalk style OO langs), but not Java and C++?
The difference is that the Java compiler assigns a datatype to the location of myvar, but python assigns a datatype to the value held in myvar.
This is a minor point, but that doesn't show Java is statically typed:
Object myvar = "Hello";
myvar = new Foo();
That would be dynamic, AAUI. So Java has both static and dynamic typing? Or do OO languages just confuse things?
Am I missing something? The /. summary is almost as long as the article itself.
I know this, I worked there...
HP (15 - 16 from DEC via Compaq iirc)
I seem to recall much muttering about this being the only reason for buying Compaq.
I also use and endorse 'Cringley article'.
RMS's article is pretty light on the full horror, but Cringley's gives a nice idea what a tangled mess the simple phrase "our IP" can mean.