Dans ce cas autant partager un fichier chiffré avec GPG. Toute le monde peut alors transporter les données (aider à le faire transiter) mais seuls ses destinataires peuvent le déchiffrer. Bien sûr, on peut vouloir intégrer ça de façon plus couplée avec le protocole de partage pour gérer des droits ou du versionnement, mais dans ce cas l’approche de l’auteur me semble plus pertinente que je système de clefs asymétriques.
Ce que je trouve le plus dommage, c'est que l'application dessine le contour de la fenêtre, qu'il n'y ait pas de WM réellement séparé.
Espérons que des solutions standardisées émergeront. Je ne sais pas comment les logiciels KDE vont négocier ça avec Kwin, mais il y a de fortes chances que ça devienne le standard de fait. Espérons alors que les autres logiciels hors de KDE suivront. Il serait dommage que Wayland tue les gestionnaires de fenêtre pavant, ou à onglets et autres gestions de fenêtres avancées.
Tu pourrais tout à fait avoir un client local qui fait la même chose (c'est juste que je n'en connais pas).
Avec Gnome, il y a Gucharmap qui permet de faire des recherches hors ligne sur le descriptif des symboles Unicode et de regarder leur représentation dans différentes polices de caractères. Pour le moment, il n’inclut pas encore Unicode 7.0 il me semble, mais ce n’est qu’une question de temps.
donc savoir qui participe, pas facile sur une liste de diffusion
C’est évident que l’une des prémisses au chiffrement est de savoir à qui l’on destine son message.
Ensuite, pour une liste, il est sûrement plus pratique de partager un secret (qui peut toujours être une clé privée commune pour la liste, transmise une seule fois à chaque participant avec sa clé publique à lui, ce n’est pas une limitation de la crypto ou de PGP en soi).
C’est un fait, le chiffrement fonctionne mal pour les informations diffusées publiquement. Ses critiques souligneront que c’est fort dommage car ça ne permet pas de s’assurer que seul un destinataire inconnu parviendra à lire le message. Étonnant, non ?
En gros, au lieu d'avoir une structure simple derriere la table de hash, on fait appel a une structure un peu plus complexe qui permet de diminuer l'impact d'une collision. En passant a du O(log n) dans le pire cas.
C’est à mon avis nécessaire. Au delà de mon avis plus que réservé sur les décorations côté client, la richesse des environnement de bureaux dépasse largement Gnome et KDE. Les gestionnaires de fenêtres pavant, ou le groupement de fenêtres en onglets auront toujours des utilisateurs après le passage à Wayland… si les applications ne supportent pas un mode de décoration par le gestionnaire, la vie de ces utilisateurs sera bien moins belle quand « Linux sera prêt pour le desktop ».
ça joue pas toute les notes, mais je m'en fout, j'ai pas besoin du Do mineur
Les problèmes avec autofs, ou le boot sur partition chiffrée, etc me font penser que systemd n’est pas non plus un stradivarius. Personnellement, je pense que systemd est une piste intéressante, et sûrement le futur, mais il arrive beaucoup trop vite dans les distributions et est présenté par ses auteurs et défenseurs comme une solution qui surpasse toutes les précédentes, alors qu’il ne tient pas encore toutes ses promesses.
Je n’ai pas répondu « sécurité » au sondage car il y est explicitement fait référence à la réactivité. Cela me parait un bon argument, mais à destination des connaisseurs, et pas du tout du grand public non-informaticien. Par contre, dans mon entourage non informaticien, j’en trouve un certain nombre qui privilégient des logiciels libres par qu’il est en général plus facile de les trouver via des canaux « fiables ». Par fiable je n’entend pas ici un dépot et des paquets signés (ceux qui y seraient sensibles auraient déjà quitté Windows), mais pour les utilisateurs de Windows, au moins des installateurs qui ne pourrissent pas le système de logiciels tiers aux fonctionnalités pas très claires et de barres de recherche ou autres windowseries courantes.
Ce n’est pas vraiment un avantage inhérent au libre, mais les usages font que l’on trouve plus facilement des installateurs pour Windows propres pour des logiciels libres, sur les sites officiels des projets (et non sur télécharge-un-logiciel-gratuit-fourni-par-jenesaisqui.com). Je sais aussi combien cette habitude majoritaire n’est pas une règle absolue, Sourceforge ayant basculé du côte obscur maintenant, les mauvaises habitudes se répandent.
Donc ça m'agace un peu qu'on cite systématiquement ces logiciels en tant que tel.
En réalité, il faudrait parler de OwnCloud + service d'hébergement de serveur virtuel. Au final on se retrouve aussi dépendant du cloud
Donc, tu cherches une alternative à Dropbox, qui ne soit pas dépendante du cloud (en utilisant la définition qui transparaît de ton commentaire : à savoir un service hébergé, joignable par le réseau Internet) ? Effectivement, toute alternative qui te sera proposée risque de te décevoir.
"deb7u6" […] il y a t'il une signification spécifique derrière ça
"deb7u6" = Debian 7 (Wheezy) update 6.
Les mises à jour 5 et 6 (deb7u5, deb7u6) de l’équipe de sécurité servent justement à corriger la faille Heartbleed (cf. l’autre réponse de Xavier Claude pour le vérifier).
Oui, mille excuses pour la désinformation. Erreur de ma part. La machine sur laquelle j’ai fait la vérification était en « oldstable » et non « stable ».
C’est le rôle de « testing ». C’est plus un « bassin de décantation » de Sid, dans lequel les dépendances sont toujours cohérentes qu’une véritable distribution à part entière. Pour les problèmes de sécurité, les délais sont accélérés, mais le processus reste le même, rien n’entre dans « testing » sans maturation/validation préalable. Il faut bien comprendre qu’au départ « testing » n’était qu’une étape intermédiaire entre Sid et la nouvelle « stable » pour assurer sa cohérence, dans l’espoir de gagner du temps pour la sortie (avec un succès très relatif).
Le délai entre Sid et « testing » restera toujours, et pour du « responsible disclosure », Sid est corrigé au moment de l’annonce officielle, et donc « testing » traîne un peu.
En pratique, ça signifie qu’il ne faut pas utiliser « testing » seule. Sur un serveur, on laisse « stable » [0] de toute façon. Sur son ordi perso, on pioche dans Sid lors des annonces de sécurité (ou on ajoute un dépôt tiers pour la sécurité, solution qui devrait être adoptée pour Debian CUT si le projet aboutit).
[0] qui n’a été affecté ni par le bug Debian dans le générateur de nombres aléatoires, ni par celui-ci et dispose de dépôts de sécurité propres. Certaines failles surviennent évidemment en « stable » aussi, mais le niveau général de sécurité de cette distribution est incomparablement meilleur que les autres branches, voire que beaucoup de distrib’s.
Un ordinateur est quand-même plus polyvalent qu’une vieille console, d’ailleurs les consoles récentes font souvent beaucoup plus que lancer des jeux (lecteurs vidéos de salon, etc) et ces usages nécessitent plus qu’une vieille console d’occasion. Personnellement, j’ai pas mal cherché une distribution pour se bricoler une console de salon, et bien que je ne représente pas une masse critique d’utilisateur(s) à moi seul, je crois qu’il y a un besoin auquel LinuxConsole peut répondre.
Par contre, la communication autour de ce projet est quasi-inexistante, même le site internet ne contient guère qu’une liste de jeu (sans même de lien vers leurs sites web respectifs pour les présenter). Ça n’inspire pas confiance, et si la distrib’ n’est en fait qu’une compilation de jeux, n’importe quelle distrib’ fera l’affaire car les potentiels utilisateurs sauront sûrement installer des jeux eux-même.
Dans mon cas, je suis parti sur OpenELEC : j’installe les jeux à la main et j’ajoute des lanceurs dans XBMC. Ça marche bien, et à terme ce sera encore plus intéressant quand les projets XBMC et RetroArch auront fini leur rapprochement et s’intégreront bien l’un avec l’autre.
nous cherchons quelqu'un d'autonome
ayant de bonnes bases en administration systeme
nous n'avons pas assez de moyens pour embaucher,
nous n'avons pas fixé le montant de la rémunération
c e n 'est donc pas dans un but d'exploitation pur et simple
P'tite question, est-ce que CookieMonster est comparable à RequestPolicy ?
Je pose la question car seul le premier est disponible dans les dépôts Debian
Les deux ne font pas la même chose, mais tu as de la chance :
plus j'ai l'impression qu'il n'y a finalement pas d'ordre logique ou naturel sur certains cas
Je suis d’accord. Il y a des cas qui sont de toutes façons problématiques. Ensuite, la question ici est de savoir comment les traiter :
une solution justifiable par la logique étant inexistante, un algo donnera des résultats insatisfaisants pour ces cas ;
une solution paramétrable en dur ne sera sûrement pas meilleure, mais elle présente l’avantage de pouvoir être décidée par le concepteur du menu, donc le jour ou il a une bonne raison d’agencer les widgets de façon anti-naturelle (je n’en ai pas en tête, c’est hypothétique), il a les outils pour assumer ce choix et maîtriser le résultat.
Pour la lib jnuit qui se veut générique, la différence entre les deux solutions peut se reformuler ainsi :
veut-on une bibliothèque complètement générique utilisable par tout le monde, même si les cas d’utilisations n’ont pas été envisagés à l’avance par l’auteur ;
ou comme le but est de bien faire les choses, est-il préférable de ne pas fournir d’outils qui facilitent les mauvais choix de conception (au risque que la notion de « mauvais » ne soit pas partagée par tous, ni par toutes les applications possibles).
En tant que développeur de la bibliothèque en question, c’est toi qui feras ce choix, et quel qu’il soit, il sera justifié.
les flashs sont interdits parce qu'ils donnent l'impression d'être violents et néfastes
Dans un grand musée avec beaucoup de visiteurs, ils seraient surtout insupportables. Regarder une toile illuminée au stroboscope des flashs n’est pas d’un grand confort pour tous ceux qui regardent l’œuvre avec leurs yeux plutôt que l’écran de leur smartphone.
Je voulais juste faire remonter mon avis pour signaler que tout le monde ne soutenait pas forcément cette demande, je ne souhaitais pas polémiquer, ni critiquer l’auteur de l’entrée de suivi. Je ne vais donc pas m’éterniser en arguments mais même après explication, je ne vois toujours pas d’amélioration en changeant la police par défaut :
je trouve DejaVu plus lisible que Open Sans sur les captures présentées, justement parce-que le hinting est beaucoup plus fort [0] ;
le « saut » est perceptible lorsque l’on change la taille de police, mais ne perturbe pas du tout la lecture si l’on ne change pas la taille de police pendant que l’on lit, donc je ne vois pas en quoi il gène ;
le « problème », s’il existe, se résout aisément dans le navigateur ;
je trouve étonnant que la solution préconisée soit d’adapter tous les sites visités (dont LinuxFr par effet de bord) plutôt que le navigateur ;
le contournement si le « problème » est corrigé côté CSS implique de surcharger ou écrire une CSS soi-même, ou de se passer des cas légitimes de polices personnalisées, ce qui est soit une solution complexe, soit se traduit par une perte de fonctionnalité et de confort.
De plus,
tous les navigateurs utilisent les mêmes polices par défaut donc le problème se pose partout
me fait penser, peut-être à tort, que ce choix par défaut est apprécié par beaucoup de monde, au moins parmi les développeurs de navigateurs et de distributions, et pas seulement par moi.
[0] Je ne vois pas le gain d’Open Sans avec les réglages de hinting utilisés pour la capture plutôt que DejaVu Sans sans hinting. Les deux me paraissent aussi floues.
Je m’arrête ici et laisse la police faire son travail les personnes concernées faire leur choix.
Ce n’est pas à Linuxfr de pallier un choix par défaut du navigateur qui ne plaît pas à l’utilisateur. Si les polices par défaut sont vraiment affreuses, le problème se posera sur tous les sites de la même manière et c’est au niveau du navigateur qu’il faut régler ce problème. À moins qu’elle découle d’un choix esthétique explicite, je ne vois pas pourquoi la police serait définie par le site visité. J’apprécie de pouvoir choisir une police lisible et qui me plaît, et j’apprécie que les sites respectent ce choix. Tout comme j’apprécie qu’ils utilisent la possibilité de changer la police pour des usages pertinents (mise en valeurs de titres, effets de styles).
De plus, je ne comprends pas la justification technique : chez moi DejaVu Sans est parfaitement « hinté » même en zoomant énormément. J’ai l’impression que le souci se situe plutôt du côté des réglages de l’utilisateur d’une part et du lissage de police exécrable sous Windows d’autre part.
S’il-te-plaît Nono, ne « corrige » donc pas ce bug/friture trop vite, il se règle facilement côté utilisateur pour le moment, et le « correctif » sera beaucoup plus embêtant à contourner si la police est forcée en CSS.
Posté par jyes .
En réponse à la dépêche LUTIm 0.2 : le retour.
Évalué à 4.
Dernière modification le 11 mars 2014 à 11:06.
Bien évidemment, il est conseillé, si on utilise le chiffrement, d'utiliser une connexion sécurisée
La clé est apparemment mentionnée dans l'URL qui est envoyée au serveur, donc tous les routeurs intermédiaires peuvent la récupérer
Si tu chiffres la connexion vers Lut.im alors les routeurs ne verront pas l’URL (ils ne verront que le nom du serveur contacté). L’intérêt de ne pas envoyer la clé au serveur, c’est que même l’administrateur de ce serveur (ou la NSA qui en aurait pris possession) n’aura pas la clé (avec le chiffrement côté navigateur, elle est même contenue dans une partie de l’URL qui n’est pas envoyée au serveur).
selon ta locale. Tu peux aussi définir tes propres séquences dans le fichier “~/.XCompose” en suivant le même format. Commence le alors par :
include "%L"
pour charger les séquences par défaut.
Attention toutefois. Tous ces réglages ne seront pris en compte que si tu utilises le mécanisme d’entrée XIM, si tu utilises un mécanisme alternatif (IBus, UIM, etc) il te faudra regarder du côté de leurs réglages. Tu peux vérifier quel mécanisme d’entrée tu utilises en regardant le contenu des variables d’environnement QT4_IM_MODULE et/ou GTK_IM_MODULE. Si ces variables sont vides, force les dans les réglages de démarrage de ta session, ou trouve le réglage correspondant pour ton environnement de bureau, car par défauts les toolkits ne l’utilisent pas forcément.
Par exemple, GTK utilise par défaut une table des séquences enregistrée en dur, synchronisée de temps en temps avec celle d’X.org. Du coup, GTK ne lira pas ton “~/.XCompose” par défaut. Cependant, dans les champs textes GTK par défaut, il est possible de changer localement la méthode de saisie vie le menu contextuel (clic droit/“Méthodes de saisie” ouvre un menu dans lequel figure “Méthode de saisie X”).
Je ne suis pas expert Windows (loin de là) mais Vista et son UAC ont été très critiqués par leurs utilisateurs. Personnellement, j’ai dû installer un Seven pour mon boulot, et mon compte était administrateur par défaut. J’ai dû en créer un second pour séparer les droits.
Un plus connaisseur que moi confirmera ou infirmera mais il semble que suite aux difficultés rencontrées par Vista, Microsoft est revenu à un compte administrateur par défaut dans la version suivante de son OS (par contre, je crois que c’est mieux fait avec Windows 8, mais je n’ai jamais vraiment bien compris comment celui-là fonctionne).
Si tu arrives à installer QEMU sous Windows, alors tu sauras quoi faire de la VM :)
Ben voila, c'est pas facile cette partie… C'est carrément éliminatoire.
C’est toi qui débarques avec ton OS moyenâgeux et râle parce-que ça marche pas en trois clics. Sous DOS, Virtualbox marche pas non plus. Ils indiquent clairement dans la FAQ que leur offre hyper-simplifiée s’adresse aux utilisateurs de *BSD et *Linux, mais que pour les windowseux les plus aventureux il y a quand-même moyen de la faire fonctionner. C’est honnête, et dans ces conditions la simplification est réelle. Pourquoi tu grognes ?
[^] # Re: ID
Posté par jyes . En réponse à la dépêche Rakoshare, un outil de synchronisation de dossiers pour tout le monde. Évalué à 3.
Dans ce cas autant partager un fichier chiffré avec GPG. Toute le monde peut alors transporter les données (aider à le faire transiter) mais seuls ses destinataires peuvent le déchiffrer. Bien sûr, on peut vouloir intégrer ça de façon plus couplée avec le protocole de partage pour gérer des droits ou du versionnement, mais dans ce cas l’approche de l’auteur me semble plus pertinente que je système de clefs asymétriques.
[^] # Re: Comment c’est possible ?
Posté par jyes . En réponse au journal [bookmark] 30 ans de X. Évalué à 2.
Espérons que des solutions standardisées émergeront. Je ne sais pas comment les logiciels KDE vont négocier ça avec Kwin, mais il y a de fortes chances que ça devienne le standard de fait. Espérons alors que les autres logiciels hors de KDE suivront. Il serait dommage que Wayland tue les gestionnaires de fenêtre pavant, ou à onglets et autres gestions de fenêtres avancées.
[^] # Re: je suis curieux
Posté par jyes . En réponse au journal Unicode 7.0 is out. Évalué à 4.
Avec Gnome, il y a Gucharmap qui permet de faire des recherches hors ligne sur le descriptif des symboles Unicode et de regarder leur représentation dans différentes polices de caractères. Pour le moment, il n’inclut pas encore Unicode 7.0 il me semble, mais ce n’est qu’une question de temps.
[^] # Re: Segmentation et dé-segmentation dans le développement mobile
Posté par jyes . En réponse au journal Apple annonce Swift, son nouveau langage de programmation. Évalué à 7.
Shippeur, arrête de shipper.
[^] # Re: Pourquoi je ne chiffre jamais mes courriels
Posté par jyes . En réponse au sondage Chiffrez/signez-vous vos courriels?. Évalué à 2. Dernière modification le 20 mai 2014 à 14:48.
Je réagissais surtout à
C’est évident que l’une des prémisses au chiffrement est de savoir à qui l’on destine son message.
Ensuite, pour une liste, il est sûrement plus pratique de partager un secret (qui peut toujours être une clé privée commune pour la liste, transmise une seule fois à chaque participant avec sa clé publique à lui, ce n’est pas une limitation de la crypto ou de PGP en soi).
[^] # Re: Pourquoi je ne chiffre jamais mes courriels
Posté par jyes . En réponse au sondage Chiffrez/signez-vous vos courriels?. Évalué à 8.
C’est un fait, le chiffrement fonctionne mal pour les informations diffusées publiquement. Ses critiques souligneront que c’est fort dommage car ça ne permet pas de s’assurer que seul un destinataire inconnu parviendra à lire le message. Étonnant, non ?
[^] # Re: Solution alternative
Posté par jyes . En réponse au journal OpenJDK JEP 180: HashMap, collisions & attaques par la complexité. Évalué à 10.
Tu as lu le journal avant de commenter ?
[^] # Re: Capture d'ecran sous linux ?
Posté par jyes . En réponse à la dépêche Un nouveau pelage pour Firefox 29. Évalué à 4.
C’est à mon avis nécessaire. Au delà de mon avis plus que réservé sur les décorations côté client, la richesse des environnement de bureaux dépasse largement Gnome et KDE. Les gestionnaires de fenêtres pavant, ou le groupement de fenêtres en onglets auront toujours des utilisateurs après le passage à Wayland… si les applications ne supportent pas un mode de décoration par le gestionnaire, la vie de ces utilisateurs sera bien moins belle quand « Linux sera prêt pour le desktop ».
[^] # Re: If it works, don't fix it.
Posté par jyes . En réponse au journal Chronique des dinosaures rétrogrades. Évalué à 6.
Les problèmes avec autofs, ou le boot sur partition chiffrée, etc me font penser que systemd n’est pas non plus un stradivarius. Personnellement, je pense que systemd est une piste intéressante, et sûrement le futur, mais il arrive beaucoup trop vite dans les distributions et est présenté par ses auteurs et défenseurs comme une solution qui surpasse toutes les précédentes, alors qu’il ne tient pas encore toutes ses promesses.
# Sécurité (installation)
Posté par jyes . En réponse au sondage Quels sont les critères de choix pour adopter un logiciel libre pour un non informaticien ?. Évalué à 2.
Je n’ai pas répondu « sécurité » au sondage car il y est explicitement fait référence à la réactivité. Cela me parait un bon argument, mais à destination des connaisseurs, et pas du tout du grand public non-informaticien. Par contre, dans mon entourage non informaticien, j’en trouve un certain nombre qui privilégient des logiciels libres par qu’il est en général plus facile de les trouver via des canaux « fiables ». Par fiable je n’entend pas ici un dépot et des paquets signés (ceux qui y seraient sensibles auraient déjà quitté Windows), mais pour les utilisateurs de Windows, au moins des installateurs qui ne pourrissent pas le système de logiciels tiers aux fonctionnalités pas très claires et de barres de recherche ou autres windowseries courantes.
Ce n’est pas vraiment un avantage inhérent au libre, mais les usages font que l’on trouve plus facilement des installateurs pour Windows propres pour des logiciels libres, sur les sites officiels des projets (et non sur télécharge-un-logiciel-gratuit-fourni-par-jenesaisqui.com). Je sais aussi combien cette habitude majoritaire n’est pas une règle absolue, Sourceforge ayant basculé du côte obscur maintenant, les mauvaises habitudes se répandent.
[^] # Re: Alternatives ?
Posté par jyes . En réponse au journal Condoleezza Rice nommée au conseil de direction de Dropbox. Évalué à 5.
Donc, tu cherches une alternative à Dropbox, qui ne soit pas dépendante du cloud (en utilisant la définition qui transparaît de ton commentaire : à savoir un service hébergé, joignable par le réseau Internet) ? Effectivement, toute alternative qui te sera proposée risque de te décevoir.
[^] # Re: Debian stable wheezy à jour mais version 1.0.1e
Posté par jyes . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 3.
"deb7u6" = Debian 7 (Wheezy) update 6.
Les mises à jour 5 et 6 (deb7u5, deb7u6) de l’équipe de sécurité servent justement à corriger la faille Heartbleed (cf. l’autre réponse de Xavier Claude pour le vérifier).
[^] # Re: FreeBSD
Posté par jyes . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 4.
Oui, mille excuses pour la désinformation. Erreur de ma part. La machine sur laquelle j’ai fait la vérification était en « oldstable » et non « stable ».
[^] # Re: FreeBSD
Posté par jyes . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 2.
C’est le rôle de « testing ». C’est plus un « bassin de décantation » de Sid, dans lequel les dépendances sont toujours cohérentes qu’une véritable distribution à part entière. Pour les problèmes de sécurité, les délais sont accélérés, mais le processus reste le même, rien n’entre dans « testing » sans maturation/validation préalable. Il faut bien comprendre qu’au départ « testing » n’était qu’une étape intermédiaire entre Sid et la nouvelle « stable » pour assurer sa cohérence, dans l’espoir de gagner du temps pour la sortie (avec un succès très relatif).
Le délai entre Sid et « testing » restera toujours, et pour du « responsible disclosure », Sid est corrigé au moment de l’annonce officielle, et donc « testing » traîne un peu.
En pratique, ça signifie qu’il ne faut pas utiliser « testing » seule. Sur un serveur, on laisse « stable » [0] de toute façon. Sur son ordi perso, on pioche dans Sid lors des annonces de sécurité (ou on ajoute un dépôt tiers pour la sécurité, solution qui devrait être adoptée pour Debian CUT si le projet aboutit).
[0] qui n’a été affecté ni par le bug Debian dans le générateur de nombres aléatoires, ni par celui-ci et dispose de dépôts de sécurité propres. Certaines failles surviennent évidemment en « stable » aussi, mais le niveau général de sécurité de cette distribution est incomparablement meilleur que les autres branches, voire que beaucoup de distrib’s.
[^] # Re: But?
Posté par jyes . En réponse à la dépêche AlbatrOS prend son envol. Évalué à 2.
Un ordinateur est quand-même plus polyvalent qu’une vieille console, d’ailleurs les consoles récentes font souvent beaucoup plus que lancer des jeux (lecteurs vidéos de salon, etc) et ces usages nécessitent plus qu’une vieille console d’occasion. Personnellement, j’ai pas mal cherché une distribution pour se bricoler une console de salon, et bien que je ne représente pas une masse critique d’utilisateur(s) à moi seul, je crois qu’il y a un besoin auquel LinuxConsole peut répondre.
Par contre, la communication autour de ce projet est quasi-inexistante, même le site internet ne contient guère qu’une liste de jeu (sans même de lien vers leurs sites web respectifs pour les présenter). Ça n’inspire pas confiance, et si la distrib’ n’est en fait qu’une compilation de jeux, n’importe quelle distrib’ fera l’affaire car les potentiels utilisateurs sauront sûrement installer des jeux eux-même.
Dans mon cas, je suis parti sur OpenELEC : j’installe les jeux à la main et j’ajoute des lanceurs dans XBMC. Ça marche bien, et à terme ce sera encore plus intéressant quand les projets XBMC et RetroArch auront fini leur rapprochement et s’intégreront bien l’un avec l’autre.
[^] # Re: stagiaire != CDD/Freelance
Posté par jyes . En réponse au message Stage Administration Système à Paris centre. Évalué à 3.
[^] # Re: RequestPolicy
Posté par jyes . En réponse au journal Internet, "Le Monde", et la 4G et la fibre optique. Évalué à 2.
Les deux ne font pas la même chose, mais tu as de la chance :
https://packages.debian.org/search?keywords=xul-ext-requestpolicy
[^] # Re: Hardcoder ?
Posté par jyes . En réponse au journal Les artistes, ce fléau ou l'invasion des profanateurs de GUI. Évalué à 2.
Je suis d’accord. Il y a des cas qui sont de toutes façons problématiques. Ensuite, la question ici est de savoir comment les traiter :
Pour la lib jnuit qui se veut générique, la différence entre les deux solutions peut se reformuler ainsi :
En tant que développeur de la bibliothèque en question, c’est toi qui feras ce choix, et quel qu’il soit, il sera justifié.
[^] # Re: Domaine public
Posté par jyes . En réponse au journal Les Halles, un tableau naturaliste. Évalué à 8. Dernière modification le 20 mars 2014 à 11:30.
Dans un grand musée avec beaucoup de visiteurs, ils seraient surtout insupportables. Regarder une toile illuminée au stroboscope des flashs n’est pas d’un grand confort pour tous ceux qui regardent l’œuvre avec leurs yeux plutôt que l’écran de leur smartphone.
[^] # Re: Bug à soumettre aux développeurs de navigateurs
Posté par jyes . En réponse à l’entrée du suivi Utilisation d'une police "zoomable". Évalué à 2 (+0/-0).
Je voulais juste faire remonter mon avis pour signaler que tout le monde ne soutenait pas forcément cette demande, je ne souhaitais pas polémiquer, ni critiquer l’auteur de l’entrée de suivi. Je ne vais donc pas m’éterniser en arguments mais même après explication, je ne vois toujours pas d’amélioration en changeant la police par défaut :
De plus,
me fait penser, peut-être à tort, que ce choix par défaut est apprécié par beaucoup de monde, au moins parmi les développeurs de navigateurs et de distributions, et pas seulement par moi.
[0] Je ne vois pas le gain d’Open Sans avec les réglages de hinting utilisés pour la capture plutôt que DejaVu Sans sans hinting. Les deux me paraissent aussi floues.
Je m’arrête ici et laisse
la police faire son travailles personnes concernées faire leur choix.# Bug à soumettre aux développeurs de navigateurs
Posté par jyes . En réponse à l’entrée du suivi Utilisation d'une police "zoomable". Évalué à 3 (+0/-0).
Ce n’est pas à Linuxfr de pallier un choix par défaut du navigateur qui ne plaît pas à l’utilisateur. Si les polices par défaut sont vraiment affreuses, le problème se posera sur tous les sites de la même manière et c’est au niveau du navigateur qu’il faut régler ce problème. À moins qu’elle découle d’un choix esthétique explicite, je ne vois pas pourquoi la police serait définie par le site visité. J’apprécie de pouvoir choisir une police lisible et qui me plaît, et j’apprécie que les sites respectent ce choix. Tout comme j’apprécie qu’ils utilisent la possibilité de changer la police pour des usages pertinents (mise en valeurs de titres, effets de styles).
De plus, je ne comprends pas la justification technique : chez moi DejaVu Sans est parfaitement « hinté » même en zoomant énormément. J’ai l’impression que le souci se situe plutôt du côté des réglages de l’utilisateur d’une part et du lissage de police exécrable sous Windows d’autre part.
S’il-te-plaît Nono, ne « corrige » donc pas ce bug/friture trop vite, il se règle facilement côté utilisateur pour le moment, et le « correctif » sera beaucoup plus embêtant à contourner si la police est forcée en CSS.
[^] # Re: Chiffrement
Posté par jyes . En réponse à la dépêche LUTIm 0.2 : le retour. Évalué à 4. Dernière modification le 11 mars 2014 à 11:06.
Si tu chiffres la connexion vers Lut.im alors les routeurs ne verront pas l’URL (ils ne verront que le nom du serveur contacté). L’intérêt de ne pas envoyer la clé au serveur, c’est que même l’administrateur de ce serveur (ou la NSA qui en aurait pris possession) n’aura pas la clé (avec le chiffrement côté navigateur, elle est même contenue dans une partie de l’URL qui n’est pas envoyée au serveur).
# XIM et ~/.XCompose
Posté par jyes . En réponse au message Touche compose, ☑ et ☐. Évalué à 10.
Les séquences sont définies dans les fichiers :
selon ta locale. Tu peux aussi définir tes propres séquences dans le fichier “~/.XCompose” en suivant le même format. Commence le alors par :
pour charger les séquences par défaut.
Attention toutefois. Tous ces réglages ne seront pris en compte que si tu utilises le mécanisme d’entrée XIM, si tu utilises un mécanisme alternatif (IBus, UIM, etc) il te faudra regarder du côté de leurs réglages. Tu peux vérifier quel mécanisme d’entrée tu utilises en regardant le contenu des variables d’environnement QT4_IM_MODULE et/ou GTK_IM_MODULE. Si ces variables sont vides, force les dans les réglages de démarrage de ta session, ou trouve le réglage correspondant pour ton environnement de bureau, car par défauts les toolkits ne l’utilisent pas forcément.
Par exemple, GTK utilise par défaut une table des séquences enregistrée en dur, synchronisée de temps en temps avec celle d’X.org. Du coup, GTK ne lira pas ton “~/.XCompose” par défaut. Cependant, dans les champs textes GTK par défaut, il est possible de changer localement la méthode de saisie vie le menu contextuel (clic droit/“Méthodes de saisie” ouvre un menu dans lequel figure “Méthode de saisie X”).
La situation n’a pas tellement évolué depuis mon journal sur ce sujet.
[^] # Re: Avis de Windowsien
Posté par jyes . En réponse à la dépêche VM4nerds : téléchargez des VMs sous Linux ou BSD prêtes à l'emploi sous QEMU-KVM. Évalué à 2.
Je ne suis pas expert Windows (loin de là) mais Vista et son UAC ont été très critiqués par leurs utilisateurs. Personnellement, j’ai dû installer un Seven pour mon boulot, et mon compte était administrateur par défaut. J’ai dû en créer un second pour séparer les droits.
Un plus connaisseur que moi confirmera ou infirmera mais il semble que suite aux difficultés rencontrées par Vista, Microsoft est revenu à un compte administrateur par défaut dans la version suivante de son OS (par contre, je crois que c’est mieux fait avec Windows 8, mais je n’ai jamais vraiment bien compris comment celui-là fonctionne).
[^] # Re: Avis de Windowsien
Posté par jyes . En réponse à la dépêche VM4nerds : téléchargez des VMs sous Linux ou BSD prêtes à l'emploi sous QEMU-KVM. Évalué à 10.
C’est toi qui débarques avec ton OS moyenâgeux et râle parce-que ça marche pas en trois clics. Sous DOS, Virtualbox marche pas non plus. Ils indiquent clairement dans la FAQ que leur offre hyper-simplifiée s’adresse aux utilisateurs de *BSD et *Linux, mais que pour les windowseux les plus aventureux il y a quand-même moyen de la faire fonctionner. C’est honnête, et dans ces conditions la simplification est réelle. Pourquoi tu grognes ?