17 October 2012

Added Google Chrome to Browser Preferences

After reading this recent review of Liferea over at TechNewsWorld I found that we somehow missed adding Google Chrome to the browser preferences!

Thanks to review author Jack M. Germain this is now added in 1.9 git branch to be released with 1.9.7.

As a workaround you can still use Chrome if you select "Default Browser" if your system preferences default to Chrome or you can specify the following "Manual Command" in the browser settings tab:

    google-chrome "%s"

Have fun!

09 October 2012

1.9.6 Released

Fixes mass downloading enclosures. Introduces support for downloading using the steadyflow download manager. Removes support for curl/wget. Improves spacing of browser tab buttons. Prevent DnD problems with Google Reader.

04 October 2012

1.8.9 Released

1.8.9 was released, but SourceForge seems to be instable right now...

So please be patient if you get HTTP 500 and try again some minutes later.

16 September 2012

Contributions to 1.8

Wanted to do this post for quite some time now... Here is a list of all the contributors to coded, debugged, tested, translated and otherwise helped getting out the current stable release line 1.8!

Adrian Bunk, Emilio Pozuelo Monfort, Sven Hartge, Leon Nardella, Gustavo Noronha, Hubert Figuiere, Jeff Fortin, Marc Brinkmann, Arnold Noronha, Simon Lipp, Rupr Swarbrick, Rafael Kitover, Ted Gould, Ricardo Cruz, hyperair, Fred Morcos, Solomon Peachy, Peter Oliver, Matthew Bauer, Wictor Lund, Sergey Snitsaruk, Maia Kozheva, Paulo Schreiner, Robert Trace, Dennis Nezic, Chris Siebenmann, adriatic, Paulo Anes, Regis Floret, John Levon, msqared84, Fabrice Bellet, Yanko Kaneti, prurigo, Chow Loong Jin, Daniel Noffsinger, Khaled Hosny, Vincent Lefevre, Gianvito Cavasoli, Takeshi Aihana, Antonio Lima, Daniel Nylander, Rodrigo Gallardo, Pavol Klacansk, Leonid Selivanov, Aron Xu, Besnik Bleta, Yuri Chornoivan, Yaron Sheffer, Anxo Outeiral, Joe Hansen, Marquinos, Ghengis Khan, Bruno Miguel, Erwin Poeze, Mikel Olasagasti Urange, Mindaugas Baranauskas, Rihards Prieditis, Jorma Karvonen, Rudolfs Mazurs

The list is propably incomplete: so thanks to everyone not listed that helped with 1.8 too!

And more importantly please keep the contributions on, as this is the only way how Liferea can go on and get better!

15 September 2012

Latest Security News in Your Feed Reader

Are you working in IT operations and responsible to keep the your systems safe and sound? Did you know that you can use Liferea (or any other news aggregator) as your primary source for security advisories and vulnerability news?

Using official feeds from Unix distributions and software vendors as well as aggregated feeds from sites as http://cvedetails.com/ you can get everything bundled in your news aggregator.

By selecting only the feeds for the distros and software stacks you run you get only the information you need (as to compared to all-purpose CERT bulletins). By using a news aggregator you keep track of the read status per advisory and can flag relevant advisories for later reference.

Feel free to check out my overview list of Unix / Linux IT Security Feeds!

14 September 2012

Fedora Crashes Solved

Thanks to different contributors phixy in SF #3481675, Fabrice Bellet and Yanko Kanedi in Fedora #857348 the crashing issue on Fedora has been debugged and solved.

The Cause 

The crash cause was found to be a missing signal handler disconnect in the HTML view class. So with the object being finalized, the signal handler for network change events did trigger on an object that didn't exist anymore. Interestingly this only did crash Liferea on Fedora.

So the effect did only happen when you lost your network connection after closing a browser tab (e.g. by Wifi resconnect).

New Packages


There are new Fedora packages for 1.8.8 FC17 and FC18. Please upgrade and retest! A new upstream release 1.8.9 will follow soon.


Feedback!

Thanks to everyone that did debug and retest the issue. If you upgrade to the fixed version in Fedora please leave a comment here wether it solves the crashes for you or not.

01 September 2012

Switched to GtkApplication

Todays commits saw 500 legacy code lines for X11 ICE session management gone! The functionality is now used from GtkApplication (introduced with GTK+ 3.4). Using GtkApplication also removes the libunique dependency.

As with many changes in 1.9 which is more or less a GTK+ 3 migration branch the end-user will not notice anything...

30 August 2012

Complying with the XDG directory specification

With the most recent commit for version 1.9.5 Liferea will now correctly follow the XDG directory layout. The XDG Base Directory Specification describes where applications have to put user data. The focus lies on separating different types of data (volative/cache/configuration/data needing backup...).

So according to the specification Liferea now uses the following three user data paths
  1. ~/.config/liferea for all configuration files as 
    • feed list OPML
    • user defined menu shortcuts
    • user defined CSS
    • ...
  2. ~/.cache/liferea for all cache files that can be deleted without problems
    • favicons
    • OPML caches
    • merged CSS
    • ...
  3. ~/.local/share/liferea for the database file

This way if you ever "rm -rf ~/.cache/" you'll also get the Liferea cache files and you can backup ~/.config or ~/.local knowing you'll backup everything to restore your Liferea data.

21 August 2012

Small Things Need To Be Fixed Too..

Until now: A non-standard close-button at the right of the URL.


Starting with 1.9.4: Per-tab close buttons as found in all major browsers.


Enjoy!

19 August 2012

Help Needed with the Crashes on Fedora!

Many Fedora users report frequent crashes of Liferea. As the only active developer right now I can only cover the Debian/Ubuntu world. My time doesn't allow more. Is there someone out the running Fedora with the necessary skills to debug this?

I guess a lot of users would be grateful for a solution.

Update: A list of crash reports
Most of the crashes are caused by a SIGABORT.

18 August 2012

Compile Problems with automake 1.12

Each new automake version makes developers happy! So also does 1.12 which seems to require an extra AM_PROG_AR in configure.ac. If you encounter this problem please add the line to configure.ac as a workaround!

Thanks to Matthias Männich for hinting this!

10 July 2012

Second Plugin: A Media Player

One thing I wanted to do for a long time, but wasn't possible until GObject introspection (short GIR) came around, was a playing multimedia attachments from within Liferea. Maybe you remember how we sometime ago we tried XSPF...

The reason of this being actually hard to do is that Liferea only depends on GTK+. This allows using Liferea with KDE, XFCE, Windows and other non-GNOME setups.

With GStreamer and Python via GIR it is as simple as this to get a working media player without any worries on compile time dependencies or codecs support. As a proof-of-concept I implemented a simple three button plugin for Liferea that allows playing music enclosures:




While this is experimental (git master, soon to be 1.9.4) I intend to enhance it to provide simple player control and support videos. When testing this interface several usability questions like "Can I switch to the next item with the song still playing?" already came up. So there is much to do, but this could be one of the next great things in Liferea.

I'm wondering how many of our user will use such a player?
Would you?


And if you are good at Python and GIR have a look at the plugin code and help building this!

07 July 2012

By the power of introspection...

... 1.9.4 will provide a libpeas based plugin system. With the first plugin being a GnomeKeyring integration so Liferea can stop storing unencrypted passwords in the feedlist.opml file.

28 June 2012

Ever-growing DB files

If you experience Liferea 1.8.5 eating more and more disk space while running please upgrade to the recent release 1.8.6 as we've fixed a bug with using prepared statements that caused the WAL journal checkpointing to be always blocked.

30 March 2012

AC_PROG_RANLIB needed?

Several users reported problems running "./configure" and that only adding "AC_PROG_RANLIB" to configure.ac helped to solve the issue. The blog statistics show some searches on this too. It is not yet clear what causes this problem. Still adding "AC_PROG_RANLIB" shouldn't be neceesary as we have "LT_INIT" in configure.ac. And according to the libtool documentation
— Macro: LT_INIT (options)
— Macro: AC_PROG_LIBTOOL
— Macro: AM_PROG_LIBTOOL

   Add support for the --enable-shared, --disable-shared,
--enable-static, --disable-static, --with-pic, and --without-pic
configure flags.1 AC_PROG_LIBTOOL and AM_PROG_LIBTOOL are deprecated
names for older versions of this macro; autoupdate will upgrade your
configure.ac files.
Does anyone reading knows a solution to this problem?

28 March 2012

1.8.3 in Debian now

Yesterday 1.8.3 went into Debian Sid (unstable). Once it gets to stable this will solve the performance issue for a lot of users.

25 March 2012

Full Screen Support

As discussed a while ago I've now implemented a simple fullscreen toggle. As in many other applications a toogle menu action can now be found in the "Views" menu. This enhancement will be released with 1.9.3

Navigate Your History of Read Items

Today I found the time to implement a simple item history feature. Liferea now tracks the last 250 viewed items and using the new backward/forward buttons in the toolbar (or the corresponding menu items in the "Item" menu) you can navigate through this sessions previously read items.

This helps a lot when you use the "Unread" search folder and accidentily skip an item and forgot from which feed it came.

Note: To introduce the new buttons I had to change the stock icon of the "Next Unread Item" button. I decided to change it from the "forward" stock button to the "jump to" stock button which I believe to be a good match.

This feature is planned to be released with 1.9.3

23 March 2012

Using sqlite3 WAL Journaling

Morpheus suggested in a comment to check recent Mozilla sqlite changes for their places database. They basically switched to the new WAL journaling that is supported since sqlite 3.7. Therefore I performed some measurements on the update behaviour in WAL mode with different sqlite page sizes and "PRAGMA synchronous" settings.

The Results:

FS Journal Mode Page Size Sync Mode Update Duration
ext4 none 1k (default) FULL 59s
ext4 WAL 1k FULL 6,3s
ext4 WAL 4k FULL 6,2s
ext4 WAL 8k FULL 5,9s
ext4 WAL 16k FULL 5,8s
ext4 WAL 32k FULL 6,7s
ext3 WAL 32k FULL 1s
ext4 WAL 32k NORMAL 0,9s

According to the sqlite documentation WAL journaling is expected to have a significantly better write-throughput compared to synchronous mode without journaling. The results above confirm this.

When using "PRAGMA synchronous=FULL" the execution time improves to 1/10 of the original 60s. With WAL journaling the sqlite documentation recommends to use only "PRAGMA synchronous=NORMAL". By doing so we loose the durability guarantee from the ACID criterias, but 1/60 of the original execution time might be worth it. The sqlite documentation says

 "There is a very small (though non-zero) chance that a power failure at just the wrong time could corrupt the database in NORMAL mode."

Additionally the page size is said to have an influence on the performance. This isn't the case for Liferea, but to be on the safe side it doesn't hurt increase from the default setting of 1k to 32k which should cost only a bit more memory.

Disadvantages:

  • As already mentioned the chance of data loss will increase...
  • Also sqlite3s WAL journal is not supported on network filesystems!

Fazit:

We have to try to switch to WAL mode.There is no guarantee that it will be safe without long term tests, but the immediate performance gain is critical.

I'll create two releases 1.8.3 and 1.9.2 soon and hope you give a lot of feedback! It would be most helpful if you can include the number of feeds, your cache size setting and DB file size.

60x Performance Decrease

For everyone wondering about the bad performance when using Liferea on ext4 this is how it looks:

Version Avg Startup Avg Full Update
1.6.7 (ext3) 2,3s 15,8s
1.8.0 (ext3) 2,6s
(VACUUM on startup)
1s
(introduced asyncsqlite)
1.9.1 (ext3) 2,1s
(VACUUM now on demand)
1,1s
1.9.1 (ext4 defaults) 2,2s 59,1s
1.9.1 (ext4 no barriers) 2,1s 1,2s

Test Notes:
  • All tests were performed on the same host with Debian Wheezy the same feed list (and same cache directory for each cache version) and a "echo 3 >; /proc/sys/vm/drop_caches" to get a cold disk. 
  • DB Size was roughly 10MB with 80 feeds and cache size 100
  • The "Avg Startup" column corresponds to the "liferea_shell_create" measurement you get with "liferea --debug-perf". The "Avg Full Update" column is the sum of the costs of all update callbacks as reported by the "feed_process_update_result" callback.

As you can see we have a 60-times decrease in performance with the same code! This causes the GUI to freeze during updates and surely makes Liferea unusable.

Dark Welcome Screen

1.9.1 fixes the welcome screen for dark themes which had a fixed background colour until now. Still I found no solution for the help pages (which are fixed black on white) as we load them as static files into Webkit with no chance to apply dynamically generated CSS...

What could be the best way to hook dynamic CSS into Webkit? I found no WebkitView properties for setting font and background color which would also be a solution and I want to avoid implementing an internal callback just to load dynamic CSS...


18 March 2012

1.8.2: VACUUM only when needed...

I believe a lot of our users will like this release. The startup behaviour until now was to perform a costly database VACUUM on each start. Starting with this release the VACUUM is only performed when a certain fragmentation ratio is reached.

Be lazy with cleaning!


This behaviour was suggested by adriatic in the discussion of a blog post concerning Lifereas performance by Jeff Fortin.

I hope this will easy the pain of the heavy users since most distros moved to ext4. Please give feedback wether this did help you or not!!!