Cédric Chantepie a écrit 88 commentaires

Je crois avoir compris que ta mandrake demarre directement en X (graphique). Une fois loggé sous KDE en utilisateur normale, tu peux faire un ++<1> pour repasser en mode terminal.
En terminal tu fais un + pour finir le KDE lancé en utilisateur puis un petit "su" pour passer en root en terminal. Après être passer en root en terminal un petit "startx" devrait relancer KDE, cette fois en root.

Il y a surement plus propre mais sans me creuser le crane je ferrais comme ça.

Portage/emerge de gentoo gère les install de binaires depuis divers format d'archives (.tar.*, .zip, .rpm) et les install depuis sources également.

Personnellement je suis un contributeur récent à mozilla et je n'ai jamais eu de problème quant au passage de mes patch ; Le premier que j'ai proposé est passé en une nuit (http://www.mozilla.org/hacking/life-cycle.html(...)). (C'est peut être le joli T-shirt mozilla qui aide :-) ).

Quant à la doc xul c'est très vrai que c'est très ennuyeux, surtout que xulplanet a eu de serieux soucis dernièrement pour maintenir en ligne une doc potable. Ya tjs le LXR (http://lxr.mozilla.org/(...)) mais ca n'aide pas tjs.

Je viens de tester la construction d'interface un XUL, c'est génial la simplicité de fabrication comparable à du web avec toutes les fonctionnalité d'une interface client lourd.

Avec un bris de SOAP pour déporter les business logic sur un serveur d'appli est c'est le pied.

C'est un projet sourceforge open et gratuit mon cher

Script modifié utilisant le mktemp pour plus de sécurité.

#! /bin/sh 

TMPFILE=`mktemp /tmp/jit.XXXXXX`
CLASSNAME=`echo $TMPFILE | perl -p -e 's/jit\.//g;s/\/tmp\///g'`
CLASSFILE="/tmp/$CLASSNAME.java"

mv $TMPFILE $CLASSFILE

cat > $CLASSFILE << EOF
public class $CLASSNAME {
public static void main(String[] args) {
EOF
tail +2 $1 >> $CLASSFILE
cat >> $CLASSFILE << EOF
}
}
EOF

javac $CLASSFILE
rm -f $CLASSFILE
java -classpath /tmp $CLASSNAME
rm -f /tmp/$CLASSNAME.class

Ya le format .nib d'OS X aussi, c'est pas du XML mais c'est aussi un format de description qui permet de changer l'interface sans avoir à coder. A voir si c'est ouvert j'ai pas trouver cette information...

Soyez open un peu les gars

En fait si, tous les types de base sont en objet mais en partique manipulable également par des type primitifs, ex. int pour java.lang.Integer, char pour java.lang.Charater.

Exception pour String qui n'est qu'en objet.

C'est sur qu'en terme de performances pures C++ est plus puissant mais pas portable en réalité.

Si ton programme C++ dépend d'une lib C++ il faut que cette lib existe sur toute les plateformes, ce qui n'est pas toujours le cas.
En du moment qu'il ya un JVM pour la plateforme, quasi toute les plateformes, ta lib windows marchera sous la JVM linux et donc, le programme en Java dépendant de la lib fonctionnera lui aussi, à fortiori.

Et puis le C++ c'est moins objet (je dis pas que Java est tout objet, je dis qu'il est largement plus objet que C++), avec les histoires d'héritage multiple qui viole la notion d'objet.

C++ pour les performances pures
Java pour la portabilité et l'objet

- gestion en standart du multi-cpu
- reflexivité
- plein d'api gratuites
- très bon support des bases (en standart) avec jdbc
- une bonne api de distribué intégrée en standart
- connection aux annuaires (ldap, open directory, active directory , etc...) en trois coup de cuiller à pot
- Simplicité
- Objet

etc....

Quasi tout les compile Java que je connais sont en natif (pas en java eux-même), la force de celui d'IBM c'est surtout qu'IBM à réécrit de manière plus optimale les classes du JDK.

Celui d'Apple est pas mal non plus ;-)

Par forcement ya Exception et RuntimeException le tout est de bien chargé en fonction des cas.

EJB Exception Handling :
http://www-106.ibm.com/developerworks/java/library/j-ejb01283.html(...)

Je confirme qu'en ne faisant pas n'importe quoi Win2000 tient la route.
Ma bécane sous 2000 au bureau tient sans rebooter pendant plusieurs mois.

La dernière fois que j'ai rebooter c'était à cause d'un shareware pourri que je me suis empresser de dégager.

Vive linux quand même ;-)

Peut être que si Sun laisse ouvert Looking glass (Desktop 3D) ca pourrait être un bon successeur.

http://wwws.sun.com/software/looking_glass/(...)

C'est sur que la couche graphique n'est pas ouverte c'est quand même le principal attrait d'OS X qui permet à Apple de vivre. Si je ne me trompe c'est quartz et quicktime qui se charge de ça.

C'est sur si Apple libérait ne serait ce qu'une version beta de ces joli petits trucs ça serait génial mais faut pas leur en demande trop.

En même temps quand on compare les contributions d'Apple au libre
face à celle Microsoft il n'y a vraiment pas photo.

En échange de l'utilisation de KHTML, Apple contribue ses correctifs qui profite à Konqueror, de même pour Xfree du fait du port sous OS X.

De plus darwin est complètement ouvert, en GPL si je me souviens bien (cf. OpenDarwin basé dessus).

Tout n'est pas ouvert avec OS X mais Apple est loin d'être Microsoft.

Niveau érgonomie ca sert énormément.

Ex.: Tu veux un terminal pour compiler et faire ta petite cuisine mais tu veux aussi garder un oeil sur des logs. Tu mets ton terminal principal où tu compile avec une semi-transparence juste de quoi voir quand ton log derrière bouge. Il y a plein de cas dans ce genre ou s'est utile.

De plus ya pas de mal à avoir une belle interface graphique, ca ne rend pas plus bête pour autant (attention au vannes ;-) ).

Sous OS X le bureau est beau de base et surtout c'est toute la couche
graphique qui est belle. Il n'y a pas de couche graphique compositée
fonctionnant sous Linux, ca limite pas mal.

Sous Linux ca s'améliore mais bossant sur Linux et OS X (panther) je suis très loin de penser que Linux puisse également OS X avant un certain temps, même si je l'espère.

La majorité des applications cocoa sont loin de pouvoir tourner sous GNUStep du fait que sous OS X toute l'API graphique délègue à QuickTime hors, à moins de me tromper lourdement, il n'y pas de port quicktime (en tant qu'équivalent Direct X) sous Linux.

Ca s'est bien dommage quand on vois les outils de developpement qu'Apple à mis gratuitement à disposition des developpeurs (Xcode, Interface builder, ...). S'il avait une vraie compatibilité les applications graphiques seraient développées plus vite et de bien plus belle manière. Mais là c'est vrai que c'est un peu la faute d'Apple qui n'a pas libérer QuickTime, mais bon faut bien qu'ils vivent quand même...

Vive OS X, Vive cocoa et vive linux
(et bonjours aux autres unix pour faire bonne mesure).

C'est également mon avis, que c'est le plus prometteur, surtout de freedesktop ne propose pas seulement un prototype mais surtout des spécifications pour un meilleur desktop.

Ca bien joli mais ce n'est qu'un prototype rien de réellement utilisable

Ca sera pas de sitôt même avec la plus grande bonne volonté vu la beauté de l'interface OS X. Faut dire qu'il sont pas reparti de zero...

Ce qui serait quand même pas mal c'est que X sous linux supporte
une vraie transparence c'est partique pour pas mal de choses
(style les terminaux, consoles de log, etc...)

C'est -y sur certaine autre version

Voici l'adaptation pour des tests Java
de l'astuce de Salagnac (voir http://linuxfr.org/tips/197.html(...)). Cette adaptation permet de faire des test en Java sans avoir à compiler puis interpreter, à la JIT shell. 

===( Fichier "jit.sh" )===
#! /bin/sh 

cat > /tmp/Test.java << EOF
public class Test {
public static void main(String[] args) {
EOF
tail +2 $1 >> /tmp/Test.java
cat >> /tmp/Test.java << EOF
}
}
EOF 

javac /tmp/Test.java
rm -f /tmp/Test.java
java -classpath /tmp Test
rm -f /tmp/Test.class
===( Fin fichier "jit.sh" )=== 

Ensuite à chaque fois que l'on veux tester quelque chose en java en shell il suffit de executer un fichier sh du type : 

#! /bin/sh [ABSOLUTE_PATH_TO]/jit.sh 

System.out.println("#Test");