Language Selection

English French German Italian Portuguese Spanish

Opening large PDF files in GNU/Linux: muPDF comes to the rescue

Filed under
Linux
HowTos

I was recently given an ebook by a friend. It was a photography book, with tons of hi-res images and very little text. When I opened it with Ubuntu, Evince (the default PDF viewer that comes with Ubuntu) gave in: after a few pages, it slowed to a crawl. I did a bit of research, and found the program that rescued my viewing needs: MuPDF. The good news was that I could finally read my book. The bad news was that I found out that the company behind it has in the past misunderstood the terms of the GPL and started a (later dismissed) litigation against Palm.

http://www.freesoftwaremagazine.com/articles/opening_large_pdf_files_mupdf_comes_rescue

More in Tux Machines

'This was bigger than GNOME and bigger than just this case.' GNOME Foundation exec director talks patent trolls and much, much more

Patent assertion entities: do not pick a fight with open source. It won't end well for you. This is the message from GNOME Foundation executive director Neil McGovern, who will speak on the subject at the Open Source Summit Europe next week. McGovern talked to The Register ahead of the event on patents, Microsoft, and more. The open-source outfit develops the default desktop environment on major Linux distributions including Ubuntu and Red Hat. In late August 2019, Rothschild Patent Imaging filed a lawsuit against the GNOME foundation claiming that GNOME Shotwell, a photo manager, infringed one of its patents. “We didn't receive a letter before the court documents were filed or any sort of warning, it was just filed and then within a week there was a settlement request for $75,000,” McGovern told us. Read more

Debian Janitor: Hosters used by Debian packages

The Debian Janitor is an automated system that commits fixes for (minor) issues in Debian packages that can be fixed by software. It gradually started proposing merges in early December. The first set of changes sent out ran lintian-brush on sid packages maintained in Git. This post is part of a series about the progress of the Janitor. The Janitor knows how to talk to different hosting platforms. For each hosting platform, it needs to support the platform- specific API for creating and managing merge proposals. For each hoster it also needs to have credentials. At the moment, it supports the GitHub API, Launchpad API and GitLab API. Both GitHub and Launchpad have only a single instance; the GitLab instances it supports are gitlab.com and salsa.debian.org. This provides coverage for the vast majority of Debian packages that can be accessed using Git. More than 75% of all packages are available on salsa - although in some cases, the Vcs-Git header has not yet been updated. Of the other 25%, the majority either does not declare where it is hosted using a Vcs-* header (10.5%), or have not yet migrated from alioth to another hosting platform (9.7%). A further 2.3% are hosted somewhere on GitHub (2%), Launchpad (0.18%) or GitLab.com (0.15%), in many cases in the same repository as the upstream code. Read more Also: Multiple git configurations depending on the repository path

Benchmarks and Graphics Leftovers: x86, Zink, and Navi

  • Intel Core i7 1165G7 Tiger Lake vs. AMD Ryzen 7 PRO 4750U Linux Performance

    For the Intel Tiger Lake Linux benchmarking thus far with the Core i7 1165G7 on the Dell XPS 13 9310 it's primarily been compared against the Ryzen 5 4500U and Ryzen 7 4700U on the AMD side since those are the only Renoir units within my possession. But a Phoronix reader recently provided me with remote access to his Lenovo ThinkPad X13 with Ryzen 7 PRO 4750U (8 cores / 16 threads) for seeing how the Tiger Lake performance compares against that higher-end SKU. Phoronix reader Tomas kindly provided SSH access to his ThinkPad X13 with Ryzen 7 PRO 4750U and 16GB of RAM. The Ryzen 7 PRO 4750U is quite close to the Ryzen 7 4800U with 8 cores / 16 threads but graphics capabilities in line with the 4700U. He's been quite happy with the ThinkPad X13 as a replacement to the Dell XPS 13 for business usage and has been running it with Ubuntu 18.04 LTS on the Linux 5.8 kernel.

  • Mike Blumenkrantz: Catching Up

    A rare Saturday post because I spent so much time this week intending to blog and then somehow not getting around to it. Let’s get to the status updates, and then I’m going to dive into the more interesting of the things I worked on over the past few days. Zink has just hit another big milestone that I’ve just invented: as of now, my branch is passing 97% of piglit tests up through GL 4.6 and ES 3.2, and it’s a huge improvement from earlier in the week when I was only at around 92%. That’s just over 1000 failure cases remaining out of ~41,000 tests. For perspective, a table.

  • AMD 'Big Navi' 3DMark Firestrike results shared by HW testing firm

    The Linux specialists over at Phoronix have noticed that the AMD Linux driver has been tweaked to add support for a new graphics card dubbed the "navi10 blockchain SKU". It comments that the only visible difference in support for this card vs existing Navi 1X support, from the driver perspective, is that the patches disable the Display Core Next (DCN) and Video Core Next (VCN) support - basically creating a 'headless' Navi 1X graphics card. Cryprocurrency is showing signs of a resurgence in popularity and values, and some are worried that the latest and greatest GPUs from both Nvidia and AMD will be plucked from retailers even faster if they are viable mining platforms. It has been reported that AMD is trying to make sure retailers follow certain distribution practices with its upcoming Radeon RX 6000 series products, to make sure they are distributed to gamers and enthusiasts rather than scalpers and such like. An initiative like creating appealing crypto-specific Navi 1X products might help everyday consumers get their hands on a new Navi 2X graphics card too.

Does the Snap Store Use Too Much Memory?

This week I noticed that the Snap Store app on my Ubuntu 20.10 laptop uses a tonne of memory, even when it’s not running — we’re talking more memory than the main GNOME Shell process uses, and that is always running! Naturally I assumed something in my config was to blame. I do make heavy use of Snap apps — don’t worry I use plenty of Flatpak and PPAs too. I’m pretty polyamorous when it comes to packaging formats and I did install using an Ubuntu 20.10 daily build. Therein lay bugs. I know the caveats. All good. Don’t mind. Whatever. Read more