Alexander Larsson: Flatpak – a history

Share Button

I’ve been working on Flatpak for almost 4 years now, and 1.0 is getting closer. I think it might be interesting at this point to take a retrospective look at the history of Flatpak.

Early history

Ancient Egyptian Flatpak

The earliest history goes back to the summer of 2007. I had played a bit with a application image system called Klik, which had some interesting ideas. However, I was not really satisfied with some technical details. One day at the beach I got an interesting ideas for a hack that could improve this.

Fast forward until August 2007 when I released Glick in the wild, based on these ideas. The name is sort of a pun on the old KDE/Gnome first-letter naming scheme, although neither Klik or Glick are really desktop-specific.

Glick was a a single-file-image system. It predates usable kernel container APIs, so it uses fuse and some weird hacks. It doesn’t integrate with the desktop in any way, and applications have to decide what to bundle, falling back to system-libraries for the non-bundled things. This means its not terribly robust., but it is completely stand-alone and need nothing installed on the host system.

Around 2011 the initial support for kernel namespaces had landed and started being useful. Using these I could avoid some of the hacks that my earlier experiment used. So, I got interested in bundling again and released Glick 2 based on this.

Glick 2 requires some software to be installed on the host, which allows it to integrate better with the system. For example, you can “install” bundles by putting the file in a known location, and doing this allows some level of desktop integration. Glick 2 also uses SHA1 checksums to try to automatically de-duplicate files shared between applicatins. Here we can see an early version of the ideas that make up OSTree.

Bundling using namespaces was lot more robust than the previous hacks, but it still relied on the system for the core libraries that the application doesn’t bundle. So an app would sometimes work on one distro, but not another.

Around this time I posted a blog  about how I thought application bundling combined with read-only OS images can make a really good model for an OS. This idea is very similar to what Project Atomic / SilverBlue  are doing now.

Containers, Portals and Runtimes

A few years later, around 2013 the kernel support for containers was starting to shape up, and Docker hit the market. I did a lot of work on the early docker, like porting it away from aufs in order to run on RHEL.

Around this time I also attended the Gnome Developer Experience hackfest  in Brussels where one of the topics was Application deployment and sandboxing. From the discussions there (and my previous experiences) a lot of the core ideas of Flatpak, like runtimes, sandboxing and portals originated.

In 2014 the first version (then called xdg-app) was released. The current Flatpak is a lot more polished, but the initial version of xdg-app is still very much recognizable today.

xdg-app used OSTree to download, store and de-duplicate applications. It uses kernel namespaces (via a helper called xdg-app-helper) to do unprivileged containers. It has a split between applications and runtimes which allow applications to be portable between distros in a very robust fashion, while still limiting the duplication between applications and allowing security updates. There is also integration with the desktop (icons, desktop files, mimetypes, etc), and some very early portal code can be seen.

The great renaming

Modern Flatpak

The name xdg-app was just something I picked for the first commit without much consideration, and it was not very good. However, names are hard, and we spent a lot of time trying to come up with another, eventually settling on “Flatpak” (with the above logo). The 0.6.0 release in may 2016 was the first with the new name.

The 0.6 release was also the first that split out the unprivileged container launcher (xdg-app-helper) into its own project, now known as BubbleWrap , hosted by Project Atomic.

Soon thereafter we had the first release of xdg-desktop-portal which is the host-side implementation of the portal idea, allowing sandboxed applications to safely break out of the sandbox in a controlled fashion.

Version 0.8.0, released december 2016 was the first long-term stable release, which was included in Debian Stretch and RHEL 7. Since then we have had another stable release series called 0.10.x.

We want apps!

Flatpak was always a decentralized system, in that anyone can host their own applications and be on equal terms with everyone else. However, while this is an important feature, it leads to a poor initial experience, both for users (hard to find apps) or developers (need to maintain their own repository).

To solve this we started the Flathub project, which is a single repository where you can find most apps. In the last year it has gone from a minimal viable product building its first app to something with more than 300 apps and a diverse group of developers.

Onwards and upwards!

Future Flatpak

No software is ever finished, or bug-free, but we have had a list of core things that we wanted to have before calling Flatpak 1.0, and that list is now empty. So, I’m planning to release a release-candidate (called 0.99.1) later this week.

Then 1.0 will be released later this summer.

Powered by WPeMatico

Share Button

Fedora Magazine: Welcome to Fedora CoreOS

Share Button

This is a message from Fedora Project Leader Matthew Miller.

Hi everyone. If you saw my talk at DevConf.cz this year, you’ll remember I discussed the Fedora / Red Hat relationship, and specifically how Fedora has historically worked with new technologies that come our way through acquisitions made by our primary sponsor. Little did I know, but at that very moment, something huge was in the works, and when my plane landed back in Boston my phone blew up with messages about CoreOS joining Red Hat.

That’s obviously gigantic news, directly relevant to Fedora, since we are the project Red Hat depends on for operating-system level integration and innovation. Now, most of the news is about Kubernetes, OpenShift, Tectonic, and Quay — but there’s also Container Linux (the operating system formerly known just as “CoreOS”). At Red Hat Summit, the company announced and clarified a bunch of things around product and corporate plans. Now, it’s time for us to figure out how we can welcome and include the Container Linux community in the circle of Fedora Friends.

What does this mean for the Fedora community?

Good things! Container Linux is exciting, innovative, and has a passionate user and developer community. The people who built it are awesome and well-aligned with the Fedora community foundations.

The “Fedora Editions” strategy intentionally makes space for exploring emerging areas in operating system distributions. CoreOS will help us push that even further and bring new ways of doing things to the project as a whole.

What does this mean for Container Linux users?

More good things! I know this is kind of scary. Fedora CoreOS is going to be built from Fedora content rather than in the way it’s made now. It won’t necessarily be made in the same way we make Fedora OS deliverables today, though. No matter what, we absolutely want the CoreOS user experience of “container cluster host OS that keeps itself up-to-date and you just don’t worry about it.” Again, technical details are a discussion for elsewhere, but the goal is for existing Container Linux users to be as happy as — or happier than! — you are with the OS today.

And here’s the super-important thing: Fedora really is a community-driven project, and this means that you can get involved and directly influence how the future Fedora CoreOS works to meet your needs. If you’re interested and need help getting involved, don’t hesitate to talk to me, to the Join Fedora team, or to the developers and community people already working on the project.

What does this mean for Fedora Atomic Host and other deliverables?

This isn’t the place for technical details — see “what next?” at the bottom of this message for more. I expect that over the next year or so, Fedora Atomic Host will be replaced by a new thing combining the best from Container Linux and Project Atomic. This new thing will be “Fedora CoreOS” and serve as the upstream to Red Hat CoreOS.

Hey, so… “Fedora Core”!

Everything’s a circle, right? But, this has nothing to do with the Red Hat vs. external split that was Fedora Core and Extras back in the day. We absolutely do not want to regress to that kind of community divide. “Core” just happens to be a pretty catchy name component for an OS that fits the “small, focused base” concept. This concept is powerful and useful for today’s information technology and computing world, and we want to give it proper focus in Fedora.

Okay, so, what next?

Visit the new website at https://coreos.fedoraproject.org. The project is just getting started, so there’s not much there yet, but we do have an initial FAQ. If you have questions that aren’t answered, or just want to get involved, join in discussion on the new Discourse board, the dev mailing list at coreos@lists.fedoraproject.org, and on Freenode IRC in #fedora-coreos.

Powered by WPeMatico

Share Button

Welcome to Fedora CoreOS

Share Button
This is a message from Fedora Project Leader Matthew Miller.

Hi everyone. If you saw my talk at DevConf.cz this year, you’ll remember I discussed the Fedora / Red Hat relationship, and specifically how Fedora has historically worked with new technologies that come our way through acquisitions made by our primary sponsor. Little did I know, but at that very moment, something huge was in the works, and when my plane landed back in Boston my phone blew up with messages about CoreOS joining Red Hat.

That’s obviously gigantic news, directly relevant to Fedora, since we are the project Red Hat depends on for operating-system level integration and innovation. Now, most of the news is about Kubernetes, OpenShift, Tectonic, and Quay — but there’s also Container Linux (the operating system formerly known just as “CoreOS”). At Red Hat Summit, the company announced and clarified a bunch of things around product and corporate plans. Now, it’s time for us to figure out how we can welcome and include the Container Linux community in the circle of Fedora Friends.

What does this mean for the Fedora community?

Good things! Container Linux is exciting, innovative, and has a passionate user and developer community. The people who built it are awesome and well-aligned with the Fedora community foundations.

The “Fedora Editions” strategy intentionally makes space for exploring emerging areas in operating system distributions. CoreOS will help us push that even further and bring new ways of doing things to the project as a whole.

What does this mean for Container Linux users?

More good things! I know this is kind of scary. Fedora CoreOS is going to be built from Fedora content rather than in the way it’s made now. It won’t necessarily be made in the same way we make Fedora OS deliverables today, though. No matter what, we absolutely want the CoreOS user experience of “container cluster host OS that keeps itself up-to-date and you just don’t worry about it.” Again, technical details are a discussion for elsewhere, but the goal is for existing Container Linux users to be as happy as — or happier than! — you are with the OS today.

And here’s the super-important thing: Fedora really is a community-driven project, and this means that you can get involved and directly influence how the future Fedora CoreOS works to meet your needs. If you’re interested and need help getting involved, don’t hesitate to talk to me, to the Join Fedora team, or to the developers and community people already working on the project.

What does this mean for Fedora Atomic Host and other deliverables?

This isn’t the place for technical details — see “what next?” at the bottom of this message for more. I expect that over the next year or so, Fedora Atomic Host will be replaced by a new thing combining the best from Container Linux and Project Atomic. This new thing will be “Fedora CoreOS” and serve as the upstream to Red Hat CoreOS.

Hey, so… “Fedora Core”!

Everything’s a circle, right? But, this has nothing to do with the Red Hat vs. external split that was Fedora Core and Extras back in the day. We absolutely do not want to regress to that kind of community divide. “Core” just happens to be a pretty catchy name component for an OS that fits the “small, focused base” concept. This concept is powerful and useful for today’s information technology and computing world, and we want to give it proper focus in Fedora.

Okay, so, what next?

Visit the new website at https://coreos.fedoraproject.org. The project is just getting started, so there’s not much there yet, but we do have an initial FAQ. If you have questions that aren’t answered, or just want to get involved, join in discussion on the new Discourse board, the dev mailing list at coreos@lists.fedoraproject.org, and on Freenode IRC in #fedora-coreos.

Powered by WPeMatico

Share Button

Matthias Clasen: Flatpak in detail, part 2

Share Button

The first post in this series looked at runtimes and extensions. Here, we’ll look at how flatpak keeps the applications and runtimes on your system organized, with installations, repositories, branches, commits and deployments.

Installations and repositories

An installation is a place on your filesystem where flatpak can install apps and runtimes. By default, flatpak has a system-wide installation in /var/lib/flatpak, and a user installation in $HOME/.local/share/flatpak.

It is possible to define additional system-wide installations by placing a key file in /etc/flatpak/installations.d. For example, this can be used to keep apps on a portable drive.

Part of the data that flatpak keeps for each installation is a list of remotes. A remote is a reference to an ostree repository that is available somewhere on the network.

Each installation also has its own local ostree repository (for example, the system-wide installation has its repo in /var/lib/flatpak/repo). You can explore the contents of these repositories using the ostree utility;

$ ostree --repo=$HOME/.local/share/flatpak/repo/ refs
gnome-nightly:appstream/x86_64
flathub:runtime/org.freedesktop.Platform.Locale/x86_64/1.6
flathub:app/de.wolfvollprecht.UberWriter/x86_64/stable
...

Branches and versions

Similar to git, ostree organizes the data in a repository in commits, which are grouped in branches. Commits are identified by a hash and branches are identified by a name.

While ostree does not care about the format of a branch name, flatpak uses branch names of the form $KIND/$ID/$ARCH/$BRANCH to uniquely identify branches.

Here are some examples:

app/org.inkscape.Inkscape/x86_64/stable
runtime/org.gnome.Platform/x86_64/master

Most of the  time, it is clear from the context if an app or runtime is being named, and only one architecture is relevant. For this case, flatpak allows a shorthand notation for branch names omitting the $KIND and $ARCH parts: $ID//$BRANCH.

In this notation, the above examples shrink to:

org.inkscape.Inkscape//stable
org.gnome.Platform//master

Deployments

Installing an app or runtime really consists of two steps: first, flatpak caches that data in the local repo of the installation, and then it deploys it, which means it creates a check-out of the branch from the local repo. The check-outs are organized in a folder structure that reflects the branch name organization.

For example, Inkscape will be checked-out in $HOME/.local/share/flatpak/app/org.inkscape.Inkscape/x86_64/stable/$COMMIT, where $COMMIT is the hash of the commit that is being deployed.

It is possible to have multiple commits from the same branch deployed, but one of them is considered active and will be used by default. Flatpak maintains symlink in the check-out directory that points at the active commit.

It is also possible to have multiple branches of an app or runtime deployed at the same time; the directory structure of checkouts is designed to allow that. One of the branches is considered current. Flatpak maintains a symlink at the toplevel of the checkout that points at the current checkout.

Flatpak can run an app from any deployed commit, regardless whether it is active or current or not. To run a particular commit, you can use the –commit option of flatpak run.

The relevance of being active and current is that flatpak exports some data (in particular, desktop files) from the active commit of the current branch, by symlinking it into ~/.local/share/flatpak/exports,  where for example gnome-shell will find it and allow you to run the app from the overview.

Note: Even though it is perfectly ok to have multiple versions of the same app installed, running more than one at the same time will typically not work, since the different versions will claim the app ID as their unique bus name on the session bus. A way around this limitation is to explicitly give one of the versions a different ID, for example, by appending a “.nightly” suffix.

Application data

One last aspect of filesystem organization to mention here is that every app that is run with flatpak gets a some filesystem space to use for permanent storage. This space is in $HOME/.var/app/$ID, and it has subdirectories called cache, config and data. At runtime, flatpak sets the XDG_CACHE_DIR, XDG_CONFIG_HOME and XDG_DATA_HOME environment variables to point at these directores.

For example, the persistent data from the inkscape flatpak can be found in $HOME/.var/app/org.inkscape.Inkscape.

Summary

Flatpak installations may look a bit intimidating with their deep diretory tree, but they have a well-defined structure and this post hopefully helps to explain the various components.

Powered by WPeMatico

Share Button

Fabian Affolter: Fedora IoT and Home Assistant

Share Button

As announced is Fedora IoT still pretty close to Fedora Atomic but I was curious how it “looks and feels”. Ok, more “feels” than there is not much see beside the prompt. My encounters with different ARM hardware and Fedora in the past where not always successful, thus I decided to take a Raspberry Pi Model B instead of one out of the Orange Pi family.

First step is to get a nightly image build Fedora IoT as described in the Getting started documentation.

# wget https://ftp-stud.hs-esslingen.de/pub/Mirrors/alt.fedoraproject.org/iot/20180618.0/IoT/aarch64/images/Fedora-IoT-28-20180618.0.aarch64.raw.xz

Just a side note: With the ARM installer, which is available in Rawhide, the

Error: mount /dev/mmcblk0p4 /tmp/root failed

  error is gone. It might be that the same applies to Fedora 28 as well but was present in Fedora 27.

Let the ARM installer create the SD card.

# arm-image-installer --image=Fedora-IoT-28-20180618.0.aarch64.raw.xz --target=rpi3 --media=/dev/mmcblk0 --resizefs

=====================================================
= Selected Image:
= Fedora-IoT-28-20180618.0.aarch64.raw.xz
= Selected Media : /dev/mmcblk0
= U-Boot Target : rpi3
= Root partition will be resized
=====================================================

*****************************************************
*****************************************************
******** WARNING! ALL DATA WILL BE DESTROYED ********
*****************************************************
*****************************************************

Type 'YES' to proceed, anything else to exit now

= Proceed? YES
= Writing:
= Fedora-IoT-28-20180618.0.aarch64.raw.xz
= To: /dev/mmcblk0 ....
0+403205 records in
0+403205 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 352.665 s, 12.2 MB/s
= Writing image complete!
= Resizing /dev/mmcblk0 ....
e2fsck 1.44.2 (14-May-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mmcblk0p3: 35398/187680 files (0.7% non-contiguous), 307012/749568 blocks
resize2fs 1.44.2 (14-May-2018)
The filesystem is already 749568 (4k) blocks long. Nothing to do!

= Raspberry Pi 3 Uboot is already in place, no changes needed.

= Installation Complete! Insert into the rpi3 and boot.

After booting the Raspberry Pi up, create a new user. Now you are able to use SSH to log in. The current build of Fedora IoT allows you to use a recent kernel.

# uname -r
4.16.15-300.fc28.aarch64

Of course is the deployment up-to-date. One advantage of nightly build if you are using one the next morning 😉 .

# rpm-ostree status
State: idle; auto updates disabled
Deployments:
● ostree://fedora-iot:fedora/28/aarch64/iot
Version: 28.20180617.0 (2018-06-17 10:36:57)
Commit: a3aee4deaa6887bfc3088ad891dfa22b4a729e802905c5135c676e440124784a
GPGSignature: Valid signature by 128CF232A9371991C8A65695E08E7E629DB62FB1

Instead of Docker is

podman

  used to deal with all container-related tasks. To get the Home Assistant images run the command below:

# podman pull homeassistant/aarch64-homeassistant

As you can see it’s pretty much the same as using the 

docker

 command-line tool.

Create a directory to store the configuration.

# mk dir -p /opt/home-assistant

And start the Home Assistant after you have adjusted the host’s firewall to match your needs.

# podman run -it --rm --name="home-assistant" 
    --network=bridge --publish=8123:8123 
    -v /opt/home-assistant:/config:Z 
    -v /et c/localtime:/et c/localtime:ro 
    homeassistant/aarch64-homeassistant

Et voilà, http://IP_ADDRESS_FEDORA_IOT_HOST:8123 is serving the Home Assistant frontend.

I will skip the autostart part as this is already covered in the blog post about Project Atomic and Home Assistant. No much news in this blog post beside

podman

. Pulling images are problematic at first because often the download stopped somewhere over 95 % (no, never at 20 % or 60 % ) in my case a local registry solved the issue for now.

Powered by WPeMatico

Share Button

Alvaro Castillo: Mastering en Bash ~ Primero de Scripting

Share Button

¡Empezamos la recta final!

Hace un mes más o menos que empezamos a ver cómo operar con Bash utilizando comandos básicos, ya podemos decir que sabemos más que antes y podemos dar el paso al Scripting. ¿Qué es el “Scripting“? Para nosotros es la habilidad que uno tiene para desarrollar un fichero de texto plano con el fin de automatizar determinadas tareas dentro del sistema. Y un script es el nombre que recibe este fichero.

Cuando hablamos de automatizar tareas, hablamos de que en vez d…

Powered by WPeMatico

Share Button

mythcat: Fedora 28 : The Powertop tool from Intel.

Share Button


The Powertop is a tool provided by Intel to enable various powersaving modes in userspace, kernel and hardware.
Using this tool is possible to monitor processes and show which of them are utilizing the CPU and wake it from its Idle-States.
The tool allowing you to identify applications with particular high power demands.
The name of this tool powertop.x86_64 come from : Power consumption monitor.
Let’s install and set this tool to Fedora 28 distro linux:

[root@desk mythcat]# dnf install powertop.x86_64 
Last metadata expiration check: 0:32:08 ago on Tue 19 Jun 2018 10:19:39 AM EEST.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
powertop x86_64 2.9-8.fc28 updates 239 k

Transaction Summary
================================================================================
Install 1 Package

Total download size: 239 k
Installed size: 650 k
Is this ok [y/N]: y
Downloading Packages:
powertop-2.9-8.fc28.x86_64.rpm 112 kB/s | 239 kB 00:02
--------------------------------------------------------------------------------
Total 71 kB/s | 239 kB 00:03
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : powertop-2.9-8.fc28.x86_64 1/1
Running scriptlet: powertop-2.9-8.fc28.x86_64 1/1
Verifying : powertop-2.9-8.fc28.x86_64 1/1

Installed:
powertop.x86_64 2.9-8.fc28

Complete!

You need root privileges to run this tool :

[mythcat@desk ~]$ powertop --calibrate --debug
PowerTOP v2.9 must be run with root privileges.
exiting...

The help output of this tool :

[root@desk mythcat]# powertop --help

Usage: powertop [OPTIONS]

--auto-tune sets all tunable options to their GOOD setting
-c, --calibrate runs powertop in calibration mode
-C, --csv[=filename] generate a csv report
--debug run in "debug" mode
--extech[=devnode] uses an Extech Power Analyzer for measurements
-r, --html[=filename] generate a html report
-i, --iteration[=iterations] number of times to run each test
-q, --quiet suppress stderr output
-s, --sample[=seconds] interval for power consumption measurement
-t, --time[=seconds] generate a report for 'x' seconds
-w, --workload[=workload] file to execute for workload
-V, --version print version information
-h, --help print this help menu

For more help please refer to the 'man 8 powertop'

To run the program and enable its background services, use the commands below:

[root@desk mythcat]# systemctl start powertop.service
[root@desk mythcat]# systemctl enable powertop.service
Created symlink /etc/systemd/system/multi-user.target.wants/powertop.service → /usr/lib/systemd/system/powertop.service.

This is my output with powertop calibrate :

[root@desk mythcat]# powertop --calibrate --debug
modprobe cpufreq_stats failedLoaded 0 prior measurements
RAPL device for cpu 0
RAPL Using PowerCap Sysfs : Domain Mask d
RAPL device for cpu 0
RAPL Using PowerCap Sysfs : Domain Mask d
Devfreq not enabled
glob returned GLOB_ABORTED
Starting PowerTOP power estimate calibration
Calibrating idle
System is not available
System is not available
Calibrating: disk usage
Calibrating backlight
Calibrating idle
System is not available
System is not available
Calibrating: CPU usage on 1 threads
Calibrating: CPU usage on 4 threads
Calibrating: CPU wakeup power consumption
Calibrating: CPU wakeup power consumption
Calibrating: CPU wakeup power consumption
Calibrating USB devices
.... device /sys/bus/usb/devices/2-1/power/control
.... device /sys/bus/usb/devices/usb1/power/control
.... device /sys/bus/usb/devices/1-1.3/power/control
.... device /sys/bus/usb/devices/1-1/power/control
.... device /sys/bus/usb/devices/usb2/power/control
Calibrating radio devices
Finishing PowerTOP power estimate calibration
Parameters after calibration:


Parameter state
----------------------------------
Value Name
0.50 alsa-codec-power (12)
0.00 backlight (4)
0.00 backlight-boost-100 (8)
0.00 backlight-boost-40 (6)
0.00 backlight-boost-80 (7)
0.00 backlight-power (5)
2.33 base power (70)
1.56 cpu-consumption (3)
39.50 cpu-wakeups (2)
0.00 disk-operations (73)
0.20 disk-operations-hard (72)
0.00 enp2s0-link-100 (21)
0.00 enp2s0-link-1000 (22)
0.00 enp2s0-link-high (23)
0.00 enp2s0-packets (24)
0.00 enp2s0-powerunsave (20)
0.00 enp2s0-up (19)
0.56 gpu-operations (71)
0.00 runtime-0000:00:00.0 (34)
0.00 runtime-0000:00:02.0 (37)
0.00 runtime-0000:00:16.0 (44)
0.00 runtime-0000:00:1a.0 (35)
0.00 runtime-0000:00:1b.0 (45)
0.00 runtime-0000:00:1c.0 (41)
0.00 runtime-0000:00:1c.2 (38)
0.00 runtime-0000:00:1c.3 (31)
0.00 runtime-0000:00:1d.0 (36)
0.00 runtime-0000:00:1e.0 (32)
0.00 runtime-0000:00:1f.0 (42)
0.00 runtime-0000:00:1f.2 (39)
0.00 runtime-0000:00:1f.3 (33)
0.00 runtime-0000:02:00.0 (43)
0.00 runtime-0000:03:00.0 (40)
0.00 runtime-Fixed MDIO bus.0 (57)
0.00 runtime-INT0800:00 (52)
0.00 runtime-PNP0103:00 (49)
0.00 runtime-PNP0800:00 (48)
0.00 runtime-PNP0C04:00 (51)
0.00 runtime-PNP0C0C:00 (58)
0.00 runtime-alarmtimer (54)
0.00 runtime-coretemp.0 (55)
0.00 runtime-gpio_ich.1.auto (47)
0.00 runtime-i2c-0 (67)
0.00 runtime-i2c-1 (63)
0.00 runtime-i2c-2 (66)
0.00 runtime-i2c-3 (62)
0.00 runtime-i2c-4 (65)
0.00 runtime-i2c-5 (69)
0.00 runtime-i2c-6 (64)
0.00 runtime-i2c-7 (68)
0.00 runtime-i8042 (60)
0.00 runtime-iTCO_wdt.0.auto (61)
0.00 runtime-microcode (53)
0.00 runtime-pcspkr (56)
0.00 runtime-platform-framebuffer.0 (50)
0.00 runtime-reg-dummy (46)
0.00 runtime-serial8250 (59)
0.10 usb-device-1d6b-0002 (10)
0.10 usb-device-248a-8366 (11)
0.10 usb-device-8087-0024 (9)
0.00 virbr0-link-100 (15)
0.00 virbr0-link-1000 (16)
0.00 virbr0-link-high (17)
0.00 virbr0-nic-link-100 (27)
0.00 virbr0-nic-link-1000 (28)
0.00 virbr0-nic-link-high (29)
0.00 virbr0-nic-packets (30)
0.00 virbr0-nic-powerunsave (26)
0.00 virbr0-nic-up (25)
0.00 virbr0-packets (18)
0.00 virbr0-powerunsave (14)
0.00 virbr0-up (13)
0.10 xwakes (74)

Score: 0.0 ( 0.0)
Guess: 2.3
Actual: 0.0
----------------------------------
Learning debugging enabled


Parameter state
----------------------------------
Value Name
0.50 alsa-codec-power (12)
0.00 backlight (4)
0.00 backlight-boost-100 (8)
0.00 backlight-boost-40 (6)
0.00 backlight-boost-80 (7)
0.00 backlight-power (5)
2.33 base power (70)
1.56 cpu-consumption (3)
39.50 cpu-wakeups (2)
0.00 disk-operations (73)
0.20 disk-operations-hard (72)
0.00 enp2s0-link-100 (21)
0.00 enp2s0-link-1000 (22)
0.00 enp2s0-link-high (23)
0.00 enp2s0-packets (24)
0.00 enp2s0-powerunsave (20)
0.00 enp2s0-up (19)
0.56 gpu-operations (71)
0.00 runtime-0000:00:00.0 (34)
0.00 runtime-0000:00:02.0 (37)
0.00 runtime-0000:00:16.0 (44)
0.00 runtime-0000:00:1a.0 (35)
0.00 runtime-0000:00:1b.0 (45)
0.00 runtime-0000:00:1c.0 (41)
0.00 runtime-0000:00:1c.2 (38)
0.00 runtime-0000:00:1c.3 (31)
0.00 runtime-0000:00:1d.0 (36)
0.00 runtime-0000:00:1e.0 (32)
0.00 runtime-0000:00:1f.0 (42)
0.00 runtime-0000:00:1f.2 (39)
0.00 runtime-0000:00:1f.3 (33)
0.00 runtime-0000:02:00.0 (43)
0.00 runtime-0000:03:00.0 (40)
0.00 runtime-Fixed MDIO bus.0 (57)
0.00 runtime-INT0800:00 (52)
0.00 runtime-PNP0103:00 (49)
0.00 runtime-PNP0800:00 (48)
0.00 runtime-PNP0C04:00 (51)
0.00 runtime-PNP0C0C:00 (58)
0.00 runtime-alarmtimer (54)
0.00 runtime-coretemp.0 (55)
0.00 runtime-gpio_ich.1.auto (47)
0.00 runtime-i2c-0 (67)
0.00 runtime-i2c-1 (63)
0.00 runtime-i2c-2 (66)
0.00 runtime-i2c-3 (62)
0.00 runtime-i2c-4 (65)
0.00 runtime-i2c-5 (69)
0.00 runtime-i2c-6 (64)
0.00 runtime-i2c-7 (68)
0.00 runtime-i8042 (60)
0.00 runtime-iTCO_wdt.0.auto (61)
0.00 runtime-microcode (53)
0.00 runtime-pcspkr (56)
0.00 runtime-platform-framebuffer.0 (50)
0.00 runtime-reg-dummy (46)
0.00 runtime-serial8250 (59)
0.10 usb-device-1d6b-0002 (10)
0.10 usb-device-248a-8366 (11)
0.10 usb-device-8087-0024 (9)
0.00 virbr0-link-100 (15)
0.00 virbr0-link-1000 (16)
0.00 virbr0-link-high (17)
0.00 virbr0-nic-link-100 (27)
0.00 virbr0-nic-link-1000 (28)
0.00 virbr0-nic-link-high (29)
0.00 virbr0-nic-packets (30)
0.00 virbr0-nic-powerunsave (26)
0.00 virbr0-nic-up (25)
0.00 virbr0-packets (18)
0.00 virbr0-powerunsave (14)
0.00 virbr0-up (13)
0.10 xwakes (74)

Score: 0.0 ( 0.0)
Guess: 2.3
Actual: 0.0
----------------------------------

Now we can sets all tunable options to their GOOD setting:

[root@desk mythcat]# powertop --auto-tune
modprobe cpufreq_stats failedLoaded 0 prior measurements
RAPL device for cpu 0
RAPL Using PowerCap Sysfs : Domain Mask d
RAPL device for cpu 0
RAPL Using PowerCap Sysfs : Domain Mask d
Devfreq not enabled
glob returned GLOB_ABORTED
Leaving PowerTOP

Powered by WPeMatico

Share Button

Fedora Community Blog: One month of GSoC with The Fedora Project: Amitosh

Share Button

  • Fedora Account: amitosh
  • IRC: amitosh (found in #fedora, #fedora-dotnet, #fedora-summer-coding, #fedora-commops)
  • Fedora Wiki User Page: amitosh

It’s been a month since I have been working on my Google Summer of Code project with The Fedora Project. And in this month, I have been working on “Improving the back-end of the Fedora App”. This month has been particularly interesting – with challenges to solve and stuff to learn, it has been a very satisfying experience so far.

Month at a glance

We have successfully completed my first evaluation and here is the list of things that I have worked on in this month:

Week 1 – Porting, Upgrading, and Patching

Week 1 was all about patching and upgrading our SDKs and toolkits to the latest and greatest versions. The process started about a month before but wasn’t completed. We migrated the entire codebase to Ionic 3 and TypeScript. There was a lot of refactoring and code reorganization in this week, and the end result was a clean, structured and documented codebase with all broken facilities restored.

Week 2 – Offline caching

Week 2 was all about bringing offline capabilities to the app. The app now caches the content from Fedora Magazine, FedoCal and Fedora Social. Every time we load the app, we refersh the cache from the API end points in the background. We no longer block the user from interacting with the app.

Week 3 – Testing

We were missing out in the testing front. In this week I worked on improving the unit testing and integration testing components of the app. We are using the popular Karma test runner and the Jasmine test library to implement unit tests. For integration tests, we are using Protractor with Selenium Framework.

Week 4 – More tests, Localization and Package Search

Week 4 was a continuaton of testing work from Week 3. I implemented tests that covered all the services of our app and some UI tests. We also brought a new feature – “package search”. It allows to search for packages right from the app. Along with the package description, it shows the dnf command to install the package, link to the upstream website, and other information.

We also started work on localizing the app. The views now respect the system locale and format the content accordingly. We also have completed the groundwork for furthur localization (and perhaps transaltion) of the app.

Contributions

Here is the list of all pull requests I made in this month:

  1. Disable splash screen autohide (#47)
  2. Sort posts by their dates (#49)
  3. Add type annotations where necessary (#57)
  4. Response caching for Magazine, Social, Calendar and Ask (#61)
  5. Show locale-aware date strings (#64)
  6. Add config for unit testing (#70)
  7. Add integration test setup (#71)
  8. Package search (#72)
  9. Introduce unit tests for providers (#78)
  10. Show posts from official Fedora facebook page and Twitter handle (#79)
  11. Unbreak HTML layout for first evaluation build (#85)

What’s happening

In the coming 4 weeks, we will be working on integrating the UI work done by @littlewornder with the app backend. Some of the planned features are: system calendar integration, more robust offline storage implementation, bookmarking, and integration with FMN to show notifications from Fedora infrastructure apps.

Please send in your feedback at amitosh@fedoraproject.org

The post One month of GSoC with The Fedora Project: Amitosh appeared first on Fedora Community Blog.

Powered by WPeMatico

Share Button

mythcat: Fedora 28 : Godot game engine.

Share Button


Today I tested the new version of Godot game engine – version 3.0.3 .
You can download it from official webpage.
I used the 64 bit version.
After download and unzip you can run the binary file in your user terminal.
The Godot game engine start with a GUI.
Into the right area of screen into Scene tab two objects: Spatial and Camera.
You need to select or add a WoldEnvironment node.
Take a look to the Inspector and use with New Environment .
Run this with the play icon.
If is all right you can see something like this:

Create e new folder into your project and name it Export.
Copy the mscorelib.dll into this folder.
Go to main menu and select Project – Export and you will see this GUI for export your game.
Press Add button to select Linux/X11 output:
Select Linux and press Export Project button.
Go to Export folder and run from your linux terminal your game.
This game engine working well with Fedora 28 and the export running without errors.

Powered by WPeMatico

Share Button

Fedora Community Blog: [Week 5] GSoC Status Report for Fedora App: Abhishek

Share Button

This is Status Report for Fedora App filled by participants on a weekly basis.

Status Report for Abhishek Sharma (thelittlewonder)

  • Fedora Account: thelittlewonder
  • IRCthelittlewonder (found in #fedora-summer-coding, #fedora-india, #fedora-design)
  • Fedora User Wiki Page

Tasks Completed

New Magazine View

We worked on a brand-new magazine view which presents the date and number of comments of a post upfront along with the featured image, quite similar to the Fedora Magazine Website. The idea was to keep things consistent and provide a similar experience to the Magazine Users.

Pull Request – #82

Sorting the Magazine Articles

We added a new feature that allows the user to sort the fetched magazine articles by date and number of comments. You can check out the most talked or the latest article in few taps now.

Pull Request – #82

More Empty States Design

We realised that not all empty states had been taken care of during the last week’s sprint, so we worked on the design of few others empty and error states. These things though may sound very small, but ultimately helps to render a reliable user experience.

What’s Happening

Ask view

We have commenced work on the ask view of the application. We needed to figure out how to sort the questions according to votes, views and answers but Askbot API will do that for us, so we are sorted.

Look into SoundCloud API

In the upcoming weeks, we are thinking to implement the Fedora Podcast into the app so that the user can listen to it on the go. We need to look into the SoundCloud API and think how to proceed possible integration.

That’s all for this week 👋
Please send in your feedback at : guywhodesigns[at]gmail[dot]com

The post [Week 5] GSoC Status Report for Fedora App: Abhishek appeared first on Fedora Community Blog.

Powered by WPeMatico

Share Button