Sytoka Modon a écrit 4544 commentaires

  • [^] # Re: Champ SRV

    Posté par  (site web personnel) . En réponse à la dépêche Miroirs pkgng disponibles !. Évalué à 2.

    Ne pas mélanger protocole et port, on met le port plus loin sur la ligne.

    Comme pkg attend un site web particulier, un peu comme les archives .deb, http est le transport mais en face, ce n'est pas un site comme un autre, c'est une base de données bien organisée.

    Personnellement, j'aurais pris un autre champ SRV afin de laisser le _http au site web du projet…

  • [^] # Re: bigre

    Posté par  (site web personnel) . En réponse au journal Cisco paie le h264 en faveur de Mozilla. Évalué à -8.

    Enfin, le jour ou CISCO arrêtera de faire au minimum x10 sur le prix de ses transeivers, j'aurais un peu plus de respect pour cette boite…

  • # Champ SRV

    Posté par  (site web personnel) . En réponse à la dépêche Miroirs pkgng disponibles !. Évalué à 1.

    Dans le cadre de XMPP, on a (voir http://wiki.xmpp.org/web/SRV_Records)

    _xmpp-client._tcp.example.net. TTL IN SRV priority weight port target
    _xmpp-server._tcp.example.net. TTL IN SRV priority weight port target
    

    Le choix est expliqué ? Je serais plutôt parti sur

    _pkg-server._tcp.pkg.freebsd.org. 60  IN  SRV 10 10 80 pkg0.bme.freebsd.org.
    

    Afin de ne pas toucher au _http…

  • # Suivant

    Posté par  (site web personnel) . En réponse au journal EnVadrouille, une galerie photo pour vos randos. Évalué à 10.

    Sur la démo, il y a un truc que je n'aime pas, les boutons suivants et précédents change de place selon la taille de la photo… Personnellement, je n'aime que les albums ou je met ma souris sur suivant et clique sans réfléchir ;-)

  • [^] # Re: malheureuses récentes transitions

    Posté par  (site web personnel) . En réponse à la dépêche GTK+ 3 disponible officiellement pour Win32 !. Évalué à 9.

    GTK n'est pas GNOME…

  • [^] # Re: Ben voyons

    Posté par  (site web personnel) . En réponse à la dépêche GNU Make 4.0 extensible. Évalué à 4.

    Il faut arrêter de tout vouloir optimiser au caractère près et croire que tous les développeurs ne basculeraient pas, pour trois touches, sur un système lisible. De plus, une partie des Makefiles sont crées automatiquement…

    target:
     -> @cc -o target.o $(OBJS)
    

    Le gros avantage, c'est qu'on voit si c'est dans le même shell ou non…

    target:
     -> @cc -o target.o \
        $(OBJS)
     -> @echo toto
    

    En plus, pour éviter l'arobase en début de ligne, on pourrait avoir deux types de flèches… Bref, c'est juste une proposition pour avoir un truc plus lisible pour un coût faible.

  • [^] # Re: Temps de jeu total

    Posté par  (site web personnel) . En réponse à la dépêche Dungeon Crawl Stone Soup 0.13 est sorti!. Évalué à 3.

    TIMTOWTDI ;-)

    La proposition a tout de même été porté par Damian Conway, c'est pas de moi. De plus 'unless' et 'if not' ont exactement la même longueur. L'idée est la même qu'en français, éviter si possible les phrases interro-négative et sinon, essayer d'être le plus clair possible.

  • [^] # Re: Ben voyons

    Posté par  (site web personnel) . En réponse à la dépêche GNU Make 4.0 extensible. Évalué à 2.

    d'utiliser la tabulation pour les commandes dans les makefiles

    Il est clair que c'est une énorme boulette MAIS elle aurait pu être corrigée depuis longtemps. Par exemple, il aurait été facile de faire une règle telle que

    s/^\s*->\s*/\t/
    

    En gros, toute ligne commençant par '->' est équivalente à une ligne commençant par une tabulation. Au bout d'une dizaine d'année, la tabulation aurait petit à petit disparu et un jour, on aurait pu la rendre obsolète. Pas mal d'année de perdus…

  • [^] # Re: Temps de jeu total

    Posté par  (site web personnel) . En réponse à la dépêche Dungeon Crawl Stone Soup 0.13 est sorti!. Évalué à 2.

    next unless ($file =~ /^morgue.*\.txt$/);
    

    Selon certain, le 'unless' est une fonction peu connue en dehors de perl donc il est parfois conseiller d'écrire

    next if not $file =~ /^morgue.*\.txt$/;
    

    En perl, les parenthèses qui ne servent pas, je ne les mets pas ;-)

  • [^] # Re: Temps de jeu total

    Posté par  (site web personnel) . En réponse à la dépêche Dungeon Crawl Stone Soup 0.13 est sorti!. Évalué à 2.

    Il est préférable de spécifier que l'on souhaite ouvrir en mode lecture seule.

    open(my $file, '<', "path/to/file");
    

    Généralement, on fait un "open() or die…"

  • [^] # Re: let mul

    Posté par  (site web personnel) . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 4.

    Je pensais que c'étais dans C++14 mais déjà dans gcc… J'ai un train de -- ;-)

  • [^] # Re: Et le DNS ?

    Posté par  (site web personnel) . En réponse à la dépêche Le programme de Google pour améliorer la sécurité des logiciels libres. Évalué à 0.

    Peut être voulait'il parler de l'AD ;-)

  • [^] # Re: let mul

    Posté par  (site web personnel) . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 8.

    Si on veut limiter les problèmes et simplifier la programmation fortement concurrente, il est important que les variables soient par défaut immutable comme en Erlang. La déclaration explicite ici me semble une très bonne chose. Ensuite, pour la performance, il faut parfois savoir aussi éviter les copies, comme le futur 'move' du C++ et le tout mutable par adresse du Fortran. Bref, pas facile de construire un langage équilibré mais pour le web et la robustesse aux threads et autres coroutines, l'immutable par défaut me semble de plus en plus une bonne approche.

    C'est aussi une approche très fonctionnelle écrite avec une typo plus déclarative !

  • [^] # Re: Nvidia travaille avec Valve

    Posté par  (site web personnel) . En réponse au journal Hypocrisie de Nvidia envers le libre : le pilote graphique Linux volontairement dégradé ?. Évalué à 2.

    Oui, enfin j'attends toujours Catia et Soliworks sous GNU/Linux… Quand à Ansys, leur merde de Workbench tourne mal car c'est du .NET 32 bits qui tourne via un émulateur (oui, ils osent vendre cela dans leur coffret Linux).

  • # Et pourquoi pas en Perl

    Posté par  (site web personnel) . En réponse au message Quel langage/outil pour divers développements (web/local) sur une base de données ?. Évalué à 2.

    c'est standard pour connecter à n'importe quel base de données et il y a des environnements pour le web qui font une grosse partie du boulot. Par exemple, Mojolicious est un (il y en a d'autres) framework à la mode. Je suis tombé l'autre jour sur cette petite application qui ne sers pas à grand chose mais donne un exemple intéressant coté code.

    https://github.com/ldidry/lstu/

    Cela donne cela en pratique

    http://lstu.fiat-tux.fr/

  • [^] # Re: La GPLv3

    Posté par  (site web personnel) . En réponse à la dépêche Logotheras, compilateur de dictionnaires de langues. Évalué à 2.

    En Perl, je n'utilise comme la plupart des personnes QUE des modules dans le CPAN. Le CPAN est un outil collaboratif, un des premiers réseaux social dédié (après le CTAN). Donc tu utilises pour ton module (bibliothèque) la même licence que Perl c'est à dire GPL + Perl Artistic. Ainsi, le CPAN grossit, est libre et cohérent et on ne se pose pas la question de la licence pour les bibliothèques. C'est une zone de grand partage réutilisable par tous.

    L'écosystème de Python me semble bien plus répartis. Avec PIP, il télécharge les paquets on ne sais trop ou et les installe.

    Voila, je me positionne face a un écosystème existant, je ne cherche pas à comparer ici les licences libres.

  • [^] # Re: La GPLv3

    Posté par  (site web personnel) . En réponse à la dépêche Logotheras, compilateur de dictionnaires de langues. Évalué à -3.

    C'est un peu le soucis de Python… Avec Perl, tu upload ton module sur le CPAN et comme tout le monde, tu met la licence Perl (Artistic) et ca va bien.

  • [^] # Re: OSEF

    Posté par  (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 6.

    Il n'empêche, NX et X2GO marche super bien… Il faut aussi avoir l'honnêteté de dire que certaine chose marche bien.

  • [^] # Re: Déjà vu

    Posté par  (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 3.

    À mon avis, les versions Linux des logiciels Ansys sont programmées avec les pieds

    Attention, il y a plusieurs choses chez Ansys. Les solveurs sont OK, pas de soucis (il faut dire pas de graphique). La BOUSE infâme, c'est le workbench, si tu regardes de manière récursive dans le dossier d'installation, tu va trouver des binaires 32bits PE32 .Net… Ansys te fait payer un prix astronomique la version GNU/Linux une merde en boite avec du binaire Windows ! C'est pas étonnant que cela marche mal coté 3D avec du X distant.

  • [^] # Re: Déjà vu

    Posté par  (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 3.

    Avec x2goclient, c'est facile mais graphique… Il y a aussi le client pyhota qui le fait en ligne de commande. Exemple sans intérêt !

    pyhoca-cli --server SERVER --username LOGIN --new --command xeyes
    

    Cela lance une nouvelle session à chaque fois. En effet, comme il y a un proxy coté serveur, on peux se reconnecter sur une ancienne session. Par exemple lancer matlab puis récupérer la session à un autre moment.

    Pour le moment, on en fait un usage basique (cela nous règle les problèmes de visualisation 3D notamment). Coté serveur, ne pas installer GNOME qui est un monstre coté ressources. Je met XFCE et je fais un lien pour simplifier la vie des utiisateurs

    /usr/bin/gnome-session -> /usr/bin/xfce4-session
    
  • [^] # Re: Déjà vu

    Posté par  (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 2.

    Oui, heureusement.

  • [^] # Re: Déjà vu

    Posté par  (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 3.

    D'ailleurs, X de base merde pas mal à ce niveau la, surtout pour la 3D ou cela marche correctement parfois. Exemple, jamais compris comment faire marcher de manière fiable Workbench d'Ansys sur une machine de calcul…

    Avec NX, la 3D se fait sur le serveur (puisqu'il a un proxy local au serveur) et alors, tout est bien plus simple et robuste coté 3D !

    Une autre piste logiciel dont les idées sont les mêmes (faire le rendus 3D sur le serveur) est VirtualGL (TurboVNC). Une petite page qui explique pas si mal la problématique est les solutions :

    http://www.virtualgl.org/About/Background

  • [^] # Re: Question...(celui qui demande ne se trompe pas...)

    Posté par  (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 5.

    Des solutions existent déjà: on peut lancer un serveur VNC ou RDP avant le login, c'est plus efficace que X
    (en terme de débit réseau).

    Oui et non.

    En pratique, NX (X2GO) est plus efficace et c'est juste un 'proxy' X bien ficelé… Comme quoi X est quand même surprenant ;-)

  • [^] # Re: Déjà vu

    Posté par  (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 3.

    Que veux-tu dire par là ? NX et X2GO demande des clients spécifiques.

    • NX est un peu merdique car il passe par une bidouille via un compte 'nx' et une clef commune…

    • X2GO a corrigé cela et tu utilises ton compte directement.

    Dans les deux cas, il faut utiliser un client spécifique, qui n'a pas forcément une ligne de commande compatible avec ssh… Pas mal de programme permettent de modifier la connexion à distance via un paramètre, c'est ainsi par exemple qu'avec MPI (calcul parallèle) on est passé en douceur de rsh à ssh.

    Si c'est intégré dans ssh, c'est beaucoup plus simple pour tout le monde ;-)

  • [^] # Re: Déjà vu

    Posté par  (site web personnel) . En réponse au journal Le mythe de la transparence réseau. Évalué à 10.

    Pour essayer de faire une synthèse rapide… Que ce soit X ou Y, l'utilisateur s'en fiche un peu, il veut que cela marche. Cependant, la transparence réseau sous UNIX est la depuis si longtemps que c'est maintenant dans le coeur d'UNIX. Tu dois pouvoir faire un ssh et avoir un retour graphique de toute application distante. C'est une des raisons du succès d'UNIX, c'est un des soucis de MacOSX, leur couche graphique n'est pas compatible (et je n'ai pas le souvenir de client libre).

    Que ce soit X, VNC, RDP… Je crois que tout le monde sera enchanté d'une solution plus performante que le X de base d'aujourd'hui (avec NX et X2GO, ça va quand même bien). Mais, cette solution doit être intégrée dans SSH afin que tout soit transparent et simple.