17 Dec 2017

feedPlanet GNOME

Michael Catanzaro: Epiphany Stable Flatpak Releases

The latest stable version of Epiphany is now available on Flathub. Download it here. You should be able to double click the flatpakref to install it in GNOME Software, if you use any modern GNOME operating system not named Ubuntu. But, in my experience, GNOME Software is extremely buggy, and it often as not does not work for me. If you have trouble, you can use the command line:

flatpak install --from https://flathub.org/repo/appstream/org.gnome.Epiphany.flatpakref

This has actually been available for quite a while now, but I've delayed announcing it because some things needed to be fixed to work well under Flatpak. It's good now.

I've also added a download link to Epiphany's webpage, so that you can actually, you know, download and install the software. That's a useful thing to be able to do!

Benefits

The obvious benefit of Flatpak is that you get the latest stable version of Epiphany (currently 3.26.5) and WebKitGTK+ (currently 2.18.3), no matter which version is shipped in your operating system.

The other major benefit of Flatpak is that the browser is protected by Flatpak's top-class bubblewrap sandbox. This is, of course, a UI process sandbox, which is different from the sandboxing model used in other browsers, where individual browser tabs are sandboxed from each other. In theory, the bubblewrap sandbox should be harder to escape than the sandboxes used in other major browsers, because the attack surface is much smaller: other browsers are vulnerable to attack whenever IPC messages are sent between the web process and the UI process. Such vulnerabilities are mitigated by a UI process sandbox. The disadvantage of this approach is that tabs are not sandboxed from each other, as they would be with a web process sandbox, so it's easier for a compromised tab to do bad things to your other tabs. I'm not sure which approach is better, but clearly either way is much better than having no sandbox at all. (I still hope to have a web process sandbox working for use when WebKit is used outside of Flatpak, but that's not close to being ready yet.)

Problems

Now, there are a couple of loose ends. We do not yet have desktop notifications working under Flatpak, and we also don't block the screen from turning off when you're watching fullscreen video, so you'll have to wiggle your mouse every five minutes or so when you're watching YouTube to keep the lights on. These should not be too hard to fix; I'll try to get them both working soon. Also, drag and drop does not work. I'm not nearly brave enough to try fixing that, though, so you'll just have to live without drag and drop if you use the Flatpak version.

Also, unfortunately the stable GNOME runtimes do not receive regular updates. So while you get the latest version of Epiphany, most everything else will be older. This is not good. I try to make sure that WebKit gets updated, so you'll have all the latest security updates there, but everything else is generally stuck at older versions. For example, the 3.26 runtime uses, for the most part, whatever software versions were current at the time of the 3.26.1 release, and any updates newer than that are just not included. That's a shame, but the GNOME release team does not maintain GNOME's Flatpak runtimes: we have three other other redundant places to store the same build information (JHBuild, GNOME Continuous, BuildStream) that we need to take care of, and adding yet another is not going to fly. Hopefully this situation will change soon, though, since we should be able to use BuildStream to replace the current JSON manifest that's used to generate the Flatpak runtimes and keep everything up to date automatically. In the meantime, this is a problem to be aware of.

17 Dec 2017 7:24pm GMT

Julita Inca: #PeruRumboGSoC2018 – Session 5

Today we have celebrated another session for the #PeruRumboGSoC2018 program at CCPP UNI. It was one of the longest sessions we have experienced.

We were able to cope with different packages and versions to work with WebKit and GTK on Fedora 26 (one of the students have a 32 bit arch), and on Fedora 27One of the accomplishes today was coding a Language Selector using GtkListBox and GtkLinkButton with GTK and Python, here in detail.

Newcomers bug list on gitlab was also checked today, specially of the applications gnome-todo and gnome-music. As well Fedora Docs Dev,system-config-language and the implementation of Elastic Search were evaluated and discussed as possible GSoC 2018 proposals for Fedora. Thanks @zodiacfireworkThis is the final chart of the effort of the participants. In this picture we have Cristian (18) as @pystudent1913 and Fiorella (21) as @aweba. They are the top two! 🙂We have shared a lunch and some food at the afternoon. Thanks again to our sponsors: GNOME, Fedora & Linux Foundation for the support of this challenge!gogogo PeruRumboGSoC2018!


Filed under: FEDORA, GNOME, τεχνολογια :: Technology Tagged: #PeruRumboGSoC2018, fedora, GNOME, GSoC, GSoC Fedora proposal, GSoC GNOME gitlab, GTK 3, gtk.py, Julita Inca, Julita Inca Chiroque, LinuXatUNI, PeruGSoC, Python

17 Dec 2017 5:09am GMT

Jim Hall: Top ten in 2017 (part 1 of 2)

It's been a great year in the usability of open source software. As I look back on the last twelve months, I thought it would be interesting to highlight a few of my favorite blog posts from the year. And here they are, in no particular order:

1. The importance of the press kit

In December 2016, we released FreeDOS 1.2. Throughout December and into January, FreeDOS was the subject of many many articles in tech press, magazines, websites, and journals. I credit our press kit, which made it really easy for anyone to write an article about FreeDOS. In this essay, I explain how we created our press kit, and the features your open source software press kit should contain so journalists can write about you.

2. Good usability but poor user experience

I like to remind people that usability is not the same as user experience. They really are two different concepts. Usability is about making software that real people can use to do real tasks in a reasonable amount of time. User experience is more about the emotional response users have when they use the software. Often, programs that have good usability will have a positive user experience, and vice versa. But it's possible for a program to have good usability and a negative user experience. Here's one example.

3. I can't read your website

The current trend in website design seems to be grey text on a light background. That's really hard for most people to read. And your small font sizes aren't helping, either. Here are a few examples of the same stanza of text in different styles. See also Calculating contrast ratios of text and The readability of DOS applications as interesting followup.

4. Screencasts for usability testing

When you're moderating a usability test, you may ask your testers to use the "speak aloud" protocol, where they say out loud what they are trying to do. If they are looking for a Print button, they should say "I'm looking for a Print button." As the tester works through the usability test, you might take notes about what the tester is doing, and where they are "looking" with their mouse. An easier way to track this is to record a screencast, for later playback. Here's an example in GNOME.

5. How many testers do you need?

Usability testing in open source software isn't that hard. But when I talk about how to do a usability test in open source software, most people ask me "How many testers do I need?" It turns out that you don't need that many people. The short answer is "about five."


I'll share part two of my top-ten list next week!

17 Dec 2017 12:09am GMT

15 Dec 2017

feedplanet.freedesktop.org

Christian Schaller: Some predictions for 2018

So I spent a few hours polishing my crystal ball today, so here are some predictions for Linux on the Desktop in 2018. The advantage of course for me to publish these now is that I can then later selectively quote the ones I got right to prove my brilliance and the internet can selectively quote the ones I got wrong to prove my stupidity :)

Prediction 1: Meson becomes the defacto build system of the Linux community

Meson has been going from strength to strength this year and a lot of projects
which passed on earlier attempts to replace autotools has adopted it. I predict this
trend will continue in 2018 and that by the end of the year everyone agrees that Meson
has replaced autotools as the Linux community build system of choice. That said I am not
convinced the Linux kernel itself will adopt Meson in 2018.

Prediction 2: Rust puts itself on a clear trajectory to replace C and C++ for low level programming

Another rising start of 2017 is the programming language Rust. And while its pace of adoption
will be slower than Meson I do believe that by the time 2018 comes to a close the general opinion is
that Rust is the future of low level programming, replacing old favorites like C and C++. Major projects
like GNOME and GStreamer are already adopting Rust at a rapid pace and I believe even more projects will
join them in 2018.

Prediction 3: Apples decline as a PC vendor becomes obvious

Ever since Steve Jobs died it has become quite clear in my opinion that the emphasis
on the traditional desktop is fading from Apple. The pace of hardware refreshes seems
to be slowing and MacOS X seems to be going more and more stale. Some pundits have already
started pointing this out and I predict that in 2018 Apple will be no longer consider the
cool kid on the block for people looking for laptops, especially among the tech savvy crowd.
Hopefully a good opportunity for Linux on the desktop to assert itself more.

Prediction 4: Traditional distro packaging for desktop applications
will start fading away in favour of Flatpak

From where I am standing I think 2018 will be the breakout year for Flatpak as a replacement
for gettings your desktop applications as RPMS or debs. I predict that by the end of 2018 more or
less every Linux Desktop user will be at least running 1 flatpak on their system.

Prediction 5: Linux Graphics competitive across the board

I think 2018 will be a breakout year for Linux graphics support. I think our GPU drivers and API will be competitive with any other platform both in completeness and performance. So by the end of 2018 I predict that you will see Linux game ports by major porting houses
like Aspyr and Feral that perform just as well as their Windows counterparts. What is more I also predict that by the end of 2018 discreet graphics will be considered a solved problem on Linux.

Prediction 6: H265 will be considered a failure

I predict that by the end of 2018 H265 will be considered a failed codec effort and the era of royalty bearing media codecs will effectively start coming to and end. H264 will be considered the last successful royalty bearing codec and all new codecs coming out will
all be open source and royalty free.

15 Dec 2017 8:53pm GMT

Bastien Nocera: More Bluetooth (and gaming) features

In the midst of post-release bug fixing, we've also added a fair number of new features to our stack. As usual, new features span a number of different components, so integrators will have to be careful picking up all the components when, well, integrating.

PS3 clones joypads support

Do you have a PlayStation 3 joypad that feels just a little bit "off"? You can't find the Sony logo anywhere on it? The figures on the face buttons look like barbed wire? And if it were a YouTube video, it would say "No copyright intended"?


Bingo. When plugged in via USB, those devices advertise themselves as SHANWAN or Gasia, and implement the bare minimum to work when plugged into a PlayStation 3 console. But as a Linux computer would behave slightly differently, we need to fix a couple of things.

The first fix was simple, but necessary to be able to do any work: disable the rumble motor that starts as soon as you plug the pad through USB.

Once that's done, we could work around the fact that the device isn't Bluetooth compliant, and hard-code the HID service it's supposed to offer.

Bluetooth LE Battery reporting

Bluetooth Low Energy is the new-fangled (7-year old) protocol for low throughput devices, from a single coin-cell powered sensor, to input devices. What's great is that there's finally a standardised way for devices to export their battery statuses. I've added support for this in BlueZ, which UPower then picks up for desktop integration goodness.

There are a number of Bluetooth LE joypads available for pickup, including a few that should be firmware upgradeable. Look for "Bluetooth 4" as well as "Bluetooth LE" when doing your holiday shopping.

gnome-bluetooth work

Finally, this is the boring part. Benjamin and I reworked code that's internal to gnome-bluetooth, as used in the Settings panel as well as the Shell, to make it use modern facilities like GDBusObjectManager. The overall effect of this is, less code, less brittle and more reactive when Bluetooth adapters come and go, such as when using airplane mode.

Apart from the kernel patch mentioned above (you'll know if you need it :), those features have been integrated in UPower 0.99.7 and in the upcoming BlueZ 5.48. And they will of course be available in Fedora, both in rawhide and as updates to Fedora 27 as soon as the releases have been done and built.

GG!

15 Dec 2017 3:57pm GMT

11 Dec 2017

feedplanet.freedesktop.org

Eric Anholt: 2017-12-11

It's been a while since I posted a TWIV update, so this one will be big:

For VC5 GL features:

While running DEQP tests on all this (which unfortunately don't complete yet due to running out of memory on my 7268 without swap), I've also rebased my Vulkan series and started on implementing image layout for it.

I also tested Timothy Arceri's gallium NIR linking pass. The goal of that is to pack and dead-code eliminate varyings up in shared code. It's a net ~0 effect on vc4 currently, but it will help vc5, and I may be able to dead-code eliminate some of the vc4 compiler backend now that the IR coming in to the driver is cleaner.

On the VC4 front, Boris has posted a series for performance counter support. This was a pretty big piece of work, and our hope is that with the addition of performance counters we'll be able to dig into those workloads where vc4 is slower than the closed driver and actually fix them. Unfortunately he hasn't managed to build frameretrace yet, so we haven't really tested it on its final intended workload.

For VC4 GL, I did a bit of work on minetest performance, improving the game's fps from around 15 to around 17. Its desktop GL renderer is really unfortunate, using a lot of immediate-mode GL, but I was completely unable to get its GLES renderer branch to build. It also lacks a reproducable/scriptable benchmark mode, so most of my testing was against an apitrace, which is very hard to get useful performance data from.

I debugged a crash in vc4 with large vertex counts that a user had reported, landed a fix for a kernel memory leak, and landed Dave Stevenson's HVS format support (part of his work on getting video decode into vc4 GL).

Finally, I did a bit of research and work to help unblock Dave Stevenson's unicam driver (the open source camera driver). Now that we have an ack for the DT binding, we should be able to get it merged for 4.16!

11 Dec 2017 12:30am GMT