For my own part I do not disagree, however, and this is reality - I've met a number of sysadmins of small educational networks and probably others too who do not use the CLI in 99% of day to day use! This is not including the illiterates who do not even know what the "computer" is.
The sysadmins I mention didn't fail to understand the concepts - I quizzed them deeply and was shocked to see them not using a CLI with the depth of understanding they had. Looking further into the methods of work showed that they knew them well but they had to deal with so many issues they were stretched in their time and ability to pick up all the tools required to support multiple platforms - sometimes even the one they were working on. Most of the time that meant they stuck to Windoze and mostly used point and click interfaces. That's not to say they wouldn't use the CLI for emergencies or look up commands but their scripting skills were weak so CLI was mostly avoided. If admins like these need a script they download one or download a tool that does it for them or purchase one and, surprise, most of the time it does eleviate the requirement.
To move to other OS's means that those sysadmins are looking for a system that makes the concepts intuitive to implement - without having to learn commands that aren't intuitive. The illiterates also need this to the small extent that they need the tools at all.
Before anyone jumps on this as an argument of CLI/point and click - I use the examples only to highlight a point. The argument is one of transferable skills related to the concepts behind system administration. CLIs do allow this if the CLI is standardised across OS and people are prepared to learn, but it usually isn't. GUI interfaces are rarely standardised but they are intuitive and well designed and can help boost platforms by making day to day skills easy to pick up on a platform.
A web service may mean an application hosted somewhere accessed via a browser - it may still be an application though it may just be a piece of data in a specific format rendered by the browser. I don't see how this can be delineated - should this be delineated by static/dynamic pages maybe?
However, if we say it is an application and its built from open source code (whether as a "web service" or not) the rules are clear, the code must be open but, if its just built on top of and by using open source tools but includes none of the code the rules are negated - even when they rely on open source systems to run there is no comeback from the community. In the dim and distant past applications used to be something that you could run on top of an operating system completely in isolation. This is without relying on code from others and if you did rely on the code then you had to have the code licensed. My understanding is that the GPL allows this to take place which is why it is an easy target for a quick buck...
It isn't just web applications either - we're gradually seeing more applications that provide development frameworks, hosting environments, operating systems, ideas and projects remaining open source. These are the kind that makes distros bloat before becoming "extended" by companies into "products" - by providing management interfaces and other stuff too numerous to mention. Proprietary "add-on" services are then provided by developing using these tools, developing using the ideas as a base and using the hosting and operating systems to run them. Again my understanding is that there is no rule in the license of open code to prevent its reuse in this way...
There is only one downside to companies producing applications around open code depending on whether they have any respect for the community. Companies that do produce proprietary products are on their own - their "product" is not a community one, they shouldn't expect community support or development of open code not to break their "product" or expect the community not to fork the base community product or produce competitive applications. The code is there for anyone to use not just people wanting to use it in a proprietary way.
It might be a mistake but its still a deal and I suspect one they couldn't get out of if they tried.
Besides, did anyone really think that because they admitted they had screwed up they'd suddenly turn down all those nice little vouchers that mean sales of Suse?
Lets face it, they are playing a dangerous game, courting MS to get compatibility and acceptance whilst trying to sit on the fence and not get completely hosed in the process.
8Gb FC v 10Gb iSCSI? Well thats 2Gb potential bandwidth more...
Tcpip is not really a limiting factor.
In test I've seen boxes demo'd using IOMeter and the like showing iSCSI boxes with 10Gb with throughputs of 800MBps or higher whilst 2 x 4Gb FC connected SANs of a higher price were only pushing 600MBps.
As someone else here says - the disks are slow. The limitation in any well designed SAN is disk spindles and disk seek times and unfortunately most iSCSI boxes are SATA disks not SAS or Fibre Channel disk.
SATA is big with higher seek times and it has approximately 1/4 the throughput of SAS or FC disk.
If your disk is decent, the raid cards in the iSCSI boxes are up to the task (some are just plain cheap - if they aren't just cheap servers running Windows Storage Server) and you have the network bandwidth on the iSCSI boxes then you should look elsewhere for your performance limit not blame iSCSI or TCPIP in general.
Q. Are your switches configured for Jumbo frames?
Q. Is you bandwidth to the SAN through the same network cards as the normal network data?
Q. Are your servers performance not able to load the iSCSI boxes?
Any of these may be the other factors...
Slashdot Mirror
For my own part I do not disagree, however, and this is reality - I've met a number of sysadmins of small educational networks and probably others too who do not use the CLI in 99% of day to day use! This is not including the illiterates who do not even know what the "computer" is.
The sysadmins I mention didn't fail to understand the concepts - I quizzed them deeply and was shocked to see them not using a CLI with the depth of understanding they had. Looking further into the methods of work showed that they knew them well but they had to deal with so many issues they were stretched in their time and ability to pick up all the tools required to support multiple platforms - sometimes even the one they were working on. Most of the time that meant they stuck to Windoze and mostly used point and click interfaces. That's not to say they wouldn't use the CLI for emergencies or look up commands but their scripting skills were weak so CLI was mostly avoided. If admins like these need a script they download one or download a tool that does it for them or purchase one and, surprise, most of the time it does eleviate the requirement.
To move to other OS's means that those sysadmins are looking for a system that makes the concepts intuitive to implement - without having to learn commands that aren't intuitive. The illiterates also need this to the small extent that they need the tools at all.
Before anyone jumps on this as an argument of CLI/point and click - I use the examples only to highlight a point. The argument is one of transferable skills related to the concepts behind system administration. CLIs do allow this if the CLI is standardised across OS and people are prepared to learn, but it usually isn't. GUI interfaces are rarely standardised but they are intuitive and well designed and can help boost platforms by making day to day skills easy to pick up on a platform.
What is an application?
A web service may mean an application hosted somewhere accessed via a browser - it may still be an application though it may just be a piece of data in a specific format rendered by the browser. I don't see how this can be delineated - should this be delineated by static/dynamic pages maybe?
However, if we say it is an application and its built from open source code (whether as a "web service" or not) the rules are clear, the code must be open but, if its just built on top of and by using open source tools but includes none of the code the rules are negated - even when they rely on open source systems to run there is no comeback from the community. In the dim and distant past applications used to be something that you could run on top of an operating system completely in isolation. This is without relying on code from others and if you did rely on the code then you had to have the code licensed. My understanding is that the GPL allows this to take place which is why it is an easy target for a quick buck...
It isn't just web applications either - we're gradually seeing more applications that provide development frameworks, hosting environments, operating systems, ideas and projects remaining open source. These are the kind that makes distros bloat before becoming "extended" by companies into "products" - by providing management interfaces and other stuff too numerous to mention. Proprietary "add-on" services are then provided by developing using these tools, developing using the ideas as a base and using the hosting and operating systems to run them. Again my understanding is that there is no rule in the license of open code to prevent its reuse in this way...
There is only one downside to companies producing applications around open code depending on whether they have any respect for the community. Companies that do produce proprietary products are on their own - their "product" is not a community one, they shouldn't expect community support or development of open code not to break their "product" or expect the community not to fork the base community product or produce competitive applications. The code is there for anyone to use not just people wanting to use it in a proprietary way.
It might be a mistake but its still a deal and I suspect one they couldn't get out of if they tried. Besides, did anyone really think that because they admitted they had screwed up they'd suddenly turn down all those nice little vouchers that mean sales of Suse? Lets face it, they are playing a dangerous game, courting MS to get compatibility and acceptance whilst trying to sit on the fence and not get completely hosed in the process.
8Gb FC v 10Gb iSCSI? Well thats 2Gb potential bandwidth more... Tcpip is not really a limiting factor. In test I've seen boxes demo'd using IOMeter and the like showing iSCSI boxes with 10Gb with throughputs of 800MBps or higher whilst 2 x 4Gb FC connected SANs of a higher price were only pushing 600MBps. As someone else here says - the disks are slow. The limitation in any well designed SAN is disk spindles and disk seek times and unfortunately most iSCSI boxes are SATA disks not SAS or Fibre Channel disk. SATA is big with higher seek times and it has approximately 1/4 the throughput of SAS or FC disk. If your disk is decent, the raid cards in the iSCSI boxes are up to the task (some are just plain cheap - if they aren't just cheap servers running Windows Storage Server) and you have the network bandwidth on the iSCSI boxes then you should look elsewhere for your performance limit not blame iSCSI or TCPIP in general. Q. Are your switches configured for Jumbo frames? Q. Is you bandwidth to the SAN through the same network cards as the normal network data? Q. Are your servers performance not able to load the iSCSI boxes? Any of these may be the other factors...