Google Reader est bientôt mort, et l'on doit se poser la question : pourquoi avoir utilisé Google Reader plutôt qu'un aggrégateur local de fils RSS ? Dans mon cas, je vois quatre justifications possibles à l'utilisation de Google Reader pour la collecte des fils RSS. Par ordre décroissant d'importance :

• La mobilité : il existe quelques sites que je veux pouvoir suivre en déplacement avec tous les moyens informatiques disponibles, qu'il s'agisse d'un ordinateur emprunté quelques minutes dans un lieu de passage, d'une tablette ou d'un smartphone, et pour lesquels il est bien commode de synchroniser l'état de lecture entre les différents appareils utilisés ;
• Le souci de discrétion : une connexion sécurisée (https) vers Google.com est moins révélatrice qu'une connexion directe (et qui plus est non sécurisée) vers un site susceptible de déplaire à votre gouvernement ou à tout autre organisme qui prétend vouloir votre bien (et qui pourrait confondre facilement votre bien ou celui de la communauté avec le sien). Cette approche n'a cependant de sens que pour les cas où l'on peut faire raisonnablement confiance à Google. Or, le halo croissant de mystère autour de cette société doit faire s'interroger de plus en plus sur l'équilibre entre avantages et inconvénients.
• Plus marginalement, la courtoisie envers certains sites : envoyer une requête à Google plutôt que directement à ces sites permet de mutualiser l'utilisation de leur bande passante. Si vous envoyez à un site une requête toutes les cinq minutes alors qu'il publie seulement une fois par semaine, c'est que vous êtes un sagouin qui n'a pas vraiment réfléchi sur l'utilité des flux RSS. En passant par Google Reader, vous reportez sur la société de Mountain View la responsabilité de réfléchir.
• Ce n'est pas mon cas, mais certaines personnes peuvent être confrontées à des sites particulièrement bavards, qui nécessitent une collecte permanente des articles publiés. Un serveur allumé en permanence est la meilleure solution dans de tels cas.

Il fut un temps où je lisais tous mes flux en allant les chercher chez Google. Depuis le début de 2013, et même en tenant compte des raisons cités plus haut, moins de 10% des flux que je lis passent par Google. Ajoutons que je n'ai jamais utilisé l'interface web de Google Reader qu'à titre de solution de dépannage temporaire, car un client RSS dédié est bien plus réactif et sollicite moins la bande passante. C'est encore mieux lorsque ce client est capable de stocker les images afin de les afficher même en l'absence de connexion.

Il n'empêche que Google Reader ferme le 1er juillet, et l'on ressent comme un manque. Vers quoi se tourner ?

Pour beaucoup, l'alternative s'appelle Feedly. Feedly a gagné 500.000 utilisateurs dans les 48 heures qui ont suivi l'annonce de l'arrêt de Google Reader, et cela n'a rien d'étonnant : le produit est séduisant à l'oeil et plutôt bien fait. De plus, Feedly a été un des premiers services à annoncer qu'il s'efforcerait de reproduire l'API de Google Reader, ce qui ne peut qu'intéresser tous les développeurs de clients RSS comme moi.

Mais à titre personnel, je crains que Feedly ne soit pas le produit qui s'adapte à mes besoins :

• l'accès est largement moins universel que je ne le voudrais. Pour le moment, l'accès à Feedly n'est possible qu'après l'installation d'une application dédiée pour iOS ou Android ou d'une extension spécifique à certains navigateurs web (Safari, Firefox ou Chrome seulement).
• le business model de Feedly est encore plus mystérieux que celui de Google. Maintenir des serveurs pour satisfaire des utilisateurs coûte de l'argent, qu'entend faire Feedly pour faire bouillir la marmite ? Quelles seront plus tard les contreparties à payer pour ces "clients" ? ("clients" est mis ici entre guillemets, car le vrai client est celui qui paye en argent sonnant et trébuchant).

Ce billet devait traiter des petites astuces nécessaires pour mettre en place une installation de Tiny Tiny RSS. Mais il m'est entretemps apparu que NewsBlur.com était une meilleure alternative.

I am often amused and sometimes irked by financial "analysts", "tech pundits" and social networks comments about Apple being cornered by competition, losing its sense of innovation, and so on...

Countering these comments was not on my priority. Thanks to Timothy Pereira for gathering the demonstration that we are hearing the cover of an older song.
Real life is more complicated than A + B. Like any firm, Apple is reinventing itself ; the only real "problem" is that outsiders don't know yet how this is being done.

---

Why Apple Is Losing Its Appeal Again
by Sam Jaffe, published in BusinessWeek - Dec. 11, 2000

Investors may be asking themselves what Apple can do to revive its fortunes. The likely answer, unfortunately, is that Steve Jobs has no white rabbits left in his hat. Apple appears to be facing a dead end in its business growth, the victim of mismanagement and unmitigated hubris.

Technology's walking dead
by Michael Kanellos, published in ZDNet - Jan. 5, 2001

2004: Apple - Watch for the big fire sale. Pretty designs and overpriced blue plastic can only get you so far.

Mac G5: Too Little, Too Late
by James Maguire, published in NewsFactor - Jun 12, 2003

Looking at the future of the PC market, Apple's premium pricing structure becomes ever more outdated. A few years downstream, Linux desktops will force Windows to get cheaper. At that point even Windows boxes, seriously cheaper than Apple, will be in the "too expensive" category.

Will the iPod Become the Next Pet Rock?
by Paul Thurrott, published in Connected Home Magazine - Sep 15, 2004

Apple's short-term success is very real and quite admirable, but the company's inability to see coming trends in video, subscription content, and interoperability suggests that Apple is repeating the mistakes of the past. In the 1980s, the Mac held an early lead over the PC but was quickly buried after the industry standardized on a common Microsoft technology. Today, that series of events is repeating itself, and online music services -- and to a greater degree, the digital delivery of all media types -- is very much at a nascent stage. If Apple doesn't change its ways, the company simply won't survive.

[fr]

Un peu lassé du manque de support de la gestion de couleur dans les versions d'ImageMagick sur Mac, je teste photivo pour traiter mes fichiers. Vous pouvez télécharger une version Macintosh ici.

[en]

I made a Mac OS X build of photivo, an interesting tool for processing photographic RAW files. Download it here.

photivo is a photo processor for handing RAW files.

The following instructions updates on those found on photivo wiki as they were written by user kwip. These were tested on Mac OS X Mountain Lion, but the final result should probably run on Lion as well.

Installing and setting a current gcc compiler

Get a recent gcc

photivo requires gcc >= 4.6, because it needs a good support of OpenMP. But Apple freezed its support of gcc at level 4.2.1, in favor of LLVM compilers.

Fortunately, you won't need building gcc yourself. You can find recent builds of gcc and gfortran, thanks to the High Performance Computing for Mac OS X project.

Go there, and download both gcc 4.7.1 and gfortran 4.7.1 (fortran is needed for building fftw). Follow the site's instructions, and these components will get installed in /usr/local.

Make sure that /usr/local/bin is in your $PATH, but is behind /usr/bin, where are located Apple Xcode's command line tools. This is the default. (We will see later how to make sure gcc 4.7 is called when needed.)

Improve on the standard gcc

Apple's gcc incorporates the -arch extension, which is especially useful for building fat binaries. When they detect that they are run on a Macintosh, many configuration scripts expect gcc to support this extension ; the problem is that it is not incorporated in the standard gcc trunk, nor in HPC builds.

Fortunately, John Bowers found some creative solutions to these shortcomings.

He uses MacPorts in his examples, but my hpcgccfixup is a transposition to HPC's gcc. Download it, and do the usual "./configure, make, make install" stuff.

Notes :

• you will need cmake if it is not installed yet on your system,
• in case of problem, compare the variables set at the beginning of the CMakeLists.txt file to the structure of the archives downloaded from HPC (the Zipeg utility might be handy to inspect the archives)

Get Qt

The following frameworks from Qt are needed :

• QtCore
• QtGui
• QtNetwork

I got them for the open source version of qt libraries 4.8.3 for Mac.

Build Gtk+ for MacOS X

Download gtk-osx-setup.sh to your home directory and run it:

sh gtk-osx-build-setup.sh

If necessary, make ~/.local/bin added to your $PATH.

To tell jhbuild to use the 4.7 version of GCC, add these instructions at the end of the ~/.jhbuilrc-custom script :

os.environ["CC"] = "/usr/local/bin/gcc"
os.environ["OBJC"] = "/usr/local/bin/gcc"
os.environ["CXX"] = "/usr/local/bin/g++"
os.environ["F77"] = "/usr/local/bin/gfortran"

Now, do :

$jhbuild bootstrap
$jhbuild build meta-gtk-osx-bootstrap
$jhbuild build meta-gtk-osx-core

In case of trouble, see https://live.gnome.org/GTK+/OSX/Building

Build dependancies

Important : enter a jhbuild environment by typing the command:

$jhbuild shell

Grab some GraphicsMagick delegates (FTP) :

• libpng
• tiff
• libjpeg
• lcms2

Grab other elements :

• fftw3
• liblqr

Build the above elements in the order they are listed, using for each of them the sequence :

$ ./configure  --prefix=/Users/YOURUSERNAMEHERE/gtk/inst --enable-shared  --disable-static
$ make
$ make install

(Replace YOURUSERNAMEHERE with your Unix user name).

Get and build lensfun :

$ ./configure  --prefix=/Users/YOURUSERNAMEHERE/gtk/inst
$ make
$ make install

Still under a jhbuild shell, get and build GraphicsMagick (FTP) :

$ ./configure  --prefix=/Users/YOURUSERNAMEHERE/gtk/inst --enable-shared --disable-static --without-x --without-bzlib --without-zlib --without-xml --with-quantum-depth=16
$ make
$ make install

Note : after the ./configure stage, I recommend you check that JPEG, TIFF and PNG supports are enabled. If not, you might have missed something from above.

For some reason, exiv2 is the single dependency which should not be build under jhbuild (it crashes photivo otherwise). Open a normal shell, get exiv2 and build it :

$ ./configure  --prefix=/Users/YOURUSERNAMEHERE/gtk/inst --enable-shared  --disable-static
$ make
$ make install

Build photivo

You will need Mercurial (or a Mercurial client, I use SourceTree) to get the photivo code :

$ cd
$ hg clone https://photivo.googlecode.com/hg/ photivo

Replace every occurrence of /usr/bin/gcc with /usr/local/bin/gcc in the .pro files. Replace also every occurrence of /usr/bin/g++ with /usr/local/bin/g++ in the .pro files.

Make sure you are under a jhbuild shell again, and type these commands :

$ cd photivo
$ PATH=/usr/local/bin:$PATH qmake -spec macx-g++ CONFIG+=WithoutGimp
$ PATH=/usr/local/bin:$PATH make

(We force the use of the HPC gcc here).

You will probably get errors at this stage. You will have to fiddle with some of the Makefiles and repeat many times the PATH=/usr/local/bin:$PATH make command to get photivo.app build.

Personally, I had to :

• remove -rdynamic occurrences in ptclearProject/Makefile and photivoProject/Makefile
• remove spaces before line 16 of photivoProject/Makefile in order to have the parameter of -DAPPVERSION= correctly recognized

To make photivo.app run correctly, I also had to :

• copy ~/gtk/inst/lib/liblensfun.dylib in ~/lib
• copy the Themes directory in photivo.app/Contents/MacOS/

Package photivo

If you do a otool -L photivo.app/Contents/MacOS/photivo, you will notice there are references to libraries stored in your specific machine's directories. The following script will do the right stuff, using install_name_tool and Qt's macdeployqt.

#!/bin/sh
cd ~/photivo
rm -rf photivo.app
rm -rf photivo.dmg
PATH=/usr/local/bin:$PATH make
mkdir ./photivo.app/Contents/Resources/data
cp -R ChannelMixers Profiles Presets LensfunDatabase Icons Curves Themes ./photivo.app/Contents/Resources/data
mkdir ./photivo.app/Contents/Resources/data/images
cp *.png ./photivo.app/Contents/Resources/data/images/
cd photivo.app/Contents/MacOS
ln -s ../Resources/data/* .
unlink images
ln -s ../Resources/data/images/* .
cd -
install_name_tool -change liblensfun.dylib ~/gtk/inst/lib/liblensfun.dylib photivo.app/Contents/MacOS/photivo
cp photivo-appicon.icns ./photivo.app/Contents/Resources/
cp Info.plist ./photivo.app/Contents/
macdeployqt photivo.app
# The following instruction is optional :
# useful to people having an Apple developer ID for signing the build
codesign -f -s 'Developer ID Application' photivo.app
# Make a DMG
hdiutil create photivo.dmg -ov -volname "Photivo Mac OS X" -srcfolder photivo.app/ -format UDBZ

That's it, a photivo.app you can install on any recent machine !

Discussion enflammée sur Cuk sur la moralité et/ou la légalité de fabriquer un Hackintosh ; autrement dit de faire tourner un PC avec MacOSX, ce qui est interdit par la license utilisateur Apple. Le commentaire le plus lumineux me semble celui de Yanfi :

En ce qui concerne la license Apple “seulement sur du Matériel Apple”, je vois ça non pas comme une interdiction, mais comme une protection légale. Personne ne peut attaquer Apple en justice parce que OS X ne marche pas bien sur son matériel générique, non-Apple. Si Apple se mettait à vendre OS X séparément ils auraient alors la charge du support. Et je suis sûr que ça n’arrivera jamais.

Cette opinion (qui n’engage que moi) est supportée par le fait qu’Apple a fait ZÉRO efforts pour fermer les sites de Hackintosh. Ils ont pignon sur Web, si l’on peut dire. Aucun n’a reçu de mise en demeure et autres plaisanteries légales dont Apple sait très bien faire usage quand elle est déterminée à faire valoir ses intérêts. Je pense qu’il laissent faire en sachant que ceux qui aiment OS X après y avoir gouté, et qui se lassent de bricoler finissent par s’acheter un Mac, parce que “ça marche” (sauf quand ça tombe en panne, mais bon…).

Cette attitude me paraît complètement cohérente avec la culture Beatnik et libertaire qui imbibe une société comme Apple... Elle n'a aucune envie de trop s'embêter avec ce que le reste du monde bidouille. S'il y avait obligation morale de tenir compte de tout ce que les ateliers de Taïwan et de Chine produisent, ce serait beaucoup moins fun pour ses ingénieurs...

Parce que c'est déjà suffisamment contraignant d'avoir à s'assurer de la compatibilité avec ses propres matériels, Apple la libertaire se réserve le droit souverain de laisser tomber un truc « pas assez bien » ou « trop vieux ». Elle se souvient avec un brin de terreur que Mac OS n'avait jamais eu autant de problèmes et stagné que lors de la brève période où elle avait autorisé les clones. Qui plus est, elle garde à l'esprit qu'elle est capable de faire de vrais miracles lorsqu'elle est hyper-concentrée sur l'intégration très poussée de matériels choisis sans faire de concession au passé et d'un logiciel qu'elle maîtrise seule : ainsi naquit le premier Macintosh, ainsi se fit sa résurrection, et ainsi vit l'iPhone.

Certains déploreront une conception plutôt individualiste du "free and open". Mais on ne reste pas fun sans n'en faire parfois qu'à sa tête.

Tombé sur ça :

Popup Facebook: "Facebook wants to know your place." Moi: "Don't know, just ask Google... What? You're not friends with Google?"

Il y a de quoi être un rien jaloux à voir une telle catégorie baptisée « Fastoche... »

Les langages informatiques, c'est un peu comme les goûts et les couleurs. Quitte à passer pour un vieux ringard, j'avoue rester un peu Pascalien dans l'âme. J'aime les THEN bien lisibles, et prise fort peu les langages où la ponctuation joue un rôle clé.

Les syntaxes dérivées des shells Unix ou du C et leurs exigences côté {, }, &&, || et ; ont un petit côté masochiste à mes yeux. Oui, on s'y fait : j'ai même pratiqué avec intérêt le Perl, langage cryptique s'il en est.

Mais ces syntaxes restent peu naturelles à mes yeux. Lorsque je lis par exemple du code Javascript et du code Applescript, je ne ressens pas du tout le même plaisir. Inexplicable et pas forcément rationnel, mais c'est comme cela.

Et puis, à la fin de l'année dernière, j'ai lu la version française de « Become an Xcoder ». Et le côté intimidant du C et des surcouches objet s'est d'un coup sérieusement éloigné : foin de pointeurs, de complications liées à l'allocation d'objets... à condition d'accepter d'oublier tout ce qu'on avait appris auparavant.

Dans la réalité, les choses sont parfois un peu plus compliquées. Le langage a connu des évolutions dans le temps, et l'on rencontre notamment différentes approches en matière de gestion de mémoire. Me faisant la main en tentant d'améliorer du code existant, je découvrais plein de choses et ne voulait surtout pas tout casser ; et mon côté « développement durable » m'incite particulièrement à ne pas rendre des machines encore vaillantes prématurément obsolètes.

Mais en seulement huit mois, que de progrès ! Coïncidence, l'annonce publique du travail fait coïncidait avec une longue discussion un brin idéologique avec @tandriamirado (premier, deuxième et troisième arguments) qui m'en rappelait une autre pas si lointaine.

Je ne suis pas un idéologue, mais s'il est une chose que je peux assurer, c'est que coder sur Mac, ça me fait du bien. Et l'open source, il vaut mieux en faire qu'en parler.

Il y a un certain groupe de presse qui ne manque pas d'air, et qui n'a pas la légèreté d'un Mozart...

J'invite tous les blogs à créer un lien <a href="http://leschantiersdelapprentissage.eklablog.com/">Madame Figaro</a> pour bien marquer que la vraie Madame Figaro, c'est elle.

Pourquoi ? Parce que c'est l'histoire du pot de terre et du pot de fer... Et même si le groupe de presse qui ne manque pas d'air change d'avis, que sa politique de gros sabots reste en mémoire.

Edit : J'ai un gros faible pour cette fable de la coccinelle et de l'éléphant.

Edit 2: Tout est bien qui finit bien (sauf que c'est désormais Mme et non pas Madame...)

La migration du blog est achevée. La politique d'Apple, qui consiste à jeter sans pitié à la poubelle toute technologie qui n'est plus jugée suffisamment bonne, a certes des inconvénients, mais aussi des avantages. Après avoir subi la disparition finalement oubliée des lecteurs de disquettes, des ports série et SCSI, il a fallu cette année faire passer à la trappe MobileMe, précédemment Mac.com, anciennement iTools...

Mais cette politique de la terre brûlée technologique a sa contrepartie bénéfique : en obligeant à repartir d'une feuille blanche, elle amène à s'interroger sur ce que l'on estime vraiment essentiel et à concentrer toute son énergie sur l'amélioration de l'avenir.

À l'abandon de mac.com s'est ajouté celui de Haloscan/JS-Kit, celui-ci renonçant à ses activités d'hébergement de commentaires de blogs en Octobre prochain. C'est finalement cette seconde migration qui m'aura demandé le plus de travail et causé des frustrations ; car en examinant les alternatives, seul Disqus s'est avéré en mesure de récupérer le stock (dont une partie est vieille de dix ans) et même cela a loin d'être sans difficultés, l'alchimie de la liaison entre un billet et ses commentaires s'étant avérée plutôt subtile... Quant aux frustrations, elles tiennent d'une part à la nouvelle obligation d'avoir Javascript pour lire les commentaires, et d'autre part à la perte des Gravatars liés aux anciens commentaires.

Malgré cela, j'avoue que je reste plutôt satisfait de ce double reset technologique. Tout en préservant une philosophie minimaliste et un certain dépouillement graphique, il y a de réels rafraichissements dans la version 2012 : - celui qui, à mon sens, était le plus indispensable consiste en une lecture facilitée sur les petits écrans des téléphones portables ; sur ce point, le résultat visuel me semble plus personnel que ce que j'ai vu ailleurs (Wordpress et tes plugins, je m'adresse à toi) ; - pour la page principale, Disqus ne supporte pas officiellement l'affichage de commentaires de plusieurs articles sur une seule page, mais uniquement l'affichage du nombre de commentaires avec des renvois vers les pages individuelles. N'ayant pas l'habitude de me laisser impressionner par ce genre de challenge, j'ai hésité entre inclusions AJAH à l'intérieur de la page (ça rappellera peut-être quelque chose aux anciens) et les popups en dialogue modal. Les deux solutions ont été réalisées, mais quelques effets de bord avec l'inclusion AJAH m'ont amené à m'en tenir à la seconde solution (Disqus 2012 n'était pas encore disponible au moment des tests). Ce choix n'est peut-être pas définitif, bien que j'ai réussi à me passer du lourd jQuery (merci Tinybox 2) tout en conciliant écrans traditionnels et tactiles, du moins sur navigateurs basés sur Webkit.

Vos commentaires sur la fonction commentaires (ah ah) seront particulièrement bienvenus : avec un intérêt particulier sur les préférences en matière d'accessibilité, les suggestions d'améliorations pour les mobiles sous Opera, Mozilla et même (pas si sectaire que ça) Internet Explorer, voire des alternatives opensource à Disqus... Tout est possible, y compris l'impossible.

Autrement, par simplicité administrative et parce que ça ne fait pas de mal de commercer avec des gens qu'on connaît IRL (Mahefa est un ancien collègue de travail, et pas le plus mauvais), je me suis adressé pour l'hébergement à dot.mg (qui lui même s'approvisionne chez Hostigation). Prix très compétitif, support sympa et efficace, et un environnement Debian Squeeze familier qui me permet d'utiliser ssh et git : bien plus rapide pour transférer les mises à jour que la combinaison antérieure WebDAV/rsync. De quoi m'inciter peut-être à faire des billets plus nombreux et plus courts. Au bénéfice de mes 3 lecteurs ?

Alors que j'ignorais presque tout de cette maladie il y a encore 7-8 ans, j'ai du mal aujourd'hui à compter les personnes qui comptent pour moi qui sont mortes depuis d'un cancer du pancréas.

Wikipedia dit pudiquement : le cancer du pancréas est une tumeur de très mauvais pronostic. On survit rarement longtemps à ce cancer qu'on ne détecte le plus souvent que lorsqu'il commence à être au stade de la métastase. À ce moment, il est déjà inopérable et la survie médiane est de 6 mois. Je ne peux que confirmer.

Simple coïncidence ou illustration du fait que, en raison de la meilleure détection des autres cancers, celui-ci est condamné à devenir plus visible, il y eut cette semaine deux cas très médiatiques de décès suite à un cancer de pancréas.

Le comité Nobel s'est fait surprendre. Alors que depuis 1974, les statuts du célèbre Prix interdisent une remise à titre posthume, il annonçait lundi la remise du Nobel de médecine au Canadien Ralph Steinman (conjointement avec l'Américain Bruce Beutler et le Français Jules Hoffmann), alors que celui-ci était décédé trois jours plus tôt.

Il semble que Ralph Steinman ait pu prolonger sa vie en s'appliquant le résultat de ses propres recherches sur le système immunitaire. Pas suffisamment efficacement cependant pour apprendre sa récompense.

L'autre décès bien plus médiatisé est celui de Steve Jobs. Un survivant particulièrement conscient du caractère rarissime de sa situation et qui en avait retiré une leçon très forte.

[VOSTFR] Discours de Steve Jobs devant les étudiants de Stanford en 2005 recueilli par Cladouros.

L'émotion autour de la mort de Jobs est logique, car cela ne peut que glacer le sang que quelqu'un vous annonce qu'il part pour mourir, et qu'il meurt si peu de temps après. Nous sommes mortels, nous pouvons tous mourir beaucoup plus tôt que nous le croyons ; mais rares sont ceux qui apprécient qu'on le leur rappelle. Là réside sans doute une bonne part de la différence d'ampleur des réactions autour des morts de Steinman et de Jobs.

Mais l'émotion autour du décès de Jobs n'est pas due qu'à cela. Certains se glosent de cette émotion, sous prétexte qu'il n'était « qu'un » capitaine d'industrie. Comme si un capitaine d'industrie ne pouvait pas faire de sa vie une magistrale oeuvre d'art, comme si cela devait être réservé aux chefs d'orchestre, aux scientifiques, aux écrivains, ou à l'extrême rigueur, à un Enzo Ferrari...

Pour parodier un slogan publicitaire : on n'en rêvait même pas, et Jobs le faisait. Il a ouvert la route à ces bicyclettes pour nos esprits, et il l'a fait avec un sens du beau qui ne pouvait que nous rendre plus créatifs et plus inventifs. Rien à voir avec de la banale consommation.

Et encore moins avec des questions d'argent. "Being the richest man in the cemetery doesn’t matter to me… Going to bed at night saying we’ve done something wonderful… that’s what matters to me.”

Normal alors qu'on se fasse un peu de bile...

À lire aussi :

• « Steve Jobs, mon ami... », par l'autre Steve ;
• François Nonnenmacher ;
• Ma propre réaction au post de Maître Eolas.