bad sheep a écrit 476 commentaires

Sous Mac aussi d'ailleurs: caps lock + accent

Fukushima a changé quelque chose, pour beaucoup de gens non-hostiles au nucléaire comme moi auparavant, car autant on pouvait blâmer l'URSS d'utiliser des technologies obsolètes et de ne pas donner trop d'importance à la sécurité (c'était d'ailleurs l'argument principal des pro-atome depuis 1987), autant il est difficile d'accuser les Japonais de la même façon : si eux ont merdé comme ils l'ont fait, nous, occidentaux, Français, ne sommes pas du tout à l'abri. Les Japonais ont plutôt une réputation de superpuissance technologique et de rigueur enviée par de nombreux pays, nous compris.

Ouaip, super simple les tests, tes super tests ne disent pas par contre si le probleme est genre l'anti-virus qui intercepte toutes les requetes disque au hasard, ou autre, parce qu'au final tu fais un test sans meme comprendre ce que tu testes (par exemple que le soft utilise (Visual Studio) soit moins efficace que grep).

J'ai pu constater exactement les mêmes symptômes depuis longtemps sous Windows… l'écart est moins conséquent sous 7 que sous XP, mais il existe encore bel et bien. Y compris en utilisant les outils similaires (grep sous Windows), les perfs ne sont juste pas là. Personnellement, je n'ai jamais compris comment fonctionnait le cache de fichiers Windows, et dans tous les cas, ça marche mal, tout au moins pour ce que j'en fais, à savoir compiler et faire des recherches dans des fichiers.

Supputation, tu supputes que le FS de Windows n'est pas performant, alors que tu n'en sais fichtre rien.

En tous cas, ça marche très mal pour compiler, j'ai remarqué exactement la même chose depuis de nombreuses années.

2) avec une gestion de la mémoire performante, ils n'y sont pas.

Idem

Je n'ai pas bossé sérieusement en développement avec gestion de la mémoire sous Vista/7, mais j'approuve ! Du temps d'XP (et antérieurs), l'allocateur est à chier en fait du gruyère, conduisant à des impossibilités d'allouer plus de mémoire très rapidement.
Alors, oui, on peut le changer, mais celui par défaut, c'est à dire celui qui est utilisée par 95% des programmes était juste nul.

Oui, mais où s'arrêter ?

specification.rtf ou spécification.rtf ?

Ah oui, pas possible de mettre un "? / : /…" dans le nom de fichier aussi… "emmerdant non ?.txt" (ceci dit, là, je suis de mauvaise foi, c'est le shell Windows je crois, il me semble qu'on peut créer un tel fichier via cmd.exe ou via un programme (mais bon, ça n'aide pas à l'homogénéisation non ? :-)

Windows veut souvent en faire trop, c'est à mon sens son plus grand défaut. En plus, certaines erreurs du passé sont trimballées depuis des années, du coup, à part PasBill et quelques experts, y'a pas grand monde qui sait comment ça marche… et c'est parfois loin d'être logique.

Dans ma carrière, je me suis souvent retrouvé face à des développeurs Windows qui en savaient moins que moi sur l'interne de OS. En fait, à part en ce qui concerne des mecs spécialisés en sécu ou des mecs de MS, j'ai jamais vraiment rencontré de dév Windows qui savait comment marchait son OS bcp mieux que moi (qui pourtant n'utilise pas Windows, mais qui bouquine un peu)

A l'inverse, la plupart des dev Unix avaient des connaissances assez poussées sur le fonctionnement de l'OS, et sans tout connaître, savaient diagnostiquer et décrire un problème.

Certains diront que c'est parce que le code source est ouvert pour pas mal d'UNIX, je dirais plus simplement que c'est parce que Windows est trop compliqué, en fait bcp trop. La gestion de la casse est symptomatique, mais tout est comme ça, un exemple parmi d'autres, je crois me souvenir que c'est NTFS qui fait le clobbing (*.rtf par ex) des caratères génériques il me semble (ou si c'est pas lui qui le fait, en tous cas, la fonctionnalité existe)… bcp de choses sont comme ça, j'espère pour eux, pas au niveau du kernel, mais au niveau du programmeur, tout semble mélangé, les responsabilités sont difficiles à déterminer, bref, c'est le bordel.

Ceci dit, il parait qu'ils ont amélioré les choses depuis Vista, mais le poids des années se fait toujours sentir pour le développeur moyen.

Celui du contexte :-)

Seul problème effectivement, le comportement ne serait plus le même qu'avec les liens symboliques (truc qui pose d'ailleurs tout un tas de problèmes n'étant pas toujours très intuitif, par ex, créer
ln -s /usr/bin ~/monbin
puis regarder le résultat de
ls -l ~/monbin/..

Ce n'est pas impossible, preuve en est, c'est ce qui est utilisé par Mac OS X pour réaliser timemachine (le système d'archivage d'Apple).

Le problème de Java c'est que ça masque pas mal de concepts bas niveau, comme les adresses (pourtant utilisées dans les références, avec plein de limitations), la décomposition de la mémoire en octets (pas d'union, pas de cast de pointeurs, pas d'équivalent à void*), etc. Et donc l'étudiant qui programme en Java n'a limite pas besoin de savoir que ses variables sont stockées en binaire en mémoire, ce qui donne des situations où ils ne comprennent pas ce qu'est un masquage de bits ou un décalage, alors que ça sert tout le temps.

Ces trucs là, c'est utile à savoir oui... en fait, les cours de système devraient être obligatoires pour tous les étudiants... de même que les étudiants devraient savoir toutes les étapes pour afficher une page de http://linuxfr.org/ ...

Perso, je programme en Java et en C et je ne me sers pratiquement jamais de ces trucs en C, si ce n'est pour émuler des fonctionnalités de langages objet (genre, les unions pour de l'héritage, les void* ... euh non merci...

Les masquages/décalages de bits, ça m'arrive en Java et en C, mais ce n'est quand même pas ce qu'il y a de plus courant.

Le fait est que bien penser un design, ça demande du temps de cerveau disponible... et perso, je préfère l'utiliser pour faire un belle architecture ou diminuer la complexité de mon algo que me prendre la tête à gérer une fuite de mémoire.

De mon expérience, on passe au moins 25% du temps à corriger des bugs de mémoire en C, je dirai 1% dans le cas d'applications Java (oui, on peut aussi perdre de la mémoire en Java)... ce temps est du temps perdu.

Je ne parle même pas de l'utilisation faible d'algorithmes efficaces dans la plupart des projets C par le manque de ré-utilisation de code, du coup, Hop, listes chaînes pour tout le monde (ou le contraire, des tableaux pour tout le monde)... des limitations de merde dans tous les sens (BUFFER_MAX_SZ : hop !)... bref, au final, mon code est le plus souvent bcp plus rapide en Java qu'en C, ce n'est pas une question de compétence, mais une question de temps passé réellement sur les algos.

Alors oui, mettez deux génies dans une salle avec un temps infini, et oui, sans doute, au final le dev C aura un code plus rapide... à vrai dire, je m'en fout.

Non, c'est pareil, un peu de code JNI et on appelle le C direct.

inotify-java est juste une glue avec ce code JNI déjà créé par quelqu'un autre.

Cela n'a rien à voir avec être prêt du système, la question est juste de savoir si oui ou non il existe une bibliothèque dans un langage donné ? Dans pratiquement tous les langages (Java, Python, Perl...), on fait un binding C, mais l'inverse pourrait être vrai. Il est tout à fait possible d'appeler du java depuis du C (on pourrait imaginer de créer une interface CGI dans Tomcat par exemple).

D'ailleurs être prêt du système ne veut pas dire grand chose au final, il y a des langages dans lesquels on est plus proche de l'architecture du CPU, dans tous les cas, un appel système entraîne un changement de contexte, alors JVM ou pas, ça ne change pas grand chose.

Je ne parle même pas du fait que pour être prêt du CPU en C, il faut compiler pour l'architecture donnée alors qu'une JVM ou équivalent peut s'adapter exactement au système (utilisation ou non d'unités vectorielles, utilisation d'unités de calcul flottant...)

Bonne année et bonne chance pour la suite à vous deux !

Oui, un revenant aussi :)

Non, je l'utilise moi même, mais c'est quand même un système horrible : les classpath mixés, la syntaxe pourrie (du faux XML illisible sans même de système de validation XSD ou autre...) Je hais maven, mais c'est le seul qui a toutes les fonctionnalités que je recherche... Si quelqu'un a mieux :) ... suis preneur !

Sur des cartes pros, ça marche parfaitement (par exemple en les synchonisant via un WorldClock) et de manière pro (plusieurs semaines sans downtime).

Maintenant, pour avoir utilisé les 3 (jack, jack2 et PA) :

- PA : plein de bonnes idées, implémentation parfois malheureuse (sans doute due aux drivers hein...)
- jack* : juste ce qu'il faut pour le pro, mais pas simple à configurer pour mme Michu. jack était une super idée à la base, mais qui manquait de fiabilité, problème que jack2 a corrigé. J'ai un peu contribué avec Stéphane à travailler sur jack2 et à corriger quelques trucs (problèmes de design en multi-utilisateurs notamment), et je dois dire que j'en suis assez satisfait, ça marche bien. Maintenant, pour les mecs qui n'aiment pas le camelCase dans le code, je trouve ça un peu dommage, mais bon, qu'ils fassent leur fork si ça les chante.

Lennart a un peu raison dans son post, les deux approches sont assez différentes, il est dommage de ne pas les mixer, idéalement, il faudrait que jackd puisse être un client de PA et que l'inverse soit vrai (j'aurai bien aimé cela au moment où je développais sur jack)... maintenant, il faut voir que ça marche sous OS X... c'est même la plateforme où tout marche le mieux avec Jackd... alors au lieu de ré-inventer la roue, il pourrait regarder un peu ce qu'ils font, je ne suis pas sûr que ce soit si infaisable sous les autres POSIX (modulo le setup forcément un peu plus complexe niveau temps réel car sous Mac, les utilisateurs normaux peuvent chopper les droits RT par défaut)

Bref... rien de bien nouveau ni de constructif, mais jack2, ça marche bien quand même :-)

0,4 fps sur un iPhone... Bluffant
Un android pour essayer ?

Juste pour rigoler, je viens de m'amuser à faire un tout petit test de mauvaise qualité.

C'est une fonction qui s'appelle récursivement 5000 fois (je voulais faire plus, mais java part très vite en stackoverflow). Pour bien voir la différence (et gommer le lancement de la jvm que tu dis négligeable mais qui fait que c'est 80 fois plus lent dans l'état), c'est appelé 655536 (oui il y a un 5 de trop) dans une boucle for.

Comme tu dis, de mauvaise qualité... sans aucune optimisation, un code qui répond à tes spécifications tourne chez moi en 8 secondes (compilé en debug, tout ça)... je sais pas comment tu fais ton truc, mais chez moi :


public class TestRec {

public static void rec(final int val) {
   if (val == 0)
     return;
   rec(val - 1);
}

public static void main(String args[]) {
  final long start = System.currentTimeMillis();
  for (int i = 0; i < 655536; i++) {
    rec(5000);
  }
  System.out.println("Time: " + (System.currentTimeMillis() - start) + "ms");
  }
}


Time: 8045ms ... sur un portable hein ...

Bon, en rajoutant un peut calcul sur un entier, je vais à 10s... laisse les pros faire les benchs, et il y en a pas mal qui ne pensent pas comme toi.

Je ne parle même pas des cas comme le multithreading dans lequel il y a plein de fonctionnalités utiles en java (java.util.concurrent) qui permettent facilement en java de rendre des algo en // tandis qu'en C, c'est la plaie.

Quant aux interfaces graphiques, j'ai eu récemment le cas d'un prog en C++/Qt qui s'en sortait bcp moins bien qu'une interface Java à fonctionnalités équivalentes (et Dieu sait que j'aime bien Qt)

Sinon, juste pour info, le StackOverfow, il y a un paramètre de la JVM pour le paramétrer, c'est -Xss sur les JVMs de Sun si mes souvenirs sont exacts.

C'est déjà le cas : à l'heure actuelle, sur une Ubuntu par exemple, il suffit d'installer un noyau RT au lieu d'un generic.

Sinon, il reste la solution du module realtime.

Oui, je dirai que les imprimantes HP fonctionne sous Linux, ce avec toutes les fonctions (hormis les boutons spéciaux de l'imprimante comme "Envoyer vers la messagerie"... et encore, je crois qu'il est possible de les faire fonctionner).

Ce constructeur s'investit réellement sous Linux en fournissant des drivers, libérant ces specs et tout fonctionne au mieux (chez moi, une HP Photosmart C6200, très satisfait). Le scanner marche direct avec SANE, l'imprimante aussi, et évidemment, on peut utiliser les fonctions de l'imprimante telles que l'impression depuis Memory Sticks et autres SD Cards. Vive HP (sudo apt-get install hplip pour les drivers HP)

C'est vrai mais uniquement pour les mails reçus... dans ce cas, le statut de l'émetteur du mail est affiché. Ceci dit, mettre cette information pour tous les destinataires poserait des problèmes de lisibilité sans doute...

Sinon, je plussoie pour la création des contacts dans le carnet d'adresse depuis kopete :)

Jack peut fonctionner au dessus d'un serveur de son de ce type à terme.
Le problème, c'est que (du moins pour l'instant) :
- jack n'est pas capable de découvrir les cartes sons tout seul.
- il marche mal avec deux cartes son
- il peut bouffer pas mal de CPU (afin d'obtenir une latence 0)

De fait, j'utilise jack et c'est très bien, mais ce n'est pas la panacée pour une utilisation bureau.

Je pense qu'un système comme pulseaudio a sa place à ce niveau, quitte à l'interfacer bien avec jack de manière à obtenir le meilleur des deux mondes.

Je ne vois *absolument* pas en quoi le fait d'implémenter des bugs de date ou des formats périmés permet de reproduire des anciens document :

(évidemment, tu peux remplacer ODF par OOXML...)

Prenons par ex les dates:

word97 Date = xxxy

ODF Date = xxxx


qu'est ce qui empêche le convertisseur wordDate97 vers ODF de convertir la date en xxxw ?

De même, qu'est ce qui empêche le convertisseur ODF date vers word97 de convertir xxxx vers xxxy ????? Explique moi, j'aimerai comprendre !

Tu prends vraiment les gens pour des imbéciles ou bien ?

L'avantage, mais je pense que tu le sais pertinament, c'est que cette logique de conversion ne se retrouve qu'à a un seul endroit et non pas dans tous les lecteurs, ce qui => allège le code => diminue l'empreinte en mémoire du programme (sauf le convertisseur, mais bon, il est utilisé rarement à côté de l'éditeur non ?) => augmente la fiabilité (un seul endroit pour faire la conversion).

Chez MS, vous avez jamais bossé avec du legacy de banques ou bien ?

Désolé, pasBillou, parfois tu es pertinent, mais là, tu es nul.

Et inutile de prendre l'argument de ODF qui implémente le saut "à la OO.o 1.0", la situation est différente, car c'est pour une compatibilité ascendante du format de fichier (afin que OO.o 1.0 puisse lire les fichiers produits par ODF), un cas très différent car OOXML est sensé être un nouveau format, donc pas (en théorie, sauf chez vous) exempt d'héritage lourd.

kioclient --progresswindow cp fichier1 fichier2

En plus fichier1 et fichier2 peuvent se trouver sur n'importe quel protocole supporté par KDE, et sinon ça supporte aussi les commandes suivantes:
ls, cat, put, cp, rm, mv, mkdir, rmdir

que du bonheur.

Un seul inconvénient: la fenêtre de progression utilise X

1°) lance un kwrite que tu minimise (au besoin au chargement de ton desktop)... les libs seront déjà chargées, ça devrait être presque instantané.
2°) vérifie que ton cache de polices est à jour (sudo fc-cache)... ça accélère considérablement le démarrage de la machine
3°) utilise prelink (sudo prelink -av) afin d'accélérer le chargement des applications C++
4°) Si 1 ne te vas pas et que 2 & 3 ne suffisent pas:
* au démarrage de ton desktop, lance kdeinit
* créé en raccourcis et lance "kdeinit_wrapper kwrite" au lieu de kwrite

Possibilité: le répertoire dans lequel tu te trouves est monté avec l'option noexec ... vérifie dans /etc/fstab que ta partition ne contient pas cette option de montage... auquel cas il suffit de la supprimer pour que tout fonctionne.

que donne la ligne

/bin/bash test.sh

?

Y'a aussi versionfs qui marche au dessus de n'importe quel filesystem Linux et fait exactement ça:
http://sourceforge.net/projects/versionfs/

Jamais essayé, mais il parait que ça ne dégrade que très peu les performances.

J'ai vu la même chose sur un ISA server (Windows 2000 avec un Proxy/Firewall MS) : les règles firewall se déclenchent très très tard dans le boot. Au début, le système répond, mais il faut plusieurs minutes pour que le Firewall soit démarré complètement, en ce qui me concerne, j'avais remarqué qu'on pouvait faire ce que l'on voulait pendant plus de trois minutes (ISA Server a en plus la bonne idée d'utiliser IIS...)

Sachant qu'en plus c'est un produit MS, sur un Windows 2000 version Server, je trouve ça très très très dommage, le système peut être infecté pendant ce temps de latence nécessaire au démarrage du proxy/firewall...

Enfin, c'est pas le seul problème, je me suis rendu compte que des requêtes subversion (donc WebDav), réalisaient tout bêtement un DOS sur le Proxy... alors avec un peu d'imagination:

1°) On lance une requête HTTP qui crashe ISA server.
2°) On vient de faire un DOS. Le système ne répond plus. Si l'admin a activé le redémarrage automatique, ce qui est probable, le système ou le service va redémarrer...
3°) Bravo, tu disposes de qques minutes pour infecter le serveur avec un vers ou ce qui te plait, à l'heure qui te plait... mignon non ?

Notons que ce système a été installé par un consultant spécialisé en sécu NT, donc je doute qu'il y ait trop trop d'erreurs lors de l'install. (En plus, il était cher le consultant :)

Sinon, autre truc intéressant:

doc ksmserver ksmserver logout 0 2 0

Pour délogger depuis un script shell

On peut même le faire pour tous les users en même tps:

doc --all-users --all-sessions ksmserver ksmserver logout 0 2 0

(Déconnecte tout le monde, bien sûr, root nécessaire si plusieurs users).

Très Trés pointu monsieur Pascal, Félicitations !