Tuesday, August 18, 2015

Goodis SBT-111B Change language / Mudar língua


So a quick post here. My "Goodis SBT-111B" bluetooth headset changed itself to spanish out of the blue(tooth), and the manual says zilch on how to select the language. Since the device has the huge amount of one button, it's kind-of hard to find a menu.

I was able to get it working, so here's my instructions. Hope it helps.

To change the language, enable pairing mode first:
- With the headset off, press and hold the button down for about 6 seconds
- The headset will turn off, give the "ready to pair" message (in whatever language it is in) and end with a "bleep". The blue led will start blinking fast

To change the language when in pairing mode:
- Press and hold the button, and release after hearing the **second** bleep
- The headset will start playing a message in each of the supporting languages saying "press button to select the language".
- When you hear "press call button to select english", press the button. The headset will repeat the language and presto.

Hope it helps!

Post rápido! O meu "Goodis SBT-111B", comprado na worten saltou para espanhol e pelos vistos ninguém sabe como o mudar de volta (nada no manual, e worten ignora pedidos de ajuda com o genérico "já viu no manual?". já worten. já todos procurámos lá...). De qualquer forma, pelos vistos isto é feito por um fabricante chinês chamado Stiger, e tive um palpite de procurar instrucções de outros produtos deles e achei.

Para mudar a lingua, ponham primeiro o mãos-livres em modo pairing:
- Com o bluetooth desligado, carregar no botão e deixar pressionado durante cerca de 6 segundos
- O bluetooth dá a mensagem de voz de que está pronto para fazer pair (na língua que estiver) e depois um "plim" e o led azul fica a piscar rápido

Para mudar a língua no modo pairing:
- Carregar de novo no botão, deixando-o pressionado, e largar ao **segundo** plim
- O auricular vai começar a tocar uma mensagem que diz em cada uma das línguas suportadas "pressione o botão para seleccionar a língua".
- Quando ouvirem "press call button to select english" carreguem uma vez no botão, e vão ouvir "English" e pronto!

Monday, July 13, 2015

Easily creating a wireless AP to share a wired connection on Ubuntu

I'm currently stuck at a hotel where the wireless is not working correctly, but I have wired internet. Googling around I found that hostap with a lot of configuration could be used to create a wireless AP and share this connection, but I wanted an easier solution.

Luckily I found the awesome create_ap script at https://github.com/oblique/create_ap

To use it, I just did the following:

# install hostapd
sudo apt-get install hostapd
# get the script

git clone https://github.com/oblique/create_ap
# install it 

cd create_ap
sudo make install
# share wired connection eth0 via wlan0 and set ssid to fix_yor_internet
sudo create_ap wlan0 eth0 fix_your_internet

And done! Thanks to oblique for his awesome little script :)

Monday, May 05, 2014

Uberwriter Ubuntu 14.04 trusty .deb

Uberwriter is a very nice distraction-free text editor.

As of currently there are no .deb packages for Ubuntu 14.04 trusty on the web, so I've rebuilt the latest package available from the ppa (link).

Here it is:

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.

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 / 14.04 LTS -- 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 # For Ubuntu 13.10
sudo chmod -x /usr/lib/unity-settings-daemon/usd-backlight-helper # For Ubuntu 14.04 LTS
You do lose the brightness OSD, but that's a price I'm willing to pay.

Sunday, July 07, 2013


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

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.

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.