I tweeted about a blog post which I published on opensuse.mu, explaining how I configured the GNOME desktop theme Yaru (by the Ubuntu community) on my openSUSE Tumbleweed machine. The tweet got a lot of reaction, not just for the blog post or cool Yaru theme but also for the nice wallpaper showing penguins using a computer.
Ever since Red Hat announced that they are changing the development model of CentOS and making it an upstream project rather than downstream, it left many CentOS users frowning. No matter what argument brought forward, CentOS users, especially running production machines, relied on the stability of an enterprise-grade Linux distribution. Compiled from RHEL sources, CentOS offered such stability that it powered many web servers and enjoyed a massive 20% share of the top 500 supercomputers of the world.
Some time back, Red Hat made another annoucement, about new Red Hat Enterprise Linux programs. Under the new program RHEL can be used in production for up to 16 systems (which Red Hat considers a small workload) at zero license costs. Also, Red Hat is making it easier for a customer's development team to join the program and reap the benefits.
What risks lie ahead for an enterprise if Red Hat changes or cancels the program in the future? 🤔
On the other hand, since 2018, SUSE has worked closely with the openSUSE community to bring the Leap distribution closer to SUSE Enterprise Linux (SLE), such that now Leap and SLE are binary compatible.
openSUSE currently offers two distinct distributions, Leap & Tumbleweed.
Tumbleweed is a rolling distribution constantly getting updated software whereas Leap has planned releases that sync with SUSE Linux Enterprise and its Service Packs.
The above image depicts how openSUSE & SUSE Linux Enterprise are developed together. Factory is the rolling development codebase for both openSUSE & SLE. In the pipeline we can see that Leap & SLE are synced and both receive software packages from the same source; that is why they are both binary compatible.
Red Hat allows its clients to use RHEL for free on up to 16 machines. On the other hand, openSUSE Leap boasts binary compatibility with SUSE Linux Enterprise and comes without any restriction on usage.
I am using the SOGo Groupware. I noticed that certain emojis in the event title would prevent calendar apps from synchronizing using the CalDAV protocol. I checked the logs but could not find much. I had my doubts about what could be causing it. Then, this bug report confirmed that I should investigate on the UTF-8 encoding support.
I checked the database character set.
MariaDB [sogo]> select @@character_set_database;
| @@character_set_database |
| utf8 |
1 row in set (0.001 sec)
The database name is sogo and we are using MariaDB.
I found the character set to be utf8, to my surprise. I had to dig a little further to understand what was wrong with it.
It turned out that the MariaDB utf8 character set supports a maximum of there bytes per character. Therefore, emojis being four bytes long weren't being inserted into the database. Consequently, that breaks the calendar synchronization. The solution was to use the utf8mb4 character set which supports four bytes per multi-byte character.
I altered the database character set and collation.
MariaDB [sogo]> ALTER DATABASE sogo CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
I also applied it to every table in the database, e.g:
MariaDB [sogo]> ALTER TABLE sogo_store CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Afterwards, I could create events using an emoji in the title. The event would synchronize across my calendar apps but the emoji would not show. Instead, it would appear as four questions marks (????) instead.
A little bit of further digging and I found that SOGo needs to be made aware of the full unicode support. It should be specified in the /etc/sogo/sogo.conf configuration file.
MySQL4Encoding = "utf8mb4";
Restart the SOGo service. Emojis should be then accepted in the event titles.
I can now put my recurrent coffee breaks in the calendar. ☕