GRUB is nice as it doesn't need re-installing after changing the configs, which means a rescue disk can mount the/boot partition and edit the grub.conf files and not have problems trying to re-write the boot record.
However, be warned...the kernel make files, if you rebuild the kernel and do an make install, try to invoke LILO after the new kernel is installed, which will replace the grub boot loader.
Coming from the perspective of years of designing and implementing enterprise application, I'm afraid I must disagree with "you really need to use OO". However, I do agree with the remainder concerning coming up with a model, if the model in question is modeling the communications layer between systems.
We have systems written in totally non-OO languages (MVS COBOL, Informix 4GL, RPC, etc) that we leverage quite nicely. Instead of forcing an object model on this, we use a system that either performs HTTP POST requests or passes XML documents around via the HTTP procotol and have adapters invoke the existing code.
For example, we have (don't laugh) COBOL code that generates XML documents. The COBOL code is invoked by an HTTP server listening on the MVS CICS system for POST's.
Currently it isn't necessary to have the COBOL code parse XML as it works quite well with key/value pairs from a POST.
The point was to utilize the existing available services in our 20+ year old enterprise without whole-scale re-writing. All we are doing is writing adapter's.
HTTP as a protocol works very well. Most of the activity with table maintenance in a large enterprise is OLTP, thus psuedo-conversational. HTTP works well in that environment as no real state needs maintaining on the service's side.
O-O is fine, CORBA is a nice idea as well..NET will have it's benefits. However, considering that there are many large enterprises that have never used O-O that are fully functionaly, high speed and stable, if all.NET provides is an O-O method of performing functions in the enterprise, then I won't need it.
First understand, I know perfectly well what an object is. I've been working with OO languages since C++ was first a front-end pre-processor for C. I have years of design and development experience in OO, and am highly compensated for that very knowledge. But that many years of experience results in the seeing of the base of these high level systems, and they are all the same. Kinda like the discovery of programming patterns by the Gang of Four.
I was making the point that to any remote procedure call mechanism, be it RPC, RMI, CORBA's IIOP, XML-RPC or SOAP, what is important is the data being moved, not the fact that objects are being invoked. The company I work for (one of the DOW 30 to give you size) has a heterogeneous environment that includes everything from old DEC Business Basic to Informix 4GL to Java Servlets (with everything in between). I've implemented CORBA interfaces that invoke 4GL compiled RPC servers. We've designed and written C shared libraries for invocation from MicroFocus COBOL to perform HTTP POST/GET requests to servlets that then invoke CORBA objects. Did the COBOL code know it would talk to an object? No. There's no object there, just a back end message reciever that moves data. The idea is to build interfaces to existing applications that make them available to new code. I can do that with any of the RPC methods, but objects aren't required.
To your points in detail:
Object discovery is the idea of using a registration or naming service. You tell a server that "I have an object [here] that conforms to interface [xyz]". Its a combination of CORBA's Interface Repository and directory services.
That's what I was saying. You are looking for an implementation of an interface (i.e. a method), not an object. Your code doesn't care what supplies the function. My comment was that the same thing can be accomplised with XML-RPC, so long as there is a recipient for the request (just like the actual Naming service implementation). Kinda like UDDI. I just make an XML-RPC call to a given recipient that tells me the URL of what I'm looking for. The details are stored someplace and my code knows the specific identification keys to ask.
As for the next comment block you make, there isn't a standard implementation of a Naming service either. (I'm my companies representative to the OMG). There is a specification for how a Naming service will work with CORBA 3, but the OMG doesn't put out a standard service. All that is required for a standard service is an agreed upon query language for the requesting client. Once the query language is defined, it could be used by CORBA, RMI or XML-RPC. Nothing prevents me from making an XML-RPC call to a remote service object that calls a CORBA Naming service.
CORBA has 12 different aspects to it - communication (which is what XML-RPC does, and nothing else) is just one of those 12 aspects.
In actuallity, CORBA has one aspect: IDL. It is the definition of how disparate systems can communicate with each other in a language-neutral manner. From this, there have been IDL definitions of various services that a complete ORB should provide. Your ORB may provide a complete set of functionality (from BOA to POA to IR to Naming to Transactioning) but they don't all provide it. And when all is said and done, all CORBA Stubs and Skeletons do is translate object's attributes into byte streams (using a fixed byte ordering and sizing) to allow streaming those attributes back and forth. Objects (which are code AND data) aren't sent. Try serializing a Java Hashtable object to your C++ CORBA Client. Does C++ know how to re-build the object? No, but it can take the data from the object and put it in a C++ implementation of the same interface. (RMI is different. It can stream a Java class' actual bytes to be dynamically loaded by the remote VM).
I also know that the XML-RPC spec indicates it works over HTTP. It was designed to as a means of invoking some message on some service in a simple (and firewall accessible) way. The header is specified for HTTP. What I said was that there is no reason it HAD to be HTTP. Granted, moving it to SMTP (for example) would break the spec as the header is now different, but all it is doing is moving TEXT back and forth. Nothing more. Look at the generated Stubs/Skeletons for any CORBA enabled code. You'll see that everything is moved as 8 bit bytes. Infact, a base function in most ORB toolkit's is StringToObject and ObjectToString (convert IOR's to objects and back again). It all moves TEXT back and forth.
And as for error handling, the stubs and skeletons generally look for a starting ERROR indicator in the incoming data stream. Try throwing an exception from a client to a server. What happens? The Exception is turned into TEXT and streamed. It just happens that your generated code recognizes that type of stream and reconstitutes it into an Exception for you. That's just an layer on top of the streams interpretting the incoming data. No reason an XML-RPC library couldn't do the same, seeing as it has defined an error document.
The point of all this is simple. All of these technologies boil down to nothing more than moving data from client to server over a byte-oriented transport protocol (normally some layer on top of TCP/IP). None are necessarily better or worse than the others. None actually move 'objects', they move data which the reciever (either client or server) reconstitutes into objects. After all an object is nothing more than data that represents state with an interface that knows how to affect that state.
I've never seen where XML-RPC is touted as you say as
its the standard solution to all your distributed communications problems.
Anyone who makes a claim like that for ANY solution needs more experience. As I stated before, understand your requirements, use whatever tool does the job. There's no reason to use a dump truck when you can haul the load in a child's wagon.
What are objects (in this sense) except collections of data? XML-RPC can support returning structures so where's the difference?
What is object discovery? I can have a service that I can query for a URL that supports a function I need (kinda like CORBA's Interface Repository). Since when all is said and done, all you are doing is invoking a method somewhere, this works just fine.
SOAP doesn't require HTTP a a protocol, but I don't know of any reason XML-RPC does either. Both use HTTP in their specs for an example, but any protocol that can ship XML text should work.
HTTP is primarily used as their basis as it is known and can pass through firewalls.
XML-RPC is fully specified too. Just the specs are much smaller.
XML-RPC supports error handling as well. The spec has a definition of how to return an error.
Don't misunderstand, I'm not saying one is better than the other. I'm pointing out that the differences are far fewer than presented. Both do basically the same thing. One does it minimalistically, the other in a more inflated manner. You should examine your requirements carefully and use the best tool for the job.
SOAP is interesting, but getting bloated. There's
no reason to use something that heavy for simple messaging.
XMLRPC (from which the SOAP bubble formed) would probably work just as well.
Let's assume for a moment that Compaq actually means what they are saying that they intend to own the software. Obviously this goes against GPL.
So now, Compaq can do one of two things:
Change the license to agree with GPL
Change the software to avoid GPL license
Seeing as how Compaq is a Big Company, they may not be inclined to follow option 1. Corel was a different matter. They positioned themselves as a Linux distributor.
If Compaq decided to go route 2, then could they not switch to a BSD variant where they have more licensing control?
I've been curious up to now about all the companies building product around Linux, when the GPL would require they make the source available , except for the documented pieces that aren't touch by the GPL worm. Business does not actually like giving away anything that might be a competitive advantage.
So, my question on long term consequences, could it not be possible that the GPL could infact drive businesses away from using Linux and more toward one of the BSD's?
I'm fortunate to live in one of those progressive cities that is suing the gun makers because criminals use guns and when people get injured during crimes, public money is used to pay hospital bills.
Actually, the city can't balance it's budgets so it's looking for an easy (read tort) source of funds.
Funny. Starting in 1991, Al Stevens (a DDJ contributing columnist) created a text-mode GUI framework called D Flat. It was kinda like Turbo Vision as I remember.
???I seem to remember he named it D Flat because he didn't want to use C sharp, which was another windowing system????
Is this maybe a little bit of sour grapes? According to the site the company is:
Ready Set Net, A Open Source, Linux Based, Internet Development Company.
Since RedHat is getting so much attention many potential Linux users (i.e. companies) have been talking to them about support and services (which is how they intend to really make money). Obviously if companies are going with the big name, then Ready Set Net is facing stiff competition.
How can you agree with suing companies that make LEGAL products that are KNOWN to cause problems because they cause problems? If the products are that bad, outlaw them.
Of course the guns are protected by the constitution, so people that don't want to take responsibility for their own actions go to the courts instead. They can't change the constitution so they make it too expensive to be in business.
Should game manufactures get sued because a kid fails school by playing too much and not studying?
Actually I believe DEC was sued for keyboards as part of a carpal tunnel lawsuit. The petitioner's employer didn't have enough money to make the suit worthwhile to the laywer so he added DEC as the keyboard manufacturer. Deeper pockets.
Funny this question came up as I was considering asking something similar. I was wondering if perhaps we might consider looking at the problem from a different angle.
There seems to be agreement in the fact that the bandwidth and connectivity is increasing and soon may be as ubiquitous as the dialtone. That's a good thing.
A great deal of work is being done on web browsers to support more and more functionality. JavaScript, for examples, is an attempt to get programming in the browsers. Servlets are fine, but still constrained by the HTML widget set. Applets are problematic as Java support in browsers is problematic. And plugins are just plain problems.
Some folks have mentioned VNC as an alternative approach. Others mentioned X. How about a slightly different view.
Java seems to perform very well (at least where I work) on server side applications. So long as there is no GUI, the systems run great. This makes sense, as Java gives the developers a consistent processor/OS to code to. For non GUI apps, this is possible because most all OS have the same basic functionality (i.e. memory management, file system access, networking, process control, etc). The real differentiator is the user interfaces. All work differently (except Telnet;-) ).
So, why not create a viewer that is consistent and applications are written to it? I know X is sorta there, but there are some problems with client side requirements and no session saving.
What about building a browser that is nothing more than a canvas for paint commands and an event gatherer. Then, build graphics libraries for your favorite development tools (AWT.so, libx.so, Win32.DLL, etc) that use this viewer as the graphics context. Now we could run the applications anywhere.
How does this affect browsers? Well, instead of adding more and more functionality and rendering capability into the browser (XML+XSL, JavaScript, VBScript, etc), the web servers become the rendering engines. Put all the rendering at the server and just send the paint commands to the viewer.
This way users don't need to wait Until the browsers support what I need, or make different versions for different browsers. If new functionality is added to the server, then all users now see it.
I'm thinking something like the GGI project along with VNC (which there is a mapping to by the way), might get this type of project started.
I note that ATT labs which owns VNC is using it in conjunction with CORBA. They don't want to release that as they don't want to support it. But imagine the possibilities.
Sorry for the length of this post. Just thinking out loud.
Intersting you mention the "Indian" guy in Short Circuit. That actor was Fischer Stevens who played the corporate "security" guy in "Hackers". Interesting coincidence.....
Absolutely!! A-men!!!! In my role I'm responsible for not only architecture design, but review of application teams' development. Always, the teams that use the new-kool features of the languages/tools end up with slow, buggy hard to maintain software. The teams that do it simply, end up with fairly stable solid code. KISS should be a required course for all programmers!
Slashdot Mirror
Sorry, but they did not invent XML or SOAP. Typical embrace and extend scenario.
XML comes from SGML which existed before MicroSoft.
SOAP is a bloated enhancement of XML-RPC.
Amazing how many things MS is credited with 'inventing'.
GRUB is nice as it doesn't need re-installing after changing the configs, which means a rescue disk can mount the /boot partition and edit the grub.conf files and not have problems trying to re-write the boot record.
However, be warned...the kernel make files, if you rebuild the kernel and do an make install, try to invoke LILO after the new kernel is installed, which will replace the grub boot loader.
Coming from the perspective of years of designing and implementing enterprise application, I'm afraid I must disagree with "you really need to use OO". However, I do agree with the remainder concerning coming up with a model, if the model in question is modeling the communications layer between systems.
.NET will have it's benefits. However, considering that there are many large enterprises that have never used O-O that are fully functionaly, high speed and stable, if all .NET provides is an O-O method of performing functions in the enterprise, then I won't need it.
We have systems written in totally non-OO languages (MVS COBOL, Informix 4GL, RPC, etc) that we leverage quite nicely. Instead of forcing an object model on this, we use a system that either performs HTTP POST requests or passes XML documents around via the HTTP procotol and have adapters invoke the existing code.
For example, we have (don't laugh) COBOL code that generates XML documents. The COBOL code is invoked by an HTTP server listening on the MVS CICS system for POST's.
Currently it isn't necessary to have the COBOL code parse XML as it works quite well with key/value pairs from a POST.
The point was to utilize the existing available services in our 20+ year old enterprise without whole-scale re-writing. All we are doing is writing adapter's.
HTTP as a protocol works very well. Most of the activity with table maintenance in a large enterprise is OLTP, thus psuedo-conversational. HTTP works well in that environment as no real state needs maintaining on the service's side.
O-O is fine, CORBA is a nice idea as well.
First understand, I know perfectly well what an object is. I've been working with OO languages since C++ was first a front-end pre-processor for C. I have years of design and development experience in OO, and am highly compensated for that very knowledge. But that many years of experience results in the seeing of the base of these high level systems, and they are all the same. Kinda like the discovery of programming patterns by the Gang of Four.
I was making the point that to any remote procedure call mechanism, be it RPC, RMI, CORBA's IIOP, XML-RPC or SOAP, what is important is the data being moved, not the fact that objects are being invoked. The company I work for (one of the DOW 30 to give you size) has a heterogeneous environment that includes everything from old DEC Business Basic to Informix 4GL to Java Servlets (with everything in between). I've implemented CORBA interfaces that invoke 4GL compiled RPC servers. We've designed and written C shared libraries for invocation from MicroFocus COBOL to perform HTTP POST/GET requests to servlets that then invoke CORBA objects. Did the COBOL code know it would talk to an object? No. There's no object there, just a back end message reciever that moves data. The idea is to build interfaces to existing applications that make them available to new code. I can do that with any of the RPC methods, but objects aren't required.
To your points in detail:
Object discovery is the idea of using a registration or naming service. You tell a server that "I have an object [here] that conforms to interface [xyz]". Its a combination of CORBA's Interface Repository and directory services.
That's what I was saying. You are looking for an implementation of an interface (i.e. a method), not an object. Your code doesn't care what supplies the function. My comment was that the same thing can be accomplised with XML-RPC, so long as there is a recipient for the request (just like the actual Naming service implementation). Kinda like UDDI. I just make an XML-RPC call to a given recipient that tells me the URL of what I'm looking for. The details are stored someplace and my code knows the specific identification keys to ask.
As for the next comment block you make, there isn't a standard implementation of a Naming service either. (I'm my companies representative to the OMG). There is a specification for how a Naming service will work with CORBA 3, but the OMG doesn't put out a standard service. All that is required for a standard service is an agreed upon query language for the requesting client. Once the query language is defined, it could be used by CORBA, RMI or XML-RPC. Nothing prevents me from making an XML-RPC call to a remote service object that calls a CORBA Naming service.
CORBA has 12 different aspects to it - communication (which is what XML-RPC does, and nothing else) is just one of those 12 aspects.
In actuallity, CORBA has one aspect: IDL. It is the definition of how disparate systems can communicate with each other in a language-neutral manner. From this, there have been IDL definitions of various services that a complete ORB should provide. Your ORB may provide a complete set of functionality (from BOA to POA to IR to Naming to Transactioning) but they don't all provide it. And when all is said and done, all CORBA Stubs and Skeletons do is translate object's attributes into byte streams (using a fixed byte ordering and sizing) to allow streaming those attributes back and forth. Objects (which are code AND data) aren't sent. Try serializing a Java Hashtable object to your C++ CORBA Client. Does C++ know how to re-build the object? No, but it can take the data from the object and put it in a C++ implementation of the same interface. (RMI is different. It can stream a Java class' actual bytes to be dynamically loaded by the remote VM).
I also know that the XML-RPC spec indicates it works over HTTP. It was designed to as a means of invoking some message on some service in a simple (and firewall accessible) way. The header is specified for HTTP. What I said was that there is no reason it HAD to be HTTP. Granted, moving it to SMTP (for example) would break the spec as the header is now different, but all it is doing is moving TEXT back and forth. Nothing more. Look at the generated Stubs/Skeletons for any CORBA enabled code. You'll see that everything is moved as 8 bit bytes. Infact, a base function in most ORB toolkit's is StringToObject and ObjectToString (convert IOR's to objects and back again). It all moves TEXT back and forth.
And as for error handling, the stubs and skeletons generally look for a starting ERROR indicator in the incoming data stream. Try throwing an exception from a client to a server. What happens? The Exception is turned into TEXT and streamed. It just happens that your generated code recognizes that type of stream and reconstitutes it into an Exception for you. That's just an layer on top of the streams interpretting the incoming data. No reason an XML-RPC library couldn't do the same, seeing as it has defined an error document.
The point of all this is simple. All of these technologies boil down to nothing more than moving data from client to server over a byte-oriented transport protocol (normally some layer on top of TCP/IP). None are necessarily better or worse than the others. None actually move 'objects', they move data which the reciever (either client or server) reconstitutes into objects. After all an object is nothing more than data that represents state with an interface that knows how to affect that state.
I've never seen where XML-RPC is touted as you say as
its the standard solution to all your distributed communications problems.
Anyone who makes a claim like that for ANY solution needs more experience. As I stated before, understand your requirements, use whatever tool does the job. There's no reason to use a dump truck when you can haul the load in a child's wagon.
What are objects (in this sense) except collections of data? XML-RPC can support returning structures so where's the difference?
What is object discovery? I can have a service that I can query for a URL that supports a function I need (kinda like CORBA's Interface Repository). Since when all is said and done, all you are doing is invoking a method somewhere, this works just fine.
SOAP doesn't require HTTP a a protocol, but I don't know of any reason XML-RPC does either. Both use HTTP in their specs for an example, but any protocol that can ship XML text should work. HTTP is primarily used as their basis as it is known and can pass through firewalls.
XML-RPC is fully specified too. Just the specs are much smaller.
XML-RPC supports error handling as well. The spec has a definition of how to return an error.
Don't misunderstand, I'm not saying one is better than the other. I'm pointing out that the differences are far fewer than presented. Both do basically the same thing. One does it minimalistically, the other in a more inflated manner. You should examine your requirements carefully and use the best tool for the job.
SOAP is interesting, but getting bloated. There's no reason to use something that heavy for simple messaging. XMLRPC (from which the SOAP bubble formed) would probably work just as well.
So now, Compaq can do one of two things:
- Change the license to agree with GPL
- Change the software to avoid GPL license
Seeing as how Compaq is a Big Company , they may not be inclined to follow option 1. Corel was a different matter. They positioned themselves as a Linux distributor.If Compaq decided to go route 2, then could they not switch to a BSD variant where they have more licensing control?
I've been curious up to now about all the companies building product around Linux, when the GPL would require they make the source available , except for the documented pieces that aren't touch by the GPL worm. Business does not actually like giving away anything that might be a competitive advantage.
So, my question on long term consequences, could it not be possible that the GPL could infact drive businesses away from using Linux and more toward one of the BSD's?
Just wondering.
I had a copy of Windows 286 (came in the box with a mouse). Was it before or after Windows 1.0?
I'm fortunate to live in one of those progressive cities that is suing the gun makers because criminals use guns and when people get injured during crimes, public money is used to pay hospital bills.
Actually, the city can't balance it's budgets so it's looking for an easy (read tort) source of funds.
Funny. Starting in 1991, Al Stevens (a DDJ contributing columnist) created a text-mode GUI framework called D Flat. It was kinda like Turbo Vision as I remember.
???I seem to remember he named it D Flat because he didn't want to use C sharp, which was another windowing system????
Is this maybe a little bit of sour grapes? According to the site the company is:
Ready Set Net, A Open Source, Linux Based, Internet Development Company.Since RedHat is getting so much attention many potential Linux users (i.e. companies) have been talking to them about support and services (which is how they intend to really make money). Obviously if companies are going with the big name, then Ready Set Net is facing stiff competition.
Justa thought.
How can you agree with suing companies that make LEGAL products that are KNOWN to cause problems because they cause problems? If the products are that bad, outlaw them.
Of course the guns are protected by the constitution, so people that don't want to take responsibility for their own actions go to the courts instead. They can't change the constitution so they make it too expensive to be in business.
Should game manufactures get sued because a kid fails school by playing too much and not studying?
Actually I believe DEC was sued for keyboards as part of a carpal tunnel lawsuit. The petitioner's employer didn't have enough money to make the suit worthwhile to the laywer so he added DEC as the keyboard manufacturer. Deeper pockets.
There seems to be agreement in the fact that the bandwidth and connectivity is increasing and soon may be as ubiquitous as the dialtone. That's a good thing.
A great deal of work is being done on web browsers to support more and more functionality. JavaScript, for examples, is an attempt to get programming in the browsers. Servlets are fine, but still constrained by the HTML widget set. Applets are problematic as Java support in browsers is problematic. And plugins are just plain problems.
Some folks have mentioned VNC as an alternative approach. Others mentioned X. How about a slightly different view.
Java seems to perform very well (at least where I work) on server side applications. So long as there is no GUI, the systems run great. This makes sense, as Java gives the developers a consistent processor/OS to code to. For non GUI apps, this is possible because most all OS have the same basic functionality (i.e. memory management, file system access, networking, process control, etc). The real differentiator is the user interfaces. All work differently (except Telnet ;-) ).
So, why not create a viewer that is consistent and applications are written to it? I know X is sorta there, but there are some problems with client side requirements and no session saving.
What about building a browser that is nothing more than a canvas for paint commands and an event gatherer. Then, build graphics libraries for your favorite development tools (AWT.so, libx.so, Win32.DLL, etc) that use this viewer as the graphics context. Now we could run the applications anywhere.
How does this affect browsers? Well, instead of adding more and more functionality and rendering capability into the browser (XML+XSL, JavaScript, VBScript, etc), the web servers become the rendering engines. Put all the rendering at the server and just send the paint commands to the viewer.
This way users don't need to wait Until the browsers support what I need, or make different versions for different browsers. If new functionality is added to the server, then all users now see it.
I'm thinking something like the GGI project along with VNC (which there is a mapping to by the way), might get this type of project started.
I note that ATT labs which owns VNC is using it in conjunction with CORBA. They don't want to release that as they don't want to support it. But imagine the possibilities.
Sorry for the length of this post. Just thinking out loud.
Intersting you mention the "Indian" guy in Short Circuit. That actor was Fischer Stevens who played the corporate "security" guy in "Hackers". Interesting coincidence.....
Absolutely!! A-men!!!! In my role I'm responsible for not only architecture design, but review of application teams' development. Always, the teams that use the new-kool features of the languages/tools end up with slow, buggy hard to maintain software. The teams that do it simply, end up with fairly stable solid code. KISS should be a required course for all programmers!