Profile

Cover photo
Aaron Seigo
Works at Kolab Systems
6,148 followers|6,209,215 views
AboutPostsPhotosYouTube

Stream

Aaron Seigo

Shared publicly  - 
 
Kolab Now gets a Beta program where you can try features out before they are put into production rotation! This has been in internal testing / private beta for probably a good 4 months by now, so nice to finally see it go public. Feedback via the Kolab Hub web forums, and regular updates on changes on the Beta page itself.
Welcome to the Kolab Now Beta programme. Are you a Kolab Now customer? Then you have the opportunity to access our Kolab Beta programme right now! Features in the Kolab Now Beta programme include software, applications, and services that are still in testing but which we want to make available ...
8
Add a comment...

Aaron Seigo

Shared publicly  - 
 
Seems people are finding out that Kube, even in its current pre-alpha form, and understanding the goals. One insight from the article that neatly captures why something new is needed to move forward: "Let’s face it: there’s little innovation happening in this field not because there’s no need but because change can quickly become costly when it comes to personal information management tools."

This is a polite way of recognizing the immense technical debt and resulting inertia inherent to current software in this area that holds us back from even maintaining stasis, let alone push forward.
19
3
Ivan Čukić's profile photoDaniel Nicoletti's profile photo
2 comments
 
That's exactly the reason I tried to launch Litteras but not being baked by an organization often leads to failure, tho I'm not done yet with that.
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.
30
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...
Have him in circles
6,148 people
Matthias Welwarsky's profile photo
Syvolc Syvolc's profile photo
Torrie Fischer's profile photo
Alfred Fickensher III's profile photo
Harry Buck  Neu-und Betonbau S.L's profile photo
Zain us Sami Ahmed Ansari's profile photo
Andy Carlson's profile photo
Fabio “Pixel” Colinelli's profile photo
Romain d'Alverny's profile photo

Aaron Seigo

Shared publicly  - 
 
The danger of proprietary web services writ large. In this case #OpenStreetMap  ftw ... hopefully they can figure something out with them.
If you were set to plan your weekend activities using the GNOME Maps application, you'll need to change course.
24
7
Andreas Nilsson's profile photoMarkus S.'s profile photoThiago Macieira's profile photoChristoph Haag's profile photo
13 comments
 
Oh nice, someone in the comments to the omgubuntu article mentioned QLandkarteGT. The newer version is qmapshack and it does what I want: https://i.imgur.com/zgtRYHu.png
Sadly it doesn't draw the track segments like the other map applications do.
Same track segments in marble: https://i.imgur.com/XYvRmWA.png
sigh
Add a comment...

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.
7
Vedran Rodic's profile photo
 
Very nice, good work Timotheus :)
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...
People
Have him in circles
6,148 people
Matthias Welwarsky's profile photo
Syvolc Syvolc's profile photo
Torrie Fischer's profile photo
Alfred Fickensher III's profile photo
Harry Buck  Neu-und Betonbau S.L's profile photo
Zain us Sami Ahmed Ansari's profile photo
Andy Carlson's profile photo
Fabio “Pixel” Colinelli's profile photo
Romain d'Alverny's profile photo
Collections Aaron is following
Links
Contributor to
Work
Occupation
Create technology that embodies and spreads freedom
Employment
  • Kolab Systems
    present
Basic Information
Gender
Male