You don't know what your talking about. SAP does not run either Tomcat or JBOSS. Take a look at the file system structure of the SAP's J2EE engine, it is nothing like Tomcat or Jboss.
It would make perfect sense that an SAP consultant could not configure Tomcat or Jboss -- they are not SAP's products
How do you figure that SAP is closed source? 90 percent of the code that a business would need to change is fully readable and absolutely changable. SAP does require a key to modify their code, which is available to all their customers equally, but a customer is free to modify just about any of the code that a business would want or need to change. Customers are even allowed to take SAP code and clone it and make it their own by modifiying it. Although SAP's code is not completely open source it is far from closed source
I agree with you. this is just another attempt by Google to gain more ownership of our desktop. In my opinion they are on the same quest for domination that M$ has achieved.
I think that most very large corporations are looking to have better collaboration avenues with there vendors and suppliers. For example if you do business with a Ford or GM you typically interface them through a portal. It is becoming less frequent that word documents that need to be filled out by the vendor/supplier are being sent via email unless they are very specialized for that particular vendor/supplier. Most of the interaction between the two companies is done via the portal -- even inventories and supply chain information are being shared between the vendors/suppliers through the portal and external interfaces. Once the infrastructure is in place and doing "business" through a portal is more commonplace, the need for being on the same version of office software should diminish. For example some of the supply chain software that I work with uses pdf for output and pdf forms for input when a document is sent to an external source. I don't see us all having to be on the same office application, also because of the portal approach I don't see us having to be on the same browser either.
Also, although I agree with you regarding your filesystem to database comparison, running a rdbms engine --even if it is stripped down creates yet another abstraction layer between the user request and the hardware. I know from using SAP on high volume transactions systems that even Oracle's dbwr's (or even db_ioslaves) can get backlogged during periods of high write activity. I think I am going to take a "wait and see" approach with this type of filesystem.
I think a SQL based FS would be fine for an application that you are mentioning but what about more write intensive based needs like graphics and video. Could you imagine downloading your home video over a Firewire and rendering it? I don't think that having the intermediate layer of an MSDE would work in those cases. I also wonder how this would impact our SAMBA shares on our linux boxes?
Slashdot Mirror
You don't know what your talking about. SAP does not run either Tomcat or JBOSS. Take a look at the file system structure of the SAP's J2EE engine, it is nothing like Tomcat or Jboss.
It would make perfect sense that an SAP consultant could not configure Tomcat or Jboss -- they are not SAP's products
How do you figure that SAP is closed source? 90 percent of the code that a business would need to change is fully readable and absolutely changable. SAP does require a key to modify their code, which is available to all their customers equally, but a customer is free to modify just about any of the code that a business would want or need to change. Customers are even allowed to take SAP code and clone it and make it their own by modifiying it. Although SAP's code is not completely open source it is far from closed source
You should have researched this one first
I agree with you. this is just another attempt by Google to gain more ownership of our desktop. In my opinion they are on the same quest for domination that M$ has achieved.
No Firefox Google Toolbar for me
I agree, Google is a M$ wannabee. They want to touch all the information that an end user generates and stores. Please see their own press releaes @ http://www.google.com/intl/en/press/pressrel/deskt opsearch_for_enterprise.html
I think that most very large corporations are looking to have better collaboration avenues with there vendors and suppliers. For example if you do business with a Ford or GM you typically interface them through a portal. It is becoming less frequent that word documents that need to be filled out by the vendor/supplier are being sent via email unless they are very specialized for that particular vendor/supplier. Most of the interaction between the two companies is done via the portal -- even inventories and supply chain information are being shared between the vendors/suppliers through the portal and external interfaces. Once the infrastructure is in place and doing "business" through a portal is more commonplace, the need for being on the same version of office software should diminish. For example some of the supply chain software that I work with uses pdf for output and pdf forms for input when a document is sent to an external source. I don't see us all having to be on the same office application, also because of the portal approach I don't see us having to be on the same browser either.
I wonder if you could use a SQL command like "Select * from (hd01 or hd02..) where filetype = '.xls' :)
:)
It could mean some additional job security
Also, although I agree with you regarding your filesystem to database comparison, running a rdbms engine --even if it is stripped down creates yet another abstraction layer between the user request and the hardware. I know from using SAP on high volume transactions systems that even Oracle's dbwr's (or even db_ioslaves) can get backlogged during periods of high write activity. I think I am going to take a "wait and see" approach with this type of filesystem.
I think a SQL based FS would be fine for an application that you are mentioning but what about more write intensive based needs like graphics and video. Could you imagine downloading your home video over a Firewire and rendering it? I don't think that having the intermediate layer of an MSDE would work in those cases. I also wonder how this would impact our SAMBA shares on our linux boxes?