VinDuv a écrit 15 commentaires

  • # Boot en émulation BIOS et utilisation serveur (sans écran)

    Posté par  . En réponse au journal Libérer un Mac/Intel. Évalué à 5.

    Attention, l’émulateur de BIOS qui est utilisé pour démarrer un OS non EFI sur un Mac ne supporte pas de démarrer sans écran : il attend infiniment longtemps qu’un écran soit branché, à priori.
    Pour utiliser un Mac mini 2006 en serveur, c’est un peu gênant.
    Il y a une bidouille possible qui consiste à brancher un adaptateur DVI->VGA sur la sortie vidéo et à brancher une résistance entre deux des pins du port VGA de l’adaptateur afin de lui faire croire qu’un vieil écran est branché. Je me souviens plus des détails mais je l’ai fait et ça marche.

    Bien sûr, le boot natif EFI n’a pas ce problème.

  • [^] # Re: pareil en IPv4

    Posté par  . En réponse au journal Jouons un peu avec les adresses IPv6…. Évalué à 10.

    Sous Linux, getaddrinfo(2) reconnaît directement les IP hexadécimales, donc on peut les utiliser avec ping, par exemple :

    $ ping -c 1 0x7F000001
    PING 0x7F000001 (127.0.0.1) 56(84) bytes of data.
    

    Plus amusant, on peut aussi passer la représentation décimale :

    $ ping -c 1 2130706433
    PING 2130706433 (127.0.0.1) 56(84) bytes of data.
    

    Ou octale :

    $ ping -c 1 017700000001
    PING 017700000001 (127.0.0.1) 56(84) bytes of data.
    

    On peut aussi omettre des champs à 0 au milieu d’une IPv4 :

    $ ping -c 1 127.1
    PING 127.1 (127.0.0.1) 56(84) bytes of data.
    

    Et je suppose qu’il doit y avoir quelques autres représentations supportées…

  • # Abstraction des variables dans le système de fichier

    Posté par  . En réponse au journal rm -rf tue votre bios UEFI. Évalué à 4.

    À mon avis, le problème se situe dans la manière dont le noyau rend accessible ces variables.

    On peut déjà se demander s’il est bien opportun de les mettre dans le système de fichiers; le noyau pourrait proposer une API à base d’ioctl pour les manipuler. Ça empêcherait toutefois la modification des variables depuis un script shell (sauf à proposer un exécutable dédié à cette tâche).

    Une autre solution, qui garderait le mapping des variables dans le système de fichier mais résisterait aux rm intempestifs serait d’empêcher la suppression des pseudo-fichiers de variable et de fournir un fichier delete_var dans lequel on puisse écrire le nom d’une variable pour la supprimer. Ça se rapprocherait d’ailleurs du fonctionnement de /sys/class/gpio.

  • [^] # Re: ?

    Posté par  . En réponse au journal xip.io pour une infinité de domaines gratos !. Évalué à 5.

    Une autre solution pour avoir plusieurs noms sur une IP, sans modifier quoi que ce soit, est d’utiliser les noms alternatifs pour une IP.
    Par exemple, “127.0.0.1”, “127.00.0.1”, “127.1”, “2130706433”, “0x7f000001” vont tous être résolus (par getaddrinfo) vers l’IP 127.0.0.1, mais le nom d’hôte indiqué par le navigateur sera différent.

  • [^] # Re: campagne agressive de Wikipedia

    Posté par  . En réponse au journal La suite GPGtools pour MacOsx s'essaye au modèle payant. Évalué à -2.

    3 clics

    3 clics qui ont également pour effet secondaire d’inscrire ton adresse e-mail d’office à une mailing list de Wikimedia, avec un lien de désabonnement planqué à la fin d’un mail de remerciement probablement ignoré par la majorité des personnes qui auront fait un don…

  • [^] # Re: iMac 27" 5K

    Posté par  . En réponse au journal Une baudruche qui se dégonfle avec fracas.... Évalué à 2.

    Ultra wide television c’est 5120 × 2160.
    L’écran de l’iMac a 720 lignes de plus donc 3 686 400 pixels supplémentaires.
    Je sais pas si ça lui faut d’être appelé “5K”, mais de toutes façons ces dénominations sont complètement arbitraires, alors…

  • [^] # Re: scp

    Posté par  . En réponse au journal cv, un petit outil pour surveiller vos copies. Évalué à 0.

    scp plop1 plop2 est équivalent à cp plop1 plop2 (scp lance cp en sous-main)
    Donc il faut faire scp plop1 localhost:$PWD/plop2 ou équivalent, je suppose… Mais question efficacité, c’est franchement pas ça.

  • # Licence CDDL

    Posté par  . En réponse au journal Rhoo, c'est bon, ça !!. Évalué à 4.

    http://www.open-zfs.org/wiki/About_OpenZFS#Other :

    ZFS source code is copyright various contributors, and available under the CDDL open-source license.

    Du coup ça change quoi par rapport à l’implémentation de Sun/Oracle, qui était déjà sous CDDL ? Ça ne pourra toujours pas être intégré proprement au noyau Linux à priori…

  • [^] # Re: Fichiers anonymes

    Posté par  . En réponse à la dépêche Linux pour Workgroups 3.11, le noyau prêt pour le bureau. Évalué à 8.

    Le rapport avec la sécurité, c'est que sans nom, il n'y a aucun risque de collision de nom, n'est-ce pas ?

    C’est aussi pour éviter qu’un autre processus ne puisse ouvrir le fichier (entre sa création et sa suppression) pour aller lire ou écrire dedans. Le but recherché est que seul le processus qui a créé le fichier puisse le faire (il peut bien sûr une fois le fichier anonyme créé transférer cette possibilité à d’autres processus en transférant son descripteur de fichier, mais il a le contrôle).

    À priori il est possible, lors de la création d’un fichier anonyme, de s’assurer que personne n’a ouvert le fichier entre sa création et sa suppression, mais ça peut être délicat (il faut récupérer après la suppression le nombre de fd ouverts sur le fichier et s’assurer qu’il est égal à 1—si ce n’est pas le cas, on réessaye). Au moins avec O_TMPFILE ça sera directement sécurisé.

  • # Serveur DNS perso et IP dynamique

    Posté par  . En réponse au journal Le monde change, dyndns aussi.... Évalué à 4.

    Personnellement, j’ai mon propre serveur DNS (avec une IP fixe bien sûr), et j’utilise nsupdate pour mettre à jour l’IP dynamique d’un des domaines.

    Ça me paraît être une bonne méthode quand on gère soi-même ses DNS (pas besoin d’écrire des scripts pour aller mettre à jour le fichier de zone, pas besoin d’accès SSH, c’est sécurisé, les contrôles d’accès sont fins, …)

    En contrepartie, ça rend l’édition du fichier de zone un peu plus complexe, puisque Bind réécrit le fichier quand il reçoit une requête nsupdate (et en profite pour réécrire et trier les définitions), ce qui impose d’utiliser rdnc freeze et rdnc thaw respectivement avant et après les modifications manuelles du fichier.

  • [^] # Re: il manque une fonctionnalité inutile en c++, le ramasseur de miette

    Posté par  . En réponse au journal C++11 : sur le fil. Évalué à 3.

    Quelle est la différence réelle avec un shared pointeur ? (ormis le fait de devoir écrire shared_pointeur).

    Le concept de shared_ptr ne serait pas applicable en ObjC, notamment parce que le langage ne permet pas d’allouer des objets sur la pile (uniquement sur le tas, comme en Java). Donc forcément, ça marche un peu différemment… En Objective-C, la gestion de la mémoire se fait à l’aide d’un compteur de référence (intégré aux objets), qui était jusqu’ici géré manuellement par les développeurs, et qui maintenant est géré automatiquement par ARC (en gros ARC fait le travail des développeurs en rajoutant des appels aux méthodes de gestion du compteur de référence là où c’est nécessaire)

    La compatibilité d’un code compilé avec ARC avec du code "classique" est complète (sous réserve que le code classique en question gère correctement la mémoire…), donc ça facilite les migrations (on peut même le faire fichier par fichier). Alors que pour passer d’un code C++ qui fait des new/delete à des shared_ptr, il doit falloir plus de boulot d’un coup…

    Je pense aussi que ARC doit pouvoir gérer la mémoire plus finement que les shared_ptr, parce que C++ impose que les objets alloués sur la pile soient détruits seulement lorsqu’il ne sont plus accessibles (donc généralement à la fin de la méthode/fonction). Donc si un objet temporaire est alloué via un shared_ptr au début d’une fonction, il ne sera libéré qu’à la fin, même si il ne sert à rien entre-temps. ARC, en revanche, peut décrémenter le compteur de référence d’un objet dès qu’il n’est plus utilisé.

  • [^] # Re: Emmerder Apple ?

    Posté par  . En réponse au journal Un de moins, un de plus : fork de WebKit par Google. Évalué à 8.

    C’est possible, mais d’un autre côté si j’ai bien compris WebKit a aussi du code spécifique pour gérer certains aspects de Chrome (notamment l’utilisation du moteur JavaScript V8 au lieu de JavaScriptCore), donc ça pourrait aussi simplifier le code de WebKit et donc le travail d‘Apple.
    Aussi, en suivant la liste de diffusion concernant le développement de WebKit (webkit-dev), j’ai vu que les relations entre les développeurs Chromium et les autres n’était pas au beau fixe (par exemple leur propositions d’intégrer d’autres languages de script à WebKit ou d’ajouter des les bindings V8 à WebKit2 ont été rejetées plus ou moins unanimement), donc ce fork n’est pas vraiment une surprise à mon avis.

  • # Xfce 4.8, pas 4.10

    Posté par  . En réponse au journal Debian Wheezy passe à XFCE ?. Évalué à 7.

    Et une petite nimage.

    Attention, l’image vient de Xfce 4.10. Debian ne proposera vraisemblablement que Xfce 4.8, apparemment pour de sombres histoires de compatibilité de configuration :

    It's very likely that the next stable release (wheezy) will stick to Xfce 4.8. The main reason: direct upgrades from 4.6 to 4.10 are unsupported, untested, and very glitchy (xfce4-panel and xfce4-session don't like that very much, you'll experience problems to close your session from your Xfce desktop after the upgrade).

  • [^] # Re: Y a quelqu'un

    Posté par  . En réponse au message [Terminal] Du bon ordre des redirections. Évalué à 1.

    Le 2>&1 sert à faire en sorte que l'erreur standard pointe au même endroit que la sortie standard.
    Donc si on fait >/dev/null 2>&1 : (les redirections sont lues de gauche à droite)
    1) stdout (la sortie standard) est redirigée sur /dev/null
    2) stderr (l'erreur standard) est redirigée sur ce que pointe stdout, dans ce cas /dev/null
    Donc tout finit dans /dev/null. On pourrait écrire >/dev/null 2>/dev/null, ça aurait le même effet.
    On pourrait aussi faire : 2>/dev/null (rediriger stderr sur /dev/null) >&2 (rediriger stdout sur ce que pointe stderr)

    Si on fait 2>&1 >/dev/null :
    1) stderr est redirigée sur ce que pointe stdout, dans ce cas la console (donc rien ne change)
    2) stdout est redirigée sur /dev/null.
  • [^] # Re: Paquet Arch Linux

    Posté par  . En réponse à la dépêche Sortie de la version 2.4.1 de Slime Volley.. Évalué à 3.

    Si je me souviens bien, j'avais fait ce petit hack parce que lintian râlait que mon paquet Debian installe un jeu dans /usr/bin... (package-section-games-but-has-usr-bin)

    Effectivement, je n'avais pas pensé au fait que d'autres distributions puissent utiliser des normes différentes... Je trouverai une autre solution, mais en attendant il suffit de remplacer les lignes 128 à 134 du CMakeLists.txt par juste :
    INSTALL(TARGETS slimevolley DESTINATION "bin")
    Néanmoins, la bidouille ne posera des problèmes que si l'on installe dans /usr (si on utilise un autre préfixe, le jeu s'installe bien dans ${prefix}/bin).