I know Ruby but have little experience with web apps. If you're like me then this article could be useful.

I needed a way to browse API documentation of multiple related code repositories. (Yes, it's YaST).

I made a tool for that in the form of a web application. This was really easy with the Sinatra framework.

First I ran it locally on my machine for myself. Then I ran it on a machine in the company network for team mates to use. It was a VM that I repurposed from a previous experiment. Then Pepa said it would be nice to have it publicly accessible. How hard could that be?

I had heard that Heroku makes that sort of thing easy, and it turned to be true!

1. It's free. A low profile app, that only needs to run occasionally, fits into their Free service plan. It sleeps after 30 minutes and takes 10 seconds to wake up.

2. Easy to sign up. Enter your e-mail, pick a password. No other details required.

3. Easy app creation: pick the region (US or EU). Optionally pick a name (I got salty-waters-71436 for my demo app).

4. Easy to set up the tooling. Well, they install the curl | bash way. Over https. And then the downloaded code downloads some more.

   If you want to start small, the setup by hand is easy too, now download required:

   touch ~/.netrc
   chmod 600 ~/.netrc
   echo "machine git.heroku.com login YOUR_EMAIL password ffffffff-ffff-ffff-ffff-ffffffffffff" >> ~/.netrc

   Where the hex string is your API Key (Top-right Person icon > Account Setings > scroll down)

Now let's write a trivial web app.

1. Make a git repo.

2. Make a two-line Sinatra app.

   require "sinatra"
   get "/" { "Hello, world!" }

3. Add a two-line Gemfile declaration; add also Gemfile.lock to Git.

   source "https://rubygems.org"
   gem "sinatra", "~> 1.4.0"

4. Add a oneliner Procfile.

   web: bundle exec ./timeserver
   

   (This was new to me. It's not needed locally but needed for Heroku, and anyway useful once you outgrow oneliners. Use foreman start to use it)

5. Use your app name as the remote repo name. Push to deploy (or set up automatic deployment):

   git remote add heroku https://git.heroku.com/salty-waters-71436.git
   git push heroku

That's it! See the app in action: https://salty-waters-71436.herokuapp.com/?q=1_500_000_000.

To see my actual app, instead of the trivial demo built for this blog post, go to http://apitalism.herokuapp.com/.

Here is something that might be a little outdated already, but I hope it still adds some interesting thoughts. The rainy Sunday afternoon today finally gives the opportunity to write this little blog.

Recently an ownCloud fork was coming up with a little shiny box with one harddisk, that can be complemented with a Rapsberry Pi and their software, promoting that as your private cloud.

While I like the idea of building a private cloud for everybody (I started to work on ownCloud because of that idea back in the days), I do not think that this example of gear is a good solution for private cloud.

In fact I believe that throwing this kind of implementations on the table is especially unfortunate because if we come up with too many not optimal proposals, we waste the  willingness of users to try it. This idea should not target geeks who might be willing to try ideas on and on. The idea of the private cloud needs to target at every computer user who wants to store data safely, but does not want to care about longer than ever necessary. And with them I fear we only have very little chances, if one at all, to introduce them to a private cloud solution before they go back to something that simply works.

Here are some points why I think solutions like the proposed one are not good enough:

Hardware

That is nothing new: The hardware of the Raspberry Pi was not designed for this kind of usecases. It is simply too weak to drive ownCloud, which is an PHP app plus database server that has some requirements on the servers power. Even with PHP7, which is faster, and the latest revisions of the mini computer, it might look ok in the beginning, but after all the neccessary bells and whistles were added to the installation and data run in, it will turn out that the CPU power is simply not enough. Similar weaknesses are also true for the networking capabilities for example.

A user that finds that out after a couple of weeks after she worked with the system will remain angry and probably go (back) to solutions that we do not fancy.

One Disk Setup

The solution comes as one disk setup: How secure can data be that is on one single hardisk? A seriously engineered solution should at least recommend a way to store the data more securely and/or backup, like on an at homes NAS for example. That can be done, but requires manual work and might require more network capabilities and CPU power.

Advanced Networking

Last, but for me the most important point: Having such a box in the private network requires to drill a whole in the firewall, to allow port forwarding. I know, that is nothing unusual for experienced people, and in theory little problem.

But for people who are not so interested, that means they need to click in the interface of their router on a button that they do not understand what it does, and maybe even insert data by following an documentation that they have to believe. (That is not very much different from downloading a script from somewhere letting it do the changes which I would not recommend as well). Doing mistakes here could potentially have a huge impact for the network behind the router, without that the person who did it even has an understanding for.

Also DynDNS is needed: That is also not a big problem in theory and for geeks, but in practice it is nothing easily done.

With a good solution for private cloud, it should not be necessary to ask for that kind of setups.

Where to go from here?

There should be better ways to solve this problems with ownCloud, and I am sure ownCloud is the right tool to solve that problem. I will share some thought experiments that we were doing some time back to foster discussion on how we can use the Raspberry Pi with ownCloud (because it is a very attractive piece of hardware) and solve the problems.

This will be subject of an upcoming blog here, please stay tuned.

Long time not talking about fglrx rpm, mostly because they’ve got no update since last December 2015.

Short Summary

In a word as hundred, fglrx is now a dead horse!

We had the hope of getting it working for Leap 42.2 in October, but except freezing kernel and xorg, you will not get what you would expect: a stable xorg session

Say goodbye fglrx!, repeat after me, goodbye fglrx.

If you are locked down and forced for any reasons to use fglrx with your gpu, and are still using 42.1, then don’t upgrade to 42.2, without a plan B

It has no more support from AMD upstream, and that’s it!, if someone want to break its computer, it’s still possible to pick the last files and try it by yourself, but the repository will never contain it for 42.2 (see below how-to)

That’s said, I’m not still sure, to keep for a long time the repository, I’ve been managing since 6 years now.

A bit of history

In 2010, when we were working hard to get 11.1 out, the news that no supported ATI (at that time) will be available for end-users, as we have for nvidia gpu

I didn’t check back the irc log, but we were a few, that would like to have this still available, by pure commodity. Especially that I’ve just exchanged a non working gpu by my new hd5750.

I remember the first chaotic steps, how to build that, and create repeating builds, what about the license? Did we have the right to offer a pre-build rpm etc. I spent some time fixing all of this stuff.
And start the build on real hardware. Hey afterward kvm was really in infancy stage.

Release after release amd/ati and openSUSE, the driver was build, on hardware for each supported distribution. When beginning of 2013 Sebastian Siebert, who got some direct contacts with AMD, release
his own script, we collaborate to have the possibility to build on virtual machines, which allow me to simplify the build process, as having on kvm for each openSUSE release supported.

Afterward, AMD start to split fglrx with the fglrx for HD5xx and above, and fglrx-legacy. So 2 drivers to maintain, but as always with proprietary software, the legacy version became rapidly obsolete,
and non usable. Not that bad, in the meantime the AMD effort on the free and open source radeon driver, quickly overcome the performance of legacy.

Still from 2013, to 2016 I’ve been able to propose ready to use rpm for several version of openSUSE’s distributions. I think the repository serve quite well end users, and I never got big flames.

I can’t avoid to mention the openSUSE powered server and sponsored by Ioda-Net Sàrl that has serve this objective so well during that time frame.

Future of the repository

Now that fglrx is becoming obsolete, I think seriously about why the repository online should stay online.

At openSUSE project level, we still have 13.1, 13.2, 42.1 and 42.2 that are mostly active. 13.1 is already almost out of the game of evergreen,
13.2 will follow soon, and I don’t know yet the exact plan for 42.1, but it will certainly go out of maintenance in less than a year.

If you feel or have the need of the repository, please express that in the comments below.

Wait there’s amd-gpu-pro, no?

Yeap there’s a closed driver, called amd-gpu-pro, available, for newer cards. But there’s two things that bring me out of the game, first I don’t have those newer gpu,
and don’t have the need to replace my hd5750 for the moment. The second and certainly the most important, those drivers are only available for Ubuntu or at least in .deb format.

I will certainly not help proprietary crap, if I don’t have a solid base to work with, and a bit of help from their side. I wish good luck to those who want to try those drivers,
I’ve got a look inside, and got a blame face.

For crazy, and those who don’t love their computer

So you want to loose your time? you can! I’ve kept in raw-src directory all the script used to build the driver.
They differ a bit compared to Sebastian Siebert last version in the sense of making Leap 422 as a possible target.
If you dig a bit around, you should be able to build them, but you’re alone on that way, you’ve been warned!

I’m not against a republished version, if someone find a way to make them working, just drop me a message.

That’s all for this journey, Have Fun!

Very recently, I've been working on implementing the required tooling for creating and modifying Open Container Initiative images without needing any external components. The tool I've written is called umoci and is probably one of the more exciting things I've worked on in the past couple of months. In particular, the applications of umoci when it comes to SUSE tooling like the Open Build Service or KIWI is what really makes it exciting.

Admit it: how many times you have seen “software from this branch is completely untested, use it at your own risk” when you checked the latest code from any FOSS project? I bet you have, many times. For any reasonably modern project, this is not entirely true: Continuous Integration and automated testing are a huge help in ensuring that the code builds and at least does what it is supposed to do. KDE is no exception to this, thanks to build.kde.org and a growing number of unit tests.

Is it enough?

This however does not count functional testing, i.e. checking whether the software actually does what it should. You wouldn’t want KMail to send kitten pictures as a reply to a meeting invitation from your boss, for example, or you might want to test that your office suite starts and is able to actually save documents without crashing. This is something you can’t test with traditional unit testing frameworks.

Why does this matter to KDE? Nowadays, the dream of always summer in trunk as proposed 8 years ago is getting closer, and there are several ways to run KDE software directly from git. However, except for the above strategy, there is no additional testing done.

Or, should I rather say, there wasn’t.

Our savior, openQA

Those who use openSUSE Tumbleweed know that even if it is technically a “rolling release” distribution, it is extensively tested. That is made possible by openQA, which runs a full series of automated functional tests, from installation to actual use of the desktops shipped by the distribution. The recently released openSUSE Leap has also benefited from this testing during the development phase.

“But, Luca,” you would say, “we already know about all this stuff.”

Indeed, this is not news. But the big news is that, thanks mainly to the efforts of Fabian Vogt and Oliver Kurz, now openQA is testing also KDE software from git! This works by feeding the Argon (Leap based) and Krypton (Tumbleweed based) live media, which are roughly built daily, to openQA, and running a series of specific tests.

You can see here an example for Argon and an example for Krypton (note: some links may become dead as tests are cleaned up, and will be adjusted accordingly). openQA tests both the distro-level stuff (the console test) and KDE specific operations (the X11 test). In the latter case, it tests the ability to launch a terminal, running a number of programs (Kate, Kontact, and a few others) and does some very basic tests with Plasma as well.

Is it enough to test the full experience of KDE software? No, but this is a good solid foundation for more automated testing to spot functional regressions: during the openSUSE Leap 42.2 development cycle, openQA found several upstream issues in Plasma which were then communicated to the developers and promptly fixed.

Is this enough for everything?

Of course not. Automated testing only gets so much, so this is not an excuse for being lazy and not filing those reports. Also, since the tests run in a VM, they won’t be able to catch some issues that only occur on real hardware (multiscreen, compositing). But is surely a good start to ensure that at least obvious regressions are found before the code is actually shipped to distributions and then to end users.

What needs to be done? More tests, of course. In particular, Plasma regression tests (handling applets, etc.) would be likely needed. But as they say, every journey starts with the first step.

libelektra is a configuration library and tools set. It provides very many capabilities. Here I’d like to show how to observe data model changes from key/value manipulations outside of the actual application inside a user desktop. libelektra broadcasts changes as D-Bus messages. The Oyranos projects will use this method to sync the settings views of GUI’s, like qcmsevents, Synnefo and KDE’s KolorManager with libOyranos and it’s CLI tools in the next release.

Here a small example for connecting the org.libelektra interface over the QDBusConnection class with a class callback function:

Declare a callback function in your Qt class header:

public slots:
 void configChanged( QString msg );

Add the QtDBus API in your sources:

#include <QtDBus/QtDBus>

Wire the org.libelektra intereface to your callback in e.g. your Qt classes constructor:

if( QDBusConnection::sessionBus().connect( QString(), "/org/libelektra/configuration", "org.libelektra", QString(),
 this, SLOT( configChanged( QString ) )) )
 fprintf(stderr, "=================== Done connect\n" );

In your callback arrive the org.libelektra signals:

void Synnefo::configChanged( QString msg )
{
 fprintf( stdout, "config changed: %s\n", msg.toLocal8Bit().data() );
};

As the number of messages are not always known, it is useful to take the first message as a ping and update with a small timeout. Here a more practical code elaboration example:

// init a gate keeper in the class constructor:
acceptDBusUpdate = true;

void Synnefo::configChanged( QString msg )
{
  // allow the first message to ping
  if(acceptDBusUpdate == false) return;
  // block more messages
  acceptDBusUpdate = false;

  // update the view slightly later and avoid trouble
  QTimer::singleShot(250, this, SLOT( update() ));
};

void Synnefo::update()
{
  // clear the Oyranos settings cache (Oyranos CMS specific)
  oyGetPersistentStrings( NULL );

  // the data model reading from libelektra and GUI update
  // code ...

  // open the door for more messages to come
  acceptDBusUpdate = true;
}

The above code works for both Qt4 and Qt5.

With my last post I promised to give some more detailed information on the migration of the crowbyte website and blog as well as my plans for the future of crowbyte.org and I live up with my promise in this post.

Migration details

After over half a year of absence I had the time to rethink the direction into which the blog and website headed lately.

I used Nikola as a page generator for my blog and websites. This was a decision which I made after a lot of consideration and testing of av...