Among a variety of deliberations concerning the security and transparency of a little Kolab thing running anywhere — at home, rented space or hybrid cloud — this post is about the transparency of the hardware layer, and our ongoing efforts to make that so.
We have said what, why and how on LWN, at events like FOSDEM (with a supplemental interview), at FSFE Summits, various other occasions, and perhaps your next opportunity to get acquainted with the message is at the OpenPOWER Summit in Barcelona — when I say “we”, I mean one of our most widely respected and prominent people, Georg Greve.
Firstly, it’s a good little challenge, that many of our respectable peers have already gone over, and solved. Such include IBM, Red Hat, and some of the best Fedora people (I highlight just one). It’s easy for me to state “challenge accepted”.
For an application suite like Kolab Groupware, consisting of many individual components, we play in the realm of customer demands on a platform that raises portability issues like something signed vs. unsigned, something specific to the generation of Linux distribution that is the target, something specific about the CPU architecture left, right and center, that are very interesting — technically speaking.
Some of the known problems in porting an otherwise superior application suite to a previously undervalued CPU architecture no longer exist — once the bug-fixes and architecture-specific optimizations have landed in upstream projects, involving among others, low-level projects like GCC and Boost.
However, customer demand will fall in to a stable, supported, long-term solution space. This is either already Red Hat Enterprise Linux, or you’re going to want to migrate to it. We’re not going to be able to sell a solution as business-critical as email and collaboration on top of Fedora 26 though (unless I have that pitch).
That being said, the current version of RHT‘s flagship product version does not yet have these fixes and enhancements. Arguably, RHT’s flagship product is Fedora 26 (at the time of this writing). Hopefully, Kolab Systems is going to come to the rescue. Hopefully, we’re in time for RHEL 7.6 planning, or can get ahead of RHEL 8 planning.
We’re going to be entertaining benchmarking our product, the Kolab Groupware solution, on Power 8, at the largest facility in the world. We’ll use what RHT has so far chosen to put to market, and what is also available. We’ll gather some data, and distil some graphs.
It’ll yield results, and it’ll be fun.
kanarip 
3 thoughts on “Kolab for Open Power”
Comments are closed.