Choose a base image

[jospoortvliet]

We need to pick a single image to build on. There are several options right now:

• Debian https://github.com/owncloud/pi-image/issues/14
• Ubuntu
• Ubuntu Snappy https://github.com/owncloud/pi-image/issues/13
• openSUSE
• openWRT https://github.com/owncloud/pi-image/issues/16
• ?

(add your own).

Let's have a look at the various options and come with pro's and con's. Note that we're not going for perfection but something we can make work AND from somebody who can put in the work to keep it working. So if, say, theoretically Arch is the best but the Ubuntu image has more people with knowledge of and working on it, it is probably best to go with Ubuntu.

Please add your pro's and con's to the respective issues.

[Offerel]

At this time i use Arch Linux. But i think this is not the right Distribution for a Project like PiDrive but its ideal for others. Its not that good since its a Rolling Release Cycle. This makes it difficult to manage Updates automatically. For the Pi i would prefer Ubuntu Snappy, because it has the stability of Debian (mostly), a big Community (like Core Ubuntu) and is small enough for a good performance.

[jospoortvliet]

@Offerel yeah, I am also very charmed by the Ubuntu Snappy option. I think it is the right choice for what we're trying to do, even though I'm more of an openSUSE person...

[miska]

Well, I think for most parts it doesn't matter as target audience will probably not touch the system. From my experience, Debian (and thus Ubuntu) have tighter package integration so they can mess up with the setup we create more and I found their packaging confusing and unnecessary complicated, so if it will be Debian, I will not help with any packaging :-)

[JKawohl]

IMHO i would prefer the ubuntu based image. It simply has the biggest community out there and is well documented, i'll be glad helping with the packaging ;-) .

[tflidd]

I used Raspbian/Minibian 8 on my raspberry pi 2 (my own one) to install owncloud 8.2 for testing purposes. It went quite well, I could use all standard-packages (not like Ubuntu 14.04 with broken version of the caching modules).

I had the idea to install the system on the SD card and to put all important data on the hard disk (owncloud data, owncloud database and basic system settings). When your SD card dies, you want to update your system, or even change the operating system, you just get a new SD card, copy an image to it. Once you boot it, the original network settings are restored and you can continue to use owncloud.

[miska]

I used openSUSE on my Cubieboard, RaspberryPi 1 and Banana Pi and everything worked for me as well and my idea about booting PiDrive in on planet ownCloud :-)

http://michal.hrusecky.net/2016/01/my-way-of-booting-pidrive-raspberry-pi2/

Although I admit I haven't used distribution packages for ownCloud deployement on my other boards, used git directly.

[cryptworks]

Well to pull a line from Ubuntu snappy "Snappy apps and Ubuntu Core itself can be upgraded atomically and rolled back if needed"

It looks like Snappy is really designed specifically for this sort of build, even more so than a number of other distributions. I know there are a number of distributions that have slim builds by nature, and there are other distributions that have a slim build. But ubuntu seems to be really embracing the core that that IOT-Owncloud project really seems to need. (and besides the option of a customer being able to buy extended support is never a bad thing)

Snappy Pro's

• Ease of core image installation (ubuntu/win/mac) -> https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/

[oparoz]

What about OpenWRT?

• It's designed for embedded systems
• Comes with all the networking software you need for remote configuration and access and would also provide standard protection for people willing to connect their box to the Internet
• Has packages for most of what we need (haven't made a definitive list)
• Has a flexible image builder which would let us add missing packages
• Has some documentation on how to install ownCloud

The fact that it's designed for remote management is a big plus imho. It should be less work to build and especially maintain everything we need.

If not, since Clear Linux (probably doesn't work on Arm) and Sansdstorm (x86 only) are not available, I think Snappy would be a good option, but I don't have any experience with Suse.

[atsarajev]

I am in favor of Tiny Core Linux (http://tinycorelinux.net/) for it's speed as well as ready made images for the Raspberry Pi. The downside being the lack of an easy package upgrade mechanism.

The thing I currently have troubles with is actually getting it to boot with BerryBoot. Can someone point to a detailed tutorial on this? I have looked at http://www.berryterminal.com/doku.php/berryboot/adding_custom_distributions but maybe someone has a better detailed post somewhere. I also took a look at a post by @miska but it doesn't go into much detail from what I could tell

[oparoz]

We need to pick a single image to build on.

@jospoortvliet - You're positive about that? With so many ideas and backgrounds in the "team", it might be worth considering adding the 3 best (most finished) solutions.

[cryptworks]

​that would depend on the end result. If this is to be a finished product that gets delivered in conjunction with WD as device or a proof of concept then we need to take a strong look at this from a business product standpoint.

so a single distribution is going to be somewhat important. As is some level of administration. If we can build in the scripts right it should be rather simple to do.​

On Wed, Jan 13, 2016 at 3:08 PM, Olivier Paroz notifications@github.com wrote:

We need to pick a single image to build on.

@jospoortvliet https://github.com/jospoortvliet - You're positive about that? With some many ideas and backgrounds in the "team", it might be worth considering adding the 3 best (most finished) solutions.

— Reply to this email directly or view it on GitHub https://github.com/owncloud/pi-image/issues/10#issuecomment-171452538.

A mouse trap, placed on top of your alarm clock, will prevent you from rolling over and going back to sleep after you hit the snooze button.

Stephen

[oparoz]

:-1: for Snappy

Note: the snappy update command will currently not work with Raspberry Pi 2 images. It requires hosting the device tarball on a system-image server, which is not yet available.

[enoch85]

@oparoz It works. Tried it myself.

@cryptworks

But ubuntu seems to be really embracing the core that that IOT-Owncloud project really seems to need. (and besides the option of a customer being able to buy extended support is never a bad thing)

As the maintainer, I could arrange something for that.

[oparoz]

@enoch85 - Might be worth shooting Ubuntu Org an email since that statement comes directly from the official doc.

[cryptworks]

https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/

I think this may be a case of one hand not talking to another.

On Thu, Jan 14, 2016 at 8:04 AM, Olivier Paroz notifications@github.com wrote:

@enoch85 https://github.com/enoch85 - Might be worth shooting Ubuntu Org an email since that statement comes directly from the official doc.

— Reply to this email directly or view it on GitHub https://github.com/owncloud/pi-image/issues/10#issuecomment-171666082.

A mouse trap, placed on top of your alarm clock, will prevent you from rolling over and going back to sleep after you hit the snooze button.

Stephen

[oparoz]

I think this may be a case of one hand not talking to another.

@cryptworks - I'm not so sure, but it could be that we don't need custom images

You might want to [build custom images] in those cases where want a different size, newer rootfs, pointing at a different channel, turning developer mode on, etc.

Also, I propose that each OS gets it's own issue, it will be way easier to try and match it with requirements and comment on strength and weaknesses.

[cryptworks]

I second this idea, once we get a feel for top contenders split in order to keep issues separate/unique to each build.

On Thu, Jan 14, 2016 at 10:43 AM, Olivier Paroz notifications@github.com wrote:

I think this may be a case of one hand not talking to another.

@cryptworks https://github.com/cryptworks - I'm not so sure, but it could be that we don't need custom images

You might want to [build custom images] in those cases where want a different size, newer rootfs, pointing at a different channel, turning developer mode on, etc.

Also, I propose that each OS gets it's own issue, it will be way easier to try and match it with requirements and comments on strength and weaknesses.

— Reply to this email directly or view it on GitHub https://github.com/owncloud/pi-image/issues/10#issuecomment-171719326.

A mouse trap, placed on top of your alarm clock, will prevent you from rolling over and going back to sleep after you hit the snooze button.

Stephen

[oparoz]

• The image has been ported to our new u-boot handling which now finally makes ubuntu-core rootfs updates (and rollback) possible. Note that neither the kernel nor the oem part can be updated on not fully supported images (i.e. not using the mainline kernel). This should still be a massive improvement for everyone using the Pi image though.

https://lists.ubuntu.com/archives/snappy-devel/2015-August/001005.html

[enoch85]

@oparoz Idk about the Raspberry PI image, only tried it once - and when I did, I didn't experience any issues.

Thing is, we (me and @kyrofa) are not using the Pi image, we develop a separate ownCloud-snap. And as he is a Ubuntu Dev, I think things will be sorted. :)

You can find the ongoing work here. You are very welcome to contribute.

[cryptworks]

Thats classy... will have to try this later.

On Thu, Jan 14, 2016 at 1:27 PM, Daniel Hansson notifications@github.com wrote:

@oparoz https://github.com/oparoz Idk about the Raspberry PI image, only tried it once - and when I did, I didn't experience any issues.

Thing is, we (me and @kyrofa https://github.com/kyrofa) are not using the Pi image, we develop a separate ownCloud-snap. And as he is a Ubuntu Dev, I think things will be sorted. :)

You can find the ongoing work here https://github.com/kyrofa/owncloud-snap.

— Reply to this email directly or view it on GitHub https://github.com/owncloud/pi-image/issues/10#issuecomment-171770111.

A mouse trap, placed on top of your alarm clock, will prevent you from rolling over and going back to sleep after you hit the snooze button.

Stephen

[oparoz]

@enoch85 - Snaps live on top of core, which is an unstable Pi2 image (from what I gathered by reading the devel mailing list). Core can't be easily updated since apparently a full flash is required to upgrade the kernel and I don't think there is a GUI for that for users. As exciting as the project is, I feel it's too young for a commercial endeavour targeting people who can't use the terminal. Great for enthusiasts though :). Things may change with 16.04, but that will be released too late.

[enoch85]

@oparoz I hear what you say. I still feel that Snappy is the way to go on this. Right now the updates come via snappy update along with everything else.

And yes, there will be changes on 16.04 according to @kyrofa.

[oparoz]

Yes, I've seen that in the doc, but as mentioned earlier, that doesn't work for Pi2 (for kernel and oem) and so users will be stuck. Not a problem for people buying a Pi2 and tinkering with it, but I see one for someone who is buying an off-the-shelf, easy-to-use cloud solution without really knowing what's inside.

[tflidd]

What about FreeBSD? It is supposed to have good performance -> http://raspbsd.org/ OpenWRT sounds interesting.

[oparoz]

What about FreeBSD?

That image is also unstable (based on 11-current). If the raspbsd.org maintainer of these images is doing a good job and only releasing a few of them a year, then it could be an option, but I read the forums and mailing list and it seems best to wait for the official release :( The other problem, of course, is that not many people team members know how to use, let alone configure it.

[enoch85]

@oparoz What is there to configure of everything comes pre-configured? Or are we not talking the same language here? :S

[oparoz]

@enoch85 - We're not :D. I'm talking about people in here who have been tasked to build a user-friendly image to ship with the system :)

[enoch85]

@oparoz Let's just see the end result of all this. I have faith in Snappy. :)

[oparoz]

It's not for me to decide and not many people have voiced their opinion or built a case for their OS yet, so we'll see. I'm just not a fan of putting newbies on alpha software built by a team who mostly have never used it before and hoping for the best, but it's a community project, not one run by inc, so maybe org and wd will green light that proposition:). Just to be clear, I like the concept and the fact that there is at least 3-4 of you willing to back Snappy! I'm just worried for end users in the long term and I'd like WD to succeed and sell more than 500 devices.

I think anyway that starting with the OS is not the right approach, we're missing a full list of agreed functional requirements. We do have some non-functional ones provided by @jospoortvliet and some proposal went in depth describing the stack we should use, but no agreement and already bits and pieces that may not fit together (snaps don't run on OpenSuse, etc.)

[enoch85]

@oparoz We think the same way. I also want this to be bigger than 500 devices, I'm also concernd about an easy setup for the end user (that's why I started building VMs in the first place), I also think about the aspects you bring up. But in the end, everything can be solved and nothing is impossible. Yes, Snappy is new, yes there are some issues - but what I mean is, wait for the end result before you draw any conclusions. I look forward to see the best possible soulution. Maybe Snappy isn't, but I will put my effort into that it will be. I'm happy with anything else as well. Just to be clear. :D

[piggz]

                                                                                                                                                                                                                                                                                                                                                                                                                          Sent from my BlackBerry 10 smartphone.                                                                                                                                                                                                                From: Olivier ParozSent: Thursday, 14 January 2016 9:48 PM‎To: owncloud/pi-imageReply To: owncloud/pi-imageSubject: Re: [pi-image] Choose a base image (#10)Yes, I've seen that in the doc, but as mentioned earlier, that doesn't work for Pi2 (for kernel and oem) and so users will be stuck. Not a problem for people buying a Pi2 and tinkering with it, but I see one for someone who is buying an off-the-shelf, easy-to-use cloud solution without really knowing what's inside.

—Reply to this email directly or view it on GitHub.

[cmacq2]

Well as for:

Debian

Pros:

• It's got a proper upstream community behind it, not just the one maintainer or two or a small team. This could be somewhat important for 3rd parties who want to build a product.
• Proper infrastructure tools exist for hosting a repository, signing packages/code etc. etc. Tools like reprepro don't just handle "serving packages to clients", they also handle things like importing from upstream repositories, handling lots of packages efficiently and so on. The tools are mature and fairly well understood and documented. This could be somewhat important if you want 3rd parties to build a product on top of whatever we do: the 3rd party must have a fair chance maintaining said infrastructure on their own.
• Related there are also 'bootstrapping' tools to generate Debian rootfs hierarchies from scratch or to perform automated installations.
• Debian has 'form' on numerous architectures. See also: Raspbian.
• Users would be able to take advantage of all the community love and effort poured into Raspbian as it is almost 1:1 transferable to Debian.
• Debian admin tools and Debian style package management. This makes it feasible for a motivated user to actually admin the box on their own.
• Related, Debian does a lot of the hard work on all sorts of process and engineering features like 'reproducible builds' for example.
• Without having to set up any complicated build tool chains.
• (These tools are also fully free software.)
• Combined with the community's strong focus on software freedom, this means you are able to do things like download your OS updates over TOR from a TOR hidden service.
• Existing efforts to do conceptually closely aligned or very similar things with Debian exist: e.g. freedombox.

Cons:

• Default Debian packages of owncloud are ... old. Counter: but owncloud already provides custom Debian packages which we could rebuild for armhf (if not available for armhf) and use instead.
• Compared to something like buildroot/dd-wrt/yocto: rootfs will probably be bigger in size. Counter 'advantage'. that also means it is a lot easier to work with and in the case of some of those: easier on your long term sanity prospects as well.
• Compared to something like snappy or os-tree: updates are not fully atomic and it's probably not quite as easy to admin/use. Counter: snappy et. al. achieve this by making some other trade-offs, notably what the sysadmin (i.e user) actually can do on the system/disk. Also: it is developed in the context of Ubuntu which means Canonical which implies legal shenanigans or at least uncertainty if you want to take it to market as a commercial product.
• Compared to OpenSUSE: ???

Summary

Debian is a good choice from user freedom, and 'proven' technology perspectives. Debian is not necessarily the most exciting or most 'customisable' technology choice, but more of a solid middle road that has been proven to work on the R.Pi/R.Pi2 formfactors (Raspbian) with a live and vibrant community behind it that is not just a small 'in-crowd' of developers working on their pet tech.

Debian can also readily be turned into a product by 3rd parties that they can maintain and support themselves. Tools and documentation for the necessary infrastructure, processes and policy exist and have been used in anger before.

I think we do need to keep the purpose of the project in mind as prototype for what may be turned into a product by some 3rd party. (At least that is how I understood the original owncloud blog post/pitch.) So we should consider how usable our choice is for a downstream, possibly a commercial entity.

Alternatives

Without a doubt the most interesting alternative from a technology perspective would be Snappy. Such a shame about Canonical's tendency to muddle the legal waters with their unhelpful behaviour, really.

Picking something like OpenSUSE means picking conceptually much the same, only possibly less awesome (in my subjective opinion, I may very well turn out to be wrong if someone cares to champion OpenSUSE vigorously).

Picking something like buildroot/dd-wrt/yocto seems a lot of pain for little gain compared to Debian and loss of valuable functionality in the process (speaking as someone who has used both buildroot and yocto in the past). I might well be wrong when it comes to dd-wrt, I just haven't seen an convincing case being made for it yet in this issue.

[oparoz]

I've updated the OP and created 2 new base OS issues so that each one can be easily discussed.

[oparoz]

Also, picking an OS doesn't mean that the other projects are going to die. Enthusiasts are probably going to come to the official blog and see that there are 4-5 images they can use, some automatically connecting to outside services, etc.

[LEDfan]

Don't forget the EOL of a distro. What should happen if a distro becomes EOL, should the user flash a new image, should the distro be updated etc.

• Debian squeze was released February 2011 and is supported until feb 2016. The EOL of Jessie isn't yet available. It was released in April 2015, so let's say it's supported until 2020.
• Centos 7 is supported with "full updates" until Q4 2020 and with "maintenance updates" until June 2024. So that's from now +-8 years.

Of course this problem will maybe be solved by it self over time. What would the lifetime of the RPI?

[oparoz]

@LEDfan - Rasbian is base on Jessie, so no problem there :). There is even a Lite version:

https://www.raspberrypi.org/downloads/raspbian/

[oparoz]

Ubuntu Snappy has been selected, so closing this.