Saturday, April 19, 2014

Cards Against Humanity - All White Backgrounds Version

I have modified the stock Cards Against Humanity PDF from http://cardsagainsthumanity.com/ to use all-white backgrounds, so I could print the cards with my inkjet printer and not cry for all the wasted ink.

Doing it was surprisingly hard: I had to use a combination of pdfedit and recolor.pl.

All credits for the original game go to the original authors, I just repainted the walls.

Download:
CAH_MainGame_AllWhite.pdf (Mirror 1)
CAH_MainGame_AllWhite.pdf (Mirror 2)

sha1sum is 602f8cbf92af1933e9613812e7610fa629c1a13f, have fun!

Monday, January 20, 2014

Fixing the brightness keys skip steps on Ubuntu 13.10 -- my solution

As explained in http://askubuntu.com/questions/173921/why-does-my-thinkpad-brightness-control-skip-steps sometimes there are multiple things fighting to do the job when you press the brightness keys on your laptop.

In my case, it seems like both the gnome-settings-daemon and the brightness switch for the video driver were both trying to adjust the brightness, so whenever I pressed I button, it adjusted twice.

Now while the proposed solution
sudo sh -c 'echo -n 0 > /sys/module/video/parameters/brightness_switch_enabled'
worked, it stopped me from adjusting brightness on a tty (ok not a biggie), but especially I've noticed that leaving brightness up to gnome is slow and sluggish.

So instead I thought I'd disable gnome instead. There's a lot of old information relating to gnome-power-manager and other deprecated configurations, but I managed to discover that gnome-settings-daemon uses the gsd-backlight-helper (on my system it is installed as /usr/lib/gnome-settings-daemon/gsd-backlight-helper) to do its work.

To disable it, I just did
sudo chmod -x /usr/lib/gnome-settings-daemon/gsd-backlight-helper
You do lose the brightness OSD, but that's a price I'm willing to pay.

Sunday, July 07, 2013

AEG AX500

Was looking into this mysterious AEG AX500 cellphone, and as I suspected it's a rebrand of the Karbonn A9+ / CM Flare. Also check the thread at xda-developers.

Wednesday, March 06, 2013

Skype Group Video Calling not possible on Linux nor Android


As the title says, group video calling is currently not possible on Linux nor Android. This means that while you can participate in a group call, you will not be able to see other people, nor will they see you, only sound is possible.

This happens EVEN if you pay for a premium Skype account.

Official statements:
Linux: "... However, it is not possible to make group video calls." (top of the page)
Android: "Unfortunately, Skype for Android does not support group video calls. You can participate in a group call, but only using audio - you will not be able to send or receive video." (last question)

Note that other people may or may not see an error, while all you will see is a disabled video button.


Hope this helps someone. Because this needs to be stated more clearly. On the client. When you try to enable the call. Not hidden somewhere on semi-related pages.

Monday, January 02, 2012

Loop-mounting a backup of an entire disk, and accessing its partitions

The following is a short howto on how to mount a full-disk backup (that you took using dd, for example), and access its partitions.
# Assuming that the backup is called diskbackup.bin
$ losetup /dev/loop0 diskbackup.bin
$ kpartx -a /dev/loop0

# Your partitions should now show up on /dev/mapper/
$ ls -lah /dev/mapper/
total 0
drwxr-xr-x  2 root root       80 2012-01-02 08:45 .
drwxr-xr-x 18 root root     3.9K 2012-01-02 08:45 ..
crw-------  1 root root  10, 236 2012-01-02 08:00 control
brw-rw----  1 root disk 253,   0 2012-01-02 08:45 loop0p1

Sunday, December 11, 2011

New "BetterKubuntu" blog project

Wow, long time no update.

I've recently started a separate blog with Kubuntu tips & tweaks at
http://betterkubuntu.blogspot.com/

Be sure to visit it :)

Sunday, March 21, 2010

Package testing system for a rolling upgrades linux distribution: a proposal

Lately, I've been thinking about the issue of package testing on a linux distribution that does rolling upgrades.

I've arrived at the idea of mainly using three different repositories: stable, testing and unstable. You may notice that I borrowed the same nomenclature that the debian project uses, and that's because I intend these repositories to mean more or less the same that they mean for debian.

So, what is different about my idea? I shall explain that during the course of the article, but mainly it is different because I am referring to rolling upgrades, which debian does not use on their stable repositories. Also, for my approach to work, tight integration with a new GUI package manager is required, to support the workflow that I am about to describe.

The Unstable Branch
Packages are first uploaded by packagers to the unstable branch. I shall ignore the issue of who can upload to this branch -- most distributions already have a packaging team or some kind of organizational structure to support this.

Only stable upstream releases should reach this branch. I will come back to the issue of unstable development packages later on.

Now, the interesting part is: how do packages retire from the unstable branch into the testing branch, or are "popped out" of the unstable branch because they do not work?

I propose the usage of a GUI package manager that allows users to easily select from which branch they want to install an application, and to mix-and-match versions from the three branches, whenever possible. Of course there isn't much sense in a user that has a stable KDE SC 4.3.5 release to install Konqueror from KDE SC 4.4.1 -- the usual package management rules must be applied here, so the user either installs an older stable Konqueror, or KDE SC 4.4.1 as a whole.

But imagine now, that the stable branch contained Firefox 3.5 and Firefox 3.6 was just released and uploaded to the unstable branch. In the package manager, users can see that there is a new version for Firefox on the unstable branch.

Let's imagine that a user -- John -- chooses to install this package. The package manager does its work, and notifies John that Firefox 3.6 is done installing. It also adds the package to the "Verification queue" for John.

John fires up Firefox 3.6, goes to slashdot, and all seems ok. He can then go back to the package manager, and tick Firefox 3.6 on his verification queue as "Ok".

The idea is that packages retire from unstable to testing not on a time-based schedule, but when sufficient users give it an "Ok" after a quick test. If there was an issue and the Firefox package had something wrong, for example if it crashed on startup, a "Failure" would be reported on the verification queue on the package manager. Attached to this Failure, a small comment could be made explaining it, and optionally, links to more detailed bug reports could be added (either to the distro's own bug reporting system, or to an upstream bug).

To choose at which point a package with a number of "Ok" and "Failure" reports gets picked to the testing branch or is popped off the unstable branch, I think a scoring system could be adopted, but to simplify matters for now, let's say if a package has > 20:1 ratio of Ok/Failure reports and more than 100 Oks it is selected to the testing branch, and if it has more than 10 Failure reports it gets popped off unstable.

The main idea of this unstable branch is really a quick "does it seem to work?" test. Open Firefox, browse to a site. No problems? Check "Ok". With a Kernel release, boot it. It booted and you're back staring at your desktop? Check "Ok".

The Testing Branch
The testing branch works on a time-based schedule. Users can also choose to install packages from here, and they will also be added to the Verification Queue, but in a different way: they will be there, but users will need to have the package installed for at least a week to be able to do mark them as "Ok".

On the other hand, if they experience any problem, they can flag a "Failure" right away, and follow the same procedures that they did on the unstable branch to comment on why they marked their test of the package as a "Failure" and to link it to bug reports.

The idea is that a week is usually enough for users to notice problems in usage of the package for their normal work.

After enough users have verified the package as "Ok", and not enough users had problems (again I shall discuss my ideas for scoring later on), the package gets transferred to the Stable branch.

If there are too many problems with a package, it might go back to the unstable branch or popped off completely. I'm not entirely sure what would work better for this case yet.

The Stable Branch
The stable branch behaves as expected from other distros.

Development Packages
Many distributions also want to make it easy for users and other developers to test development versions of upstream packages. For these, I propose a parallel repository system with just two different repositories: unstable-development and testing-development. Both of these should work as the ones above, but the difference is that a package never retires from testing-development to any other repository; it either stays there, or is deleted by the packagers.

Scoring System and "Social" Stuff
This scheme might work even with a simple scoring system, but I think that a more complex system might yield better results. I've held back on explaining this part so far because I think that although this should be part of the integral solution, it is not the main part, and Social-whatever is used too much as a buzzword nowadays.

The first part of this idea is that users should have an account on the package testing system. I don't know if anonymous voting would work without trying it out, so it might be an option, but anonymous votes should have the least weight on verification queue voting.

This account could be used across multiple computers by the same user (laptop, desktop), allowing the user to, for example, install Firefox 3.6 from the testing repository on their work computer on monday, install the same package on their laptop on the following friday, and report it as "Ok" on the following monday on their laptop -- that is, the testing week is not tied to the system the package is installed, but to the time and date it was first installed by that user on one of his systems.

Also, the weight of a user's "Ok" to a package would be tied to multiple things: account creation time (long-time users are more likely to give more trust-worthy reviews), number of correct verifications (the user could be penalized for giving an "Ok" to a package that was eventually popped off unstable, and rewarded if a package it marked "Ok" on testing and unstable made it through to stable), maybe a community rating (part of the distro team, helps people on the forums regularly, etc).

These combined values would determine the weight of a user's vote, and this weighted vote would be the one used when determining if a package is ready or is too buggy. For example, if 15 very trusted users gave an "Ok" for a package, maybe it can retire from unstable into testing right away, instead of having to wait for 200 anonymous users to test it.

Epilogue
I hope some (or even all) of these ideas can be applied in the creation of a simple linux distribution (or transformation of an existing one) that does rolling upgrades. Most binary, easy-to-use distros currently do not possess such a feature, and users are normally left to pick and match from experimental "repositories" that have different degrees of testing and readiness, and normally there is no standard way to flag problems or open bug reports on them.

If you read this entry so far, I thank you, and I hope I was able to spark some ideas about this issue. Please do leave your opinions on my proposal, or anything else you think is important, on the comments below.

Saturday, March 13, 2010

Hacking pommed 1.31 to use nvclock / smartdimmer to control lcd backlight

Recently a MacBook Pro 5,5 came into my hands. It seems this model has a known gotcha that is kind of hard to find clearly stated online: currently, you can only adjust your backlight while using the nvidia proprietary linux driver by using nvclock.

I tried using pommed without a kernel driver, I tried mbp_nvidia_bl, I've tried nvidia_bl, but using any one of those I can only adjust my backlight outside of X.

Using nvclock, and its buddy smartdimmer, you can adjust it from within X. As I'm lazy and I like pommed, I did a quick hack for pommed to use nvclock, and here it is:

diff --git a/pommed/dimmerhack.sh b/pommed/dimmerhack.sh
new file mode 100755
index 0000000..52f0036
--- /dev/null
+++ b/pommed/dimmerhack.sh
@@ -0,0 +1,3 @@
+#!/bin/bash
+
+exit `smartdimmer -g | grep level | cut -d " " -f 3`
diff --git a/pommed/lcd_backlight.h b/pommed/lcd_backlight.h
index 20feecc..f141b9d 100644
--- a/pommed/lcd_backlight.h
+++ b/pommed/lcd_backlight.h
@@ -56,8 +56,8 @@ gma950_backlight_probe(void);


/* nv8600mgt_backlight.c */
-#define NV8600MGT_BACKLIGHT_OFF 0
-#define NV8600MGT_BACKLIGHT_MAX 15
+#define NV8600MGT_BACKLIGHT_OFF 15
+#define NV8600MGT_BACKLIGHT_MAX 100

void
nv8600mgt_backlight_step(int dir);
diff --git a/pommed/mactel/nv8600mgt_backlight.c b/pommed/mactel/nv8600mgt_backlight.c

index 79373f4..94b4a2c 100644


--- a/pommed/mactel/nv8600mgt_backlight.c

+++ b/pommed/mactel/nv8600mgt_backlight.c
@@ -35,6 +35,7 @@
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
+#include <sys/wait.h>
#include <fcntl.h>
#include <unistd.h>

@@ -60,27 +61,15 @@ static unsigned int bl_port;
static unsigned char
nv8600mgt_backlight_get()
{
- unsigned char value;
-
- if (nv8600mgt_inited == 0)
- return 0;
-
- outb(0x03, bl_port + 1);
- outb(0xbf, bl_port);
-
- value = inb(bl_port + 1) >> 4;
-
- return value;
+ return (unsigned char) WEXITSTATUS(system("dimmerhack.sh"));
}

static void
nv8600mgt_backlight_set(unsigned char value)
{
- if (nv8600mgt_inited == 0)
- return;
-
- outb(0x04 | (value << 4), bl_port + 1);
- outb(0xbf, bl_port);
+ char buffer[200];
+ snprintf(buffer, 200, "smartdimmer -s %u", value);
+ system(buffer);
}
I know it is a very ugly hack, but it works for me.

I may be motivated to implement this in a less hacky way if anyone finds this useful, but for now, this will do.

That is all for now :)

P.s.: Don't forget to put step=15 or something big like that on the lcd_8600mgt section of /etc/pommed.conf otherwise it will take a while to change the setting, and also don't forget to put smartdimmer and the above bash script somewhere pommed can find them (I recommend /usr/bin).

Monday, November 30, 2009

Minimal xorg.conf

This minimal xorg.conf file may come in handy if you need to configure something in X, but you don't have a minimal xorg.conf base file you can start with.

Section "Device"
Identifier "Configured Video Device"
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
EndSection

Thursday, September 03, 2009

Qt confused about multimedia?

I've always had a very high opinion of Trolltech's Qt Software's Nokia's Qt framework.

But after a post today on Qt Labs Blogs, it seems that there are two upcoming Qt multimedia frameworks that seem to duplicate and ignore the existing Phonon module -- these are the Qt Multimedia module and the Multimedia framework for QtMobility.

Dear trolls, what is going on with all of this? Is Phonon going to be abandoned? Is Phonon the new arts?

Update: It seems that indeed Phonon is the new arts, as Nokia is putting it on life support. Fortunately, it seems that some KDE hackers (including Phonon's original author) will support and develop Phonon further, so it might not be so bad after all.