Je l'ai pas encore essayé, mais ça ne saurait tarder.
Par contre, les limitations, je les trouve vraiment rigolotes. Franchement, si ce sont vraiment des limitations 'Majeures', il doit être plus que perfectionniste l'auteur de ce logiciel. A part peut-être l'absence du undo qui pourrait être ennuyeux, rien de bien méchant ... euh maichant pardon.
Pour les dépendances, ce qui simplifierait les choses ce serait d'avoir une base de donnée de packages installées dans tous les OS existants, comme c'est le cas dans beaucoup de distros Linux (Gentoo, Mdk, Debian, etc). Tu l'interroges et tu peux résoudre de suite les problèmes de compatibilité. Mais ça n'est pas le cas malheureusement, y compris pour les distros Linux qui n'ont pas toutes un système de gestion de packages. Pour Windows n'en parlons meme pas :-)
Un scan de la base de registre devrait suffire, encore que je ne sais pas si c'est possible avec Java. Et je ne sais pas si "non polluant" et "base de registres" sont compatibles.
La base de registre n'est pas accessible directement en Java, il faut passer par des librairies natives. Pour le support des raccourcis sauce Windows, on a été obligé d'en arriver là :-/ En meme temps on a bien limité la casse et on écrit rien dans la base de registre et au final IzPack reste bien "non polluant" sur un système Win32. De plus le support des raccourcis (et donc le besoin d'une librairie native) est optionnel. En meme temps, rien ne garanti qu'un soft aura une entrée dans la base de registre. Par exemple si tu dépend de Tomcat, il faut le chercher sur le disque, pas dans la base de registre. Donc au final c'est un problème assez compliqué :-/
Je ne sais pas si les MD5 seraient vraiment à envisager. Pardonne-moi si je me trompe, mais les MD5 servent à vérifier l'intégrité d'un fichier et non sa version, donc il faudrait comparer les MD5Sums de toutes les versions possibles d'un fichier. Est-ce que l'on peut avoir toutes les MD5Sum possibles d'un fichier? Si oui, est-ce raisonnable comme solution?
On peut considérer que si on cherche un fichier en particulier pour tester la présence d'un logiciel, les différentes versions seront différentes. Par exemple si je cherche la présence de Jakarta Ant, je vais chercher un fichier nommé "ant.jar". C'est lui qui contient les classes Java de Ant, donc d'une version à l'autre il est forcémment différent. Donc sa signature MD5 sera différente. Pour que l'on ait un conflit de signatures (2 fichiers différents avec la meme signature), la probabilité est très faible. Un MD5 permettrait donc d'identifier une version de fichier. Est-ce raisonnable de stocker différentes signatures ? Non :-) Tout ça pour dire que ce style de dépendance est très difficile à vérifier. Tout ce que l'on peut faire est implémenter des heuristiques assez lourdes, ce n'est pas très raisonnable.
C'est quoi "en O(0.5)"?
C'est quelque chose d'impossible :-) Plus sérieusement, reportes-toi à un cours de complexité algorithmique. Des exemples, meme si c'est hors-sujet :
a = 2 + b;
c = (a == 3) ? (5 * x) : 0;
Est de complexité O(1)
for (i = 0; i < 100; ++i)
std::cout << "Coucou !" << endl;
Risque de Virus ? Quand tu respires dans l'air il y a risque de virus aussi. Là je ne vois pas de 'risque' particulier. Bien sur on peut s'amuser à en mettre un dedans, comme on peut mettre des chevaux de troie dans des sources (cf openssl).
Pour le reste, tu n'as qu'à essayer, tu comprendra peut-etre mieux, qui sait ?
Ok, IzPack utilise les JAR un peu comme on peut utiliser des zip auto-exécutables sous MS Windows et ce n'est pas seulement pour des programmes Java qui auraient des librairies fournis sous formes .JAR.
Heu ... je vais expliquer. Un .jar n'est qu'un fichier zip. On a l'habitude en Java de grouper les classes compilées + d'autres resources (images, etc) dans le Jar. Un Jar peut etre exécutable, en spécifiant dans un fichier qu'il contient (nommé manifeste) la classe principale à utiliser (une qui contient une méthode statique main - idem int main(int argc, char **argv) en C/C++). Un installateur est donc un Jar exécutable. Autrement dit tu fais :
java -jar IzPack-install.jar
et ça le lance. L'avantage est aussi que tout est groupé dans le Jar, et accessoirement compressé. Après un Jar peut servir aussi à contenir des librairies. Il faut voir un Jar avant tout comme un groupement de classes Java.
Le boulot d'un générateur d'installateurs est de générer des installateurs et qu'il soit fait en Java, en C ou en smlurph ne doit pas changer cet objectif.
Tout à fait, sauf qu'en général si tu veux un installateur en Java, c'est que tu distribues quelque chose qui a un rapport avec Java. Sinon tu auras plutot tendance à utiliser des méthodes d'installations spécialisée pour chaque plateforme. C'est juste qu'en général, on utilise IzPack pour des logiciels Java car il y a un intéret immédiat. Pour installer un soft uniquement Linux par exemple, l'intéret serait bien moindre car tout le monde n'a pas de machine Java installée. Donc tu utilises plutot un installateur Java si ta cible d'utilisateurs utilise Java aussi.
La phrase IzPack, générateur d'installateurs de logiciels en Java vient... n'est AMHA pas très claire. Moi, j'ai compris que en Java était pour les logiciels, alors que c'était juste pour IzPack. Ce qui m'a conforté dans mon erreur était que toutes les réferences ( www.izforge.com/izpack/index.php3?content=references ) semblent être des programmes Java.
En effet ma phrase peut induire en erreur. Java est bien pour IzPack. Les références sont uniquement de programmes Java car à ma connaissance personne ne l'a utilisé pour autre chose que des programmes Java, ce qui correspond à ce que j'ai dit au paragraphe précédant.
Est-ce que ça gèrent aussi les dépendences? Histoire que ça n'installe pas un software qui auraient besoin de telles ou telles librairies.
Non. En fait on pourrait gérer des dépendances au niveau des paquets d'une installation (par exemple tu peux faire un paquet pour les fichiers obligatoires, un paquet pour la doc, etc). Pour une dépendance du style "ne pas installer si Jakarta Ant n'est pas sur la machine", le problème est très complexe. Sous un Unix-like, tu peux t'attendre à trouver ça dans /usr/**/ voir /opt/** . Sur un Windows par exemple, tu es bon pour te payer un scan du disque :-/ Sans compter que si tu veux vérifier la version, c'est encore moins simple. Avec des MD5 ça serait éventuellement envisageable. Mais dans l'ensemble ça reste sujet à erreurs et c'est très compliqué à faire. Mais si tu trouves une méthode efficace (style en O(0.5)) je suis preneur :-)
Personnellement, je pense qu'un fork découle de la création d'une deuxième branche de développement active à partir des sources. Donc, les deux branches de dev sont actives en même temps. Là, on aura une branche de dev morte et une active.
L'Itanium... ça fait longtemps qu'on l'attends celui là. De toutes façons, c'est à terme ce que vont faire quelques uns des constructeurs d'Unix proprio (les quels? Ben HP :) ).
Concernant zSeries, il y a toujours une couche os propriétaire IBM (zOS). Donc, non, c'est pas un Unix.
Premièrement, il n'y a aucune excuse technique pour mettre du Windows en production pour remplacer un Unix (quelqu'il soit). Bon, maintenant que le troll est posé, je peux continuer sérieusement :) .
Deuxièmement, Sun a encore de très beau jour devant lui. Il a une base installée très importante et ses serveurs sont en général de très bonne qualité, le support est quand même bien supérieur à ce qui se fait ailleurs (sauf peut-être celui d'IBM avec lequel je n'ai jamais eu a[f ]faire). Il y a certes le prix, mais les sociétés qui veulent que ça marche et qui ont les moyens de prendre des serveurs à quelques millions d' ont les moyens de prendre quelques admins Unix bien payés.
Pour la bureautique et les entreprises plus "pauvres", il reste Windows. Qui là aussi a encore de belles années devant lui. Malheureusement.
Qu'IBM et Sun investissent dans Linux, c'est bien. Enfin, c'est pas trop mal. Mais ils vendent moins de postes clients que des serveurs. Le jour où des sociétés qui vendent des postes clients (comme Dell ou Compaq) se mettront aussi à Linux avec un support digne de ce nom sur des postes bureautique, cela changera peut-être la donne.
HP est TRES loin d'abandonner le PA-RISC, et son architecture est très bien faite. C'est d'ailleurs le seul vrai concurrent de Sun sur les serveurs multi domaines Unix (je crois pas qu'IBM en fasse, en dehors des zSeries, qui ne sont pas des Unices).
Ah! Les clusters Oracle... Fonctionnent assez bien avec 2 noeux. Avec 3, tu as une "surcharge" pour la gestion du cluster de 30% (ça veux dire que tu gagne 70% de perf pour le noeux supplémentaire). A 4, ça passe 50%.
1 serveur -> 1
2 serveurs -> 1.9 (en vrai, c'est un peu plus, mais bon...)
3 serveurs -> 2.6
4 serveurs -> 3.1
Et bien sur ça s'arrête pas là. En gros, plus tu mets de serveurs, moins tu gagnes en perf. ça, c'est pour Oracle 8i, Oracle nous promettant pour la 9 un-truc-vachement-mieux. Mais on attend.
Je vois même pas d'ailleurs comment ils peuvent gagner 100% ou même 90% pour chaque serveur ajouté. C'est pas du mauvais esprit, mais techniquement, je voudrais savoir comment ils font.
Concernant le 'cluster' Linux de chez Google, quelqu'un a des infos? Parceque je voudrais bien voir si c'est un cluster, et si c'en est un, un cluster de quoi (calcul? base de donnée?).
Et une dernière précision sur le terme "cluster": cluster, tout seul ça veux pas dire grand chose. On a des clusters de calcul, des clusters à haute performance, à tolérance de panne, à répartition de charge (ce qui n'est pas tout à fait pareil que ceux à haute performance).
C'est sur que si tu compares jusqu'au quadri ou octo processeur...
Mais que penser quand tu a besoins de gérer une base de donnée en cluster de quelques tera octets? Une machine avec 32 proc et 32 Go de mémoire, c'est plus puissant que n'importe quel machine x86.
Le type qui passe sur la page principale et qui voit ca sans aller plus loin, il va se faire une idee completement fausse de la chose.
Non il ne se fera pas une idée fausse de la chose vu que c'est peu ou prou ce que pratique déjà Microsoft ... Il y a tellement d'exemples de ce genre de "pratiques" limite légales (voir pas du tout) que peu de gens seraient surpis d'apprendre une énième pratique foireuse de la part de ton employeur que tu défend avec tant de conviction.
[^] # Re: c'est domage que ibm et sun ai peur de hp compaq
Posté par Anonyme . En réponse à la dépêche Attention Sun débarque. Évalué à 1.
Le zSeries n'est pas un unix mais il gère le multidomaine.
Les Unix d'IBM ne gèrent pas le multidomaine, alors que les SuperDome HP et les SunFire le font.
J'ai voulu dire ça. Et toi, tu voulais dire quoi?
# Limitations
Posté par Anonyme . En réponse à la dépêche MlView: éditeur et validateur XML. Évalué à 10.
Par contre, les limitations, je les trouve vraiment rigolotes. Franchement, si ce sont vraiment des limitations 'Majeures', il doit être plus que perfectionniste l'auteur de ce logiciel. A part peut-être l'absence du undo qui pourrait être ennuyeux, rien de bien méchant ... euh maichant pardon.
[^] # Re: Que pour Java :-(
Posté par Anonyme . En réponse à la dépêche Sortie de IzPack 3. Évalué à 5.
Pour les dépendances, ce qui simplifierait les choses ce serait d'avoir une base de donnée de packages installées dans tous les OS existants, comme c'est le cas dans beaucoup de distros Linux (Gentoo, Mdk, Debian, etc). Tu l'interroges et tu peux résoudre de suite les problèmes de compatibilité. Mais ça n'est pas le cas malheureusement, y compris pour les distros Linux qui n'ont pas toutes un système de gestion de packages. Pour Windows n'en parlons meme pas :-)
[^] # Re: Enfin !
Posté par Anonyme . En réponse à la dépêche Sortie de IzPack 3. Évalué à -1.
[^] # Re: Que pour Java :-(
Posté par Anonyme . En réponse à la dépêche Sortie de IzPack 3. Évalué à 5.
La base de registre n'est pas accessible directement en Java, il faut passer par des librairies natives. Pour le support des raccourcis sauce Windows, on a été obligé d'en arriver là :-/ En meme temps on a bien limité la casse et on écrit rien dans la base de registre et au final IzPack reste bien "non polluant" sur un système Win32. De plus le support des raccourcis (et donc le besoin d'une librairie native) est optionnel. En meme temps, rien ne garanti qu'un soft aura une entrée dans la base de registre. Par exemple si tu dépend de Tomcat, il faut le chercher sur le disque, pas dans la base de registre. Donc au final c'est un problème assez compliqué :-/
Je ne sais pas si les MD5 seraient vraiment à envisager. Pardonne-moi si je me trompe, mais les MD5 servent à vérifier l'intégrité d'un fichier et non sa version, donc il faudrait comparer les MD5Sums de toutes les versions possibles d'un fichier. Est-ce que l'on peut avoir toutes les MD5Sum possibles d'un fichier? Si oui, est-ce raisonnable comme solution?
On peut considérer que si on cherche un fichier en particulier pour tester la présence d'un logiciel, les différentes versions seront différentes. Par exemple si je cherche la présence de Jakarta Ant, je vais chercher un fichier nommé "ant.jar". C'est lui qui contient les classes Java de Ant, donc d'une version à l'autre il est forcémment différent. Donc sa signature MD5 sera différente. Pour que l'on ait un conflit de signatures (2 fichiers différents avec la meme signature), la probabilité est très faible. Un MD5 permettrait donc d'identifier une version de fichier. Est-ce raisonnable de stocker différentes signatures ? Non :-) Tout ça pour dire que ce style de dépendance est très difficile à vérifier. Tout ce que l'on peut faire est implémenter des heuristiques assez lourdes, ce n'est pas très raisonnable.
C'est quoi "en O(0.5)"?
C'est quelque chose d'impossible :-) Plus sérieusement, reportes-toi à un cours de complexité algorithmique. Des exemples, meme si c'est hors-sujet :
Est de complexité O(1)
Est de complexité O(n)
[^] # Re: Que pour Java :-(
Posté par Anonyme . En réponse à la dépêche Sortie de IzPack 3. Évalué à 0.
Risque de Virus ? Quand tu respires dans l'air il y a risque de virus aussi. Là je ne vois pas de 'risque' particulier. Bien sur on peut s'amuser à en mettre un dedans, comme on peut mettre des chevaux de troie dans des sources (cf openssl).
Pour le reste, tu n'as qu'à essayer, tu comprendra peut-etre mieux, qui sait ?
[^] # Re: Que pour Java :-(
Posté par Anonyme . En réponse à la dépêche Sortie de IzPack 3. Évalué à 10.
Heu ... je vais expliquer. Un .jar n'est qu'un fichier zip. On a l'habitude en Java de grouper les classes compilées + d'autres resources (images, etc) dans le Jar. Un Jar peut etre exécutable, en spécifiant dans un fichier qu'il contient (nommé manifeste) la classe principale à utiliser (une qui contient une méthode statique main - idem int main(int argc, char **argv) en C/C++). Un installateur est donc un Jar exécutable. Autrement dit tu fais :
et ça le lance. L'avantage est aussi que tout est groupé dans le Jar, et accessoirement compressé. Après un Jar peut servir aussi à contenir des librairies. Il faut voir un Jar avant tout comme un groupement de classes Java.
Le boulot d'un générateur d'installateurs est de générer des installateurs et qu'il soit fait en Java, en C ou en smlurph ne doit pas changer cet objectif.
Tout à fait, sauf qu'en général si tu veux un installateur en Java, c'est que tu distribues quelque chose qui a un rapport avec Java. Sinon tu auras plutot tendance à utiliser des méthodes d'installations spécialisée pour chaque plateforme. C'est juste qu'en général, on utilise IzPack pour des logiciels Java car il y a un intéret immédiat. Pour installer un soft uniquement Linux par exemple, l'intéret serait bien moindre car tout le monde n'a pas de machine Java installée. Donc tu utilises plutot un installateur Java si ta cible d'utilisateurs utilise Java aussi.
La phrase IzPack, générateur d'installateurs de logiciels en Java vient... n'est AMHA pas très claire. Moi, j'ai compris que en Java était pour les logiciels, alors que c'était juste pour IzPack. Ce qui m'a conforté dans mon erreur était que toutes les réferences ( www.izforge.com/izpack/index.php3?content=references ) semblent être des programmes Java.
En effet ma phrase peut induire en erreur. Java est bien pour IzPack. Les références sont uniquement de programmes Java car à ma connaissance personne ne l'a utilisé pour autre chose que des programmes Java, ce qui correspond à ce que j'ai dit au paragraphe précédant.
Est-ce que ça gèrent aussi les dépendences? Histoire que ça n'installe pas un software qui auraient besoin de telles ou telles librairies.
Non. En fait on pourrait gérer des dépendances au niveau des paquets d'une installation (par exemple tu peux faire un paquet pour les fichiers obligatoires, un paquet pour la doc, etc). Pour une dépendance du style "ne pas installer si Jakarta Ant n'est pas sur la machine", le problème est très complexe. Sous un Unix-like, tu peux t'attendre à trouver ça dans /usr/**/ voir /opt/** . Sur un Windows par exemple, tu es bon pour te payer un scan du disque :-/ Sans compter que si tu veux vérifier la version, c'est encore moins simple. Avec des MD5 ça serait éventuellement envisageable. Mais dans l'ensemble ça reste sujet à erreurs et c'est très compliqué à faire. Mais si tu trouves une méthode efficace (style en O(0.5)) je suis preneur :-)
En espérant avoir répondu à tes questions ...
[^] # Re: RPM/DEB KILLER?
Posté par Anonyme . En réponse à la dépêche Sortie de IzPack 3. Évalué à 2.
[^] # Re: RPM/DEB KILLER?
Posté par Anonyme . En réponse à la dépêche Sortie de IzPack 3. Évalué à 10.
C'est une solution de déploiement multiplateformes, dont l'utilisation la plus courante est les logiciels Java.
RPMs et Debs n'ont rien à voir avec IzPack ...
[^] # Re: Que pour Java :-(
Posté par Anonyme . En réponse à la dépêche Sortie de IzPack 3. Évalué à 10.
MAIS tu peux installer ce que tu veux avec ...
[^] # Re: Pas de trace de Sun Linux 5.0 dans les free downloads...
Posté par Anonyme . En réponse à la dépêche Attention Sun débarque. Évalué à 1.
Je ne dirais qu'une chose: non. Rien ne les oblige à te donner les sources juste par le fait que tu les demandes.
[^] # Re: Fork? explication
Posté par Anonyme . En réponse à la dépêche Peng for aol: invitation au fork. Évalué à 2.
Ce n'est donc pas un fork.
[^] # Re: si t'es pas content tu participes
Posté par Anonyme . En réponse à la dépêche Attention Sun débarque. Évalué à -1.
[^] # Re: c'est domage que ibm et sun ai peur de hp compaq
Posté par Anonyme . En réponse à la dépêche Attention Sun débarque. Évalué à 3.
Concernant zSeries, il y a toujours une couche os propriétaire IBM (zOS). Donc, non, c'est pas un Unix.
[^] # Re: Fork?
Posté par Anonyme . En réponse à la dépêche Peng for aol: invitation au fork. Évalué à 0.
# Attention, troll en vue.
Posté par Anonyme . En réponse à la dépêche Drakian. Évalué à 10.
Et ben ça doit être un beau bordel ;-). Pourquoi pas utiliser Debian alors?
[-42]
[^] # Re: Sun et Linux
Posté par Anonyme . En réponse à la dépêche Attention Sun débarque. Évalué à 10.
Deuxièmement, Sun a encore de très beau jour devant lui. Il a une base installée très importante et ses serveurs sont en général de très bonne qualité, le support est quand même bien supérieur à ce qui se fait ailleurs (sauf peut-être celui d'IBM avec lequel je n'ai jamais eu a[f ]faire). Il y a certes le prix, mais les sociétés qui veulent que ça marche et qui ont les moyens de prendre des serveurs à quelques millions d' ont les moyens de prendre quelques admins Unix bien payés.
Pour la bureautique et les entreprises plus "pauvres", il reste Windows. Qui là aussi a encore de belles années devant lui. Malheureusement.
Qu'IBM et Sun investissent dans Linux, c'est bien. Enfin, c'est pas trop mal. Mais ils vendent moins de postes clients que des serveurs. Le jour où des sociétés qui vendent des postes clients (comme Dell ou Compaq) se mettront aussi à Linux avec un support digne de ce nom sur des postes bureautique, cela changera peut-être la donne.
[^] # Re: c'est domage que ibm et sun ai peur de hp compaq
Posté par Anonyme . En réponse à la dépêche Attention Sun débarque. Évalué à 4.
[^] # Re: Hum .. Orthographe .... [-]
Posté par Anonyme . En réponse à la dépêche Attention Sun débarque. Évalué à -3.
[-42]
[^] # Re: Sun ou Cobalt?
Posté par Anonyme . En réponse à la dépêche Attention Sun débarque. Évalué à 10.
1 serveur -> 1
2 serveurs -> 1.9 (en vrai, c'est un peu plus, mais bon...)
3 serveurs -> 2.6
4 serveurs -> 3.1
Et bien sur ça s'arrête pas là. En gros, plus tu mets de serveurs, moins tu gagnes en perf. ça, c'est pour Oracle 8i, Oracle nous promettant pour la 9 un-truc-vachement-mieux. Mais on attend.
Je vois même pas d'ailleurs comment ils peuvent gagner 100% ou même 90% pour chaque serveur ajouté. C'est pas du mauvais esprit, mais techniquement, je voudrais savoir comment ils font.
Concernant le 'cluster' Linux de chez Google, quelqu'un a des infos? Parceque je voudrais bien voir si c'est un cluster, et si c'en est un, un cluster de quoi (calcul? base de donnée?).
Et une dernière précision sur le terme "cluster": cluster, tout seul ça veux pas dire grand chose. On a des clusters de calcul, des clusters à haute performance, à tolérance de panne, à répartition de charge (ce qui n'est pas tout à fait pareil que ceux à haute performance).
[^] # Re: Sun ou Cobalt?
Posté par Anonyme . En réponse à la dépêche Attention Sun débarque. Évalué à 10.
Mais que penser quand tu a besoins de gérer une base de donnée en cluster de quelques tera octets? Une machine avec 32 proc et 32 Go de mémoire, c'est plus puissant que n'importe quel machine x86.
# Fork?
Posté par Anonyme . En réponse à la dépêche Peng for aol: invitation au fork. Évalué à 10.
La continuation d'un projet est quelquefois une meilleure solution que le fork, non?
[^] # Re: ça fait pas un peu rapace ça ?
Posté par Anonyme . En réponse à la dépêche GoBe Productive libéré !. Évalué à 2.
"allez y, vous pouvez vous défouller..."
# Ils auraient dû attendre Templeet.
Posté par Anonyme . En réponse à la dépêche Arrivée de [Mandrakefr.org]. Évalué à -10.
[-42]
[^] # Re: Moderateurs...
Posté par Anonyme . En réponse à la dépêche Microsoft interdit la vente de PCs sans OS. Évalué à 4.
Non il ne se fera pas une idée fausse de la chose vu que c'est peu ou prou ce que pratique déjà Microsoft ... Il y a tellement d'exemples de ce genre de "pratiques" limite légales (voir pas du tout) que peu de gens seraient surpis d'apprendre une énième pratique foireuse de la part de ton employeur que tu défend avec tant de conviction.