LWN: Comments on "ownCloud 7 released"

ownCloud 7 released

jospoortvliet — Mon, 28 Jul 2014 20:40:40 +0000

I agree, hence I said to collaborate. The distributions tend to build their own little silos, as unproductive as the lack of regard of software writers for 'the whole'. Hence both models suck. OBS (cgithub for packaging') seems in an unique position to (help) fix this. Far better than the bloated docket future you fear, indeed.

ownCloud 7 released

jospoortvliet — Mon, 28 Jul 2014 20:37:18 +0000

While I think it is scary to rely on distributions to support software long after the original project stopped doing that, you have a fair point and it is why I suggested distros COLLABORATE through obs, both with upstream and each other. Which is indeed possible - one can build for multiple distributions from one source in OBs, which is what ownCloud does.

ownCloud 7 released

sjj — Mon, 28 Jul 2014 18:20:34 +0000

>> It ensures the latest packages by the people who actually MADE the software.

In my experience, people who are themselves mainly developers think this is a good idea, whereas sysadmins and other operations people recoil in horror. Developers do not naturally think how their application fits into the larger scheme. They are focused on getting the feature or fix they are working right *now* out so they can close that ticket. There is nothing wrong with this as such, if the developer at least realizes that other people do not share her or his priorities.

I'm kind of worried that Docker will lead to javaization of all software. Meaning every application ships with all the libraries it ever needs, but never bothers to keep those updated except when pulling in a pre-release version because of shiny new features... I have seen version control in enterprises up close and personal, and something like 80%(*) of the bits in big enterprise version control systems are copies of JDK from three years ago and Tomcat.

(*) see, Wild A Guess Statistics, Inc, 2014.

ownCloud 7 released

ballombe — Mon, 28 Jul 2014 12:20:37 +0000

> If a Debian system moves packages between repositories by default and without any warning on a normal update, something is wrong and Debian/APT developers need to re-think what they are doing...

See apt_preferences(5)

> I can do "zypper refresh && zypper update" for years without any of that, even when I have the typical (for openSUSE users) 15+ repositories.

Typical Debian users have 2 repositories.

ownCloud 7 released

amck — Mon, 28 Jul 2014 11:26:53 +0000

It ensures the latest packages by the people who actually MADE the software.

If in six months or a years time my ownCloud installation gets hit by the next generation of HeartBleed in SSL or some other library, who takes responsibility for fixing it? in 0 days?

This is one of the important features of distros like Debian: a guarantee of a fix that works. I want a fix that works without change in ABI or functionality that I can swap into my existing operational setup, not a pointer by a random group to "use the latest version, its got the fix".

Secondly, who makes sure the pieces are interoperable? current DevOps work, where you take the application you are interested in + a bunch of "other stuff" and containerize it and think you don't need integration. However you depend on all those python libraries working on python3.4, not random older versions, that everything compiles with g++ 4.9 so you can use your new C++11 features in your app. Its the distros that do the work of systems integration that you unconsciously depend on.

ownCloud 7 released

callegar — Mon, 28 Jul 2014 09:14:44 +0000

It does not really make much difference IMHO.

The point is that if there is a name that is already in use, either you can have an identical or fully compatible semantics, or you should use another name.

The amount of semantic difference (the same package with different configuration or a completely different package) does not change the above consideration. Conversely, I would say that cases where the semantics is similar, but not to the point of providing compatibility are those where you should be most careful, since they can introduce subtle, hard to track issues.

ownCloud 7 released

callegar — Mon, 28 Jul 2014 09:09:54 +0000

Thanks for sharing this experience!

ownCloud 7 released

Otus — Mon, 28 Jul 2014 06:35:19 +0000

> If a Debian system moves packages between repositories by default and without any warning on a normal update, something is wrong and Debian/APT developers need to re-think what they are doing...

That's something that happens almost daily, and I definitely don't want to see extra noise about it. For example, a package from main gets replaced with a newer version from security which later gets replaced with one from updates.

ownCloud 7 released

lsl — Sun, 27 Jul 2014 19:20:28 +0000

> If a Debian system moves packages between repositories by default and without any warning on a normal update, something is wrong and Debian/APT developers need to re-think what they are doing... I can do "zypper refresh && zypper update" for years without any of that, even when I have the typical (for openSUSE users) 15+ repositories.

Then zypper is handling this stuff different than most of the package-managing world. On Fedora, yum behaves exactly like described for APT. So does pacman on Arch. On some of these distros this behaviour is even necessary considering their repo structure with separate repositories for shipping updates.

ownCloud 7 released

jospoortvliet — Sun, 27 Jul 2014 10:47:36 +0000

If a Debian system moves packages between repositories by default and without any warning on a normal update, something is wrong and Debian/APT developers need to re-think what they are doing... I can do "zypper refresh && zypper update" for years without any of that, even when I have the typical (for openSUSE users) 15+ repositories.

The way ownCloud builds packages for a wide variety of distributions on OBS has always seemed an excellent idea to me.

It ensures the latest packages by the people who actually MADE the software. Help from Debian maintainers to improve the packages, if they have ideas or suggestions, is of course more than welcome, OBS is a very nice and open system: they can simply fork the package, make changes and do a merge request.

Having upstream build packages for their users seems a superior way of distributing software. It will hopefully force distributions to get rid of some of the random, arbitrary and often downright silly differences, make them document, streamline and simplify the packaging guidelines and with some luck run their own OBS so they can work with the upstream projects on the results. OBS instances can be linked so everybody can be working comfortably on their own infrastructure, yet together.

Stop the balkanization of Linux, use the Open Build Service ;-)

ownCloud 7 released

ballombe — Fri, 25 Jul 2014 21:53:47 +0000

care to elaborate which standard is relevant here ?

ownCloud 7 released

tzafrir — Fri, 25 Jul 2014 13:59:05 +0000

http://packages.debian.org/docker.io
http://packages.ubuntu.com/docker.io

'docker' is a completely different package that predated docker.io:
System tray for KDE3/GNOME2 docklet applications.

ownCloud 7 released

niner — Fri, 25 Jul 2014 12:52:43 +0000

Well maybe, at some point in the future, Debian will decide to finally adhere to published standards and its users won't have this kind of problem anymore.

ownCloud 7 released

callegar — Fri, 25 Jul 2014 09:27:18 +0000

BTW, docker itself ships as a distribution package for ubuntu, debian, redhat, etc.

Furthermore, on debian/ubuntu, its deb package is called docker.io, precisely to avoid stomping on the 'docker' package shipped by debian/ubuntu, which would result in auto-upgrades back and forth and breakage.

Furthermore, some of the most popular items that are shipped as docker images are mini-images of popular distributions (ubuntu, redhat, etc.) that you internally upgrade using their own distribution packages, which evidently play a role in some environments.

ownCloud 7 released

callegar — Fri, 25 Jul 2014 09:21:22 +0000

Or, rather than updating the post install script, one could make a package that is compliant with the distribution guidelines in the first place.
Libreoffice does this, to mention one. This just works.

Or, one could make no package at all, and provide an installer that puts everything in /opt or in /usr/local and just creates symlinks to /var/www.
Mathematica and Matlab to this, to mention a couple of notable apps. This just works too.

Or, you could even make a package that is not fully compliant but that at least avoids taking the same name of a distribution package.
On debian derivatives, docker does this to mention one. Its package is named docker.io, to avoid stomping on the docker package shipped by debian/ubuntu.

ownCloud 7 released

Cyberax — Fri, 25 Jul 2014 09:17:57 +0000

We're using RPi to test that our stack works on ARM-based devices. We have a somewhat minimal bootstrap based on Raspbian with Docker-customized kernel and then we simply run our infrastructure on top of it. Sometimes it's a single application and sometimes a complex multi-container system.

Everything works fine, but obviously RPi is not known for its raw computing power. Also, RPi has a bit dated CPU so most of the software has to be compiled with RPi in mind or it won't work.

I also use a similar setup at home for Samba4+AirPlay+Assorted_Crap, so my migration from RPi to Cubietruck was extremely simple.

ownCloud 7 released

callegar — Fri, 25 Jul 2014 09:15:28 +0000

It is not exactly the same.

If I can choose whether to use distro packages or my own managed installation, that is fine, because the choice is made once forever.

Here the problem is that you have your own distro packages or other packages /with the same name/. Via standard upgrades you always have the risk of jumping back and forward from distro packages to other packages. Unless you play some trick like pinning on ubuntu/debian.

ownCloud 7 released

callegar — Fri, 25 Jul 2014 09:10:18 +0000

Nice. For a single app or on your system you have just a minimal bootstrap and all you run there is installed on independent docker images? Say firefox, apache, mysql, exim, pure-ftpd, gcc, runeaudio or some music player, python?

ownCloud 7 released

seneca6 — Thu, 24 Jul 2014 22:44:01 +0000

Isn't this just the typical story for (web) applications? At first install, you decide whether you use upstream sources or packages, or the distribution packages (or Docker images or whatever). Then you stick to updates through that channel, lest you care yourself about the migration.

So your suggestion only holds for people on Debian/Ubuntu that are using ownCloud through the distribution packages.

ownCloud 7 released

Cyberax — Thu, 24 Jul 2014 19:18:58 +0000

I've been using Docker on RPi. Works fine.

Event exceptions

ejr — Thu, 24 Jul 2014 16:34:49 +0000

These are the sticking point for interop. Major players don't handle EXDATE/EXRULE (either at all or just in the same way), and those really are insufficient for just changing a single instance of a recurring meeting. So ownCloud likely is just trying to work with the lowest common denominator.

This problem also kills migrating between calendar systems. Everyone gets to claim "interoperability by standards conformance" without ever interoperating in a way that might lose customers. I know I have to reschedule individual meetings frequently but cannot lose the general recurring pattern...

ownCloud 7 released

dowdle — Thu, 24 Jul 2014 16:30:08 +0000

I'm guessing this breaking could easily be solved by a few directory symlinks? And if so, a fairly simple update to the post-install/upgrade script could do the tiny bit of needed fix magic automatically.

ownCloud 7 released

callegar — Thu, 24 Jul 2014 14:37:30 +0000

I dare to disagree...

First of all you simply cannot run multiple entire OS images on resource constrained systems. Try that on a raspberry pi, for instance. OS images and distribution fit different needs and saying that one model is better than the other without reference to the environment unfortunately makes little sense, IMHO.

Secondly, the whole matter goes down to the desire to put something in common or not. Distributions try to put as much as possible in common (libraries and infrastructure) among their applications, in order to squeeze the best possible performance out of the system resources and maximize security (by relying on a single trusted version of each lib). Putting something in common necessarily implies some management overhead. The OS image philosophy puts nothing in common and replicates everything. In this way they minimize the management overhead but they pay a price in resource waste. It is not much different from living in a detached house or in a flat. In the first case you spend more, but you do not need to coordinate with anybody. Now, distros are nothing but a means to formalize how coordination should happen and to minimize the overhead inherent in sharing. Do they succeed? Some would say that to a sufficiently good extent they do. Could they do it better? Probably. Should they /all/ do it in /exactly/ the same way? This is not an important question, because it will simply not happen. Humans like to experiment their own way as long as they have the freedom to do so. In fact, even the OS image approach fails when you consider kernels and hypervisors that are not 'identical' in their interfaces.

Last, the issue with distros is probably that they are too similar, not too different. Since they are similar, everybody seems to think that if you respect Suse's guidelines the result will work on Red Hat. Conversely, since Windows and OSX are sufficiently different, no-one makes this mistake when developing for these two platform. The proof is that the mistake was made between Win95 and XP, at times with funny results. Reality is that distros provide guidelines that should be treated like APIs. When opening a file in posix, you would not pass the file path as the second parameter of 'open', because posix tells you it is the first. So, why when you develop for debian you fill it right to put config files in /var/www if debian policy tells you they should go in /etc? When you code, you do not call your function printf, because there is a printf already. So why when developing for debian, you make a package with the same name as a package that is already in debian but with a different 'semantic'? The real issue is that distro's guidelines are not strictly enforced. If they were, there would be no problem. And this is the reason why there are no issues with IOS. Either you respect the guidelines or your package cannot go in the store and be installed. Stop.

Here, the problem is that owncloud pretends to be building packages for debian, but in fact it does not respect the debian "contract" (APIs and guidelines). The real problem is that the result sorts of work, so it seems good enough. Until it fails bringing your data with it.

One more thing, for something important that I had forgotten before. Compliments to all the owncloud developers for the release and for the new great features!

ownCloud 7 released

torquay — Thu, 24 Jul 2014 11:38:05 +0000

This looks like a perfect example of how not to provide cross-distribution support.

Yes, but in a larger context this is also a perfect example that the entire idea of distros is broken. Kudos to owncloud for trying to tackle the fragmented Linux-based OS landscape by providing packages for many distros. The core fault with the resulting brokenness does not lie with owncloud, but the continuing lack of compatibility across various distros. In reality this makes the distros separate and distinct operating systems, where the only real commonality that can be relied upon is the kernel and glibc.

Seeing that the open source community has had this compatibility problem pretty much since year zero, I don't think the solution is to try to standardise on any particular set of packaging tools, or libraries, or APIs, or file system hierarchy, or whatever, but to simply acknowledge that we need to ship entire OS images (ala Docker) in order to ship applications.

ownCloud 7 released

callegar — Thu, 24 Jul 2014 11:08:37 +0000

I would like to suggest *not* to attempt an upgrade if you are on debian/ubuntu.

The owncloud sites says that there are fresh packages for all major distributions and points to http://software.opensuse.org/download/package?project=isv... since all packages are built on the opensuse factory.

The problem is that the owncloud debian/ubuntu packages shipped with the opensuse-factory are totally incompatible with the owncloud packages shipped by debian, while retaining the same name. They put everything in different places and probably they do not follow the debian guidelines in this regard.

As a consequence, when a system that had a debian/ubuntu shipped owncloud gets the opensuse owncloud repo listed in its apt lists, it happily upgrades to the opensuse version and it breaks (possibly causing the loss of all your owncloud data). At this point, even manually fixing the system is not enough. In fact, the day when debian/ubuntu decides to ship an owncloud package with a sufficiently high release version, your system will again nicely upgrade, breaking again. And when a new deb version is shipped on the opensuse this will happen again.

This looks like a perfect example of how not to provide cross-distribution support.

I think that either the deb packages on opensuse should be made truly compatible with the debian ones /or/ they should carry different names (owncloud-upstream? owncloud-suse?) and be marked as conflicting with the debian/ubuntu ones, in order to prevent going back and forward during upgrades.

ownCloud 7 released

The-Grue — Thu, 24 Jul 2014 07:55:56 +0000

I love ownCloud because it's the first time that I can easily and reliably sync data between my mobile phone and my own server. It really works great and until now I had no problems.

Of course, there's the grain of salt: I still can't set an exception to a series of calender entries. I have a few of them and it is really sad to add another calender entry that says "not today" instead of deleting this one instance. If ownCloud could do this, it would be perfect for me :)