Bjoern and I attended FrOSCon, the Free and Open Software Conference, a major FOSS-Event in Germany, which took place August 25th and 26th.
We had a booth, showing off ownCloud, as well as the Beta of the Desktop Client 1.4.0, and giving away leaflets, pins and t-shirts. The huge interest reflected in the fact that we didn’t even get to take a picture if the booth. If you have one, let us know ;-). We’ll make sure to be back!The traffic at the booth stood proof to the vast interest in ownCloud: People literally queued up to ask questions or voice suggestions, especially after Bjoerns talk in the main lecture hall, which was well received and will shortly be available online.
Next to discussing with visitors, many of which were already actively using ownCloud, I also got to hack and discuss with some people like Domme, of Tomahawk fame, this resulted in first steps towards a Qt 5 port for Mirall, and concrete planning steps towards a file manager integration, which is scheduled for ownCloud Client 1.5. We’re looking forward to FrOSCon 2014!
Full disclosure: I am a former FrOSCon organizers, and contributed to the Video Operations Center this year.
Only slightly more than a month has passed since the release of ownCloud 1.3.0 and it’s been quite a ride. But now, we are at the first milestone of the 1.4.0 release that we would like to share with you: Beta 1. The focus in this release, apart from the usual fixes, was to provide improved user feedback, and to extend both the user interface and the backend in a way that would allow us to bring the client forward. For the UI, this meant the introduction of a Settings dialog. For the backend, it meant a lot of refactoring.
Feedback
All important information is now available in the context menu.
Previous versions of the ownCloud client were quite sparse in terms of feedback. You would have to wait for a complete sync to finish in order to receive your results, and to understand what the client actually did, you would have to resort to running with the --logwindow option. No more! The new beta features feedback about the current sync progress and already processed items in the context menu. If this is not enough, you can choose Details... from the Recent Changes. This will pop up a dialog that will give you the complete details about all uploaded, downloaded, deleted and moved files and directories. On top, the information will be available as it the sync happens, but only as a result afterwards like before. There is also feedback on the upload progress both in the context menu and in the account details. When there are problems with the sync like running out of quota, the system tray icon will now change to indicate a problem.
Finally, we introduced a Help... item, which points to the official online manual. We are currently updating it to make it more useful, but it already
contains many important hints for trouble shooting. If you want to help out with documentation, check Issue #788.
Settings
Icons going native
It’s hardly believable, but so far the Client went without a settings dialog. Under the hood, we had features piling up such as switching to native/monochrome icons, but they were only available as command line switches. Now they are all pretty check boxes. On top, there are now options to disable pop ups resulting from syncs, as well as auto-starting the Client on all o systems on a per-user basis. Auto start is now only default if an account has been successfully configured.
This release features the most changes in terms of lines of code since the beginning of the Client development. Code has been refactored to enable new functionality, such as bandwidth control, aforementioned quota visualization, or to allow for Custom Ignore patterns. Not only can you add new file patterns that will be ignored by the client, but you can also define them as discardable. For instance locally created meta-files such as .DS_Store (Mac) or Thumbs.db (Windows) would not be deleted which the folder was removed remotely, rendering the client incapable of removing the directory. Ignored files marked as discardable will now be removed without warning, making the sync experience a lot smoother.
Another, still ongoing effort is the introduction of a smarter scheduler that ensures that sync runs will only be performed whenever there are changes on the server. Before, we could only detect local changes. In order to achieve this, we leverage the E-Tag, a Unique ID provided by the ownCloud WebDAV server. This should result in significantly reduced CPU load and networking traffic. No more sync runs every 30 seconds. Instead, the root E-Tags on the server are being checked, and a sync run is only started if they changed. Also, we have lowered the thread priority for the actual sync run to provide a smoother experience.
There are a lot more changes in this release, which are summarized in the ChangeLogs for Mirall and OCSync as well as the open and closed issues for the 1.4 milestone in GitHub.
We are looking for projects that would like to present in the exhibition area, as well as interesting talks or workshops. Additionally, you can request a project room if you want to sit together to do some hacking, or have your own, topic specific course of lectures. Sign up now!
But even more so, we are looking for speakers. The focus this year is on Seamless Computing, How Free Software should deal with closed ecosystems and How to let the computer do your chores. Even if your topic is not in one of those domains: Submit your proposal.
Today, along with the server updates, we have released ownCloud Client 1.2.3. This release will continue working users of the 4.5 series. Clearly the most important and single-most annoying bug this release addresses is the creation of illegitimate conflict files. This can happen due to several reasons. Lately, it has been reported due to a regression in 5.0.0 (which was fixed in 5.0.3). We now compare the files for equality, which avoids illegitimate conflict files on the client side.
We also fixed the sync handling of Microsoft Office Documents and possibly other locked files on Windows: Before, when a file was locked (e.g. by an Office application), the client would think that the file was gone, deleting it from the server (and hence other clients) until the application would release the file again. In 1.2.2, when a file is locked, the Client simply skips it. We all ignore the lock files.
People have reported this behavior as a bug for OpenOffice files already, because they think that we should transport the lock file. However, this is wrong: Suppose you sync while someone else has a lock on the file and then you go on the train: You will not be able to open the file due to the lock file. Also, by the time the lock file is synced, the original author might already have closed down the Application that was locking it. This is a matter of principle: unlike on a local file system, two people editing the same file is perfectly ok — it will result in a legitimate conflict during sync, and only on one of the sides.
Finally, a quick tour through the additional changes: We fixed some of the crashes seen especially on Mac OS when setting up a folder. Also, Linux users using Nautilus will now have their sync folder will be automatically added to Nautilus during sync setup. Finally, the Client now works with screen readers on Windows. For those observing crashes after some time on Linux, please read this post for a description of workarounds.
The packages are available at the usual place and pose a significant improvement over 1.2.1 for many users, especially when using a 5.0 server (which you should also upgrade). For the next release, we are working on chunked syncing, and an overhaul of the user interface, which also brings a lot of code improvements along the way. Stay tuned.
We had many reports on crashes due to exhaustion of file descriptors on Linux. When we started to look into them, we found that unfortunately they all have their cause in broken packages further down the dependency chain:
One confirmed leak is due to a bug in libgnutls/libgcrypt, which is not unload-safe and keeps opening /dev/random at every sync run. I added a workaround for this in 1.2.1, but that will only work if you have the unversioned .so files installed. Those are part of your distributions libgnutls-devel package.
The other leak we observed, which leaks sockets, has not finally be investigated, but seems to be related to gnome-keyring’s pkcs#11 support. Moving away /etc/pkcs11/modules/gnome-keyring-module works around the issue. We are on working proper fixes and/or getting in touch with the original authors and distro package maintainers.
I will update this post with more findings as they appear.
When the Qt sources were first released on ftp.troll.no, the Troll Tech (mind the spelling, it’s that long ago!) FTP server, many FTP mirror admins quickly started mirroring the software, because it was cool, and useful to them or their company/university. And quite right so, because this meant that everyone in the world could use his local mirror to get their files real fast, i.e. high speed and low latency. However, over time, traditional mirrors were replaced by Content Delivery Networks (CDNs). They were deemed more convenient because, well, the user doesn’t need to look for the his closest mirror. The CDN is a one-stop-shop which will automatically find a fast download location. This can either be done by employing GeoIP, or by performing a distance calculation based on routing information (the users’ ASN). There are even more ways of doing this, but let’s not digress:
During the time at Nokia, the Qt packages were also moved to a Commercial CDN. It was good, but it was also expensive. As an Open Source project, we should use our resources cost-effectively and have an infrastructure that is decentralized to a certain degree. Fortunately there is a software that helps us doing that, by combining the ease of CDN-like user-experience with the old system of FTP and HTTP mirrors, and it’s called MirrorBrain. Happy users include LibreOffice, openSUSE and the KDE Project. MirrorBrain presents itself to the user as one page, redirecting the actual downloads to mirrors. While doing that it makes sure that only those mirrors that contain the latest, up-to-date version of the files will be used.
A Call for Mirrors
Since a few days, we have a MirrorBrain infrastructure in place. If you run a mirror or have a reliable, well-connected machine (>= 50 MBit/s) that can help us delivering Qt (currently a total of 120GB), please read the mirroring instructions on the Qt Project page, send us a mail and join the mirrors mailing list.
Credit where Credit is due
The KDE Sysadmin team has helped us a lot in getting MirrorBrain started while setting up the evaluation system. Peter Poeml, the uberbrain behind MirrorBrain, has been of great assistance. Finally, Digia has been sponsoring the man power to set up the production system.
Klaas explaining cross-device syncing to visitors.Right after the ownCloud 5 release event in Berlin I took the train to Chemnitz to join Klaas in staffing the ownCloud booth, which we shared with the openSUSE folks this year.
Lots of people dropped by to see ownCloud 5, while others were eager to learn about the concepts of ownCloud, or were asking about tips on how to host their files at home or on a self-maintained server.
Snapshot from the buffet.Many were pleased to see the availability of clients across devices. We used a Nexus 7 to demo the Instant upload capabilities for photos, which quickly appeared on the web interface and the desktop folder.
The feedback from existing users overall was very positive, and many were pleased to see the advances ownCloud had made in its evolution. We also discussed sharing questions with users and even managed to do some live debugging, the result of which will soon show up in the next release of the Desktop client.
Me in front of the booth.This years installment of Chemnitzer Linux-Tage was a fun event, not only because of the fantastic show and dinner buffet on Saturday night, but also due to the family atmosphere, and the fun that it was to present ownCloud, but also openSUSE and Klaas’ very own Kraft project.
If you want to meet us again, visit the ownCloud booth at LinuxTag in Berlin from 22.-25. of May.
Arthur giving his overview of oC 5.0 features.On Friday evening, more than 50 people followed the summoning to C-Base in Berlin in order to celebrate the ownCloud 5.0 release, learn about new features and getting to meet some of its makers.
ownCloud server engineer Arthur Schiwon kicked off the talk series with an overview of ownCloud 5.0 features. Only a few minutes after he started, we had to interrupt the talk – the room had gotten too croweded, so we removed some of the desks and sqeezed in another two rows of chairs.
A packed room listens to the talks.Next up was Sam Tuke. He outlined the new encryption system and detailed on how it works with sharing, something the old sharing module fell short at.
After Sam had taken a lot of question from a very interested audience, it was about time for some fresh air and a slice of pizza, kindly sponsored by ownCloud Inc.
Sam talking about the upcoming encryptiion system.After all pizza slices were gone, I concluded the series of talks presenting the ownCloud clients for Android, iOS and Desktop, detailing on new features in the next versions, followed by lots of questions from the audience.
Discussions after the talks lasted past midnight. Finally the three of us as well as Georg Ehrke of Calendar and Contacts fame, who had joined in later, engaged in busy group discusions with the visitors. This way we got to talk face to face with enthusiastic fans, new users and (soon to be) new contributors.
Thanks everyone for joining in. It was an awesome night!
It is is dead Jim: The Raspberry Pi’s cheap SD card reader does not cope well with the leverage effect.A weak spot of the Raspberry Pi board in terms of physical robustness is its SD Card reader: I made the mistake of carrying the Pi around with an SD Card inside, and the leverage forces worked their magic. As a result, the readers plastic framework fractured, and the reader no longer embraced the card safely. This resulted in a behavior that can at best be described as unreliable.
So what should I do? Clearly I could reorder the SD card reader at one of the distributors, but it’s going to be expensive, and, more importantly, it’s going to be the same crappy reader that will most likely break again (unless your learn from your errors, which I rarely do). But the spare part itself is ridiculously expensive, some 6 Euros + shipping just for a spare part.
Provides our spare part: LogiLink Card ReaderCaveats: You should probably not try this as your first soldering project. Find help from someone with expertise.
Note that for simplicity, the new reader will ignore the read-only switch of the SD Card. The respective pads on the PCB will simply be shorted (If you want to go the extra mile, you can of course fix this properly). Also, not every card reader on the market is the same. Check how your reader is connected, and which pins serve which purpose.
Still with me? Well, luckily there is a cheap USB key card reader (affilate link) available which I aquired at at Amazon.de at 2.50 Euros, including shipping. Yes, it’s sad to deconstruct a completely working USB key because it’s cheaper than a spare part, but on the upside you gain a USB connector, an LED and a quartz crystal and a controller as free spare parts for your next projects.
Required Parts and Tools
Ready for unsoldering: uncoated card reader
USB Card reader
Tin-solder
Enamelled Wire
Soldering iron
Desoldering wick
Desoldering pump
Opt: Volt meter
Opt: Pliers
Opt: Wire
Opt: Hot-melt gun
The process
Unsolder new Card Reader from USB Reader
Open the USB keys’ plastic housing by inserting a screw driver into the card slot and turn it by 90 degrees. Once you have gotten hold of the PCB, unsolder the LED and the quartz crystal first – they are in the way. Finally, unsolder the reader pin by pin. Be careful: the pins loosen easily, and if they fall off, you will have to replace them with a piece of wire, which makes the process more difficult.
Unsolder old Card Reader from RPi
Using pliers to cut off the connectors close to the reader gave good results. Use desoldering techniques for proper separation if still required. The more pin wire is left on the board, the easier the resoldering will be.
Resolder new Card Reader to RPi
The SD Card Reader on the Pi is connected via SPI. The general mapping of an SD Card to the SPI can be deduced from pin mapping at Wikipedia. The mapping of the pins remains the same with our chosen reader. However, there are four more pins as you can see from the close up on the right.
Old reader with pin mapping (brand-new Pi board).
As you can see, there are thirteen pins, but there are only nine connectors on the card. We need extra pins for detecting if a card is actually inserted (located on the pins to the right) and another to check if the card is notched (i.e. write-protected, located on the left).
Now we need to map the pin layouts to the new card reader. On our case, the pin mappings are identical. However, the new reader only has eleven pins, but we will be fine – just find the two additional data pins, which set themselves apart from the rest of the pins in height — both are located on the right hand side of the new reader (see the top most picture). The left one is the one you want to solder to to any of the ground pins using the the enamelled wire — we chose the second from the left. Finally, shorten the two left-most contacts pins on the PCB to signal the PI that the card is always on read-write (again, you can easily fix this yourself if you really want your OS to reside on a read-only card).
The result
Raspberry Pi with new, more sturdy SD Card reader. The old reader module and the unsoldered USB key PCB still in the background.
Making it rock-solid
Use some solder to fixiate the reader on the sides, even though the card reader might not have extra spots to hold the solder tin. It will most likely still work. If you want to make sure your reader is really well-tied to the PCB, use a hot-melt gun and put some glue onto the new wiring (check if it works first, there is no going back!), as well as on the sides.
Credits
The project was suggested by and conducted with the invaluable help of @d3rp3t3r.
ownCloud 5 is about to be released – an event that cannot go uncelebrated. Joining events in Nürnberg and Stuttgart, we will have an event for everyone who happens to live in or nearby Berlin and shares an interest in ownCloud. Even though it’s on short notice, make sure to save the date:
We will give an introduction to ownCloud and its concepts, show off new features in ownCloud 5.0 and give some insight into the syncing clients. And yes, there will also be Pizza, sponsored by ownCloud Inc!
If you want to come, please add a comment below to make planning easier. See you there next Friday!
Bjoern and I attended FrOSCon, the Free and Open Software Conference, a major FOSS-Event in Germany, which took place August 25th and 26th.
Icons going native
Today, along with the server updates, we have released ownCloud Client 1.2.3. This release will continue working users of the 4.5 series. Clearly the most important and single-most annoying bug this release addresses is the creation of illegitimate conflict files. This can happen due to several reasons. Lately, it has been reported due to a regression in 5.0.0 (which was fixed in 5.0.3). We now compare the files for equality, which avoids illegitimate conflict files on the client side.
Friday, 15.03.2013, 19:00h