Based on the recent Linux Kernel Community Enforcement Statement and the article describing the background and what it means , here are some Questions/Answers to help clear things up. These are based on questions that came up when the statement was discussed among the initial round of over 200 different kernel developers.

Q: Is this changing the license of the kernel?

A: No.

Q: Seriously? It really looks like a change to the license.

SailfishOS should need no introduction, but just in case someone doesn’t know about it, it’s the successor of MeeGo developed by Nokia and Intel so to speak, i.e. it’s a proper GNU/Linux system, with a cool and efficient swipe based interface built on Qt, it uses a few SUSE technologies such as libzypp and Open Build Service and it sports an Android runtime, that lets you run most Android apps. In short: SailfishOS is made of awesome.

Until now SailfishOS has only been available on sub-par hardware, and sometimes devices haven’t really been available for purchase at all. But since yesterday you can buy a SailfishOS image for the Sony Xperia X (single SIM model, F5121).

I installed it yesterday and so far it’s an amazing experience to run SailfishOS on pretty decent hardware, and the standby battery time appears to be through the roof.

The instructions for unlocking the bootloader and installing SailfishOS are a bit lengthy and technical and for the time being it requires access to a Microsoft Windows PC, but I managed without much hassle, and so can you!

UPDATE: Official installation instructions for Linux were published now.

In other news the Librem 5 crowdfunding reached it’s minimum goal, so overall it’s been a great couple of days for GNU/Linux on mobile devices.

1. Unique Privacy Features: Kill-switches and auditable code

Neither Apple nor Android have convincing stories when it comes to privacy. Ultimately, they’re both under the thumbs of a restrictive government, which, to put it mildly doesn’t give a shit about privacy and has created the most intrusive global spying system in the history of mankind. Thanks to the U.S., we now live in the dystopian future of Orwell’s 1984. It’s time to put an end to this with hardware kill switches that cut off power to the radio, microphone and camera, so phones can’t be hacked into anymore to listen in on your conversations, take photos you never know were taken and send them to people you definitely would never voluntarily share them with. All that comes with auditable code, which is something that we as citizens should demand from our government. With a product on the market supplying these features, it becomes very hard for your government to argue that they really need their staff to use iphones or Android devices. We can and we should demand this level of privacy from those who govern us and handle with our data. It’s a matter of trust.
Companies will find this out first, since they’re driven by the same challenges but usually much quicker to adopt technology.

2. Hackable software means choice

The librem 5 will run a mostly standard Debian system with a kernel that you can actually upgrade. The system will be fully hackable, so it will be easy for others to create modified phone systems based on the librem. This is so far unparalleled and brings the freedom the Free software world has long waited for, it will enable friendly competition and collaboration. All this leads to choice for the users.

3. Support promise

Can a small company such as Purism actually guarantee support for a whole mobile software stack for years into the future? Perhaps. The point is, even in case they fail (and I don’t see why they would!), the device isn’t unsupported. With the librem, you’re not locked into a single vendor’s eco system, but you buy into the support from the whole Free software community. This means that there is a very credible support story, as device doesn’t have to come from a single vendor, and the workload is relatively limited in the first place. Debian (which is the base for PureOS) will be maintained anyway, and so will Plasma as tens of millions of users already rely on it. The relatively small part of the code that is unique to Plasma Mobile (and thus isn’t used on the desktop) is not that hard to maintain, so support is manageable, even for a small team of developers. (And if you’re not happy with it, and think it can be done better, you can even take part.)

4. It builds and enables a new ecosystem

The Free software community has long waited for this hackable device. Many developers just love to see a platform they can build software for that follows their goals, that allows development with a proven stack. Moreover, convergence allows users to blur the lines between their devices, and advancing that goal hasn’t been on the agenda with the current duopoly.
The librem 5 will put Matrix on the map as a serious contender for communication. Matrix has rallied quite a bit of momentum to bring more modern mobile-friendly communication, chat and voice to the Free software eco-system.
Overall, I expect the librem 5 to make Free software (not just open-source-licensed, but openly developed Free software) a serious player also on mobile devices. The Free software world needs such a device, and now is the time to create it. With this huge success comes the next big challenge, actually creating the device and software.

The unique selling points of the librem 5 definitely strike a chord with a number of target groups. If you’re doubtful that its first version can fully replace your current smart phone, that may be justified, but don’t forget that there’s a large number of people and organisations that can live with a more limited feature set just fine, given the huge advantages that private communication and knowing-what’s-going-on in your device brings with it.
The librem 5 really brings something very compelling to the table and those are the reasons why it got funded. It is going to be a viable alternative to Android and iOS devices that allows users to enjoy their digital life privately. To switch off tracking, and to sleep comfortably.
Are you convinced this is a good idea? Don’t hesitate to support the campaign and help us reach its stretch goals!

Such a problem should not happen to a real pro in computer technology, but unfortunately we are only human beings. That's what made me exidentially reformate the EFI Boot Partition while installing Fedora 26 lately. And here is how to recover your Windows data on the EFI Boot Partition!

Requirements

You will need

• a Windows (10) bootable USB stick or installation DVD,
• and your EFI Boot Partition should be ok
• as well as the partition table.

If all these things apply to your case, fixi...

Restic had been on my watch list for a while, but i never really got around to play with it.

After Jan-Piet Mens blogged about it [1, 2], I thought it was finally time to give it a go. Of course this means, first we need to package it.

This is done now. You can find the packages in home:darix:restic. After reading the first blog post I did restic and rest-server. Happy camper I was until i noticed to next post. Minio was another item on my “Lets play with that” list. So one stone, two birds. Added 2 packages to my collection, because you know just packaging the server without the client is a no go.

The Open Beta for PC ends Oktober 2nd, 2017. Who wants to take a peek at the brandnew Call of Duty, or at least the multiplayer part, has to hurry up now. For all who still don't had a look at it and prefer to read a few lines about it instead of being part of the battle oneself, here are my first impressions.

Open Beta

Since Oktober 29, 2017 everyone is free to participate in the Open Beta for Call of Duty:WWII via Steam. There was an earer longing for the new Game of the series but only a...

Last year, the AppStream specification gained proper support for adding metadata for fonts, after Richard Hughes did some work on it years ago. We weren’t happy with how fonts were handled at that time, so we searched for better solutions, which is why this took a bit longer to be done. Last year, I was implementing the final support for fonts in both appstream-generator (the metadata extractor used by Debian and a few others) as well as the AppStream specification. This blogpost was sitting on my todo list as a draft for a long time now, and I only just now managed to finish it, so sorry for announcing this so late. Fonts are already available via AppStream for a year, and this post just sums up the status quo and some neat tricks if you want to write metainfo files for fonts. If you are following AppStream (or the Debian fonts list), you know everything already .

Both Richard and I first tried to extract all the metadata to display fonts in a proper way to the users from the font files directly. This turned out to be very difficult, since font metadata is often wrong or incomplete, and certain desirable bits of metadata (like a longer description) are missing entirely. After messing around with different ways to solve this for days (afterall, by extracting the data from font files directly we would have hundreds of fonts directly available in software centers), I also came to the same conclusion as Richard: The best and easiest solution here is to mandate the availability of metainfo files per font.

Which brings me to the second issue: What is a font? For any person knowing about fonts, they will understand one font as one font face, e.g. “Lato Regular Italic” or “Lato Bold”. A user however will see the font family as a font, e.g. just “Lato” instead of all the font faces separated out. Since AppStream data is used primarily by software centers, we want something that is easy for users to understand. Hence, an AppStream “font” components really describes a font family or collection of fonts, instead of individual font faces. We do also want AppStream data to be useful for system components looking for a specific font, which is why font components will advertise the individual font face names they contain via a <provides/> -tag. Naming fonts and making them identifiable is a whole other issue, I used a document from Adobe on font naming issues as a rough guideline while working on this.

How to write a good metainfo file for a font is best shown with an example. Lato is a well-looking font family that we want displayed in a software center. So, we write a metainfo file for it an place it in /usr/share/metainfo/com.latofonts.Lato.metainfo.xml  for the AppStream metadata generator to pick up:

<?xml version="1.0" encoding="UTF-8"?>
<component type="font">
  <id>com.latofonts.Lato</id>
  <metadata_license>FSFAP</metadata_license>
  <project_license>OFL-1.1</project_license>

  <name>Lato</name>
  <summary>A sanserif type­face fam­ily</summary>
  <description>
    <p>
      Lato is a sanserif type­face fam­ily designed in the Sum­mer 2010 by Warsaw-based designer
      Łukasz Dziedzic (“Lato” means “Sum­mer” in Pol­ish). In Decem­ber 2010 the Lato fam­ily
      was pub­lished under the open-source Open Font License by his foundry tyPoland, with
      sup­port from Google.
    </p>
  </description>

  <url type="homepage">http://www.latofonts.com/</url>

  <provides>
    <font>Lato Regular</font>
    <font>Lato Black Italic</font>
    <font>Lato Black</font>
    <font>Lato Bold Italic</font>
    <font>Lato Bold</font>
    <font>Lato Hairline Italic</font>
    ...
  </provides>
</component>

When the file is processed, we know that we need to look for fonts in the package it is contained in. So, the appstream-generator will load all the fonts in the package and render example texts for them as an image, so we can show users a preview of the font. It will also use heuristics to render an “icon” for the respective font component using its regular typeface. Of course that is not ideal – what if there are multiple font faces in a package? What if the heuristics fail to detect the right font face to display?

This behavior can be influenced by adding <font/>  tags to a <provides/>  tag in the metainfo file. The font-provides tags should contain the fullnames of the font faces you want to associate with this font component. If the font file does not define a fullname, the family and style are used instead. That way, someone writing the metainfo file can control which fonts belong to the described component. The metadata generator will also pick the first mentioned font name in the <provides/>  list as the one to render the example icon for. It will also sort the example text images in the same order as the fonts are listed in the provides-tag.

The example lines of text are written in a language matching the font using Pango.

But what about symbolic fonts? Or fonts where any heuristic fails? At the moment, we see ugly tofu characters or boxes instead of an actual, useful representation of the font. This brings me to an inofficial extension to font metainfo files, that, as far as I know, only appstream-generator supports at the moment. I am not happy enough with this solution to add it to the real specification, but it serves as a good method to fix up the edge cases where we can not render good example images for fonts. AppStream-Generator supports the FontIconText and FontSampleText custom AppStream properties to allow metainfo file authors to override the default texts and autodetected values. FontIconText will override the characters used to render the icon, while FontSampleText can be a line of text used to render the example images. This is especially useful for symbolic fonts, where the heuristics usually fail and we do not know which glyphs would be representative for a font.

For example, a font with mathematical symbols might want to add the following to its metainfo file:

<custom>
  <value key="FontIconText">∑√</value>
  <value key="FontSampleText">∑ ∮ √ ‖...‖ ⊕ ? ℕ ⋉</value>
</custom>

Any unicode glyphs are allowed, but asgen will but some length restrictions on the texts.

So, In summary:

• Fonts are hard
• I need to blog faster
• Please add metainfo files to your fonts and submit them upstream if you can!
• Fonts must have a metainfo file in order to show up in GNOME Software, KDE Discover, AppCenter, etc.
• The “new” font specification is backwards compatible to Richard’s pioneer work in 2014
• The appstream-generator supports a few non-standard values to influence how font images are rendered that you might be interested in (maybe we can do something like that for appstream-builder as well)
• The appstream-generator does not (yet?) support the <extends/> logic Richard outlined in his blog post, mainly because it wasn’t necessary in Debian/Ubuntu/Arch yet (which is asgen’s primary audience), and upstream projects would rarely want to write multiple metainfo files.
• The metaInfo files are not supposed to replace the existing fontconfig files, and we can not generate them from existing metadata, sadly
• If you want a more detailed look at writing font metainfo files, take a look at the AppStream specification.
• Please write more font metadata