Cyanogen vient de sortir la RC2 de sa version 10.1 (basée sur Android 4.2.2 Jelly Bean)
Vous pouvez la télécharger sur get.cm

A noter que, contrairement à ce que laisse entendre FrAndroid, le best-seller Samsung Galaxy S III européen, n'aura pas de version Cyanogen 10.1 officielle. En effet, malgré les nombreuses paroles de Samsung, les sources pour le support de leur processeurs Exynos 4 sur Android Jelly Bean n'a jamais été publiées. Est-ce même légal au regard de la GPL puisque certains S3 ont été vendu avec Jelly Bean pré-installé? Andrew Dodd explique la saga en long et en large sur son blog. Il y a vraiment de quoi être désappointé.

Original post of Tuxicoman.Votez pour ce billet sur Planet Libre.

Si vous avez une ip fixe et un serveur avec une connexion stable, pool.ntp.org ont besoin de vous. Installez un serveur de temps et participer à la redondance du système.

Vous pouvez aussi utiliser librement ntp.bazzanella.org pour synchroniser les horloges de l’ensemble du parc de vos machines.

Ma config :

nano /etc/ntp.conf

restrict 127.0.0.1
restrict network W.X.Y.Z mask A.B.C.D nomodify notrap
server chronos.univ-montp3.fr
server chronos2.univ-montp3.fr
server ntp.crifo.org
server ntp.duckcorp.org
server ntp.pbox.org
driftfile /var/lib/ntp/drift

W.X.Y.Z est votre réseau
A.B.C.D est votre masque de réseau

Vous devez choisir au moins 5 autres serveurs proches de chez vous.

Un ntpq -p doit vous donner :

remote refid st t when poll reach delay offset jitter
=========
+ns1.univ-montp3 192.93.2.20 2 u 33 128 377 13.938 -0.921 0.144
+anubis.univ-mon 192.93.2.20 2 u 24 128 377 13.958 -1.000 0.139
*ntp.crifo.org 192.93.2.20 2 u 17 128 377 4.271 -1.415 0.218
-orfeo.duckcorp. 192.93.2.20 2 u 27 128 377 9.495 -4.828 4.677
-ns.pbox.org 192.93.2.20 2 u 60 128 377 4.421 -0.487 0.305

et sur votre vhost ntp.tonsite.tld il est sympa de faire une redirection 301.
Pour ma part: http://ntp.bazzanella.org est redirigé vers http://www.pool.ntp.org/fr/

Configurez également votre parefeu en fonction pour le port 123

Une fois que cela tourne, vous pouvez inscrire votre service ntp sur le site http://www.pool.ntp.org/fr/ dans manage server et demander par mail à Bjørn Hansen (très sympa), si tout est ok avec un récapitulatif de votre config et de votre ntpq -p. Vous trouverez comment le joindre sur le site.

Si tu vous avez des soucis, les logs de votre machine et si vous ne vous en sortez toujours pas la mailing-list du site pool.ntp.org, ils vous apporteront l’aide nécessaire …

En espérant que ces quelques infos puissent vous aider à mettre en place votre serveur de temps et l’intégrer à pool.ntp.org.

Original post of bazzanella.Votez pour ce billet sur Planet Libre.

Que feriez-vous ?

Le titre est provocateur. Pour ceux qui n’utilisent pas github, je me doute que vous ne ferez rien. Quoique…

Comme vous le savez, github est un service de gestion de projet utilisant git. Comme tout service administré par un tiers (qu’il soit libre ou non, ça ne change rien), sa pérennité n’est pas assurée.

Contrairement à beaucoup de services du "cloud", l’utilisation de github n’est pas le mal absolu, car étant basé sur un gestionnaire de version décentralisé, chaque contributeur possède une copie locale avec l’historique du code.
Théoriquement, si github fermait, nous devrions pouvoir tout reconstituer avec ce que nous avons sur nos disques.

Dans la pratique, s’assurer d’avoir des copies à jour de ce qui nous intéresse, ce n’est pas du luxe. Joey Hess, l’un des développeurs dont j’apprécie le travail, a développé github-backup.
Le logiciel est codé en Haskell et publié en GPL. L’utilisation est triviale, il suffit de lire le README.

Le principale avantage de ce logiciel est de récupérer les tickets ainsi que les forks (aspect de récursivité). C’est donc une sauvegarde complète. La limite provient de l’API de github, qui limite les requêtes. Il faut donc lancer parfois plusieurs fois le script, surtout lors de la première copie. Ensuite, naturellement, ça fonctionne en "diff".

Pour ma part, j’ai mis ce code python en trois minutes et lancé en tâche cron sur mon serveur. a, b et c sont bien entendu des dépôts fictifs.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# Author: Francois Boulogne
# License: GPLv2+

import os
from subprocess import call
import random

repos = ['a',
        'b',
        'c',
        ]
random.shuffle(repos)

backup_dir = os.path.expanduser('~/github_backup')

soft = 'github-backup'

for repo in repos:
    backup_path = os.path.join(backup_dir, repo)
    os.makedirs(backup_path, exist_ok=True)
    os.chdir(backup_path)
    call([soft, repo])

En quelques mots, le fonctionnement. Je mélange ma liste de dépôts. De cette manière, je ne commence jamais par le même dépôt, et j’évite qu’un dépôt sature le compteur de l’API de github et empêche ainsi la sauvegarde d’autres dépôts. Pour le reste, je crée des répertoires et je me place dedans pour synchroniser. Il faudrait que je maintienne un log pour être propre, avec le sortie de la commande.

On pourrait ensuite mettre en place une interface web là-dessus comme gitweb pour avoir un miroir visible par d’autres.

A titre personnel, je synchronise mon espace, mais aussi les projets que j’apprécie et qui sont hébergés sur github. Ce sont parfois de petits codes qui ne font pas la une de linuxfr, mais j’y accorde beaucoup d’importance.

Pour ce qui est de la question original, j’essaie de me poser systématiquement la question sur ce qui m’environne. Et si ça disparaissait ? Comment serait-je affecté ? Comment puis-je l’anticiper pour que ça se passe au mieux ?

Original post of François.Votez pour ce billet sur Planet Libre.

GitHub est aujourd’hui la plus dynamique forge de développement de logiciels libres. Mais n’y aurait-il pas, dans sa conception même, quelques problèmes de gouvernance et de circulation du code qui menacent l’efficacité, voire la viabilité, des projets ?

Remarque : Pull request, issue, commit… nous présupposons que vous êtes familier avec le vocable GitHub, mais si un gentil lecteur veut nous les préciser dans les commentaires, qu’il/elle n’hésite surtout pas ;)

De la citoyenneté dans le développement de logiciels open source

On Citizenship in Open-source software development

Christophe Maximin - 8 mai 2013 - Blog personnel
(Traduction : ProgVal, Melchisedech, nano-plink, TheCamel, Al + anonymes)

Comment GitHub peut révolutionner la question en donnant le pouvoir aux utilisateurs dans les dépôts auxquels ils contribuent.

TL;DR : En donnant un véritable statut social aux personnes contribuant à un dépôt, GitHub résoudrait le problème des projets-zombies ayant une communauté éparpillée. En permettant à ces citoyens de collaborer réellement les uns avec les autres, et non avec le seul propriétaire, les dépôts seront vivants tant que leur communauté existera, de manière complètement auto-régulée.

L’année a très bien commencé pour GitHub. Après avoir levé cent millions de dollars d’Andreesen-Horowitz et atteint les trois millions d’utilisateurs en janvier (3,4 millions et plus à présent), ils sont sur une dynamique qu’il sera difficile d’arrêter.

Néanmoins, le service a aussi ses défauts, et si certaines personnes pointent du doigt de tous petits problèmes liés aux services et aux applications, le problème que je m’apprête à décrire touche à la nature même de nos interactions sur la plate-forme.

1. État actuel d’un dépôt

Chaque dépôt que vous créez est un petit pays avec une très faible population : 1 habitant, vous, le créateur/roi/commandant suprême.

Même si votre dépôt a des centaines de rapports de bugs créés par d’autres, et des centaines de pull requests, il n’y a qu’une seule personne aux commandes.

Bien sûr, vous pouvez ajouter des collaborateurs à votre dépôt, mais il ne seront que des collaborateurs, des membres du cabinet, choisis juste parce que vous le souhaitez. Bien sûr, dans le cas des organisations, vous pouvez ajouter des co-commandeurs suprêmes.

Mais c’est tout. Vous n’atteindrez probablement pas cinquante collaborateurs/membres; même si votre dépôt est vraiment populaire, et même si des centaines de personnes y contribuent. Est ce que cela vous parait normal ?

Ce ne serait pas un problème si ce n’était pas la cause de…

2. La fragmentation des dépôts et de leurs fonctionnalités

J’ai vu la chose suivante arriver bien trop souvent :

• Le développeur abandonne graduellement un projet à cause de nouveaux engagements dans sa vie, ou juste parce qu’il n’est plus intéressé. Et donc il regarde les pull requests une fois par mois, peut être. Le projet semble vivant. Il ne l’est pas.
• Le développeur est dépassé par les rapports de bugs et les pull requests qu’il reçoit. Et bien qu’il sache qu’il a une solide communauté autour de ce projet, il ne peut pas juste ajouter quelqu’un comme collaborateur car il devra quand même lire chaque ligne pour être sûr que tout est en ordre. Et donc, il regarde les pull requests une fois par mois, peut être. Le projet semble vivant. Il ne l’est pas vraiment.

Et vous vous dites : « Qui s’en soucie ? N’importe qui peut forker le dépôt et donner une nouvelle vie au projet autre part ! »
Bien entendu, mais combien de fois avez-vous vu cela se faire réellement ?
La plupart du temps, les gens forkent le projet pour régler « le » bug qu’ils voulaient régler, et c’est tout.

Maintenant, si vingt personnes agissent de la sorte, cela devient une vraie tragédie : le projet est en fait encore mis à jour, mais à vingt autres endroits. Vous devrez fusionner les commits de 20 dépôts différents pour être à jour de toutes les nouvelles choses cools que vous pouvez faire avec le projet. Mais vous ne le ferez jamais. Certains forks sont incompatibles de toute façon.

D’autre part, comme le projet « semble vivant », personne ne se presse pour essayer de le remplacer. La léthargie se poursuit alors encore et encore, et va créer la confusion chez n’importe quel nouveau venu quant à l’état du projet, sur l’emplacement des dernières mises à jour, et sur leur éventuelle acceptation par la communauté.

Je ne vais pas donner de noms (ce n’est pas bien de pointer du doigt publiquement) , mais je suis sûr que vous voyez à quoi je fais référence.

3. Le pouvoir au peuple, le pouvoir à la cité

Sans entrer dans un débat sur les multiples définitions du mot citoyenneté, vous trouverez ici une liste de quelques fonctionnalités qui en feront une réalité. Rien de ce qui est listé ici n’est absolu, et ce sera à l’administrateur de définir les règles.

• Tout le monde peut voter pour une issue.
• Tout le monde peut voter pour une pull request, avec un merge automatique quand une majorité (ou quelque chose d’autre à définir) est atteinte.
• Les citoyens se voient attribuer des « points de karma » suivant les votes positifs ou négatifs qu’ils reçoivent sur leurs commits et leurs réponses aux issues. Les citoyens ont un total de points pour ce dépôt, et pour le reste de GitHub.
• Tous les commits qui sont approuvés par le peuple vont dans un branche spécifique préfixée « par_le_peuple_* » .
• Les administrateurs ont toujours le droit de veto sur ce qu’ils veulent, et peuvent complètement couper ce mode « auto-pilote » .

Conclusion

Il est temps que les gens qui contribuent à des projets acquièrent enfin une réelle existence. Il n’y a vraiment rien à perdre, et cela semble pour moi être une évolution naturelle et inévitable de toute façon.

La question est : combien de temps devrons nous attendre ?

Original post of Framablog.Votez pour ce billet sur Planet Libre.

Plop les bovins,

L’info n’est pas toute fraîche mais pour ceux qui ne le savent pas encore, une version 4.10.1 d’XFCE a été publiée il y a quelques jours, embarquant sont lot d’améliorations et de corrections de bugs. Cette version n’inclut pas de grandes nouveautés mais constitue plutôt une version de « maintenance », visant à rendre XFCE 4.10 plus stable et plus performant.

Parmi les changements importants nous relèverons le passage de Thunar en version 1.6.3, qui améliore l’outil permettant de renommer facilement plusieurs fichiers, qui corrige quelques problèmes relatifs aux raccourcis clavier et qui optimise la transition entre les nouveaux onglets de navigation.

On notera également la mise à jour d’Xfce4-terminal corrigeant ainsi quelques problèmes liés à la barre d’outils de ce dernier, la mise à jour d’Xfce-panel qui corrige le problème d’affichage des icônes inférieures à 22 pixels et la correction d’un bug concernant xfce4-notifyd, dont les notifications n’apparaissaient pas correctement quand le mode de composition était activé.

Nous noterons enfin l’amélioration du support pour systemd, la suppression du soutien pour Gnome-keyring (ce qui occasionne moins de dépendances nécessaires pour installer Xfce), la correction d’un bug affectant l’enregistrement d’une session Xfce et enfin, la mise à jour de divers modules (xfwm4 4.10.1, libxfce4util 4.10.1, tumbler 0.1.29, garcon 0.2.1, etc…), ainsi que diverses corrections de bugs.

Si ça vous intéresse, vous pouvez consulter l’annonce de sortie en vous rendant sur cette page.

XFCE 4.10.1 est déjà disponible dans les dépôts officiels d’Archlinux et d’autres dérivés comme Manjaro, mais le PPA pour Ubuntu (et dérivé n’a pas encore été publié. Il faudra donc encore un peu patienter.

Amusez-vous bien.

Moo!

source + image

Original post of Noireaude.Votez pour ce billet sur Planet Libre.