22 Feb 2018

feedPlanet GNOME

Matthias Clasen: Fedora Atomic Workstation: Works on the beach

My trip is getting really close, so I decided to upgrade my system to rawhide. Wait, what ? That is usually what everybody would tell you not to do. Rawhide has this reputation for frequent breakage, and who knows if my apps will work any given day. Not something you want to deal with while traveling.

Image result for project atomic logo

With rpm-ostree, installing a newer OS is very similar to updating your current OS: a new image is downloaded in the background, and when the download is complete, you boot into the new image. The previous image is still available to boot back into, as a safety net. That is the reason that I felt confident enough to try this a day before a major trip:

rpm-ostree rebase \
systemctl reboot

I would love to say that things went perfectly and I was back to a working system in 10 minutes. But it was not quite as easy, and i did encounter a few (solvable) problems. It is worth pointing out that while I was solving these problems, rpm-ostree had already downloaded all of the rawhide image, but I was still safely running my F27 OS. At no point was there a mess of a half-upgraded system with a mix of old and new rpms. I was running my old system until I had solved all the problems and had a OS image that was ready, and then I booted into it. A safe, atomic switch.

Problem 1: The rpmfusion repo is not available for f28 yet. It is a common occurrence that 3rd party repositories lag behind the Fedora releases a bit, so this is not surprising. It is a bit unfortunate that i had to remove my layered rpms from the repository to work around this.

Problem 2: buildah now in the base image. This is a good thing, of course, but it caused rpm-ostree to complain about the conflict between the OS image and the layered package. In this case, I removed the layered rpm without any qualms.

Problem 3: Rawhide repositories had a bad day. For some reason, they were missing the repomd.xml file today.

This is a good reminder that as long as you are using package layering, you haven't really left the world of yum repositories and out-of-sync mirrors behind. rpm-ostree has to check the yum repositories for updates to the layered packages, which means that it can be hit by the same issues as dnf on a traditional Fedora workstation.

For my rebase to proceed, I had to remove everything that was layered on top of the OS image. After I did that, rpm-ostree no longer needed to look at yum repositories, and switched my system to the already-downloaded rawhide image.

After the reboot, I'm now running rawhide… and all my applications are just the same as they were before. A nice aspect of the Atomic Workstation approach is that (flatpak) applications are decoupled from the OS. I can update the one without the other. We are not entirely there yet: as you can see in the screenshot below, a number of applications are still installed as part of the OS image.

More importantly, the screenshot shows that GNOME software will support updating the OS on the Atomic Workstation in Fedora 28. It does so by talking to the rpm-ostree daemon.

Switching from one Fedora release to the next ls already working pretty well in the last few releases. With the Atomic Workstation, it can become as undramatic as installing the latest updates.

One could almost do it on the beach.

22 Feb 2018 2:52am GMT

Alberto Ruiz: 1+ year of Fedora and GNOME hardware enablement

A year and a couple of months ago, Christian Schaller asked me to pivot a little bit from working full time on Fleet Commander to manage a new team we were building to work on client hardware enablement for Fedora and GNOME with an emphasis on upstream. The idea was to fill the gap in the organization where nobody really owned the problem of bringing up new client hardware features vertically across the stack (from shell down to the kernel), or rather, ensure Fedora and GNOME both work great on modern laptops. Part of that deal was to take over the bootloader and start working closer to customers and hardware manufacturing parnters.

15525894974_17d28e4e5c_z.jpgSound Blaster 16 PnP, Danipuntocom @ Flickr, CC BY-NC 2.0

At first I hesitated as I wasn't sure I could do a good job, y'all know how the impostor syndrome works specially outside of the comfort zone, also had very little engineering experience on the kernel or hardware related fields outside the hardware design I did at uni.

However after some thinking I thought this was a terribly exciting prospect and I had some ideas as to how to go about it and do a decent job.

Fast forward 16 months and I'm loving it, in a relatively short period of time we've been able to build an amazing team that have been able to execute quite a few important highlights to make Fedora and GNOME work better on laptops:

Beyond the engineering efforts, we are working with OEMs and silicon vendors as well to try to educate them in the difficult transition from the proprietary OS model to contribute upstream. Some of them are doing really great work and others need improvement. While I can't share any specific details of these conversations, I must say it's an incredibly exciting moment for Linux on laptops/workstations and if we are able to push enough silicon vendors to have a more fluent relationship with upstream I think we really have a chance to reduce the problems people have with newer hardware at least on the enterprise offerings at first.

I have to say, it is an incredibly humbling experience to work with this team, I'm learning a lot about the space and I'm excited about the things we're planning for the next couple of years and the opportunities those efforts could bring for the free software desktop.

22 Feb 2018 1:36am GMT

21 Feb 2018

feedPlanet KDE

Article about cmake

Just in case someone is interested: two days ago a very good article about cmake popped up, called It's Time to do CMake Right. There also is a discussion about it on reddit/r/cpp. happy reading

21 Feb 2018 10:21pm GMT

feedPlanet GNOME

Jim Hall: Using groff to write papers

In 1993, I discovered Linux, when I was an undergraduate university student. Linux gave me the same power as the Big Unix systems in our campus computer labs, but on my personal computer. I was immediately hooked.

But in the early 1990s, Linux didn't have a lot of applications. When I needed a word processor to write a paper for class, I rebooted into MS-DOS and ran WordPerfect or the shareware word processor, Galaxy Write. I wanted to stay in Linux as much as possible, but I also needed to write papers for class.

I knew a bit about the nroff and troff text processing systems from our campus computer labs, and I was pleased to find that nroff and troff existed on Linux as GNU groff. So I taught myself how to use the groff macro sets to write my class papers. The first macros I learned were the "e" macros, also known as "groff -me" because that was how you invoked the macros from the command line.

I recently wrote an article for OpenSource about How to format academic papers on Linux with "groff -me." I cover the basics for writing most papers, and skip the really esoteric stuff like keeps and displays, nested lists, tables, and figures. This is just an introduction for how to use "groff -me" to write common documents, like papers for class.

21 Feb 2018 7:08pm GMT


Alan Coopersmith: Oracle Solaris 11.3 SRU 29 Released

We've just released Oracle Solaris 11.3 SRU 29. It contains some important security fixes and enhancements. SRU29 is now available from My Oracle Support Doc ID 2045311.1, or via 'pkg update' from the support repository at https://pkg.oracle.com/solaris/support .

Features included in this SRU include:

The SRU also updates the following components which have security fixes:

Full details of this SRU can be found in My Oracle Support Doc 2361795.1
For the list of Service Alerts affecting each Oracle Solaris 11.3 SRU, see Important Oracle Solaris 11.3 SRU Issues (Doc ID 2076753.1).

21 Feb 2018 5:51pm GMT

Alyssa Rosenzweig: My Name is Cafe Beverage

I have a secret, so secret that it cannot be whispered without multiple layers of encryption. So secret that it could only be told to the world under a pseudonym -- an alter ego -- except to the closest of friends on a "need to know" basis. So secret that this pseudonym only connected to the Internet through Tor, using the Tor Browser Bundle and Tor Messenger to maintain resilience against even the most subtle of identity leaks.

So secret that I'll write it on my blog under my real legal name, for all the world to see and criticise:

Over the summer I founded the chai project (proof). My goal was to write a free software driver for Midgard GPUs, better known as the Mali T series produced by ARM. Why? Libreboot supports the Rockchip RK3288 chipset, containing a Mali T760 GPU that is unusable without proprietary software. I purchased a laptop1 with this chipset, and thus my work began.

I was not the first to free the GPU. Luc Verhaegan, better known by his handle libv, precedes me. His project, Tamil, reverse engineered enough of the command stream2 to display a textured cube at FOSDEM.

But the project ceased there due to the pushback; he never released his work. To this day, the source code for Tamil remains only on the hard drive of libv, invisible to the rest of the free software community. Without that source code, Tamil could not enable free graphics acceleration on my own laptop.

I was aware of his ill-fated tale. That said, I was not discouraged. My work with the GPU would proceed, only carefully enough to avoid his own fate. For starters, to avoid the risk that a future me would withhold the source code, I published everything from the beginning, immediately as it was written. Thankfully, the source code remains online, downloaded by many others, spread out between several laptops and servers hosted in multiple countries. Retroactive attempts to censor me would inevitably fail thanks to the Streisand effect. The work is safe.

My other change was to adopt a pseudonym. By contrast, libv worked under his real name, so when there was alleged retaliation, they knew exactly who to target. His real person was exposed to damage as a result of Tamil. This could be a problem for me: depending on my life aspirations and my personal resilience, to work on this GPU under my real name could pose a threat to me as well. Thus, I, Alyssa Rosenzweig, student, writer, programmer, and artist, did not author the work.

Cafe Beverage did. If the project were to come into jeopardy, no harm would come to me. Only my alias cafe was at risk. And at least at first, I was surgically careful to ensure that an outsider could not correlate my two identities.

Yet here I am, six months later, proclaiming it for all to hear: I am Cafe Beverage.

What changed?

I was no longer able to handle the cognitive load of a second persona. Technically, I am well-versed in anonymity software, as an avid user of Tor, GPG, and OTR. But socially and psychologically? Nobody warned me of the mental toll it would take to have to separate myself from, well, myself.

To use anonymity technologies passively is easy. When simply browsing the web in peace, merely exercising the anonymous right to read, the only burden is the frustration of the network speed itself. But once you begin to contribute, changing from anonymity to pseudonymity, the complexity balloons. It becomes necessary to scrutinise every little thing you do, in both your pseudonymous and real lives, to ensure that there will be no crossing over whatsoever.

There is no golden rule to staying pseudonymous. No, there are dozens of rules, most of which are easy to ignore and difficult to follow. It is nearly impossible to balance it all for anyone not already well-versed in operational security ("opsec").

What types of precautions are needed? The Whonix project maintains a short list of twenty-two basic missteps which compromise your anonymity. They also maintain a specific guide on anonymous "Surfing, Posting, and Blogging" with another endless list of attacks to defend against. There are, of course, the precautions given by the Tor project itself, although really you should read through the entirety of the Tor FAQ -- it's only twenty-one thousand words.

Of course, the mind-boggling complexity is warranted. For an activist in a repressive regime, perhaps the archetypical blogger in Iran, these precautions are necessary and hardly enough. For someone in such a situation, the slightest identity slip is lethal. Maintaining full separation of identities is difficult, but when a user's own government is determined to kill dissidents, there are bigger concerns than the cognitive burden of pseudonymity.

But for me? For me, there is no risk of physical injury from my research. libv is still alive despite his "secret" being out for years. There are no black bags in my future from publicising who cafe really is.

Of course, there is a third option: disappear. Stop using the cafe identity, pretend it never existed, let my nick on IRC expire. The other contributors would not know me well enough to compromise me. I could cease the mental gymnastics. There would be virtually no risk. As far as an observer of my non-anonymous self is concerned, the project never existed.

For six months, I chose this option, or rather I succumbed to it. The quantity of my code contributions slowed to a halt; the frequency of my check-ins to IRC faded soon thereafter. At some point, I must have logged in as cafe for the last time, but I do not remember this final milestone. I merely faded into obscurity, until one day I wiped my hard drive during a routine operating system install and lost cafe's passwords. I don't mourn the missing files.

But the new year has come. I have switched computers; today, I am using my Libreboot laptop full-time. This post is being written from vim on that very laptop, running only free software. I need the free Midgard GPU drivers more than ever, and I am willing to put in the work to bring them into fruition.

So note the pronoun: I will be the one continuing on the project, alongside the awesome folks from the BiOpenly community. Not cafe nor a new pseudonym conjured from mid-air, but I. GPU driver development is difficult enough without the mental juggling associated with creating a person out of nothing.

To come out of the shadows brings legitimacy to the project. It will clear up any legal uncertainties surrounding copyright, the complexities of which are amplified when the author of a work is a pseudonym who disappeared. It will allow me to take ownership of my driver work, for instance on a C.V.

Most of all, it will allow me to be myself. It will grant me a different type of digital freedom, a familiar breath of fresh air. Coming out as the author of chai is, in many respects, the same as coming out as a queer person.

My name is Cafe Beverage.

It feels good to write it.

  1. An Asus C201 Chromebook made in 2015

  2. GPU parlance for the protocol used to interface with the hardware. It is also necessary to reverse engineer the shader binaries, a task which was completed successfully by Connor Abbott

21 Feb 2018 4:16pm GMT

Alyssa Rosenzweig: Hello, Triangle!

whistles -- Nothing to see here, move along kids.

Hello, Triangle!

Hello, Triangle!

21 Feb 2018 4:16pm GMT

feedPlanet KDE

It’s now much easier to be a bug triager

We've just rolled out a significant and welcome policy change to KDE's Bugzilla bug tracker: Everyone with an account may now edit any bug without prior permission. This means that every KDE Bugzilla user can now be a bug triager anytime they want!

So get out there and triage some bugs! Our documentation can be found here. This is one of the easiest and most impactful ways to contribute to KDE, and it doesn't require a significant time commitment. Most bugs can be triaged in a minute or two, and boring downtime is a perfect opportunity for some bug triaging! It's also a great way to ease into development; bug triagers will become familiar with KDE's codebase and encounter small easy-to-fix issues that are the perfect entry points for submitting patches.

If my efforts seem useful and you'd like to see more of them, consider supporting me on Patreon, LiberaPay, or PayPal.

21 Feb 2018 2:16pm GMT


KDAB is sponsoring ACCU, the foremost annual conference in the UK for people interested primarily, but not just, in C++ and C. See the program here.

We're offering registrants to ACCU 10% off any KDAB training in 2018. Sign up!

and Meet us there. continue reading

The post KDAB at ACCU appeared first on KDAB.

21 Feb 2018 1:13pm GMT