Include the book title, university state and name in the description and people can search for books on their campus or on surrounding ones if it's a large city.
That really should be fairly easy to explain to people in a simple e-mail/leaflet when they sign up.
If eBay get enough students using it they may include a better interface to get more people using it.
VoiceGenie build a great line of VXML servers. Originally they used SCO but have recently migrated to using Linux.
UniSys build a lot of test systems from pretty much every kind of boxen you can imagine. They pick ASR/TTS/VXMLi from loads of different people or just make their own. They have a lot of customers and are always looking at new solutions. I met the guy who has this job, lucky guy. And, yes, they use windows too.
I think you might find Pipebeach using Linux but I haven't heard from them in a while, don't quote me on this one.
I can only see MS adopting OSS in those cases where it doesn't directly affect their revenue (definition of directly will of course differ).
Take the browser market. Now that they have effectively killed commercial competition, taking a step back and looking at what they could do with IE might not be such a bad idea for them.
They are still pumping money into developing IE, but there is no bottom line gain for them. It doesn't generate revenue and none of their competitors are selling browsers anymore either.
The only argument I can see against this would be that they wish to control the capabilities that IE provides so that they can make sure their server-side subscription businesses always work best (or at all) with IE. If, however, this is their stance then I'm not sure that any argument for OSS is going to work because they do have so many pieces of software that complement each other even if some of them do not directly earn revenue.
This seems like comparing apples and oranges, partially. Some of them are specifications, some are implementations, and some are both. In particular, ILU is an implementation which supports (Sun) RPC, CORBA. AFAIK, DCE, DCOM, and Java RMI are supported in an experimental stage.
I disagree, they are all specifications, even if they are unpublished. Implementations of X are not X where X is your specification of choice. Because implementations attempt to model the specification, they are not the specification itself.
Further, just because future Java RMI spec may allow the use of IIOP for the wire protocol does not mean that you will be able to get an RMI Java client to talk to a CORBA Java server (or any CORBA server) simply because the semantics are different. Sharing a binary encoding and transmission representation will not change that.
There are some good commercial ORBs that are free for non-commercial use, e.g. ORBacus.
Maybe so, but I need something that I can redistribute!!!
This is a misconception. You don't need a single implementation that targets multiple platforms and multiple languages. For one language, using the same system on all platforms definitely helps (although portability of CORBA code is very high, across CORBA implementations). For a different language, you can use a different implementation: CORBA implementations *do* interoperate.
Yes, fine, but the point is this. If I want to generate a system to run on multiple different platforms, and have it distributed then the option that gives me as few porting and compatability issues within my own codebase is the one to go for. Hence the desire to have a system that I can use on all of my target platforms. Not because I don't think different ORBs will talk to each other but because I don't want to have to convert code for three different platforms and have to shell out for multiple developer/redistribution kits if I have to use a commercial ORB for a specific platform.
I would just finish by saying that no-one has come up with a satisfactory answer for the Perl problem. And please don't trot out CORBA::MICO or COPE. I have attempted to use them. CORBA::MICO is in a state of flux and still catching up to the current MICO release. COPE doesn't support POA operation. And as far as I know only COPE has any support for building servers rather than clients.
Thanks for all the feedback. Here is a quick update.
The article was originally posted about a month ago. Since then many things have happened.
I have started to roll my own CORBA-like implementation targeted at Perl and Java in the first instance. Focusing on platform compatibility (which is all but eliminated with the above two languages) and features on an 'as-and-when' needed basis. If a feature is required then it is implemented as close to the CORBA spec as possible. The major exception to this is marshalling/CDR adn transmission protocol which are very simple right now.
If anyone is interested in something like this then get hold of me on this address since the system is being built to enabel the main system and not as a product the licensing for it is currently undecided but may eventually be open sourced.
Thanks for all the pointers and info so far...I'm still reading.
I have no trouble in beleiving that function/method call oriented RPC may not be useful to you. Personally I want to be able to split up a program that has at its base an OO model and not have to destroy the model to do it. For this some form of method based RPC (CORBA/DCOM) is required.
On the subject of synchronous calls I think you should go and look at the specifications for both RPC and CORBA. Both allow 'oneway' invocations to take place. Basically an asynchronous call.
On the subject of coupling I would have to ask whether or not you like that fact than libraries have specific interfaces that can be relied upon. This is the only restriction that RPC/CORBA/DCOM put upon your programs. The signature of a call has to be known, just like library calls. Yes this means that there is a higher degree of coupling than in a system where the data can be 'interpreted' by the callee but it also means that you don't have to attempt to interpret the data which gives you a performance boost. I don't want my libraries to have to interpret what I give them, and neither do I want my own systems to have such fuzzy interfaces. If I do want something like that then I'll implement it myself but I won't choose it as a feature.
Having said all of that however I would be interested to keep in contact and discuss your system with you.
Cheers, yes this looks quite nice but really it is only an encoding/transmission scheme. It doesn't deal with distributed objects you would have to implement that on top of XML-RPC.
The scheme is very flexible but it doesn't address most of the surrounding problems with distributed systems. Service discovery, location transparency et cetera. All of these would have to be built on top of XML-RPC.
Maybe you do get the option of installing to a different location with windows, but seeing as their own installers for the DevStudio set of tools can't even cope with network drives for their documentation it doesn't really help much.
Sure the docs say you can install the docs onto a networked file server, what they don't say is that even when you observe their install procedure in their tech support doucments online it is up to fate to decide exactly which computers on your network will be able to use those docs.
These are the facts of the case and they are undisputed. I am sure someone can write in saying they have had no problems, but I'm a coder and a sysadmin on Unix and NT, if I have to spend a couple of hours to do something I consider trivial and still find it doesn't work then what kind of hope can anyone else have of installing something elsewhere.
The moral here is - if you are buying a computer for an MS OS then buy a hard drive that can handle as much as possible, even if you pay a premium, you may not be able to install everything you want to otherwise.
Okay, anyone out there know about the certification they discuss regarding NT? What does it comprise of? Can anyone apply for it or does the US Government only attempt to certify those systems that they wish to use? Also, if anyone knows, is there any reason that Linux (either now or in the future) would not be eligible for this kind of certification?
If the regulations are public knowledge then is anyone currently trying to get Linux certified?
After what kind of modifications to the OS does the certification become invalid? This might be a very important point since the kernel is now going through faster development cycles. Would the US Gov be able to use the latest and greatest or would they be stuck with something that was certified but older? (at least for operations that require that certification)
And, since I'm a UK bound persona, anyone know if Linux is being used in MI5/6? *grin*
The question is not really whether people should behave in an ethical manner. I hope we all agree that they should.
Its whether or not it would be good for people to make their ethics public and explicit when it comes to their profession.
And if developers were to begin to do this, what would happen? Would anyone care? Assuming people did actually care it might then be an incentive for all developers to follow suite. I can imagine that somone in any profession who does not follow prescribed codes of conduct would find it harder to find jobs if their peers do.
The real question is not whether or not we should expect people who create critical systems (and not-so-critical) systems to abide by a public set of ethics or code of conduct, but why do we accept the fact that they currently don't?
I'm a developer, show me a code of conduct I can agree with and I'll sign up. (Having said that I keep putting off joining the BCS (lazy))
Slashdot Mirror
How about eBay?
Include the book title, university state and name in the description and people can search for books on their campus or on surrounding ones if it's a large city.
That really should be fairly easy to explain to people in a simple e-mail/leaflet when they sign up.
If eBay get enough students using it they may include a better interface to get more people using it.
VoiceGenie build a great line of VXML servers. Originally they used SCO but have recently migrated to using Linux.
UniSys build a lot of test systems from pretty much every kind of boxen you can imagine. They pick ASR/TTS/VXMLi from loads of different people or just make their own. They have a lot of customers and are always looking at new solutions. I met the guy who has this job, lucky guy. And, yes, they use windows too.
I think you might find Pipebeach using Linux but I haven't heard from them in a while, don't quote me on this one.
I can only see MS adopting OSS in those cases where it doesn't directly affect their revenue (definition of directly will of course differ).
Take the browser market. Now that they have effectively killed commercial competition, taking a step back and looking at what they could do with IE might not be such a bad idea for them.
They are still pumping money into developing IE, but there is no bottom line gain for them. It doesn't generate revenue and none of their competitors are selling browsers anymore either.
The only argument I can see against this would be that they wish to control the capabilities that IE provides so that they can make sure their server-side subscription businesses always work best (or at all) with IE. If, however, this is their stance then I'm not sure that any argument for OSS is going to work because they do have so many pieces of software that complement each other even if some of them do not directly earn revenue.
This seems like comparing apples and oranges, partially. Some of them are specifications, some are implementations, and some are both. In particular, ILU is an implementation which supports (Sun) RPC, CORBA. AFAIK, DCE, DCOM, and Java RMI are supported in an experimental stage.
I disagree, they are all specifications, even if they are unpublished. Implementations of X are not X where X is your specification of choice. Because implementations attempt to model the specification, they are not the specification itself.
Further, just because future Java RMI spec may allow the use of IIOP for the wire protocol does not mean that you will be able to get an RMI Java client to talk to a CORBA Java server (or any CORBA server) simply because the semantics are different. Sharing a binary encoding and transmission representation will not change that.
There are some good commercial ORBs that are free for non-commercial use, e.g. ORBacus.
Maybe so, but I need something that I can redistribute!!!
This is a misconception. You don't need a single implementation that targets multiple platforms and multiple languages. For one language, using the same system on all platforms definitely helps (although portability of CORBA code is very high, across CORBA implementations). For a different language, you can use a different implementation: CORBA implementations *do* interoperate.
Yes, fine, but the point is this. If I want to generate a system to run on multiple different platforms, and have it distributed then the option that gives me as few porting and compatability issues within my own codebase is the one to go for. Hence the desire to have a system that I can use on all of my target platforms. Not because I don't think different ORBs will talk to each other but because I don't want to have to convert code for three different platforms and have to shell out for multiple developer/redistribution kits if I have to use a commercial ORB for a specific platform.
I would just finish by saying that no-one has come up with a satisfactory answer for the Perl problem. And please don't trot out CORBA::MICO or COPE. I have attempted to use them. CORBA::MICO is in a state of flux and still catching up to the current MICO release. COPE doesn't support POA operation. And as far as I know only COPE has any support for building servers rather than clients.
Cheers,
The article was originally posted about a month ago. Since then many things have happened.
I have started to roll my own CORBA-like implementation targeted at Perl and Java in the first instance. Focusing on platform compatibility (which is all but eliminated with the above two languages) and features on an 'as-and-when' needed basis. If a feature is required then it is implemented as close to the CORBA spec as possible. The major exception to this is marshalling/CDR adn transmission protocol which are very simple right now.
If anyone is interested in something like this then get hold of me on this address since the system is being built to enabel the main system and not as a product the licensing for it is currently undecided but may eventually be open sourced.
Thanks for all the pointers and info so far...I'm still reading.
Cheers,
On the subject of synchronous calls I think you should go and look at the specifications for both RPC and CORBA. Both allow 'oneway' invocations to take place. Basically an asynchronous call.
On the subject of coupling I would have to ask whether or not you like that fact than libraries have specific interfaces that can be relied upon. This is the only restriction that RPC/CORBA/DCOM put upon your programs. The signature of a call has to be known, just like library calls. Yes this means that there is a higher degree of coupling than in a system where the data can be 'interpreted' by the callee but it also means that you don't have to attempt to interpret the data which gives you a performance boost. I don't want my libraries to have to interpret what I give them, and neither do I want my own systems to have such fuzzy interfaces. If I do want something like that then I'll implement it myself but I won't choose it as a feature.
Having said all of that however I would be interested to keep in contact and discuss your system with you.
Cheers,
Cheers,
I also don't beleive that there is enough out there to warrant building an entire system out of yet. Just my own personal opinion.
Finally how does automatic system generation from higher level models help to create distributed systems?
Cheers,
I'm not saying that this is a complete list or that any one of them is a brick wall. But together they are giving me a headache.
Perhaps a few free ORB developers should get together and pool efforts to come up with something orthogonal? Just a thought.
Cheers,
The scheme is very flexible but it doesn't address most of the surrounding problems with distributed systems. Service discovery, location transparency et cetera. All of these would have to be built on top of XML-RPC.
Sure the docs say you can install the docs onto a networked file server, what they don't say is that even when you observe their install procedure in their tech support doucments online it is up to fate to decide exactly which computers on your network will be able to use those docs.
These are the facts of the case and they are undisputed. I am sure someone can write in saying they have had no problems, but I'm a coder and a sysadmin on Unix and NT, if I have to spend a couple of hours to do something I consider trivial and still find it doesn't work then what kind of hope can anyone else have of installing something elsewhere.
The moral here is - if you are buying a computer for an MS OS then buy a hard drive that can handle as much as possible, even if you pay a premium, you may not be able to install everything you want to otherwise.
If the regulations are public knowledge then is anyone currently trying to get Linux certified?
After what kind of modifications to the OS does the certification become invalid? This might be a very important point since the kernel is now going through faster development cycles. Would the US Gov be able to use the latest and greatest or would they be stuck with something that was certified but older? (at least for operations that require that certification)
And, since I'm a UK bound persona, anyone know if Linux is being used in MI5/6? *grin*
The question is not really whether people should behave in an ethical manner. I hope we all agree that they should.
Its whether or not it would be good for people to make their ethics public and explicit when it comes to their profession.
And if developers were to begin to do this, what would happen? Would anyone care? Assuming people did actually care it might then be an incentive for all developers to follow suite. I can imagine that somone in any profession who does not follow prescribed codes of conduct would find it harder to find jobs if their peers do.
The real question is not whether or not we should expect people who create critical systems (and not-so-critical) systems to abide by a public set of ethics or code of conduct, but why do we accept the fact that they currently don't?
I'm a developer, show me a code of conduct I can agree with and I'll sign up. (Having said that I keep putting off joining the BCS (lazy))
Regards,