Malek's Moorish Tales

Meanderings about life and technology

Is Linux a viable choice for servers

Off course Linux is not a viable choice for desktop (even Red Hat says so), but is it for servers ?

A few untrue perceptions (Secure, free, fast ...) about Linux and its value for the entreprise lead many people to think so. Here is my two cents :

1- Linux is secure :

OpenBSD

8

Trustix

18

EnGarde

20

Microsoft(Windows all versions)

26

SuSE

32

Sun

41

Mandrake

82

RedHat

82

Debian

139

  • As this claim of Linux being more secure gets the number of deployed Linux systems up, the vulnerabilities start rising quickly (two years ago, one had to add up all linux vulnerabilities for all distributions to get a number close to that of a single Windows version. today, one add up all the vulmnerabilities of all versions of windows to get a number far below that of single distributions of Linux.) How much longer cn this message of

2- Linux is free :

  • Is it really free ? the cost of ownership of a software is never just the cost of the licencing. It includes deployment, maintenance, and operation. this would at least make Linux not really much cheaper than commercial OSs.
  • In a server environment, especially in the entreprise, servers are not independent stand-alone machines, they have to fit in Kerberos realms, use LDAP, which are never out-of the box features on a Linux, and usually would become : go get the download, then spend a good portion of your time (never free in the entreprise) making it work, at your own risks for later maintenance and support ...
  • The cost of the Application Servers, Transactional Monitors, Middleware and Message Brokers make any difference in the OS costs insignificant.
  • Do we really want a free OS : the binding relation between a vendor and the entreprise is that of customer and vendor, ie: the lincence purchase. If there is no such relation between them, there could not be a binding guarantee on the quality of the software, or that of fixing up any problems that might arise later. It was not hard for Red Hat to simply say they will stop producing, supporting or patching Red Hat Linux. It was so easy for them to say so because their product was free. Do we want to base our system on an OS than can just decide someday to vanish ?

3 - Linux is Fast :

  • If Linux can be a performant solution for appliances, it certainly looses of its perf attractiveness when there are serious applications on top of it. The OS is much lighter than Windows for example, but as one starts adding the necessary modules such as LDAP, Kerberos, Transactional monitor, Web Services, Message Broker, ...etc., its performance is much more linked to the performance of the applications server used. To compare for example the perf between Linux and Windows, one should compare a WebSphere over Linux, or WebLogic over Linux, with a Windows 2003. Then Linux is no longer performant.

4- Linux is there to last :

  • Although I never like making "propheties", I will still venture with a sentence that might seem full of pretention and irrationality : Linux will not last much longer. What I mean is basically that it will not continue evolving as open source. There will be quite a few commercial product based on Linux, but they will have a very hard time competing, and keeping out of trouble, among all the copyright violations that made up Linux in the first place. When I look at the Red Hat Licence pricing (on average 3 times more expensive than Windows if we allow a version of Windows to be used for three years).
  • There cannot be a business model based of free products. Therefore, either the products becomes paying, or it vanishes from the marketplace. There can be community software that is open source and free, but it will never be interesting for the entreprise to use such an unsupported, loosely tested software...

Is Linux a viable choice for servers

Off course Linux is not a viable choice for desktop (even Red Hat says so), but is it for servers ?

A few untrue perceptions (Secure, free, fast ...) about Linux and its value for the entreprise lead many people to think so. Here is my two cents :

1- Linux is secure :

OpenBSD

8

Trustix

18

EnGarde

20

Microsoft(Windows all versions)

26

SuSE

32

Sun

41

Mandrake

82

RedHat

82

Debian

139

  • As this claim of Linux being more secure gets the number of deployed Linux systems up, the vulnerabilities start rising quickly (two years ago, one had to add up all linux vulnerabilities for all distributions to get a number close to that of a single Windows version. today, one add up all the vulmnerabilities of all versions of windows to get a number far below that of single distributions of Linux.) How much longer cn this message of

2- Linux is free :

  • Is it really free ? the cost of ownership of a software is never just the cost of the licencing. It includes deployment, maintenance, and operation. this would at least make Linux not really much cheaper than commercial OSs.
  • In a server environment, especially in the entreprise, servers are not independent stand-alone machines, they have to fit in Kerberos realms, use LDAP, which are never out-of the box features on a Linux, and usually would become : go get the download, then spend a good portion of your time (never free in the entreprise) making it work, at your own risks for later maintenance and support ...
  • The cost of the Application Servers, Transactional Monitors, Middleware and Message Brokers make any difference in the OS costs insignificant.
  • Do we really want a free OS : the binding relation between a vendor and the entreprise is that of customer and vendor, ie: the lincence purchase. If there is no such relation between them, there could not be a binding guarantee on the quality of the software, or that of fixing up any problems that might arise later. It was not hard for Red Hat to simply say they will stop producing, supporting or patching Red Hat Linux. It was so easy for them to say so because their product was free. Do we want to base our system on an OS than can just decide someday to vanish ?

3 - Linux is Fast :

  • If Linux can be a performant solution for appliances, it certainly looses of its perf attractiveness when there are serious applications on top of it. The OS is much lighter than Windows for example, but as one starts adding the necessary modules such as LDAP, Kerberos, Transactional monitor, Web Services, Message Broker, ...etc., its performance is much more linked to the performance of the applications server used. To compare for example the perf between Linux and Windows, one should compare a WebSphere over Linux, or WebLogic over Linux, with a Windows 2003. Then Linux is no longer performant.

4- Linux is there to last :

  • Although I never like making "propheties", I will still venture with a sentence that might seem full of pretention and irrationality : Linux will not last much longer. What I mean is basically that it will not continue evolving as open source. There will be quite a few commercial product based on Linux, but they will have a very hard time competing, and keeping out of trouble, among all the copyright violations that made up Linux in the first place. When I look at the Red Hat Licence pricing (on average 3 times more expensive than Windows if we allow a version of Windows to be used for three years).
  • There cannot be a business model based of free products. Therefore, either the products becomes paying, or it vanishes from the marketplace. There can be community software that is open source and free, but it will never be interesting for the entreprise to use such an unsupported, loosely tested software...

Le pinguin qui disparait dans le chapeau rouge!

Un courrier reçu par 2 de mes amis stipule que Red Hat arrête de produire, supporter ou produire des correctifs sur sa gamme Red Hat Linux. Mieux encore, ils encouragent tous les clients Rad Hat Linux de passer sur la gamme Red Hat Enterprise Linux (deux années pour le prix d’une seule) … voir liste des prix sur http://www.redhat.com/software/rhel/purchase/index.html qui montrent immédiatement des produits beaucoup plus cher que ceux de « l’empire du mal ».

Linux gratuit, enfin, à Licence gratuite (car le coût total de propriété concerne beaucoup plus l’exploitation que la licence), il en reste encore quelques distributions … probablement pour pas très longtemps, et juste pour mieux vous appâter avant de vous faire avaler l’hameçon … et là, comment leur échapperez-vous ?

Hosting the CLR Panel

These are my notes on the Hosting the CLR Panel. I will try to arrange them and make them more readable later on.

   On the panel, Mahesh Prakriya, Chris Brumme, Sean Trowbridge, Chris Brown, Dimitry Robsman(ASPNet), Jose Blakeley(SQL), Mark Alcazar (Longhorn), and Thomas Quinn from Microsoft, and Andrew Murchinson from IBM (DB2).

  
Q : Chris brown, What is the hosting API ?
A : First, the original hosting environment had 11 pages to describe the APIs, the whidbey one is 106 pages long. It is made of  COM interfaces to change the threading model, memory allocation, synchronization primitives, and other extensions to the regular interoperability methods ...

Q : Is IBM thinking of using an alternative implementation of CLR on its alternative plateform ?
IBM : The initial implementation is only for NT and thus will use the Microsoft Runtime. On next versions, We are thinking about Mono ...

Q : overhead on memory ?
A : overhead of several megs, ASPNET first app domain about 10 Mb on empty, subsequent around 1Mb ... Loader optimization to balance perf and overhead (single domain/multi app domains)

Q: Rule of thumb ?
A: single domain is faster for static, initialization ... multi domain, costs related to sharing and preventing side effects. Trying to make that better in whidbey.

Q: hosting 1.0 CLR. some client tried to use 1.1, and had problems. How to prepare for compatibility
A: office way, not have the config file (Clr version) makes the latest version load
   in SQL, ASPNet, DB2 biding to the specific version for stability and dynamically choosing the version to load

Q: SP calling an object defined on the host (ex: reporting services, write a formula in .Net, calling a ref to an object exposed by the host) ?
A: SQL, is value based.
   Fragments of the user code :
 - state

Q: programming model for SQL is limited. programming models in the particular hosting scenarios will be different ?
A: hoping others will behave

Q: something like CLS ? or informal guidelines ?
A: not aware of any attempts to standardization.

Q: unamaged code hosting the CLR
A: if it is just to deal with memory pressure, GC ... large amounts of unmanged, relating to some managed objects, inside whidbey it is possible to link those to GC
Q: How about synchronization ?
A: depends on the level at which the sync is needed

Q: Rule engine
A: reflexion emit, use compiler and load the class from file. what level ? a compiler, higher level language, persistant store (laughs) ... like Store procedure or user defined functions. light weight code generation APIs if no meta Data.

Q: legacy Win32 app. Host CLR and start using managed ?
A: COM Interop ... or IJW - if multi-app domains, then maybe to think about it.

Q: Licensing issue for hosting the CLR
A: none.
Q: ISV doing it ?
A: will not speculate.

Q: created a managed COM object, and make it not appear in the default app domain (VS calling the add in)
A: Threading models issues... launch app domain, and call from it ... obviously no good answer (just inventive ideas). in the longhorn timeframe might be solved
Q: in office, is it one runtime per process ?
A: one runtime per process
Q: hosting API is not part of CLI
A: should it be ?

Q: hosting vs MCpp
A: com interop vs MCpp, MCpp is less cosly
   hosting ? don't know exactely, but MCpp would look the way to go for less costs

Q: 120 pages can be scary
A: that stuff is used by SQL, not necessary to use all the interfaces

the v1 is what most apps will need.

hosting is really about extensibility and tuning how the runtime is used ...

DB2 created own class loader.

Q: ASPNet in addition to hosting CLR, has its hosting APIs.
A: app domains conveniently ...

Q: upgrading from 1.0 to 1.1 cused problems (regiis to get it back to old version)
A: taking it seriously, do not upgrade ...

Q: loading an assembly, what SQL does, what steps at creation, what steps at loading -is there NGEN
A: store user asemblies in the database. prefer to load from DB except those in GAC. intercept reference resolving and go get the assemblies (detach from database, attach somexhere else ...), CAS, well behaved and no conflicting parallel executions. At runtime, rely on runtime checks.NGEN not used (restriction to file system assemblies, ...

   DB2 looks up asemblies in the file system.

Q: Porting to managed or hosting
A: SQL millions of lignes of unmanaged, impossible to upgrade in short or midterm. hosting gives the exetensibility needed.

Q: different localization processes ?
A: match locale of the DB

Q: CLR GC control. objects that are machine wide shared.
A: CLR self tunning. hosting can control GC. machine wide shared not feasible.

Q: serevr vs workstation CLR
A: workload.if MT, server can add perf. Workstation useful in uniproc.

Hosting the CLR Panel

These are my notes on the Hosting the CLR Panel. I will try to arrange them and make them more readable later on.

   On the panel, Mahesh Prakriya, Chris Brumme, Sean Trowbridge, Chris Brown, Dimitry Robsman(ASPNet), Jose Blakeley(SQL), Mark Alcazar (Longhorn), and Thomas Quinn from Microsoft, and Andrew Murchinson from IBM (DB2).

  
Q : Chris brown, What is the hosting API ?
A : First, the original hosting environment had 11 pages to describe the APIs, the whidbey one is 106 pages long. It is made of  COM interfaces to change the threading model, memory allocation, synchronization primitives, and other extensions to the regular interoperability methods ...

Q : Is IBM thinking of using an alternative implementation of CLR on its alternative plateform ?
IBM : The initial implementation is only for NT and thus will use the Microsoft Runtime. On next versions, We are thinking about Mono ...

Q : overhead on memory ?
A : overhead of several megs, ASPNET first app domain about 10 Mb on empty, subsequent around 1Mb ... Loader optimization to balance perf and overhead (single domain/multi app domains)

Q: Rule of thumb ?
A: single domain is faster for static, initialization ... multi domain, costs related to sharing and preventing side effects. Trying to make that better in whidbey.

Q: hosting 1.0 CLR. some client tried to use 1.1, and had problems. How to prepare for compatibility
A: office way, not have the config file (Clr version) makes the latest version load
   in SQL, ASPNet, DB2 biding to the specific version for stability and dynamically choosing the version to load

Q: SP calling an object defined on the host (ex: reporting services, write a formula in .Net, calling a ref to an object exposed by the host) ?
A: SQL, is value based.
   Fragments of the user code :
 - state

Q: programming model for SQL is limited. programming models in the particular hosting scenarios will be different ?
A: hoping others will behave

Q: something like CLS ? or informal guidelines ?
A: not aware of any attempts to standardization.

Q: unamaged code hosting the CLR
A: if it is just to deal with memory pressure, GC ... large amounts of unmanged, relating to some managed objects, inside whidbey it is possible to link those to GC
Q: How about synchronization ?
A: depends on the level at which the sync is needed

Q: Rule engine
A: reflexion emit, use compiler and load the class from file. what level ? a compiler, higher level language, persistant store (laughs) ... like Store procedure or user defined functions. light weight code generation APIs if no meta Data.

Q: legacy Win32 app. Host CLR and start using managed ?
A: COM Interop ... or IJW - if multi-app domains, then maybe to think about it.

Q: Licensing issue for hosting the CLR
A: none.
Q: ISV doing it ?
A: will not speculate.

Q: created a managed COM object, and make it not appear in the default app domain (VS calling the add in)
A: Threading models issues... launch app domain, and call from it ... obviously no good answer (just inventive ideas). in the longhorn timeframe might be solved
Q: in office, is it one runtime per process ?
A: one runtime per process
Q: hosting API is not part of CLI
A: should it be ?

Q: hosting vs MCpp
A: com interop vs MCpp, MCpp is less cosly
   hosting ? don't know exactely, but MCpp would look the way to go for less costs

Q: 120 pages can be scary
A: that stuff is used by SQL, not necessary to use all the interfaces

the v1 is what most apps will need.

hosting is really about extensibility and tuning how the runtime is used ...

DB2 created own class loader.

Q: ASPNet in addition to hosting CLR, has its hosting APIs.
A: app domains conveniently ...

Q: upgrading from 1.0 to 1.1 cused problems (regiis to get it back to old version)
A: taking it seriously, do not upgrade ...

Q: loading an assembly, what SQL does, what steps at creation, what steps at loading -is there NGEN
A: store user asemblies in the database. prefer to load from DB except those in GAC. intercept reference resolving and go get the assemblies (detach from database, attach somexhere else ...), CAS, well behaved and no conflicting parallel executions. At runtime, rely on runtime checks.NGEN not used (restriction to file system assemblies, ...

   DB2 looks up asemblies in the file system.

Q: Porting to managed or hosting
A: SQL millions of lignes of unmanaged, impossible to upgrade in short or midterm. hosting gives the exetensibility needed.

Q: different localization processes ?
A: match locale of the DB

Q: CLR GC control. objects that are machine wide shared.
A: CLR self tunning. hosting can control GC. machine wide shared not feasible.

Q: serevr vs workstation CLR
A: workload.if MT, server can add perf. Workstation useful in uniproc.