Profile

Cover photo
Aaron Seigo
Works at Kolab Systems
6,197,548 views
AboutPostsPhotosYouTube

Stream

Aaron Seigo

Shared publicly  - 
 
At home with a cold today, but came across this fantastic summary/transcript of the talks at the Kolab Summit by Timotheus Pokorra.

Also, today is the Kolab Taster in Bern. Wish I could be there as they last ones have been awesome, but instead I am home wrapped in a blanket watching from afar.
Summary: Welcome, by Georg Greve. Georg welcomes everyone; 0:40 talks about the onsite live demo with a Power8 machine running Kolab; 1:55 describing talk from Aaron Seigo: “where we are technically and where things are going”; 2:15 welcoming Dr. Wolfgang Maier from IBM, Böblingen.
6
Add a comment...

Aaron Seigo

Shared publicly  - 
 
"We intend to ship Kube eventually on not only Linux, Windows and Mac, but also on mobile platforms like Android, so it is vital that we figure out blockers as early as possible, and keep the whole stack portable."

tl;dr on Kube: it is the KDE PIM-based groupware client being developed by Kolab Systems in coordination with the broader community. Compared to Kontact: it replaces Akonadi with Sink, a local store that focuses on simplicity, performance and correctness; it uses QML for the UI; has a laser-like focus on how people actually (want to) work, with an emphasis on "wonderful to use, easy to maintain" over "every possible feature you can think of thrown in"
I’m on my way back home from the cross-platform sprint in Randa. The four days of hacking, discussing and hiking that I spent there, allowed me to get a much clearer picture of how the cross-…
26
3
Olov McKie's profile photoAlex L.'s profile photoChristian Mollekopf's profile photoAaron Seigo's profile photo
14 comments
 
+Alex L. None; see my comment above to Olov.
Add a comment...

Aaron Seigo

Shared publicly  - 
 
More kolab taster porn, just before people began arriving. Right now we are upstairs learning about the Power hardware architecture and ecosystem.
 
All set up for the first Kolab Taster in Zürich. Ready to roll. 
3 comments on original post
14
2
Add a comment...

Aaron Seigo

Shared publicly  - 
 
A valid objection to a proposed solution is not a signal to surrender. It is valuable information: a new requirement you were not previously aware of. Now you can iterate again!

Keep faith that a solution is out there somewhere, and you can find it if you keep moving towards it. It may take time, but stopping that process prematurely is the all-to-common reason for unnecessary failure to achieve what you otherwise could.
13
1
Add a comment...

Aaron Seigo

Shared publicly  - 
 
Woo! Step by step ... it also means that we can make this available to Kolab Now users rather soon via the yet-to-be-officially-announced Beta program ..
 
I’m about to land erlang-18.3, from my home project, on to Winterfell. This enables, among other things, Guam to use the TLS SNI extension and serve Hosted Kolab deployments better. Please prepare for a rocky afternoon ;-)
View original post
6
Add a comment...

Aaron Seigo

Shared publicly  - 
 
Guam lands in Kolab's Winterfell repository, first stop on its way into both Kolab Enterprise 14 and Kolab 16 .. just in time for Kolab 16 to head towards commercial support (at which point it will replace Enterprise 14 for production deployments).
Filename, Size, Changed, Actions. debian.changelog, 0000000612612 Bytes, 14655491743 days ago, Download File · debian.control, 0000000649649 Bytes, 14577211783 months ago, Download File. debian.rules, 00000010761.05 KB, 14554603784 months ago, Download File · debian.series, 000000003838 Bytes ...
2
Add a comment...

Aaron Seigo

Shared publicly  - 
 
Going to drop off some train tickets to +Tomaz Canabrava​ who is landing in Zurich in a few minutes to attend the latest Randa event hosted by Mario, and also today I ran into Josef Spilner who I have not seen for years but who now lives nearby and is heading up a research group at Uni Zurich. Free software connects, and this world is so small...
9
Add a comment...

Aaron Seigo

Shared publicly  - 
 
Following the very successful Zurich edition, Kolab Taster opens up in Vienna today, celebrating the official opening of our corporate presence in Austria, and coming up soon after that is Bern, Switzerland. There are still spots available for Bern, grab them while you can!
Missed the Zurich Kolab Taster? No problem! You're still in time to get a Taste of Freedom at the Barbiére in downtown Berne. Come along on the 28th of June and get a taste of how Kolab, IBM and Red Hat can increase the efficiency and security of your collaboration framework, while at the same ...
11
2
Add a comment...

Aaron Seigo

Shared publicly  - 
 
Spent my after-dinner evening enjoying watching the Linux world do its usual incompetence-dance trying to figure out what it feels about Snap packages, which are suddenly being peddled hard .. just in time for the emergence of Flatpack into the Linux-communal-consciousness (coincidences!) ... with the usual mix of stupid and FUD that accompanies such things (sadly) ... none of it matters, though .. so I continued to wind down the evening with my daughter, building logic gates with transistors and bits of wire ... she loves plugging things together, watching LEDs light up, pushing the buttons to make things work ... way more important than which of the ridiculous post-modern packaging mistakes will "win".

p.s. in case nobody has noticed, software installation sucks horribly on both Microsoft Windows and Apple MacOS X .. so every time someone says "just like .." one of those two, look for your trout.
29
2
Thomas Pfeiffer's profile photoLogen Kain's profile photoprobono's profile photo
63 comments
probono
 
+Aaron Seigo Your questions were specifically about Flatpak but since #AppImage came up in the discussion I will try to answer them for AppImage since it is the system I am most familiar with. Apologies if this will take away a couple of minutes of LED blinking fun.

If you remember "Live systems", think of AppImages as "Live apps".

An AppImage is an ISO that contains an application and all the components it needs to run (e.g., libraries, icons, translations etc.) which cannot be expected to be part of the base system. There is a little executable ELF header embedded at the beginning of the ISO that loop-mounts the AppImage using FUSE and executes the payload app contained therein. Very common libraries that can be expected to be part of each target system are not bundled, less common libraries (yes, I mean you, Qt) are. By convention, an AppImage is supposed to have no other dependencies than the base system. The result is that AppImages are loosely coupled to the system, and that you can match and mix distributions and AppImages. AppImages are coupled with the OS as loosely as possible - one file equals one app, which makes it easy to "manage" apps by hand.

An AppImage also contains information on how to update "itself", i.e., where to check for new versions and download updates from. There is a binary delta updater that allows you to update from any given version by downloading only the bytes that actually have changed between the two versions. All of this is deliberately designed not to need any central infrastructure, but to enable upstrem projects to create and host the AppImages themselves.

With that, let's to your questions:

1) does it allow for first-class integration across applications, or does it result in app A not working with app B because they both depend on library C but different versions and as a flatpack you cant change that, and so no app<->app or app<->platform integrationfor you.

There are optional sandboxes that can be used with AppImage, but per se I can't see anything that would be preventing apps from working with each other or the system, even in case they bundle e.g., different versions of Qt.

2) does it allow build-one-deploy-on-all(-conforming)-Linux-OSes

Yes. Plus you (as an application author) can decide which systems you are targeting. Krita, Subsurface, and Scribus are currently targeting CentOS 6 and newer with their AppImages.

3) is it trivial to make flatpacks (tooling, tooling, tooling)

For AppImage, the main work is to compile a binary on an "old enough" (in the above example: CentOS 6) base system. Once you have the binaries for a simple app, then it is trivial to bundle them as an AppImage (a bash script that uses some functions from a sourced script). See an example here: https://github.com/probonopd/AppImages/blob/master/recipes/wxhexeditor/Recipe

For a more complex app like KDevelop which uses plugins and calls other apps a bit more work is needed, but again a bash script will do.

4) is it trivial to install and manage flatpacks, both for the single user case and the managed deployment case'

Unlike Snap Packages and Flatpak, AppImage has spfcifically been designed so that no special support from the base system is required (apart from FUSE being available, which it almost always is). The user downloads the AppImage, sets the executable bit, and can run the application. When the AppImage is executed, it loop-mounts itself using FUSE and executes the payload app. This works today - try it on your favorite desktop distribution. For some users, setting the executable bit is extra hassle; optional desktop integration (mime type association) can eliminate the need for this step.

5) does its sandboxing actually work

I am aware of at least 2 different sandboxes that can run AppImages, namely Bubblewrap (the same sandbox that powers Flatpak) and Firejail. What I can say is that they "work" in the sense that I can use them to prevent an app from doing rm -rf $HOME. I don't know whether they are really bulletproof vs. malicious attackers, and I would not run applications from entirely unknown or untrusted sources no matter what promises the sandbox makes. I do trust krita.org as a software source though.

6) how many Linux OSes support it as a first-class citizen (not a weekend-drive-by-hack-to-get-it-working, nor a downstream-maintained-solution)

AppImages are known to work on most if not all common desktop distributions. Again, they are specifically designed not to need special support from the base system (altough such support may optionally be provided, e.g., to achieve sandboxing, closer desktop integration etc.).

Then on top of that there needs to be a distribution mechanism that is sensible, e.g.:

1) has the concept of publisher identity

I think that AppImage has the stongest concept of publisher identity among all solutions being discussed, because users can download AppImages from the upstream project download pages. It is best practice to sign The AppImages with GPG. A downloader/updater could be written that would verify the signature with a public key on the upstream application download page automatically.

2) provides a single entry point for delivery to the distribution mechanism (or "app store" if you prefer); that may still end up going to/through a distributed system, but having a single point of delivery is critical

AppStream provides a tag for bundles, which can be used to make AppImages discoverable by software centers like GNOME Software and KDE Discover. An increasing number of upstream projects already provide AppStream data which is the basis for distributions' metadata collections; so it should be easy for those projects to get the AppImage information in. Plus, having a download on the project's download page is essential, as downloading something from the application author's website is still the dominant model on desktop platforms that have actual market share, despite all the efforts to introduce App Stores.

3) provides mechanism to monetize and get engagement statistics (e.g. download counts broken down by various criterion)

Since upstream projects can host their own AppImages, they can track downloads in any way they choose to.

In summary, AppImage is a lightweigt transport mechanism and set of conventions for bundling software that empower usptream application authors to do what they do for the other two desktop platforms - provide binary downloads directly to their end users and have full control over the end-to-end experience.
Add a comment...

Aaron Seigo

Shared publicly  - 
 
Data on the edge... (something something aerosmith) 
13
Jens Reuterberg's profile photo
 
+Aaron Seigo​ we need to get you a new set of pop cultural references ;) that song is 23 years old. It's old enough to drink in the US. 
Add a comment...

Aaron Seigo

Shared publicly  - 
 
So pretty, so tasty.
 
This picture shows you the setup for our Zürich taster, at the Fork & Bottle. Should you also be interested in Beer, Food, Kolab, IBM and/or Red Hat on Power8, get your (free) tickets now! @ https://taster.kolabsystems.com
This picture shows you the setup for our Zürich taster, at the Fork & Bottle. Should you also be interested in Beer, Food, Kolab, IBM and/or Red Hat on Power8, get your (free) tickets now! @
View original post
5
Add a comment...

Aaron Seigo

Shared publicly  - 
 
Swag.
28
1
Ivan Čukić's profile photo
 
I'm drooling over the black one :)_. . .
Add a comment...
People
Collections Aaron is following
Links
Contributor to
Work
Occupation
Create technology that embodies and spreads freedom
Employment
  • Kolab Systems
    present
Basic Information
Gender
Male