In our house we have a very simple system to capture rainwater into a tank. We use it to water our vegetable garden during the dry season.

Parts

We use a 1100 liter water tank. I would have liked something bigger, but there just wasn't enough space for it.

1 is the exit from the roof; water from various roofs in the house gets directed here.

2 is a T connector. On the horizontal side it goes to 3, where it enters the water tank. On the vertical exit side it goes down a relatively long pipe, all the way down to 6, which is a valve or faucet. That long pipe is the "dirty water collection pipe". When it starts raining, the first charge charge of water can be quite dirty from all the dirt on the roof. This dirty water fills the long pipe. The dirt accumulates in the bottom of the pipe, and finally cleaner water will have a chance of filling the tank when the water level in the pipe reaches the T connector.

4 is the overflow pipe. When the tank gets full, any overflowing water will exit through here.

5 is the water tank's exit pipe.

6 is the valve controlling the output from the dirty water collection pipe, as mentioned above.

7 is a normal faucet coming from the water tank. This is where you would plug a garden hose.

The trick is to adjust 6, the valve of faucet at the bottom of the dirty water collection pipe, so that water and dirt can trickle out of it. That is, don't leave it fully closed. The pipe will fill up shortly after it starts raining, allowing the rest of the rain to reach the tank; finally the pipe will empty itself for the next rain.

Does it work!

It works very well! We use the stored rainwater for plants in the vegetable garden. We used that water for construction of the garden's planting beds, to make mortar for bricks. Although we have managed to empty the tank a couple of times during very heavy use, normally it rains often enough that the tank stays almost full.

Note that the tank is basically one storey above ground level. This gives barely enough water pressure for a slow-running garden hose.

2022 Update: Since the installation of the original system in 2015, we have added a flow-activated pressurizer pump so we can irrigate comforatbly.

References

T.H. Thomas and D.B. Martinson, Roofwater Harvesting: A Handbook for Practitioners (PDF)

Common disinformation people tends to believe in is that Linux Audio is in bad shape. Actually it’s not. They are right ALSA is getting bit rusty and it’s not top of the notch but list of supported sound cards is long. There have been speak about next generation audio API for Linux but nothing is really happening (I’m happy if you prove me wrong!). Last year I had task to evaluate different Linux audio libraries for playing audio and recording. So these articles try to make some light to my journey and what did I found. inpatient can go to Github  https://github.com/illuusio/linux-audio-example/tree/master/portaudio. There is other library examples also but only Portaudio is currently updated to my last version. I wrote same very simple application to test every audio library. I’ll upgrade rest of the examples and add also Xiph libao and GStreamer.

Application

Like I said example applications are very simple. With Every library I tried to write playback and record example. If you can use blocking API interface there is blocking example also. In these Examples I use sndfile because API is super easy to use and I could test with WAV. So no troubles big bobbles approach.

Code

I won’t be posting code here it can be found on Github repository. I tried to be super clear as they are examples and added comments as needed but if you don’t get glue fault is all mine.

Portaudio

Supported outputs: Alsa, Oss, Jack, Mac OS X CoreAudio and Many Windows Audio API’s

Why do want to use something else than ALSA? If you need to support other platforms than Linux you get idea of cross platform API for audio. Portaudio is hidden gem of Linux audio libraries. It’s stable as can get. Portaudio has blocking and callback support. It has Float 32-bit Int 32-, 16- and 8-bit input/output. I tries to be very high end in every corner. Also licensing is very liberal.  For a while It’s has seen slowing development  because main developers have something else to do in life.

For me biggest no-no for me was lack of Pulseaudio support (I go so upset that I wrote Pulseaudio  hostApi for Portaudio but that is worth of another blog post). Portaudio supports Windows, Linux and Mac OS X so it’s good choice if you need same quality audio in every platform.

Biggest minus in Portaudio is there ain’t much applications using it. There is some highlights like Mixxx and Audacity. Rest of the list can be found here. Why it’s not more popular I can’t say because it’s easy to use.

Summary: Simple but powerful API for I/O which I can recommend. So go and see examples if it’s for you and documentation from official pages. Next time we get on Pulseaudio.

The other day Richard described in his blog how how he used openQA to test drive Fedora. Around the same time I read about Android x86 and saw that they offer iso images for download. So I wondered how hard it would be to get that one tested in openQA.

To find out I installed a current Tumbleweed snapshot in qemu. Installing openQA in the VM is straight forward with the provided packages, following the instrucutions at GitHub.

Keep in mind that nested virtualization needs to be turned on to be able to run the openQA worker inside qemu (pass nested=1 to kvm_intel resp kvm_amd). To conveniently access the web interface, vnc and ssh I added “-net” “user,hostfwd=tcp::8888-:80,hostfwd=tcp::5091-:5091,hostfwd=tcp::2222-:22” to the qemu command line.

As soon as openQA is up and running the remaining steps are easy:

• add the sample Android test cases I created:

  # cd /var/lib/openqa/tests
  # git clone -b android-4.4 git://github.com/lnussel/os-autoinst-distri-android.git android-4.4
  # chown geekotest android-4.4/needles
  

• import the job templates so openQA learns what to do with Android iso images

  # android-4.4/templates
  

• Download android-x86-4.4-r2.iso and store it in /var/lib/openQA/factory/iso
• register the iso image with openQA:

  # /usr/share/openqa/script/client isos post \
      ISO=android-x86-4.4-r2.iso \
      DISTRI=android VERSION=4.4 ARCH=i586 \
      FLAVOR=live BUILD=0002
  

Voilà! If everything went right openQA should now have created a job and the worker should start processing it.

Here are some screenshots and a video of my test run:

Looks like the emulator in the Android SDK is also qemu based. So theoretically it shouldn’t be hard to integrate that one into openQA in order to actually test on emulated phones as well.

Im November 2014 wurde die Version 0.57 von Kraft veröffentlicht, ich möchte nachholen, sie hier zu erwähnen, da ein Update zu empfehlen ist. Es ist die letzte fehlerbereinigende Version der 0.5x Reihe. Eine ganze Menge von Fehlern wurde behoben, für Details siehe das englische Changelog.

Zum Beispiel wurde die Dokument-per-Email-versenden Funktion überarbeitet. Sie ermittelt jetzt die Emailadresse des Empfängers aus den Kontaktdaten des Kunden. Ausserdem funktioniert die Mailfunktion wieder mit dem Emailprogramm Thunderbird.

Spezialposten wie Bedarfs- und Alternativposten können wieder auf normale Posten zurückgesetzt werden. Auch wurde die Ok/Abbrechen-Behandlung des Dokumenteditors repariert. Sollte bei einem bestehenden Dokument der Dokumenttyp geändert werden, wird jetzt auch die Dokumentnummer aus dem entsprechenden Nummernkreis nachgezogen. Einige Fixes im Bereich der Speicherverwaltung des Programmes, die sogar Abstürze verhindern, runden das Release ab.

Installationen älterer Versionen sollten aktualisiert werden.

Wie geht es weiter? Als nächstes wird der Port auf KDE Frameworks 5 in Angriff genommen. Das passiert, um am Ball zu bleiben, aber auch damit Kraft eines Tages auch auf Mac und möglicherweise auch Windows erscheinen kann.

Ich freue mich wie immer über Kommentare zu Blog und Kraft ganz allgemein, entweder per Kommentar hier im Blog oder: Kontakt zu Kraft!

My name is Robert Schweikert, IRC handle robjo, and I am standing for re-election in the upcoming openSUSE Board election in January of 2015.

With the end of 2014 my first term on the openSUSE board is already coming to an end, time flies. During my first term we collectively have seen many changes to our project. Many of these changes were difficult and I would say we had a rough ride for a good chunk of th last 2 years. I think, and am hoping others agree, that I was able to help smooth some of the rough spots and help the project move into what could now be considered calmer waters. It was not easy, but I am glad I was able to contribute.

Since 2009 I work for SUSE in the ISV Engineering team. When I started I primarily worked with IBM on joint projects. I also worked with other ISVs helping them with questions regarding their application on top of SUSE Linux. In recent years my role has transitioned and I am now focused on Public Cloud work, working with our partners.

I have been using SUSE Linux, now known as the openSUSE distribution since the beginning, i.e. I still remember when SUSE Linux 10 was released. I have been contributing to the project for many years, not from the get go, it took me some time to move from user to contributor, by maintaining packages, more recently also maintaining and publishing openSUSE images in the public cloud, and helping with organization of events. For the past two years I also had the privilege to contribute to the project as a board member. I would very much enjoy being able to continue my contribution to the board for another 2 years.

Looking forward I see the need that an effort needs to be made to re-invigorate our project. As a whole the distribution “business” has lost some of its appeal and shine. Something that is certainly to be expected. Never the less even in a world that is getting more and more dominated by cloud services, containers, and whatever else, distributions are a necessity and the openSUSE distributions always stands out as one of the top notch community distributions. We have also proven that there is still plenty of innovation potential with the recent merge of Tumbleweed and Factory, turning what was previously a pure development stream into a usable rolling release. The credit for this of course goes to the Factory team, release team and many others that contributed to the new tools and backend infrastructure that make all this possible. Re-invigoration for me not only means being proud and excited about such major technical accomplishments but also means we need to be better organized when it comes the representation of our project at FOSS events. Although the new booth box material is great we have had a difficult time getting things organized and helping those that want to represent the project at events. I want to continue to push on this part and help make the distribution of material better. There is plenty of work to be done at the board level and I am asking for your vote in the upcoming election to allow me to continue what is already in the works and help start new initiatives to re-invigorate our project.

I've been working a lot with openQA lately, openSUSE's great operating system testing tool, and I think some of what I've been getting up is kind of interesting.

This is likely to be the first of a series of blog posts about my crazy adventures with this awesome tool.

What is openQA?

openQA is a fully featured operating system testing tool.

It takes an operating system ISO or Disk Image, and using its Domain Specific Language (DSL) conducts a series of tests consisting of keyboard and mouse inputs while analysing the screen output for specific matches (called 'needles') to ensure the operating system is behaving as intended.

A typical, simple example of an openQA test for looks like this

#Header, doesn't normally need to be changed
use base "basetest";
use strict;
use testapi;

#run() subroutine, where the test code goes
sub run() {

#test functions
assert_screen "inst-bootmenu", 6;
send_key 'ret';

}

1;

This test is used to check a boot loader. The 'assert_screen' function in this case is looking for a matching 'needle' (screenshot) which has a tag named 'inst-bootmenu'. If it doesn't find a matching needle within the defined timeout (6 seconds) the test fails. If it finds a matching needle within 6 seconds, the test continues, and presses the return key with the 'send_key' function.

The results of these tests are provided in the form of logs, screenshots, and video recordings delivered over the openQA web interface. You can have a look at openSUSE's production instance at http://openqa.opensuse.org and an example of a single set of test results HERE.

Screenshots? Isn't it a pain in the arse maintaining the Needles?

Not at all. The openQA webUI contains a needle editor (example HERE) which lets testers see both the reference screenshots and the accompanying JSON file, and edit both with a WYSIWYG editor.

Select the areas of the UI you're interested in, click save, done. It takes seconds to update your needles to accept intended changes to a UI.

As needles are only looking for specific UI elements on the screen, well crafted needles can often allow regular UI changes to pass unmolested. If you're not interested in confirming the version number drawn on the screen, don't include the version number in your needles, and you'll have a version neutral needle - like in the example HERE.

The openQA web interface can automatically commit and (if you want) push your needles to a git repository (openSUSE's are HERE) making it really easy for testers/test developers to work together on keeping your needle collection up to date.

Is openQA just for openSUSE?

NO! While it's mainly used and contributed to by the openSUSE Project for testing Tumbleweed and the openSUSE Distribution, it's always been designed to be not only distribution-neutral (ie. it can test any Linux Distribution) but technically operating system-neutral - Linux, BSD, Windows, openQA doesn't care about what it's testing.

Yeah, right...prove it.

I haven't been working on openQA for a very long time. For a few weeks I've been working on new openQA tests for openSUSE and SUSE Linux Enterprise, but as we already have a huge collection of tests in our public git repository, a good number of my new tests are borrowing code and ideas from our existing test library.

So I got wondering, how hard is it to test a totally differing operating system, with a totally different installation workflow?

So, after reading the recent Register review of Fedora 21 that had a subtitle mentioning 'install woes', I decided to pick on our friends at the Fedora Project and downloaded a copy of Fedora 21 Workstation.

'Designing' tests for openQA is easy. I fired up the ISO in a VM and kept notes on which screens would make good needles and which keys to press. Each of the screens became an 'assert_screen' call in my tests, and each keypress became a 'send_key'.

NOTE: I could have used openQA's 'assert_and_click' function to check the screen for a needled area and click in the middle of it - it's a great for pressing buttons, but I decided to take a very keyboard centric approach.

In a few hours I had thrown together a basic set of tests, which you can get on GitHub

These tests successfully complete a full installation of Fedora 21 Workstation, as you can see from the openQA-produced Video I uploaded to YouTube

It wasn't perfect though, no QA tool is any good if it doesn't find bugs - luckily even these really simple tests were able to reliably reproduce a known issue in anaconda which apparently had been causing problems since October and hasn't yet been fixed.

Wanting to prove the tests and needles were generic enough that they could be reused for future testing, I've also run these against a recent Rawhide build.

Everything looks really promising, but a bug in Rawhide with Keyboard Shortcuts needs to be fixed before my tests can complete a full run.

Not bad for a few hours work if I say so myself, and I'd really like it if other people want to pick up where I've left off and extend these tests to provide more comprehensive coverage.

I'm interested, where can I find out more?

The main openQA website on GitHub is at http://os-autoinst.github.io/openQA/ and contains all the Documentation and Downloads you need to get started.

It takes about 1 hour to setup openQA on a basic openSUSE installation, and it doesn't have any crazy hardware requirements. If you can run KVM virtualisation, you can run openQA. All these Fedora tests have been run on a local instance of openQA on my X220 Laptop running openSUSE Tumbleweed.

I'd especially recommend the Getting Started Guide which explains a lot more about the fundamentals of openQA

For more help, the best place is the #opensuse-factory IRC channel on irc.freenode.org (where I can be found as ilmehtar and/or sysrich) or the opensuse-factory@opensuse.org mailinglist

Have a lot of fun!

A long time a go a coworker documented the ssh forwarding with xinetd trick that i showed him. We use it heavily on our virtualisation cluster for openSUSE. Of course it gets annoying if you have to pass the port parameter to each invocation of ssh or scp. Especially since ssh and scp are so nicely consistent for that. ;)

As the title already implies, ssh has a config file which we can use. It allows us to basically set every setting that can also pass via command line argument and all that per host.