Recently I’ve published a list of contributors who helped to test Fedora 19 Alpha. But Quality Assurance doesn’t involve just in-development releases. We need to ensure that stable releases also work well. One of the major ways to achieve that is to make sure that broken package updates don’t enter stable updates repository. We use Bodhi system for that. I have gathered the data about Bodhi feedback contributors regardless of Fedora release involved and present it here.
Who are the heroes who watch the Fedora borders and guard us against broken software updates?
Test period: Q1 2013 (2013-01-01 – 2013-03-31)
Testers: 657
Comments1: 2203
| Name | Updates commented |
|---|---|
| hreindl | 278 |
| patches | 94 |
| kparal | 92 |
| mrunge | 53 |
| adamwill | 48 |
| akshayvyas29 | 41 |
| mooninite | 33 |
| kevin | 32 |
| ankursinha | 26 |
| rdieter | 25 |
| keramidas | 25 |
| bojan | 23 |
| nucleo | 23 |
| boblfoot | 20 |
| pwalter | 18 |
| cfeller | 18 |
| quickbooks | 17 |
| bradw | 15 |
| amessina | 15 |
| sdodson | 14 |
| kwizart | 14 |
| wolnei | 14 |
| bitlord | 14 |
| freddyw | 14 |
| remi | 13 |
| pbrobinson | 13 |
| mstevens | 13 |
| lkocman | 13 |
| misc | 13 |
| orion | 12 |
| nb | 12 |
| artkun | 11 |
| nonamedotc | 10 |
| ktdreyer | 10 |
| ajax | 10 |
| jerboaa | 10 |
| vicodan | 9 |
| po80x-nontoxic at yahoo.co.uk | 9 |
| jvanalte | 9 |
| erinn | 9 |
| cairo | 8 |
| stransky | 8 |
| greenfeld | 8 |
| sysengbd | 7 |
| petersen | 7 |
| asrob | 7 |
| akurtakov | 7 |
| ejs1920 | 7 |
| jmoskovc | 7 |
| jpopelka | 7 |
| ondrejj | 6 |
| mmilata | 6 |
| mtoman | 6 |
| robatino | 6 |
| tsmetana | 6 |
| jvcelak | 6 |
| wutao85 | 5 |
| nkinder | 5 |
| gtwilliams | 5 |
| till | 5 |
| kkofler | 5 |
| rcritten | 5 |
| adomurad | 5 |
| ralph | 5 |
| bruno | 5 |
| ptisnovs | 5 |
| tjikkun | 5 |
| fabiand | 5 |
| rtcm | 5 |
| rlandy | 5 |
| balay | 5 |
| brallan | 5 |
| ppisar | 5 |
| …and also 584 other reporters who created less than 5 reports each, but 867 reports combined! | |
1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is unimportant.
As you can see, Harald Reindl (hreindl) is completely leading this effort, and no one else is even close. Thank you, Harald!
There are lots of further names from the community. T.C. Hollingsworth (patches) provided an outstanding number of comments, followed by Akshay Vyas (akshayvyas29), mooninite, Ankur Sinha (ankursinha), Rex Dieter (rdieter), Vasileios Keramidas (keramidas), bojan, nucleo, Robert C. Lightfoot (boblfoot) and many more! Thank you, and everyone else who helped with testing Fedora updates, no matter your score.
If you are interested in helping Fedora, this is a very easy way and you can start today! Just read QA:Updates_Testing and ask any questions in #fedora-qa on IRC or test list. It would be great to see more faces around.
Thanks and enjoy the day.
When reading the statistics, please take it with a grain of salt. Not all numbers are directly comparable. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by these scripts.
I have replaced my traditional HDD with an Intel 525 SSD (120 GB, mSATA) recently. To keep the write performance high a TRIM option should be enabled. You can either mount the drive with ‘discard’ option, or you can run fstrim command periodically. (This can be a bit trickier if you have LUKS encrypted partitions).
The discard option performs TRIM immediately when a file is deleted, and there is some performance hit involved. You can work around that by having fstrim in a cron job and trimming the disk just once a day or so. It takes longer (about a minute in my case), but it is not a continuous performance hit.
Two years ago Patrick Nagel published a blog about discard performance on his OCZ Vertex LE (100 GB). I was curious whether the numbers would be the same for my SSD. Let’s have a look.
Test description:
With and without discard option let’s do:
- Extract linux sources (linux-3.9.1.tar.gz; 45168 files, 592 MB extracted) including sync operation.
$ time (tar xzf linux-3.9.1.tar.gz ; sync)
- Remove the directory including sync operation.
$ time (rm linux-3.9.1 -rf; sync)
Of course, a few warmup rounds are included. The numbers are averaged from three passes. I have an ext4 partition on LVM on LUKS.
Results:
Without discard
extract: 7,367666667s
delete: 0,709666667s
With discard
extract: 7,373333333s
delete: 2,697333333s
You can also view the raw data.
As you can see, there is a substantial hit on deletion. Removing 45k files was almost 4x slower. But, on the other hand, we’re talking about mere few seconds here, which is way better than in Patrick’s example. I guess the SSD controllers really improved in two years.
I also did a quick second test with deleting a large (3 GB) file. The results are similar – without discard it takes about 0.43s and with discard it takes about 1.65s. So there is no substantial difference between deleting a huge number of smaller files and deleting a single big file.
The output? If you are a general user with no specific needs and you don’t want to bother with cron scripts, you can simply enable the discard option and have your life easier. Of course, we’re talking about Intel 525 here. If you have some other SSD, especially an older one, it might be a good idea to measure the numbers yourself.
Fedora 19 Alpha has been released. I would like to thank everyone who contributed to testing it. Here are some interesting numbers from different quality verification areas. No matter how small or large your contribution is (or whether it is listed at all), if you helped Fedora 19 Alpha quality to improve, you have our thanks.
Fedora 19 Alpha – wiki matrices
This is the list of people who filled in our release validation wiki matrices (Install, Desktop and Base), which are posted for every test compose (and release candidate) that we create. The purpose is to see which areas have been thoroughly tested and which were not.
Test period: Fedora 19 branch time – Fedora 19 Alpha release
Testers: 23
Reports: 1001
Unique referenced bugs: 69
| Name | Reports submitted | Referenced bugs1 |
|---|---|---|
| robatino | 316 | 919374 924138 924244 924248 924251 924254 924255 924256 924258 924260 926913 926916 929050 929054 929177 946964 951801 (17) |
| boblfoot | 187 | 922558 929373 929403 929421 946906 946951 947536 947538 948615 949906 951766 957486 957554 957783 (14) |
| satellit | 95 | 923951 928287 929289 947538 948921 949761 949802 950510 951842 952250 (10) |
| Wutao85 | 91 | 926926 927178 947028 947031 952512 952950 (6) |
| nonamedotc | 57 | 892178 (1) |
| adamwill | 47 | 858270 863592 928982 947558 953329 (5) |
| lnie | 45 | 951269 952950 (2) |
| spstarr | 34 | 949831 951259 (2) |
| jskladan | 27 | 928228 928279 948250 948719 949761 (5) |
| mkrizek | 21 | 928296 948615 951039 (3) |
| kparal | 20 | 928279 928287 928339 950504 950510 (5) |
| lkardos | 17 | |
| lbrabec | 10 | |
| pschindl | 9 | 947142 950504 950510 (3) |
| cra | 7 | 907058 949761 950504 (3) |
| tflink | 5 | |
| patches | 3 | |
| jsedlak | 3 | 950641 951449 953337 (3) |
| mbriza | 3 | |
| wolnei | 1 | 947285 (1) |
| boblfoor | 1 | |
| pwnall | 1 | |
| jdulaney | 1 |
1 This is a list of bug reports linked to the wiki results. They don’t have to be reported by that concrete person.
As usual, Andre Robatino (robatino) is the king of the hill 
Bob Lightfoot (boblfoot) continues to be the second most active person, as in Fedora 18 Final cycle. Many thanks, guys.
I’m very glad that there are a number of community contributors at the top. Besides robatino and boblfoot, namely Thomas Gilliard (satellit), nonamedotc and Shawn Starr (spstarr) provided an amazing number of test results. The number one Red Hatter is Tao Wu (Wutao85). Great job! Of course, even the smaller numbers in the ladder are greatly appreciated and help Fedora a lot. Thank you.
Fedora 19 Alpha – Bugzilla
This is a trimmed list of people who reported bugs into Bugzilla against Fedora 19 in the specified time period. The numbers are pretty high as usual, Bugzilla is our most visible QA tool.
Test period: Fedora 19 branch time – Fedora 19 Alpha release (2013-03-12 – 2013-04-23)
Reporters: 323
New reports: 1234
| Name | Reports submitted1 | Excess reports2 | Accepted blockers3 |
|---|---|---|---|
| Dhiru Kholia | 103 | 0 (0%) | 0 |
| Adam Williamson | 54 | 1 (1%) | 7 |
| Reartes Guillermo | 29 | 2 (6%) | 0 |
| Andre Robatino | 27 | 10 (37%) | 12 |
| Stef Walter | 27 | 1 (3%) | 0 |
| Kamil Páral | 25 | 0 (0%) | 3 |
| Jens Petersen | 25 | 1 (4%) | 0 |
| Daniel Walsh | 19 | 1 (5%) | 0 |
| Ľuboš Kardoš | 19 | 1 (5%) | 0 |
| sangu | 17 | 0 (0%) | 0 |
| John Reiser | 15 | 0 (0%) | 0 |
| Jeff Bastian | 13 | 1 (7%) | 0 |
| Mark Hamzy | 13 | 1 (7%) | 0 |
| Tim Waugh | 13 | 1 (7%) | 0 |
| Robert Lightfoot | 12 | 4 (33%) | 2 |
| Mike FABIAN | 12 | 1 (8%) | 1 |
| Ales Kozumplik | 12 | 0 (0%) | 0 |
| Jan Stodola | 12 | 0 (0%) | 0 |
| Branislav Náter | 11 | 1 (9%) | 0 |
| Dawid Zamirski | 10 | 0 (0%) | 0 |
| Flóki Pálsson | 10 | 0 (0%) | 0 |
| Karsten Hopp | 10 | 0 (0%) | 0 |
| Leslie Satenstein | 10 | 1 (10%) | 0 |
| Vladimir Benes | 10 | 1 (10%) | 0 |
| Zbigniew Jędrzejewski-Szmek | 10 | 1 (10%) | 0 |
| A S Alam | 9 | 0 (0%) | 0 |
| Jan Safranek | 9 | 0 (0%) | 0 |
| Martin Banas | 9 | 3 (33%) | 0 |
| Mikolaj Izdebski | 9 | 0 (0%) | 0 |
| mussadek | 9 | 0 (0%) | 0 |
| Tanner Doshier | 9 | 0 (0%) | 0 |
| Alex Murray | 8 | 0 (0%) | 0 |
| Matthew Miller | 8 | 1 (12%) | 0 |
| Michael Schwendt | 8 | 0 (0%) | 0 |
| Orion Poplawski | 8 | 0 (0%) | 0 |
| Patrik Kis | 8 | 0 (0%) | 0 |
| satellit at bendbroadband.com | 8 | 2 (25%) | 0 |
| Petr Schindler | 7 | 0 (0%) | 2 |
| Ankur Sinha (FranciscoD) | 7 | 2 (28%) | 0 |
| Hans de Goede | 7 | 1 (14%) | 0 |
| Jiří Martínek | 7 | 0 (0%) | 0 |
| Joachim Backes | 7 | 1 (14%) | 0 |
| Peter Robinson | 7 | 0 (0%) | 0 |
| Peter Trenholme | 7 | 0 (0%) | 0 |
| Brian C. Lane | 6 | 1 (16%) | 1 |
| Alexei Panov | 6 | 0 (0%) | 0 |
| Artem Artemov | 6 | 0 (0%) | 0 |
| Dan Waleke | 6 | 0 (0%) | 0 |
| Ed Greshko | 6 | 1 (16%) | 0 |
| Elad Alfassa | 6 | 1 (16%) | 0 |
| Harald Hoyer | 6 | 0 (0%) | 0 |
| Jakub Dorňák | 6 | 0 (0%) | 0 |
| Jakub Filak | 6 | 0 (0%) | 0 |
| Jiri Popelka | 6 | 0 (0%) | 0 |
| T.C. Hollingsworth | 6 | 1 (16%) | 0 |
| Tao Wu | 6 | 2 (33%) | 0 |
| Vadim Rutkovsky | 6 | 0 (0%) | 0 |
| Shawn Starr | 5 | 1 (20%) | 1 |
| Dan Horák | 5 | 0 (0%) | 0 |
| Dan Mashal | 5 | 1 (20%) | 0 |
| Dennis Gilmore | 5 | 0 (0%) | 0 |
| Gustavo Luiz Duarte | 5 | 0 (0%) | 0 |
| Miroslav Grepl | 5 | 3 (60%) | 0 |
| Mr-4 | 5 | 1 (20%) | 0 |
| Ondrej Hudlicky | 5 | 2 (40%) | 0 |
| Remi Collet | 5 | 0 (0%) | 0 |
| Rex Dieter | 5 | 1 (20%) | 0 |
| …and also 256 other reporters who created less than 5 reports each, but 437 reports combined! | |||
1 The total number of new reports (including “excess reports”). Reopened reports or reports with a changed version are not included, because it was not technically easy to retrieve those. This is one of the reasons why you shouldn’t take the numbers too seriously, but just as interesting and fun data.
2 Excess reports are those that were closed as NOTABUG, WONTFIX, WORKSFORME, CANTFIX or INSUFFICIENT_DATA. Excess reports are not necessarily a bad thing, but they make for interesting statistics. Close manual inspection is required to separate valuable excess reports from those which are less valuable.
3 This only includes reports that were created by that particular user and accepted as blockers afterwards. The user might have proposed other people’s reports as blockers, but this is not reflected in this number.
The most visible person here is Dhiru Kholia, who mass-reported over 100 bugs about packaging guidelines violation. When it comes to standard bug reports, the shining star here is a Red Hatter Adam Williamson. We also have quite a few community people at the top, namely Reartes Guillermo, Andre Robatino, sangu, John Reiser, Mark Hamzy, Dawid Zamirski, Flóki Pálsson, Leslie Satenstein and Zbigniew Jędrzejewski-Szmek. And of course there are hundreds of others, who reported just a few bugs each, but it all sums up in an amazing number of bug reports. Thank you all!
Fedora 19 Alpha – updates testing
This is a trimmed list of people who provided feedback in Bodhi for all updates proposed into Fedora 19 in the specified time period. The purpose is to make sure that broken updates do not enter the stable repository and the release continuously stabilizes.
Test period: Fedora 19 branch time – Fedora 19 Alpha release (2013-03-12 – 2013-04-23)
Testers: 98
Comments1: 278
| Name | Updates commented |
|---|---|
| patches | 47 |
| misc | 19 |
| akurtakov | 16 |
| raven | 16 |
| adamwill | 16 |
| kevin | 15 |
| kalev | 13 |
| pbrobinson | 5 |
| kparal | 4 |
| petersen | 4 |
| spstarr | 3 |
| mfabian | 3 |
| ankursinha | 3 |
| sharkcz | 3 |
| miketc302 | 3 |
| bruno | 3 |
| deanhunter | 3 |
| robatino | 3 |
| mschwendt | 3 |
| jerboaa | 2 |
| maners | 2 |
| elad | 2 |
| twaugh | 2 |
| adomurad | 2 |
| bellet | 2 |
| ajax | 2 |
| gustavold | 2 |
| egreshko | 2 |
| mkrizek | 2 |
| boblfoot | 2 |
| yelley | 2 |
| bruce89 | 2 |
| satellit | 2 |
| dwa | 2 |
| kraman | 2 |
| nucleo | 2 |
| …and also 62 other reporters who created less than 2 reports each, but 62 reports combined! | |
1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is unimportant.
The top contributor is T.C. Hollingsworth (patches), who provided feedback to the most updates by far. Also from the community Piotr Drąg (raven) and Kalev Lember (kalev) were near the top as well. The most active Red Hatter was Michael Scherer (misc). There are dozens of other people who tested an update or two. Thank you all. This type of testing is very useful and very easy to participate in. It’s the best place to start if you want help Fedora QA out a bit.
Summary
The testing seems to be going well and Fedora 19 seems to go much smoother than Fedora 18 had. Thanks all contributors!
If you are interested in raising the Fedora quality up, help us out. Read QA/Join, follow the announcements and talk to us in #fedora-qa on IRC and test list. We will love to see you!
When reading the statistics, please take it with a grain of salt. The numbers are not directly comparable. People might see some reports as more valuable than others. Some people tested a lot of components, but haven’t found many problems (but that also helps). Some people used their skills in other areas than those mentioned. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by these scripts.
Lately I’ve found out that I can speed up my Fedora 19 testing if I increase the number of CPUs assigned to the VM. This is a short blogpost about it, maybe it will help also others.
By default, this is what a default new VM in virt-manager looks like:
There is just a single CPU assigned, out of my 4 host CPUs available (Intel Core i7 processor).
In my completely unscientific benchmark, I tried changing the value and measuring how the boot time of Fedora 19 Alpha Live changes. It was measured from isolinux screen to displaying the Fedora welcome dialog. Of course I used a few warm-up starts first to make sure everything is cached and the results are not affected by the disk access. These are the results:
Fedora 19 Alpha Live boot time
| Number of CPUs | Boot time (seconds) |
|---|---|
| 1 | 67 |
| 2 | 48 |
| 3 | 46 |
| 4 | 46 |
It seems that the boot process of a Live image can be well parallelized. There is a large difference between a single CPU and a dual CPU. Adding more than two CPUs doesn’t help considerably. Quite interestingly, when I tried to measure an installed system, the changes were very small:
Fedora 19 installed boot time
| Number of CPUs | Boot time (seconds) |
|---|---|
| 1 | 29 |
| 2 | 27 |
| 3 | 25 |
| 4 | 27 |
The live image performs a lot of one-shot setup tasks during boot, that’s probably the major difference here.
I didn’t perform any further benchmarks inside the running system, for example Anaconda installation. It might be interesting to compare the installation speed with different number of processors, but I haven’t gotten to it yet (patches welcome:)). But because I boot Live images very often, at least I know that the boot process is significantly improved by using two CPUs in the VM. In my 4 CPU host system that seems as a good number. It doesn’t hog my host down too much, and if I really need it, I can run two VMs in parallel and they will fully utilize my processor potential, at the expense of my host system becoming a bit lagging.
As a side note, as I’ve found out, the default VM memory is 1024 MB. That is quite insufficient, your installation will suffer by a lot of swapping and it will take much longer. For pre-release images with debugging options enabled it might not even succeed. Usually I use 1.5 GB RAM for generic Fedora testing, and 2 GB RAM for pre-Beta testing (which includes debug kernel). With these amounts of memory I find the installation go pretty well. Of course you must have sufficient amount of memory available in your host system.
Also, don’t miss out on my previous blogpost about the speed of different disk bus drivers.
Happy testing!
In this blogpost I’ll describe how to run graphical applications under a different user account in your current desktop session (i.e. without fast user switching). It involves some fiddling with the system configuration, this is not intended for general users without advanced system knowledge. The instructions are created for Fedora 18.
Everything mentioned here was discovered through a trial-and-error approach, I don’t have any expertise in this area. Some of the advice might not be fully correct. I have talked to a few qualified people and I was told that Linux doesn’t support this properly and some applications might display some glitches or not work at all. Consider this a best-effort solution – it might work perfectly for some applications, but you can’t expect it to work in general.
Some background
In my setup I have a regular user account kparal and also a second user account gamer that I use for several purposes:
- Playing games. I use GNOME Fallback mode, so I get slightly better framerates (I have a very slow graphic card and it really makes a difference).
- Running unknown and “not so trustworthy” tools and scripts, often downloaded somewhere from the Internet (i.e. not packaged in Fedora). I do not really expect malware in these tools, but more likely serious bugs. I like to know that the unknown script can’t delete my personal data by accident.
But using the second user account is sometimes also inconvenient:
- If you need to transfer a piece of text (e.g. a hyperlink) from one account to the other, it involves saving it as a file, copying it and fixing permissions. Ugh.
- If you are inside gamer session, you don’t see any notifications from your kparal‘s IM clients, mail clients, etc. You need to switch forth and back all the time to check your messages and reply.
- If you are inside gamer session, you can’t easily access some files in your kparal home folder that you would like to, e.g. music. Just to play some background music, you need to fiddle with your data, set up permissions, etc. Boring.
Over the weekend I installed Steam. Obviously I run it under the gamer account. Not just because of performance, but also because my trust in Steam is far from being 100%. It downloads lots of external binaries and executes them. I trust Valve they are careful to not have any security incident (e.g. malware added to some of their game updates), they certainly have some security checks and policies, but how reliable are those? Does Steam executes everything inside some sandbox? I don’t know and honestly, running Steam (and dozens of third-party binaries it executes) in a separate account seems like a reasonable trade-off.
When I tried to buy a game in Steam, I needed to log in to my Moneybookers account. But my financial passwords usually consists of 20 random characters and are safely stored in a password manager in the kparal session. I got very annoyed at this point. The string is too long to remember, I was offended by the idea to write it down (what do we have technology for if I need to use paper?) and I didn’t really want to save it in a plain text file on disk. Call it a whim. So how do I transfer it? Why on earth can’t I just run steam under the gamer account inside my kparal session and copy and paste it? Windows can do it!
Well, it turns out Linux can do this too, more or less, but it needs a few tweaks. After that you can run any application under a different user account inside your desktop session. Let’s see how.
Basic application window
If you log in using su and run a sample graphical application, it should work out of the box:
kparal@kraken ~ $ su - gamer -c gcalctool Password: ** (gcalctool:3969): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ** (gcalctool:3969): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied. dconf will not work properly. (repeated many times)
There are some accessibility bus warnings, but I haven’t seen any loss of functionality, so I consider them mostly harmless. The dconf errors are arguably a bug and you might lose some functionality because of that – application settings might not be loaded nor saved. If you see these errors, you should unset XDG_RUNTIME_DIR variable first:
kparal@kraken ~ $ su - gamer Password: gamer@kraken ~ $ unset XDG_RUNTIME_DIR gamer@kraken ~ $ gcalctool ** (gcalctool:3969): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
At this point most of your graphical applications should work just fine (the only problem I’ve found is that the global GNOME menu doesn’t work with them). Some of their functionality can be lost however, especially if the application tries to communicate over D-Bus with other processes. According to information I gathered, you might improve the situation in certain cases if you run the application using dbus-launch:
gamer@kraken ~ $ dbus-launch your-application
I haven’t yet seen any application where this would be required, so I can’t provide any more details. Basically if you see any errors regarding D-Bus, you can expect some loss of functionality. But often you might not care, it depends on what you need to achieve with that particular application.
Using sudo instead of su
I like to use sudo instead of su, because it caches your password and it can be even configured for password-less login. However the approach is not so straightforward here and requires more tweaking. Only follow this section if su doesn’t suit your needs.
In the basic workflow, this is what you will see using sudo command:
kparal@kraken ~ $ sudo -i -u gamer gcalctool No protocol specified ** (gcalctool:5113): WARNING **: Could not open X display No protocol specified (gcalctool:5113): Gtk-WARNING **: cannot open display: :0
This is because your X server permissions do not allow anyone else to connect to it (IIUIC):
kparal@kraken ~ $ xhost access control enabled, only authorized clients can connect SI:localuser:kparal
If you want to use sudo instead of su, you need to allow gamer to display the window in your session. Like this:
kparal@kraken ~ $ xhost +si:localuser:gamer localuser:gamer being added to access control list kparal@kraken ~ $ xhost access control enabled, only authorized clients can connect SI:localuser:gamer SI:localuser:kparal
Now try it again:
kparal@kraken ~ $ sudo -i -u gamer gcalctool
The calculator should appear just fine. The xhost command has to be executed after each session start, so I wanted to add it to ~kparal/.xprofile, but then I found out that Fedora doesn’t source that file. I added it to ~kparal/.profile instead like this:
# allow gamer to display apps on this X server # (don't do that for local non-X and any remote connections) if [ -n "$DISPLAY" -a -z "$SSH_CLIENT" ]; then xhost +si:localuser:gamer fi
I now used the command above to run Steam in my session and paste in the Moneybookers login credentials conveniently. Success!
Sound
I quickly found out that sound is not routed for these redirected applications. It’s a pity it doesn’t work out of the box, but fortunately it can be fixed quite easily.
First, install and run paprefs and activate Enable network access to local sound devices. I have no idea which configuration was adjusted, because nothing changed neither in ~/.pulse nor in /etc/pulse. But you can see now the pulseaudio server listening over TCP/IP for network connections. Authorization should be required, so you don’t need to be afraid of eavesdroppers.
Now, try to play some sound:
kparal@kraken ~ $ su - gamer -c paplay /usr/share/sounds/alsa/Front_Center.wav
(or just run Totem/Firefox/etc)
If you are lucky (unlike me), your audio now works out of the box. But if you pulseaudio daemon is restarted for any reason (it crashes or you kill it and start again), the routing no longer works and you need to re-log to your desktop session. Probably a bug. I didn’t know that, so I spent hours reading PulseAudio documentation. It’s not the most thrilling experience.
If that magic routing didn’t work for you, or you need to play audio even after PA is restarted, this is what I involuntarily discovered:
- You can copy ~kparal/.pulse-cookie to ~gamer/.pulse-cookie (and re-assign file ownership). That will handle authentication.
- Then you can forward audio by sudoing to gamer, exporting PULSE_SERVER=localhost variable and running the app you wish.
(It should be also possible to route the audio using unix sockets (instead of TCP/IP sockets), but the damned documentation is not helpful at all in achieving this task.)
Graphical acceleration
Spot two differences:
kparal@kraken ~ $ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset
and
kparal@kraken ~ $ su - gamer -c glxinfo | grep render Password: libGL error: failed to load driver: i965 libGL error: Try again with LIBGL_DEBUG=verbose for more details. direct rendering: Yes OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301)
Yes, your redirected applications don’t have 3D acceleration. Here is a more detailed error message:
kparal@kraken ~ $ su - gamer Password: gamer@kraken ~ $ LIBGL_DEBUG=verbose glxinfo | grep render libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so libGL error: failed to open drm device: Permission denied libGL error: failed to load driver: i965 libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so libGL: Can't open configuration file /home/gamer/.drirc: No such file or directory. direct rendering: Yes OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301)
I tried to run chromium-bsu and extremetuxracer, both run around 30 FPS using software rendering. Not suitable to gaming at all.
Fortunately I’ve found out the reason. It’s all about access permissions to /dev/dri/card0 file, which represents your graphics card. If you log in using a standard graphical session, some daemon (probably logind) grants you temporary rw access to that file using ACLs:
kparal@kraken ~ $ getfacl /dev/dri/card0 getfacl: Removing leading '/' from absolute path names # file: dev/dri/card0 # owner: root # group: video user::rw- user:kparal:rw- group::rw- mask::rw- other::---
But if you log in using su or sudo, you are not given proper permissions. I have found two solutions. The first one is to manually add gamer‘s ACLs after each boot:
kparal@kraken ~ $ sudo setfacl -m user:gamer:rw /dev/dri/card0
This can be added for example to /etc/rc.d/rc.local in order to be executed every boot. The other approach is to add gamer to the video group, which owns the file. In this case you don’t need to execute anything else on each boot, the change is permanent.
Now your 3D applications should work correctly:
kparal@kraken ~ $ su - gamer -c glxinfo | grep render Password: direct rendering: Yes OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset
The simple games I tried now run at full speed.
Please note however, that there are slight security concerns when you elevate these permissions for gamer permanently. If the account gets hacked, the attacker can access your graphics card (maybe see your display? I don’t know) or even a camera (just if you used the video group approach, because this group also controls access to the webcam) while being logged in remotely. From this reason the first approach seems a bit safer to me (limits the number of devices) and you should definitely prohibit gamer from any remote access (e.g. disable this account in your ssh server configuration).
Epilogue
That’s it, I can finally display graphical applications (even games) from a different user account inside my desktop session. It took me quite some time to find this all out. It’s highly probable that I did a lot of things the wrong way. Does anybody know of a tool that would handle all this setup transparently and easily? Or does anyone know a working sandbox tool that would fit these use cases? Please share your improvements in the comments. Thanks.
sendKindle allows you to easily send documents to your Amazon Kindle device using a command line. You no longer need to open an email client, create a new email, fill in the recipient and a subject, add attachments, hit send, no. You just write sendKindle into your terminal, drag and drop the file, hit Enter. It’s faster
I already blogged about sendKindle before. It will use your email account (I tested just GMail) to send the file to your Amazon address. (As a bonus, I have a filter defined in GMail which will move these emails from the Sent mail to Trash, because I don’t want all the files to clutter my mailbox, and it works great.)
Recently I finally became a packager (hooray!) and pushed sendKindle as my first package into Fedora. It’s currently in updates-testing, so until it receives some karma or a week passes, you can install it like this:
$ yum install sendKindle --enablerepo=updates-testing
In a week you can use your favorite package manager without any further “complications”, because it will have landed in stable updates for Fedora 17 and 18.
The project lives at github, report all your problems there (except packaging bugs, which go to bugzilla). Be sure to see the README though – if you want new features, you need to provide patches.
Enjoy.
I have recently found out that GNOME Online Accounts now support Kerberos authentication. I assume this might be interesting for many people who use GNOME in an corporate environment, so I decided to spend a few words about it here.
The setup is as simple as it can get. You just add a new Kerberos account in GNOME Online Accounts and provide a domain name, your user name and a password. Then you see this:
Every time you boot your computer now, you will also receive a Kerberos ticket. Awesome!
Unfortunately, the world is not perfect, and neither is GNOME Online Accounts. So there are a few annoying problems:
- Your computer has to boot inside the company network. If you connect to the network afterwards, you will not receive the Kerberos ticket.
- You can’t use the ON-OFF slider the force a ticket retrieval, because GNOME Online Accounts crashes. So back to kinit in this case.
Let’s hope these problems will be ironed out in GNOME 3.8, currently it’s just a half-baked solution. But it’s definitely better than having nothing at all.
