Maybe, but a lot of similar stuff was in the CORBA Transaction and CORBA Security specs, particularly the JTA and JAAS-level interfaces and the on-the-wire representation of transaction and security contexts.
JDBC vs. ODBC would probably be a better example of J2EE borrowing vs. 'research' (i.e. borrowing from more than one source).
Despite the resemblances, I still don't think that MS deserves much credit as an innovator. To take a current example, MS is borrowing from object/relational mapping products to create a Dotnet addition called ObjectSpaces - an extraordinarily conservative approach when you consider that MS owns both the database it is mapping to and the development language and environment it is mapping from. It's almost as though Redmond wants to be the EPCOT Center version of the larger software world outside, obliged to reproduce in detail all its variety and arbitrariness internally.
However, I will give them some credit if they manage to get 'Longhorn' out - the OS with SQL Server as the file system - but last I heard, things weren't looking that positive.
A lot? A bit is closer to the mark. As has been pointed out frequently in recent/. discussions, the CLR is ideal for running lots of languages that are semantically close to C#, just as the JVM is good for languages like Java.
Every now and then, a new 'language independent language' appears - an IDL, a VM, a higher-level 'scripting' system, X Schema - which then proves to be not so independent after all, in that it assumes and constrains too much.
Gosling is relieved because there are lots of clever things that MS could have done given a blank sheet - support for logic/query programming, inbuilt databases, workflow systems, LISP-style programs-as-data etc. - but even with billions of R&D dollars at their disposal, they merely managed to clone Java. Unless you really believe that a DCE/CORBA-style common type system qualifies as innovation?
Java provides the basis of a much more coherent security and concurrency model than Apache 1.x + Unix, and products such as WebLogic, JBoss and Jetty take good advantage of it.
Essentially, the thread serving a user's request has their authenticated ID associated with it, and cannot access any resource to which that ID hasn't been explicitly authorized, e.g. in mappings in the web.xml file. If the resource corresponds to an external file or process, it is easy enough to assign it ACLs in the app server and let the server decide whether / how to run it.
The server itself doesn't need to be root.
For example, see the WebLogic security docs - you probably won't find similar these features in free products now, but with the impressive capabilities that Java 1.4 provides it shouldn't be too long before they appear.
Part of the problem, IMHO, is that C/C++ require or at least encourage the development of frameworks (GUI, RPC, storage, threading etc.) before you can get started on real functionality. This almost guarantees that development will fragment even if you start from the same place. A Java or maybe Smalltalk project would be less prone to this, though still no picnic from the convergence PoV.
Yes, this is valid in some situations. However, there's no guarantee that an incremental requirement has an equally 'incremental' cost - adding security or resilience or some other pervasive aspect to an existing code base rather than doing up-front design cost increase costs substantially.
Agility requires Abstraction and Automation - if you're forced to mix different implementation aspects in the same piece of code (persistence, security, communication...) then be prepared for some cost bumps on the development path.
Not quite sure how this apparently deliberate misunderstanding has achieved a score of 5 - to my mind the parent statement is clear: collaboration means collaboration, not necessarily convergence by merging code.
Especially an ARM with a JVM in hardware. Contrast with the dismal Itanic - moving in completely the wrong direction - painful optimization, dumb VLIW RISC instructions etc etc
the death toll in London and its environs from V1 and V2's was horrendous
Nah, not really. I mean, one nearly got my mother's family so I shouldn't make light of it, but on average I think each V2 killed one person. Not sure about V1s, but you could hear those coming, or rather, when you stopped hearing them buzz, they were coming.
Normal bombs were much worse - total civilian dead in UK was about 146000. Of course, this is in turn nothing like as bad as Germany - 2.3 million civilian deaths from bombing - 80000 in one night, for example.
I'm so glad you agree that Java offered so many improvements over C++.
However, I can't help noticing that you've not gone so far as to enumerate the equally scintillating improvements that C# offers over Java. Client-side GUI programming? Sounds very exciting...
Yeah, you should know better than to go around pointing out awkward facts about thew history of Gnome and Java. People have a right to change their mind, don't they? It's all water under the bridge. Let's be grateful that Miguel having missed the boat on Java is now being extra pushy about C#.
But at least the armchair critics aren't trying to pollute Gnome. If Miguel wasn't linking it to Gnome via Ximian then I don't think RMS & co. would be worried.
ability to treat programs as data (like LISP in 1960)
query and analysis functions (PL/SQL)
rule processing (XSLT, Prolog, J/Rules)
but I guess some people are just thrilled with plucky little Microsoft having the skill and determination to successfully make a clone of Java. Well done guys! But go easy, not sure my brain can handle any more innovation right now - phew!
The Morlocks like Lemurs? Isn't the point that the Eloi are the dumbed down consumers and the Morlocks are the technocrats? I think we know which species would inhabit the network centers, and they'd need more than Lemur brains to do that!
I always liked the image of night and day passing like the beating of a great crow's wing. Oh, and the museum as the neglected repository of knowledge - some resonance with contemporary culture there, don't you think?
For a long time? Well, the original intent of copyright in the US and the UK is clearly to avoid a simple equating of rights and property, as others have pointed out. Just for entertainment, here's an early Victorian (Macaulay) on the subject (the whole thing is here, courtesy of Eric Flint)
Speech to Parliament, 1841
...I will take an example. Dr Johnson died fifty-six years ago. If the law were what my honourable and learned friend wishes to make it [term extended], somebody would now have the monopoly of Dr Johnson's works. Who that somebody would be it is impossible to say; but we may venture to guess. I guess, then, that it would have been some bookseller, who was the assign of another bookseller, who was the grandson of a third bookseller, who had bought the copyright from Black Frank, the doctor's servant and residuary legatee, in 1785 or 1786. Now, would the knowledge that this copyright would exist in 1841 have been a source of gratification to Johnson? Would it have stimulated his exertions? Would it have once drawn him out of his bed before noon? Would it have once cheered him under a fit of the spleen? Would it have induced him to give us one more allegory, one more life of a poet, one more imitation of Juvenal? I firmly believe not. I firmly believe that a hundred years ago, when he was writing our debates for the Gentleman's Magazine, he would very much rather have had twopence to buy a plate of shin of beef at a cook's shop underground. Considered as a reward to him, the difference between a twenty years' and sixty years' term of posthumous copyright would have been nothing or next to nothing. But is the difference nothing to us?...
I don't see how you can generalise from a KT266 chipset / some BIOS to all boards out there. In my case, the BIOS did a much better job of IRQ assignment with ACPI off than W2K did with it on.
IRQ sharing was a real problem with my streaming USB device and sound card - this cured it. Not surprisingly, I found the fix on a semi-pro audio tools site.
This is the key point (hint to mods!) There's a real need to turn off ACPI - I had to do this to get a streaming USB device working, it insisted on sharing the USB IRQ with the soundcard - but now we're stuffed, apparently.
This virtually never happens. The set of objects (Flights) of interest has to be communicated from receiver to sender, and an initial snapshot still has to be provided, ergo RPC still needed.
guaranteed delivery doesn't need resends
Formally, there's no such thing as asynchronous guaranteed delivery. Practically, one needs resends because a receiver can still lose or mis-process messages.
message store is implementation dependent
Any implementation which is not the same storage resource as the sender needs 2PC. This is a fundamental problem of the paradigm, not an implementation problem.
better than RPCs because no polling is needed
In the very rare cases where polling is a significant load on the network (basically where your Max Desired Lag Time << Average Msg Interval) you can add a pub/sub or other notification mechanism on top. The point is that the notification is just advisory - this is a well-established event model dating back to Multics.
point 3
Most msging systems end up needing a state-monitoring system on top, resembling a workflow system. The problem is that a msg queue represents a black hole - you don't know whether your msg is still in the queue, or being processed downstream. Tracking the overall process state is perfectly possible, and many JMS vendors sell process mgmt frameworks on top of their basic tools, but it requires RPC between the components and the process manager, so you haven't really moved to an async model.
pub-sub has some great advantages
Such as?
message order is not guaranteed
It is guaranteed within a subject, but not across subjects. The problem is that the model encourages you to divide your transactions across subjects (customer updates, order updates), so setting you up for order-dependent problems later (cancel order, fix error in customer record, re-enter order - oops). Most apps have these dependencies, so JMS has a pretty narrow field of applicability.
your "log updates" solution lacks a few things - like scalability, authentication, security
On the contrary, I think it's clear that the 'receiver has control model' scales much better (can get many messages in a single call; no 2PC overhead; no need for queue to maintain each receiver's position), and can make use of standard secure transports such as SSL. Messaging, on the other hand, requires per-message signing/sealing, which is much more expensive than session-based encryption, while the pub/sub model is practically unsecurable (the message must be readable by all recipients, therefore must be encrypted under a common key).
Well, we differ on a few thing I think that's a fair summary:)
I'll agree that asynchronous messaging and pub-sub are cool if you show me an application that doesn't require:
the receiver to start with a 'snapshot' of the info being updated (needs RPC)
the receiver to request a resend of messages because of software or other error (needs RPC)
a messaging system that wouldn't benefit from a 'workflow-like' monitoring system (needs RPC)
a JMS system with a message store able to replace any client-side or server-side message store for recovery purposes
a way of avoiding the order-of-magnitude slowdown on key transactions imposed by 2-phase commit across database and message store
a message system that doesn't act as a 'transaction fragmenter', sending messages which are meant to be ordered down separate channels (subjects) which have no concept of overall order
In short, JMS should be next in line for attack after EJB, it's pretty useless for corporate transactional communication - just log updates in the local database and provide an RPC for clients to pull them off instead. Simpler, faster, more reliable... and cheaper!
Scheme etc. is better than XSL because it's more consistent and more powerful - no need for escapes to real programming languages as real-world XSL processors like Saxon have to provide
Programs are data, and advanced IDEs like Eclipse would be a lot easier if they started from LISP heritage (hence EMACS longevity).
RMI can do things that CORBA, EJB and SOAP cannot, including pass-by-value and code transfer.
These issues come up time after time on/. in the context of Dotnet equivalents, the future of Perl, best languages for web programming and so forth, but few people make the case for a one-size-can-fit all LISP-based alternative - something like Dylan, for example.
Slashdot Mirror
Maybe, but a lot of similar stuff was in the CORBA Transaction and CORBA Security specs, particularly the JTA and JAAS-level interfaces and the on-the-wire representation of transaction and security contexts.
JDBC vs. ODBC would probably be a better example of J2EE borrowing vs. 'research' (i.e. borrowing from more than one source).
Despite the resemblances, I still don't think that MS deserves much credit as an innovator. To take a current example, MS is borrowing from object/relational mapping products to create a Dotnet addition called ObjectSpaces - an extraordinarily conservative approach when you consider that MS owns both the database it is mapping to and the development language and environment it is mapping from. It's almost as though Redmond wants to be the EPCOT Center version of the larger software world outside, obliged to reproduce in detail all its variety and arbitrariness internally.
However, I will give them some credit if they manage to get 'Longhorn' out - the OS with SQL Server as the file system - but last I heard, things weren't looking that positive.
A lot? A bit is closer to the mark. As has been pointed out frequently in recent /. discussions, the CLR is ideal for running lots of languages that are semantically close to C#, just as the JVM is good for languages like Java.
Every now and then, a new 'language independent language' appears - an IDL, a VM, a higher-level 'scripting' system, X Schema - which then proves to be not so independent after all, in that it assumes and constrains too much.
Gosling is relieved because there are lots of clever things that MS could have done given a blank sheet - support for logic/query programming, inbuilt databases, workflow systems, LISP-style programs-as-data etc. - but even with billions of R&D dollars at their disposal, they merely managed to clone Java. Unless you really believe that a DCE/CORBA-style common type system qualifies as innovation?
Java provides the basis of a much more coherent security and concurrency model than Apache 1.x + Unix, and products such as WebLogic, JBoss and Jetty take good advantage of it.
Essentially, the thread serving a user's request has their authenticated ID associated with it, and cannot access any resource to which that ID hasn't been explicitly authorized, e.g. in mappings in the web.xml file. If the resource corresponds to an external file or process, it is easy enough to assign it ACLs in the app server and let the server decide whether / how to run it.
The server itself doesn't need to be root.
For example, see the WebLogic security docs - you probably won't find similar these features in free products now, but with the impressive capabilities that Java 1.4 provides it shouldn't be too long before they appear.
Yes, it is a bit idealistic, fair comment.
Part of the problem, IMHO, is that C/C++ require or at least encourage the development of frameworks (GUI, RPC, storage, threading etc.) before you can get started on real functionality. This almost guarantees that development will fragment even if you start from the same place. A Java or maybe Smalltalk project would be less prone to this, though still no picnic from the convergence PoV.
Yes, this is valid in some situations. However, there's no guarantee that an incremental requirement has an equally 'incremental' cost - adding security or resilience or some other pervasive aspect to an existing code base rather than doing up-front design cost increase costs substantially.
Agility requires Abstraction and Automation - if you're forced to mix different implementation aspects in the same piece of code (persistence, security, communication...) then be prepared for some cost bumps on the development path.
Some XP contributors did a 'manifesto' or something recently and used the terms 'agile programming', 'agile methods' etc. which I certainly prefer
Not quite sure how this apparently deliberate misunderstanding has achieved a score of 5 - to my mind the parent statement is clear: collaboration means collaboration, not necessarily convergence by merging code.
Two statements, both 100% wrong. At least you're consistent.
JVMs have JITs, and ARM and others have hardware VMs such as Jazelle.
Especially an ARM with a JVM in hardware.
Contrast with the dismal Itanic - moving in completely the wrong direction - painful optimization, dumb VLIW RISC instructions etc etc
the death toll in London and its environs from V1 and V2's was horrendous
Nah, not really. I mean, one nearly got my mother's family so I shouldn't make light of it, but on average I think each V2 killed one person. Not sure about V1s, but you could hear those coming, or rather, when you stopped hearing them buzz, they were coming.
Normal bombs were much worse - total civilian dead in UK was about 146000. Of course, this is in turn nothing like as bad as Germany - 2.3 million civilian deaths from bombing - 80000 in one night, for example.
I'm so glad you agree that Java offered so many improvements over C++.
However, I can't help noticing that you've not gone so far as to enumerate the equally scintillating improvements that C# offers over Java. Client-side GUI programming? Sounds very exciting...
Yeah, you should know better than to go around pointing out awkward facts about thew history of Gnome and Java. People have a right to change their mind, don't they? It's all water under the bridge. Let's be grateful that Miguel having missed the boat on Java is now being extra pushy about C#.
But then, from a LISP-person's point of view, it's probably strange to have a language that can't compile itself.
Wonder how BASIC people feel about 'eval'? Spooky, or not?
But at least the armchair critics aren't trying to pollute Gnome. If Miguel wasn't linking it to Gnome via Ximian then I don't think RMS & co. would be worried.
The Java -> C# learning curve in negligable [sic]
Good heavens, what a coincidence. Yet strangely C# is 'shocking', 'amazing' and 'excellent' whereas Java is...? The same weight as a duck, perhaps?
Now what could he possibly have meant by 'more polished'... method names in shiny InitCaps, is that it?
It is? I must have missed the
- transparent persistence (like OODBs)
- workflow management (like WebLogic)
- ability to treat programs as data (like LISP in 1960)
- query and analysis functions (PL/SQL)
- rule processing (XSLT, Prolog, J/Rules)
but I guess some people are just thrilled with plucky little Microsoft having the skill and determination to successfully make a clone of Java. Well done guys! But go easy, not sure my brain can handle any more innovation right now - phew!The Morlocks like Lemurs? Isn't the point that the Eloi are the dumbed down consumers and the Morlocks are the technocrats? I think we know which species would inhabit the network centers, and they'd need more than Lemur brains to do that!
I always liked the image of night and day passing like the beating of a great crow's wing. Oh, and the museum as the neglected repository of knowledge - some resonance with contemporary culture there, don't you think?
For a long time? Well, the original intent of copyright in the US and the UK is clearly to avoid a simple equating of rights and property, as others have pointed out. Just for entertainment, here's an early Victorian (Macaulay) on the subject (the whole thing is here, courtesy of Eric Flint)
...I will take an example. Dr Johnson died fifty-six years ago. If the law were what my honourable and learned friend wishes to make it [term extended], somebody would now have the monopoly of Dr Johnson's works. Who that somebody would be it is impossible to say; but we may venture to guess. I guess, then, that it would have been some bookseller, who was the assign of another bookseller, who was the grandson of a third bookseller, who had bought the copyright from Black Frank, the doctor's servant and residuary legatee, in 1785 or 1786. Now, would the knowledge that this copyright would exist in 1841 have been a source of gratification to Johnson? Would it have stimulated his exertions? Would it have once drawn him out of his bed before noon? Would it have once cheered him under a fit of the spleen? Would it have induced him to give us one more allegory, one more life of a poet, one more imitation of Juvenal? I firmly believe not. I firmly believe that a hundred years ago, when he was writing our debates for the Gentleman's Magazine, he would very much rather have had twopence to buy a plate of shin of beef at a cook's shop underground. Considered as a reward to him, the difference between a twenty years' and sixty years' term of posthumous copyright would have been nothing or next to nothing. But is the difference nothing to us?...
Speech to Parliament, 1841
I don't see how you can generalise from a KT266 chipset / some BIOS to all boards out there. In my case, the BIOS did a much better job of IRQ assignment with ACPI off than W2K did with it on.
IRQ sharing was a real problem with my streaming USB device and sound card - this cured it. Not surprisingly, I found the fix on a semi-pro audio tools site.
This is the key point (hint to mods!)
There's a real need to turn off ACPI - I had to do this to get a streaming USB device working, it insisted on sharing the USB IRQ with the soundcard - but now we're stuffed, apparently.
and here.
Well, you're probably both right, it is more than changing a setting, but less than a complete reinstall.
Personally, I couldn't believe I had to do this just to stop dumb IRQ sharing choices being made.
only send changes
:)
This virtually never happens. The set of objects (Flights) of interest has to be communicated from receiver to sender, and an initial snapshot still has to be provided, ergo RPC still needed.
guaranteed delivery doesn't need resends
Formally, there's no such thing as asynchronous guaranteed delivery. Practically, one needs resends because a receiver can still lose or mis-process messages.
message store is implementation dependent
Any implementation which is not the same storage resource as the sender needs 2PC. This is a fundamental problem of the paradigm, not an implementation problem.
better than RPCs because no polling is needed
In the very rare cases where polling is a significant load on the network (basically where your Max Desired Lag Time << Average Msg Interval) you can add a pub/sub or other notification mechanism on top. The point is that the notification is just advisory - this is a well-established event model dating back to Multics.
point 3
Most msging systems end up needing a state-monitoring system on top, resembling a workflow system. The problem is that a msg queue represents a black hole - you don't know whether your msg is still in the queue, or being processed downstream. Tracking the overall process state is perfectly possible, and many JMS vendors sell process mgmt frameworks on top of their basic tools, but it requires RPC between the components and the process manager, so you haven't really moved to an async model.
pub-sub has some great advantages
Such as?
message order is not guaranteed
It is guaranteed within a subject, but not across subjects. The problem is that the model encourages you to divide your transactions across subjects (customer updates, order updates), so setting you up for order-dependent problems later (cancel order, fix error in customer record, re-enter order - oops). Most apps have these dependencies, so JMS has a pretty narrow field of applicability.
your "log updates" solution lacks a few things - like scalability, authentication, security
On the contrary, I think it's clear that the 'receiver has control model' scales much better (can get many messages in a single call; no 2PC overhead; no need for queue to maintain each receiver's position), and can make use of standard secure transports such as SSL. Messaging, on the other hand, requires per-message signing/sealing, which is much more expensive than session-based encryption, while the pub/sub model is practically unsecurable (the message must be readable by all recipients, therefore must be encrypted under a common key).
Well, we differ on a few thing
I think that's a fair summary
- the receiver to start with a 'snapshot' of the info being updated (needs RPC)
- the receiver to request a resend of messages because of software or other error (needs RPC)
- a messaging system that wouldn't benefit from a 'workflow-like' monitoring system (needs RPC)
- a JMS system with a message store able to replace any client-side or server-side message store for recovery purposes
- a way of avoiding the order-of-magnitude slowdown on key transactions imposed by 2-phase commit across database and message store
- a message system that doesn't act as a 'transaction fragmenter', sending messages which are meant to be ordered down separate channels (subjects) which have no concept of overall order
In short, JMS should be next in line for attack after EJB, it's pretty useless for corporate transactional communication - just log updates in the local database and provide an RPC for clients to pull them off instead. Simpler, faster, more reliable... and cheaper!- Scheme etc. is better than XSL because it's more consistent and more powerful - no need for escapes to real programming languages as real-world XSL processors like Saxon have to provide
- Programs are data, and advanced IDEs like Eclipse would be a lot easier if they started from LISP heritage (hence EMACS longevity).
- RMI can do things that CORBA, EJB and SOAP cannot, including pass-by-value and code transfer.
These issues come up time after time on