
Envoyé par
SQLpro
Linux est gratuit, mais plus couteux en admin...
Pour avoir travaillé avec un spécialiste Windows, je peux te dire qu'il y a un certain nombre d'opération sous Windows qui nécessitent des interventions manuelles (non scriptable) et du coup quand tu dois réaliser l'opération sur un parc de serveur, le coût devient astronomique.
Après je n'ai pas les connaissances suffisantes pour affirmer dans l’absolu que l'un ou l'autre coûte plus cher en administration. Mais j'ai quand même le sentiment qu'il y a plus d'admin spécialiste Linux que Windows (auto formation sous Linux, les entreprises recherchent surement en priorité des ceritifiés pour les environnements Windows, manque d'accessibilité aux serveurs Windows, etc.)

Envoyé par
SQLpro
Le débat sur la facilité/qualité du langage est luis aussi stérile les deux étant à peu près au même niveau de version en version.
Le débat sur le cohérence est plus intéressant, mais reste mineur... Certes MS est plus cohérent, mais réserve quelques lacunes. Java l'est sans doute moins, mais avec un offre plus diversifié car plus ancienne.
Plutôt d'accord

Envoyé par
SQLpro
Non, pour moi, la vrai différence, essentielle, réside dans l'aspect "managé" du code.
D'un côté (.net) on dispose d'outils natif pour savoir en "live" comment le code se comporte... De l'autre c'est beaucoup moins évident.
Je connais pas les capacités de .net mais pour Java les outils ne manquent pas : dump mémoire (Java ou natif), dump thread (Java ou natif), décompilation du code, monitoring/paramétrage de TOUTES l'activité de la VM (GC, JIT, etc.), le tout en local mais aussi en distant. Sans compter le support de protocole de monitoring. Et le tout très aisément scriptable (pour réaliser des opérations automatiques de surveillance ou de diagnostic).
Et ce depuis au moins la version 1.4 (
20002002), soit
au moins deux ans avantdepuis aussi longtemps que la sortie de la première version de .Net

Envoyé par
SQLpro
Un exemple en pratique : SQL Server intègre une machine .net indépendante de la machine .net de l'OS, permettant de développer des routines SQL sous codage .net. Lorsque ces routines (procédures stockées, fonctions, types objets...) sont exécutées par SQL c'est sous le contrôle de SQL Server qui audite en permanence sa machine .net appelée SQL CLR. En cas de mauvaise conduite (par exemple une fonction récursive qui vampiriserait la mémoire) alors SQL Server peut décider de tuer les threads fautifs, afin de préserver la stabilité du serveur SQL...
Cela n'existe pas à ma connaissance dans la machine Java !
Pourquoi comparer Java avec SQL Server ?
Tu peux coder en Java sous Oracle DB si ca te fait plaisir. Celui-ci embarque aussi sa propre VM (voir plusieurs).
Pour le reste c'est applicatif. D'ailleurs un thread n'a pas de heap qui lui est propre, donc on peut simplement contrôler la taille de sa stack.
EDIT : Oups, erreur sur les dates de sortie de Java 1.4
5 |
0 |