Have you ever wondered why openSUSE is the platform for development? Because it offers all that is needed for professional development, also if development goes beyond the basics.
A nice proof that openSUSE has more than others was posted here by our friend Thomas, a convinced Debian user. He writes about setting up openSUSE in vagrant to be easily able to build (master build) the ownCloud Client for Win32 in it. Very easy and cool stuff. But that can be even easier without vagrant through this link ;-).
Btw, there is an appliance in SUSE Studio to ease experiments with vagrant with openSUSE as base. I haven’t tested yet, experiences?
This morning during a cup of coffee I wanted to do something adventurous. I put the raspberry which I bought recently (without having very much played with it because of my light apt-* allergy) on the table and thought I will try to install the openSUSE distribution.
I remembered awesome Bernhard was blogging about that topic recently. On that page one can find this link where raspberrypi images can be found. Oh, surprise, there is even a file from november 10th, so I downloaded that. People always recommend the latest stuff.
Well, that was easy and far away from adventure which I was looking for. So I remembered that the cool kids on the block have an ownCloud server running on the RaspberryPi. Would that be as easy? There are no official packages for the Pi yet, so what could I do?
Well, ownCloud is noarch, because it is plain PHP. So I downloaded the two ownCloud server packages owncloud and owncloud-3rdparty from our ownCloud nightly build repository on OBS and installed them with
zypper in owncloud owncloud-3rdparty
I was (adventure!) ignoring all the warnings and stuff, what you should never do! Just for a test, before the coffee is cold.
After having started apache, what should I say? It simply worked. No need for antihistamine, all nice green around, and ownCloud running after having finished it’s setup page.
That really pushed me for the day! It was such a smart experience having that running within a couple of minutes, with absolutely no fiddling around. This is cool stuff! Thanks to Bernhard and all the other openSUSE guys for doing that!
My congrats for the 13.1 release! I really hope that people will understand (again) how awesome the openSUSE distribution and the project is, especially for the more nerdy folks! Really, you wanna run the Geeko these days.
Enough praise, now, maybe there is somebody who will help me in OBS to provide proper ownCloud packages for ARM? I am sure there is not much missing.
And if you want to run ownCloud on your “normal” PC, this is the repository of the latest stable version which we actively maintain…
The new release fixes a problem with the tarball of 0.51 which contained a wrong source revision. That did not cause any harm, but also did not bring the announced fixes. That was brought up by community friends, thanks for that.
Additionally another, actually the last known bug of Kraft’s catalog management was fixed. That was the problem that it did not work to drag sub chapters onto the top level of the catalog. That is working now.
Please update to the new version and help us with your feedback.
Currently we speak a lot about performance of the ownCloud WebDAV server. Speaking with a computer programmer about performance is like speaking with a doctor about pain. It needs to be qualified, the pain, and also the performance concerns.
To do a step into that direction, here is a little script collection for you to play with if you like: the DAV torture collection. We started it quite some time ago but never really introduced it. It is still very rough.
What it does
The first idea is that we need a reproducable set of files to test the server with. We don’t want to send around huge tarballs with files, so Danimo invented two perl scripts called
torture_gen_layout.pl one can create a file that contains the layout of the test file tree, a so called layout( or .lay)-file. The .lay-file describes the test file tree completely, with names, structure and size.
torture_gen_layout.pl takes the .lay-file and really creates the file tree on a machine. The cool thing about is that we can commit on a .lay-file as our standard test tree and just pass a file around with a couple of kbytes size that describes
Now that there is a standard file tree to test with, I wrote a little script called
dav_torture.pl. It copies the whole tree described by a .lay file and created on the local file system to an ownCloud WebDAV server using PUT requests. Along with that, it produces performance relevant output.
After having installed a couple of perl deps (probably only modules Data::Random::WordList, HTTP::DAV, HTTP::Request::Common are not in perl’s core) you should be able to run the scripts from within the directory.
First, you need to create a config file. For that, copy t1.cfg.in to t1.cfg (don’t ask about the name) and edit it. For this example, we only need user, passwd and url to access ownCloud. Be careful with the syntax, it gets sourced into a perl script.
Now, create the local reference tree with a .lay-file which I put into the tarball:
./torture_create_files.pl small.lay tree
This command will build the file tree described by small.lay into the directory called tree.
Now, you can already treat your server: Call
./dav_torture.pl small.lay tree
This will perform PUT commands to the WebDAV server and output some useful information.
It also appends to two files results.dat and puts.tsv. results.dat just logs the results of subseqent call. The tsv file is the data file for the html file
index.html in the same directory. That opened in a browser gives a curve over the average transmission rate of all subsequent runs of
dav_torture.pl (You have run
dav_torture.pl a couple of times to make that visible). The
dav_torture.pl script can now be hooked into our Jenkins CI and performed after every server checkin. The resulting curve must never raise
To create your own .lay-file, open
torture_gen_layout.pl and play with the variables on top of the script. Simply call the script and redirect into a file to create a .lay-file.
All this is pretty experimental, but I thought it will help us to get to a more objective discussion about performance. I wanted to open this up in a pretty early stage because I am hoping that this might be interesting for somebody of you: Treat your own server, create interesting .lay files or improve the script set (testing plain PUTs is rather boring) or the result html presentation.
What do you think?
I am happy to announce that we today were able to release version 1.4.1 of the ownCloud Desktop Client on the three platforms Linux, MacOS and Windows.
You find suitable download links as usual at:
Version 1.4.1 is a bugfix release for the 1.4.0 version released a few of weeks ago which brought a lot of new features. This one solves a couple of problems that were coming up during the last few weeks. For example, the problem that the client lost its configuration (at least) on the Win32 platform when the machine was shut down is fixed. Also a lot of redundant uploads wont happen any more. And there are even more fixes, as the detailed Changelog rules out.
We thank you for your ongoing support and the good work on bugs that came up. As usual we are looking forward to your feedback. Please work with us in the Github bugtracker if you experience issues.
This is a bugfix release which brings a handful of useful fixes against bugs which were reported by Kraft users since the last release.
In the catalog view, now drag and drop is working to sort templates. Removing of sub chapters is also working now. A bug in the unit handling was fixed that picked wrong units in some cases. The path to document templates is not utf8 save.
As a new feature the address of the own company now can be picked from Kraft’s settings dialog also after first setup routine.
Also people who shared their critical view on the client very publically in the past are much more pleased now with 1.4.0. One example is a recent blog post on BITBlokes. It is a blog about all kind of topics around FOSS. I regularly read it and often share its opinions. He concludes very positively about the 1.4.0 client.
It is good to see the positive feedback overall. That shows a couple of things from my engineering point of view: The concentrated work we continously do on all parts of ownCloud pays off. That is obvious of course, but still nice to see. And our (also obvious) actions to improve code quality such as the consequent use of continous integration, code reviews and such helps to improve quality.
“People are always excited if releases come with GUI changes!” I heard people saying. Well, maybe, but that’s not the whole truth. It also proves for me again is how important UI design and UX is. Me as a knee-deep-developer have an interesting relationship to all UX topics: I always have an opinion. Often a strong opinion. But the results coming out of that have not always been the, well, the most optimal. Very fortunate on the client we work together with our UX guy Jan and the positive feedback also shows how good that is for the software.
But enough of release pride. There is more work to do: The bug tracker is still not empty, the list of feature ideas is long. We will continue to focus on correctness, stability and robustness of syncing, performance and useful features and work on a version 1.5 for you.
These are a couple of concrete points we’re focussing on for 1.5:
- we already merged the client code on the new upstream sync version in git.
- performace improvements through further reduction of the number of requests and more efficiency in database operations on the client.
- we are working on a new propagator component that allows us to do the changes mentioned in 2 more easily.
- File manager integration, which means havingn icons in Explorer, Dolphin and friends.
A more detailed list can be found at github.
Thank you for all your help and support. It’s big fun!