What's Holding ownCloud Back?

In the recent article about the ownCloud event program, I pointed out that while ownCloud has 2.5 million users, it is a drop in the ocean looking at the number of Internet users (a little over 4 billion today). The announcement of the "Let's Encrypt" initiative from the Electronic Frontier Foundation, Mozilla and others prompted me to write this: it is one step in the direction of removing the limitations holding back wider ownCloud adoption. What does the future hold?

Easy ownCloud

As Frank pointed out in his blog on the future of PHP, ownCloud has ease of use as an explicit and very important goal. And while the technological choices made aren't always so exciting and bleeding edge, they do result in ownCloud being very easy to deploy on a very wide range of devices. Plenty of tutorials exist showing it running on everything from Rasberry Pi devices to big iron at organizations like CERN, where physicists looking for the origins of the universe are routing hundreds of terrabytes of data through their CernBOX build on ownCloud, sharing and collaborating on the data analysis.

Limitations

Unfortunately, there are limitations outside of what ownCloud can directly control.

In the database area, SQLite is default because it requires no manual setup whatsoever. But performance suffers when an installation has more than a trivial amount of data. When sharing with more than 15 users or indexing your mp3 connection, SQLite usage leads to frequent time-outs and other issues!

Another, more serious issue, is the architecture of the current internet. Most users are set up at home behind a firewall provided by their internet router. While this provides some additional security, it is mainly because the limited number of unique addresses available in the still widely-used 'IPv4' protocol. It simply is impossible to assign a unique address to each device connected to your internet at home. But this means your server will not be reachable when you're not home, unless you adjust some settings on your router. While we can configure some routers automatically, most we can't and as every router is different, an easy 'generic' how-to can't be provided either.

A third issue is that an ideal ownCloud platform would be small and cheap devices like the Raspberry Pi, but these are almost all based on 32bit CPU's. Due to technical limitations in the platform ownCloud builds on, this means you won't be able to have it handle files bigger than about 4 gigabyte! That is a big limitation if you'd like to store your virtual machine or Blue Ray collection on your ownCloud.

The fourth issue I see is security. While not the biggest problem of the three, setting up a server to be secure, including a decent SSL certificate, is not easy. I personally couldn't figure it out and while I'm new to server things, I am not a technology hater by any means. My parents wouldn't ever be able to figure it out and more importantly, they wouldn't want to!

Solutions

These four issues to wider ownCloud adoption aren't the only ones, but as far as I can tell, the biggest. So how do we deal with it?

There are several routes to an even easier ownCloud installation. Having a pre-setup operating system in the form of a container (Docker?) or a virtual machine can take care of much of the trouble around database setup and help a lot with the security issue. However, it can't run on light hardware like a Raspberry Pi and doesn't deal with the file size problem.

When it comes to the address limitations, the internet is slowly transitioning to IPv6 which will provide more unique addresses for each person than IPv4 offered in total (see here how Google explains IPv6). So, essentially, we just have to wait for this problem to be solved.

The hardware problem is also working on solving itself: the upcoming new swath of ARM CPU's (and Intel CPU's targeting the embedded market) are fully 64 capable so while current-gen Raspberry Pi devices (and other embedded devices like routers!) aren't perfect for ownCloud, a year from now many new devices will be perfectly capable of providing a great ownCloud experience.

The Electronic Frontier Foundation's "Let's Encrypt" initiative offers a (partial) solution for the security issue. Without it, a pre-configured ownCloud system will most likely be set up to use a self-signed certificate. While secure in principle, it always warns visitors of the self-signed state and thus isn't ideal. Let's Encrypt provides an automated and more importantly free (in terms of cost) solution for this.

And now

While I'd love for all these changes to be implemented yesterday, in reality we simply have to wait for the transitioning to IPv6 and 64bit CPU's. In the mean time, we can already start working on integrating Let's Encrypt into virtual machine and Docker images with a pre-configured MySQL (or MariaDB) and perhaps recommend people to run them on a 64bit capable system like a modern NAS or a NUC. The ownCloud-in-a-Box image on SUSE Studio is a great start!

Meanwhile, getting ownCloud ready to run on a wider range of devices and perform a wider range of 'cloudy' functions like running as backend of the Chromebook devices (see this page and ping me if you want to get involved) should be on the agenda as well. I personally look forward to more 'social' integration in ownCloud, like the ability to comment on images or other data and share these with the people you share files with. We're on it, tags sharing is integrated for ownCloud 8 and a generic metadata repo was created (empty still). Get involved if you can!

Obviously, telling people about ownCloud is still important - which is what the ownCloud event program is all about - and help is welcome. Go to owncloud.org/promote and share the love!

5 steps to organizing a meetup

For both beginners and pros a meetup around a subject can be a great resource. It's a wonderful opportunity to ask questions, share ideas, practice or work on things together and and of course meet new and interesting people.

Most people think organizing a meetup is a big deal, that you need to know a lot about the subject at hand and so on. This is most certainly not the case, and to illustrate that, let me simply share 5 simple steps to go through to organize a meetup.

1. Have a goal or subject

Of course, you have some idea of what the meetup should be about. Make it a bit more concrete: come up with some questions you'd like to get answers to, some things you find difficult, strange or simply interesting. This will form the basis under your meetup! Especially for a first meetup, a concrete thing-to-discuss helps both attract people and makes it easy on the spot to have a satisfying conversation.

A speaker isn't mandatory but it can be helpful if you find somebody who can introduce the subject, or do a little demo of the product/technology you are here for. Of course, you can easily do this yourself. It is no problem if you don't know the subject through and through, the others in the audience will certainly point out what else there is. You're certain to learn something new, and so will the others!

2. Pick a date, time and location

The practical things, then:

• find a venue!
  
  Small is OK, you don't have to start big. A meeting room at the company you work forspace, universities and schools often have space and a café or restaurant isn't a bad option either.
• pick a time after work. 7-9PM works usually fine.
  
  Friday nights are great for a release party or such but for regular meetups, a weekday is often better.
• Make sure you have coffee, tea and perhaps cake.
  
  Don't bother with anything more complicated - you can always ask if people want to order food and arrange that on the spot. You can even ask people to bring something to drink or snack!

3. Find participants

The key to your meetup is simple: interest in something. For sure, there are others who feel the same and you just have to find them! Certainly you already know some people, and by looking for more you can grow a little address book of people to invite. Ask the people you already know to look for others! Other tricks include looking on social media, searching for similar groups and inviting people there.

Set up a facebook and/or google event page, maybe a blog and/or mailing list (google groups!). If you organize a KDE, ownCloud or openSUSE event - each of these projects have informational pages, mailing lists and other communication channels that can help you promote your event. Just click the links!

Don't set the bar too high - a meetup with handful of participants already makes for a fine first meetup! But if suddenly 50 people RSVP, don't worry - it just means they will keep each other plenty busy and you don't have to worry about content.

4. Have the meetup!

When people come in, welcome them and get to know them a little. If you're like me, you'll forget names at once but it might help to let everybody introduce themselves and why they joined.

Then do the introduction of the subject and ask if people have something to say on it, or other things they would like to bring up. Now you might feel there is a risk nothing happens, but believe me: this just won't happen. Bringing people with a similar interest together is all that is needed for an interesting conversation! Once the evening starts rolling, you'll feel you have over-planned and over-worried for sure.

5. Keep it going

After the first meetup, you need a line of communication to keep it up and running. There are different options - meetup.com is one, another way is handling it by hand with a wiki, blog, mailing list or google groups. In all cases, it is smart to put ask visitors at the meetup to write down their mail addresses so you can inform them about future meetups!

Getting one or more people to help you out is a good idea, too. They bring in their own network of contacts and interests. But at this point, you're up and running! I've blogged earlier about building a local community with more tips and ideas and you can find some other tips on the ownCloud meetup pages as well.

Have a lot of fun!

Where is KDE 5 and when can I use it?

The vast majority of users, when talking about "using KDE", are talking about the desktop. Plasma, that is. So when you ask "when will KDE 5 be ready?", your answer will be that our brand new desktop is already at version 5.1 and making swift progress! Stability is quite good, but there's work to do in the feature area. Distributions don't ship it as default yet.

If you ask for 'official packages from my distribution', most distributions, including Fedora, openSUSE and Kubuntu, have had packages since 5.0. The just-released openSUSE 13.2 ships with Plasma 4.11 (the latest and last version in the stable 4 series) as default desktop but has Plasma 5.1 as option, next to GNOME Shell, XFCE and everything else. Kubuntu similarly released with Plasma 4.11 and a tech preview with Plasma 5.1 simultaneously. Both have KDE Applications 4.14.x, as there is no release of the Frameworks based apps yet. openSUSE offers a repo with newer apps but they're unstable as popcorn in an oven.

"when will this be default in distributions?" might be your next question. A good estimate is that by Plasma 5.4, to be released in the 2nd quarter next year, distributions will move over to the new series. Kubuntu has already announced they will ship Plasma as default desktop in 15.04 and I expect others with a similar or later release date to follow suit.

How ready is it?

While progress has been very fast and the team has been focusing on the end user experience, there still are glitches and missing features. Many of the supporting apps and widgets are still being ported or optimized for the new environment. Klipper has seen awesome work by Martin Graßlin with help from the new KDE design team, work on KMix is in progress and things like HiDPI support aren't entirely fleshed out yet either.

I'd recommend moving over your work desktop or laptop for 5.4. Until then, help test and improve it to make sure it is ready for you! Use the experimental packages for openSUSE or Kubuntu for testing, or build your own. This is a good time to get involved as there are plenty of relatively simple yet very impact-full tasks waiting for volunteers!

What is KDE 5 and why do you call it 'Plasma'?

To talk about something you have to define it, and I realize that that is a a bit more complicated than it used to be. In July I blogged about the disappearance of the 'software compilation'. That term was introduced after we re-branded KDE to no longer be the product we made, but the people who made it.

To understand the relation, compare KDE to another organization which creates (among other things) software: Microsoft. Like KDE, they create products and technologies like Office (KDE makes Calligra), Windows (KDE develops Plasma), .NET (KDE releases Frameworks), C# (KDE uses C++). Nobody confuses Microsoft Office with Microsoft 8.1 so this should be easy enough, I hope!

Why the change?

We used to release our desktop, applications and libraries at once, the KDE releases. Unfortunately that created two problems:

• It confused many users about what was needed to run KDE applications. Could you only run Amarok in KDE? Did you have to install all of KDE to use Krita? For advanced users, these are simple to answer, but on user forums they kept coming up and you'd hear users at conferences tell you they never tried Krita because they did not like KDE (meaning the desktop).
• The KDE 4.0 release had been a disaster in part because we released all its components at the same time, while not all were of the same quality. Many of the applications had been ported almost a year before and were quite mature, while especially Plasma, the desktop, had undergone a serious rewrite and simply wasn't ready.

To deal with these two issues, we changed the meaning of "KDE" to be the people in our community and started talking about the separate products as what we released. That was still all released at once, so most users continued to talk about KDE 4.x

Today things are different. While the libraries (KDE Frameworks) are currently at version 5.4 (released monthly), Plasma is at 5.2 (released every 3 months) and the KDE Applications are at 4.14. The latter will release soon with a date-based name, as it is build on a mix of the 4.x series and the 5.x series of our libraries so a common version number just doesn't work.

Here's a view of how it all fits together:

What goes with what?

You might ask next: "what version of what goes with what?" - a fair question. Luckily, the distributions will mostly deal with these dependency questions for you!

Still, if you want, here is an overview of how the relations currently are.

Frameworks releases monthly, combining bug fixes and (small) features. You can use the latest, stability is very important for the Frameworks team and it should be perfectly safe. Of course, this introduces a bit of an issue for distributions, which often don't want to mix feature- and bugfix releases. I'm not sure how they will deal with this. The backwards compatibility of Frameworks should allow updating them like bug fixes, but we'll have to see who does what.

Plasma releases every 3 months and usually depends on the latest or latest -1 version of Frameworks at release time. It will work just fine with versions newer than what it depends on as minimum.

Applications is still in the 4.x series, but many applications are already ported to Frameworks and the first release (14.12) will come next month. The numbering will be year.month, so if the next release comes 4 months later, it will be 15.4. They, too, will probably require latest or latest -1 version of Frameworks when released.

As of today, most distributions stick with the latest version of Plasma in the 4.x series (that is 4.11) and the latest version of KDELibs in the 4.x series, 4.14 (technically 4.9 but the numbers have been kept in line with Applications to keep things simpler).

Bringing it all together:

if you want a stable system, stay on Plasma 4.11 with KDELibs and Applications 4.14 for now. If you want to try out the new tech, try Plasma 5.2, which depends on Frameworks 5.3. With Applications 4.14 - no newer release is out yet, but openSUSE offers regular git checkouts and they have been working quite well for me personally. Find instructions here.

Note:
The 4.x series has already been split up. If you run "KDE 4.14", you don't. The last official Platform release is 4.9 and Plasma is at 4.11. Only the applications have continued to release, and speeding up their release cycle, while the Platform has seen increasing version numbers to keep packaging easy.

openSUSE 13.2 out: PARTY time!

It's the 5th of November, a date the Brits are told to remember - for me, it is the day after openSUSE 13.2 was released! It's a kickin' release, good reason for a release party tonight at the Belug in Berlin.

13.2

End users will probably notice the revamped YaST most during installation, but the integration of functionality like snapper, Dracut and Wicked is also quite significant. With Snapper, you can roll back upgrades of your system, configuration changes and so on - and if an upgrade made the system unbootable, you just boot from an older version. I haven't seen it in action yet, as unfortunately my btrfs filesystem broke just a week ago - which is of course the one thing snapper can't fix. Yes, bug is fixed, but annoying.

Dracut 'just' leads to faster booting, I've been playing with it on my laptop for a while and it is cool that it made it in now. And yes, 5 second boot is realistic, my new desktop at work does that easily. It also reduces the huge scripted mess that the old mkinitrd system was with something distributions can work together on - that is a good thing in itself, I like collaboration.

I can't say anything smart about Wicked, to be honest. It's network management, but where it fits and what it does exactly somebody else would have to explain in normal-human-terms ;-)

Of course there's much more, including the latest kernel, GNOME, KDE and 5 more desktops (including a preview of Plasma 5.1!), the best selection of what Free Software has to offer and so on. Find a nice overview of openSUSE 13.2 on the info page.

party time

The Party part is easy to explain. The Berlin LUG (BeLUG) has offered their place as party space tonight, I'll give a quick intro into what is new in this release, we'll have some time for debate and then it's all up for grabs. The BeLUGgers promised there would be beer, so what can go wrong?

See you at:
Belug e.V.
Lehrter Straße 53
10557 Berlin
Be there at 18:00 for some informative fun and a beer!

If you aren't in Berlin, check if there is a release party close to you or organize one yourself!