Xavier Teyssier a écrit 1230 commentaires

Heu… Tu es sûr de toi ? Parce que là, je ne trouve pas…

Si Steam ne veut plus que tu joue, par exemple parce que tu n'aimes pas les nouvelles conditions d'utilisation, tu ne joue plus

Je n'ai pas envie de défendre un système de DRM quel qu'il soit, mais comment vont-ils m’empêcher de jouer ?
Quand je joue dans le train, je peux t'assurer que je n'ai aucune connexion Internet, et pourtant, je joue. Du coup, sans connexion Internet, Steam est incapable de m'empêcher de jouer.

Déjà fait : http://blog.humblebundle.com/post/75606190436/so-much-civilization-the-humble-sid-meier-bundle-is

Mais je n'avais pas regardé si les jeux étaient DRMisés.

avant la distance entre le pc et l'écran était toujours limité par la longueur maximum des cables VGA ou DVI.

Ou pas.

http://www.blackbox.fr/fr-fr/fi/1495/12151/Extender-Wizard-Multimedia-MM/

Il y a quelques mois, j'ai utilisé avec succès la doc suivante pour me créer un DVD personnalisé de CentOS :
http://www.virer.net/info/custom-dvd/

Peut-être pas la méthode la plus propre, mais ça fonctionne !

À mon avis une "mémoire collective" ne peut pas se construire par des moyens techniques, mais d'abord par des actions collectives: chacun peut mettre un petit lien "oui il y a des informations pertinentes sur la dépêche/journal machin"

Et c'est là que l'espace de rédaction collaborative de Linuxfr prend toute sa dimension.
Si chacun apporte un peu de sa mémoire, y'a moyen d'obtenir un contenu vraiment riche.

Quand à l'aide technique, oui, lors de la rédaction d'une dépêche, un cadre mentionnant quelques news se rapprochant pourrait être pas mal. Détermination avec des tags dans un premier temps, puis avec des technologies d'analyse de langue naturelle pour tendre vers des propositions les plus pertinentes possibles…

En gros, à partir du thème, on affiche le nuage de Tags évoqué par zeroheure, et à partir des tags choisis, on propose un ensemble de dépêche qui se rapprocherait du sujet.

Vous pensez que ce serait un plus ?

Tu lèves un point intéressant, mais difficile à traiter. Comment conserver/mettre en valeur/retrouver facilement les dépêches à "fort contenu ajouté" ?

Les journaux ne sont pas une solution. Au contraire, dans les journaux, il y a vraiment de tout et n'importe quoi.
Les dépêches apportent déjà une certaine garantie de qualité. Mais comme tu le signales, il n'y a pas de distingo entre l'annonce de la dernière réunion du lug du coin et une grosse dépêche Kernel. Les catégories permettent un premier tri, et les notations un second. Mais ce n'est absolument pas satisfaisant pour cela.

On pourrait effectivement, comme mentionné par Xavier Claude, utilisé le Wiki, soit comme annuaire, soit avec une page de synthèse sur les principaux sujets qui apporterait des pointeurs vers nos "gros" articles, mais ce serait un travail aussi fastidieux que chronophage (autrement dit, je doute que ce soit maintenu dans le temps…).

J'essaie quelquefois, quand je modère une dépêche, d'inclure des liens vers d'autres articles Linuxfr, mais n'y pense pas toujours, et surtout, ne me rappelle pas forcément des news déjà publiés sur des sujets similaires…

Difficile problème, toute suggestion pour la mise en valeur des articles à "fort contenu ajouté" est la bienvenue !

Corrigé.
Merci !

Voilà. La news bien plus complète sur Shinken est maintenant validée.

Wahouh ! C'est terrifiant, je n'ai rien compris ! Peut-être suis-je mal réveillé, mais ça parle d'unités, de timers, de conteneurs, ça évoque je ne sais combien d'applications différentes qui commencent par systemd-*… Wahouh !
Ce truc devient particulièrement complexe ! Ce qui est un peu effrayant quand on voit qu'une part non négligeable de la stabilité du système en dépend…

Question aux utilisateurs avancés du truc : est-ce qu'il existe une doc claire, exhaustive et précise sur ce que fait/sait faire/peut faire systemd, sur ses différents modules et comment les utiliser ?

interface graphique incontournable : encore des codeurs kikoolol pour qui la ligne de commande est démodée ?

La cible, ce n'est pas le développeur ou l'admin sys, mais le grand public. Et le grand public, s'il y a la moindre ligne de commande à taper, il va voir ailleurs.

Créer un tag ? Un journal ?

Mais non, directement dans l'espace de rédaction ! C'est fait pour cela, et cela permet à tout un chacun de contribuer :-)

Et si plusieurs tests de distro voient le jour au cours du temps, je pense qu'il n'y aura absolument aucun souci à créer une catégorie "Test de distribution" !

On sur linuxfr, tu aurais pu parler un peu de la technique.

La news a passé presque 40 jours sur le Wiki de l'espace rédaction, tu aurais pu y insérer quelques éléments techniques.

Et vous comment gérez-vous votre maintenance préventive ?

En faisant plein de sauvegardes.

De toute façon, mes disque vont mourir. Demain ou dans 15 ans, mais ils vont mourir.

Donc toutes mes données sont sauvegardées sur une machine, archivées sur une seconde, et pour certaines, répliquées sur une troisième, hors de chez moi.

J'ai inutilé. Je ne vois pas ce que ce commentaire peut apporter à la discussion, à moins de souhaiter sciemment entretenir un climat délétère sur ce site.

Et pour ceux qui se posent la question, Capsicum a déjà été détaillé dans une dépêche Linuxfr.
J'en cite un extrait : En deux mots, il s’agit de permettre aux applications de faire tourner certaines parties de leur code dans des « sandboxes » (bacs à sable) aux droits très restreints, gérés finement, avec la possibilité de recevoir ou de déléguer dynamiquement une partie de ces droits.

Tu n'es beaucoup plus modéré et posé, que l'autre abrutis de Beurt qui est soit un mega troll, soit une fille qui devrait voir un psy.

Hop hop hop ! Le débat est passionné, les opinions difficilement conciliables, mais aussi difficile que cela soit, merci de rester poli et respectueux.

Comment faire un choix résonné (et justifiable auprès d'une hiérarchie) dans un foutoir pareil ?

En expliquant à la hiérarchie que Nagios, ce n'est plus qu'un nom exploité par une société qui ne fait plus que du propriétaire, que les forks, c'est le foutoir où on ne sait plus qui fait quoi, et qui survivra, et qu'aujourd'hui, la véritable alternative, c'est Shinken, qui reprend les principes de Nagios en les améliorant grandement, qui existe en libre, mais avec une boite derrière basée en France et pouvant apporter du support et/ou des évolutions personnalisées si besoin.

Tout simplement ;-)

Non, je n'ai pas (encore ;-) ) d'actions Shinken :-)

En même temps, l'auteur de Nagios n'est pas des plus doué en communication et/ou en ouverture d'esprit, ni fait preuve de beaucoup de clémence envers les projets contenant le nom "Nagios" sur lesquels il n'a pas une main-mise totale… Tu es malheureusement bien placé pour le savoir… Malheureusement… Non, heureusement en fait, c'est grâce à cet état d'esprit que ton projet a pu se développer ;-)

De manière générale, est-ce que tu arrives à pinguer une adresse IP qui n'est pas sur ton réseau local ?

Si non, c'est probablement un problème de passerelle.

Depuis quelques semaines, voire mois, mon KDE (4.11.3) est d'une instabilité désespérante : vautrage d'akonadi qui ne veux plus redémarrer si le vent n'est pas dans le bon sens, disparition de mail ou à l'inverse mails dupliqués quelques centaines, voire milliers de fois… Insupportable…
Mais KDE n'y est probablement pour rien, c'est surtout moi qui cherche les ennuis : je suis en Debian Sid, et mon $HOME a subi bon nombre de mise à jour.
Sauf que, mon PC perso, je n'ai plus envie de bidouiller dessus, maintenant, j'aimerais juste m'en servir.

Quel distrib utiliser pour avoir un KDE stable et bien configuré d'office ?

Donc il y a bien des applis, peut-être de calendrier, qui ont une période de test raisonnable, mettons 2 jours ?

Il y a plein d'applications qui existent en version gratuite, avec plein de pubs et/ou quelques fonctionnalités en moins, et en version payante, sans pub et/ou avec toutes leurs fonctionnalités. Ce qui permet de prendre tout son temps pour tester et décider de passer à une version payante ou non.

Associer une commande ou application à un type particulier de fichier était un exercice très frustrant, c'est désormais un plaisir.

Dire que c'est désormais chez aisée, soit. Mais de là à qualifier l'opération de plaisir… :-)

Plus sérieusement, il me semblait avoir lu, il y a un certain temps, que Linux Mint ne voulait plus se baser sur Ubuntu, mais directement sur Debian. Apparemment, ce n'est pas le cas aujourd'hui, et je ne retrouve trace nulle part de cette intention. J'avais complètement rêvé ? Ou conserver Ubuntu comme base s'est avéré plus simple ?

Ah non, je proteste, dans l'histoire, c'est la tienne qui est customisée. C'est quoi tous ces dépôts ? :-)

Pour ma part, je n'ai que les dépôts base, addons et extras d'activés. Et je ne sais pas pourquoi ils n'apparaissent pas dans la liste. Je suppose que c'est parce qu'ils pointent vers un serveur en local.

Les seules customisations que j'ai apportées sur ces machines, c'est justement cela : faire pointer les dépôts vers des mirroirs présents sur notre réseau interne (et sur cette machine spécifiquement, désactiver le dépôt updates, mais ça, c'est une autre histoire).

Effectivement, pour le temps d'exécution de la commande, le fait que les mirroirs soit en local doit jouer. Perso, le temps d'exécution de yum ne m'a jamais gêné. Mais pour ceux qui en sont à la seconde près, j'ai déjà lu qu'on peut le configurer pour que l'équivalent du "aptitude update" ne soit pas réalisé à chaque exécution de YUM, mais uniquement sur appel manuel. Perso, je n'en suis pas à la seconde près, et j'aime les trucs automatiques :-)

Tu rajoutes à cela que je trouve yum lent, que la recherche dans ce dernier ne fonctionne pas sans être root

Ta Red-Hat m'a l'air d'avoir été drôlement customisée :

[xate@carbonatite ~]$ time yum search vim
Loaded plugins: fastestmirror
============================================================================= Matched: vim =============================================================================
vim-X11.x86_64 : Version VIM de l'éditeur vi pour le système X Window.
vim-common.x86_64 : Fichiers communs indispensables pour toute version de l'éditeur VIM.
vim-enhanced.x86_64 : Version de l'éditeur VIM comprenant des améliorations récentes.
vim-minimal.x86_64 : Version minimale de l'éditeur VIM.

real    0m0.964s
user    0m0.676s
sys     0m0.276s
[xate@carbonatite ~]$

Et je peux t'assurer que l'utilisateur Xate n'est pas l'utilisateur root…